Häufige Fragen


Wie kann ReTest automatisch Fehler finden?

ReTest kann automatisch Fehler finden die zu Abstürzen oder zum "Hängen bleiben" (Programm reagiert nicht mehr) der Software führen. Wenn ein solcher Fehler gefunden wird, so wird automatisch ein Test erzeugt, der den Fehler reproduziert. Dieser Test ist sehr hilfreich um den Fehler zu diagnostizieren und um sicherzustellen, dass er behoben wurde.
Darüber hinaus kann ReTest automatisch Änderungen detektieren. Ob eine Änderung einen Fehler darstellt, muss von einem Menschen entschieden werden (Orakel-Problem).

Wie kann ReTest automatisch fachliche Fehler finden?

Gar nicht.

Ein Fehler liegt immer im Auge des Betrachters. Daher auch der Ausspruch: It's not a bug, it's a feature. Um einen fachlichen Fehler automatisch zu finden, müssen immer zwei Dinge miteinander verglichen werden (z.B. eine Spezifikation und eine Implementierung). Ein Fehler ist dann ein Diskrepanz aus diesem Vergleich. Eine Methode die so etwas ermöglicht ist z.B. Modellbasiertes Testen oder Model Checking.

ReTest ist nicht modellbasiert. ReTest vergleicht das Programm mit sich selbst, bzw. mit dem aufgezeichneten Verhalten einer früheren Version des Programmes. Damit zeigt ReTest Änderungen am Programmverhalten auf. Ob diese Änderungen gewollt sind oder nicht, muss trotzdem ein Mensch entscheiden.

Brauche ich mit ReTest wirklich gar nicht mehr zu testen?

ReTest zeigt Änderungen am Programmverhalten auf. Neues, bisher unbekanntes Verhalten kann damit nicht getestet werden. D.h. während der Implementierung sollte vom Entwickler nach wie vor sichergestellt werden, dass seine Implementierung auch das gewünschte Resultat hat. Und entsprechend dem Vier-Augen-Prinzip sollte zusätzlich eine Qualitätssicherung stattfinden. Aber jede Änderung am Programmcode kann bestehende und bereits getestete Funktionalität beeinträchtigen. Dass heißt je größer das Programm und je kleiner die Änderung, desto mehr "unnötiger" Testaufwand — den ReTest einsparen kann.

ReTest findet keine fachlichen Inkonsistenzen. Das bedeutet, dass wenn eine Änderung an einer Stelle im Code viele Änderungen im Programmverhalten nach sich zieht, so stellt ReTest nicht sicher, dass sich alle relevanten Stellen im Programmverhalten auch tatsächlich geändert haben. Eine manuelle Überprüfung der Ergebnisse von ReTest sollte in solchen Fällen immer stattfinden. Diese kann mit Hilfe der aufbereiteten Ergebnisse von ReTest jedoch wesentlich effizienter erfolgen.

Automatische Tests gibt es doch haufenweise. Worin unterscheidet sich ReTest von anderen Test-Tools oder Test-Frameworks?

Existierende Werkzeuge und Frameworks können manuell erstellte Tests automatisch ablaufen lassen. Diese Werkzeuge sind sehr hilfreich und eine große Erleichterung bei der Softwareentwicklung. Trotzdem entsteht beim Erstellen dieser Tests (entweder durch Aufzeichnen manueller Interaktion oder beim Implementieren der Test-Skripte) manueller Aufwand, und die Praxis zeigt deutlich, dass diese Tests deshalb häufig unvollständig erstellt und suboptimal gepflegt werden. Aus diesem Grund werden 85% der Regressionstests von Software manuell ausgeführt.

ReTest dagegen erzeugt die Tests vollautomatisch, gänzlich ohne manuellen Aufwand. Dadurch kann ein Großteil der Kosten eingespart werden. Wie bei allen automatisierten Tests erfolgt zudem die Qualitätssicherung kontinuierlich, wodurch im Gegensatz zum manuellen Testen Zeitaufwand und Risiko gesenkt werden. Die automatisch erzeugten Tests sind oft vollständiger als manuell erzeugte und erhöhen damit die Qualität der Software.

Wie soll zufälliges Herumklicken irgendwelche sinnvollen Tests erzeugen?

Die erzeugten Tests stellen kein fachlich sinnvolles Verhalten dar. Diese Tests sind nicht dazu gedacht von Menschen gelesen und analysiert zu werden. Denn dafür wurden die Tests nicht optimiert. Die erzeugten Tests wurden optimiert um möglichst viele Teile des Programmcodes auszuführen (also um eine hohe Testabdeckung zu erreichen).

Das ist aber auch die Stärke dieser Tests gegenüber einem menschlichen Tester. Den der menschliche Tester arbeitet in der Regel nur sein vorgegebenes Testskript ab, ungeachtet der Tatsache welche Ausnahmen der Programmcode darüber hinaus noch abdeckt (oder abzudecken versucht). Unvorhergesehenes (und deshalb ungetestetes) Nutzerverhalten kann deshalb viele Fehler auslösen, die in der Qualitätssicherung nicht entdeckt wurden.

Jeder Mensch macht Fehler und in der Gesamtheit wirken alle Bedienungsfehler aller Nutzer tatsächlich wie zufälliges Herumklicken.

Wie soll zufälliges Herumklicken die "tiefen der Anwendung" z.B. bei komplexen Businessprozessen testen?

Zufallsbasierte Tests dienen nur als Ausgangspunkt. Diese Tests werden mit Hilfe eines Genetischen Algorithmus weiter verbessert um so viele Teile der Anwendung / des Codes wie möglich abzudecken. Diese Genetischen Algorithmen funktionieren bei uns in der Praxis sehr gut. Im Beispiel der Türme von Hanoi gibt es mehr als 263 Möglichkeiten (das sind 9.223.372.036.854.775.808 Möglichkeiten) von denen genau 1 Möglichkeit ein optimales Ergebnis erzeugt. Wenn man 1.000 Möglichkeiten pro Sekunde probiert, dauert es noch 292.471.208 Jahre alle zu probieren. Ein rein zufälliger Ansatz findet im Schnitt nach der Hälfte der Zeit die Lösung (nach 130 Mio. Jahren). Ein Genetischer Algorithmus findet die Lösung nach knapp 65.000 Versuchen, also im Vergleich nach 65 Sekunden...

Wenn meine Eingabemaske z.B. 5 Eingabefelder mit je 5 möglichen Werten hat, so sind das 55 = 3.125 Möglichkeiten. Wie testet ReTest so etwas?

Dieses Problem wird State Space Explosion genannt. Dieses Problem haben auch insbesondere manuelle Tester oder manuell erstellte automatisierte Tests. Doch im Gegensatz zu manuellen Testern hat ReTest zwei Vorteile: ReTest kann einzelne Tests schneller ausführen und durch die Analyse der Businesslogik zur Laufzeit kann ReTest die Testsequenzen z.B. auf eine möglichst hohe Abdeckung hin optimieren. Im Gegensatz zum manuellen Tester weiß ReTest, ob die Parameter überhaupt voneinander abhängig sind, oder ob sie vielleicht sogar im Programm unabhängig voneinander verarbeitet werden. Und durch die Kenntnis welche Fälle in der Businesslogik unterschieden werden, und welche Fälle davon bereits getestet wurden, kann ReTest wesentlich effizienter Testen, als dies ein manueller Tester üblicherweise könnte.

Welche Testmetrik verwendet ReTest um die Tests zu optimieren?

ReTest verwendet einen generischen Ansatz, und kann die Tests für eine beliebige Metrik optimieren. Empfehlenswert sind Abdeckungsmetriken (z.B. Anweisungs-, Zweig- oder Pfad-Abdeckung), welche auch häufig verwendet werden. Alternativen dazu ist z.B. Paarweises Testen. Prinzipiell kann ReTest die generierten Tests für jede operationalisierbare Metrik optimieren.

Wir haben schon automatisierte Tests. Warum sollten wir ReTest verwenden?

Beim Erstellen dieser Tests (entweder durch Aufzeichnen manueller Interaktion oder beim Implementieren der Test-Skripte) entsteht manueller Aufwand, und die Praxis zeigt deutlich, dass diese Tests deshalb häufig unvollständig erstellt und suboptimal gepflegt werden. Erlösen Sie Ihre Entwickler von der Bürde die Tests manuell zu pflegen bzw. beruhigen Sie deren Gewissen, weil sie es sowieso nicht im erforderlichen Maße getan haben. Ihre Entwickler werden Ihre Entscheidung lieben!

Zudem sind automatisch erzeugte Tests oft vollständiger als manuell erzeugte und finden damit mehr Fehler und erhöhen die Qualität der Software.

Wir haben/nutzen ein Test-Center. Warum sollten wir ReTest verwenden?

ReTest birgt viele Vorteile gegenüber manuellem Testen: Sie sparen Zeit und Kosten, senken das Projektrisiko und den Stress der Entwickler vor Abgabeterminen, und erhöhen die Qualität der Tests und damit der Software. Warum nutzen Sie nochmal ein Test-Center?

Wir haben bereits Unittests. Warum sollten wir ReTest verwenden?

Unittests arbeiten auf der Ebene einzelner Units. Auf der Systemebene können durch Integration und Inkompatibilitäten trotzdem Fehler entstehen. Darüber hinaus bedeutet auch die Pflege der Unittests manuellen Aufwand.

Wir nutzen Scrum/TDD/Agile Testing. Warum sollten wir ReTest verwenden?

Bei Scrum werden idealerweise die Tests vor der Funktionalität implementiert (Test Driven Development / TDD). Aber zum einen sind auch Entwickler nur Menschen und zum anderen stellen diese Tests nur eine bestimmte Funktionalität sicher und sind keinesfalls vollständig. Deshalb haben auch Projekte mit Scrum oder anderen agilen Methoden in der Regel großen Bedarf an zusätzlichen Regressionstests. Fragen Sie Ihre Entwickler!

Für welche Sprachen/Plattformen/Systeme ist ReTest verfügbar?

ReTest befindet sich derzeit in der Beta-Phase und ist momentan nur für Java-basierte Swing-Anwendungen implementiert. Dank des modularen Aufbaus und der universalen Anwendbarkeit des zugrundeliegenden Prinzips, wollen wir ReTest zukünftig für viele weitere Sprachen und Plattformen anbieten. Falls Sie Interesse haben, dann registrieren Sie sich:

Funktioniert ReTest für alle Programme?

ReTest analysiert die Benutzeroberfläche um Standard-Benutzerinteraktionselemente (Buttons, Menüs, Textfelder, Tabellen, ...) zu finden. Mit diesen Elementen führt es eine zufällige Benutzerinteraktion durch. Damit eignet es sich nicht für Programme mit wenigen Standard-Elementen (z.B. Computerspielen) oder Programmen bei denen zufällige Benutzerinteraktionen wenig Sinn machen (z.B. Quellcode-Editoren). Aber selbst bei diesen beiden Extrembeispielen gibt es viele Möglichkeiten um ReTest dennoch zu verwenden. Bevor Sie entscheiden, dass ReTest für Ihr Programm nicht verwendbar ist, sprechen Sie uns bitte unverbindlich an!

Was muss ich tun, wenn ich ReTest nutzen will?

Wenn Sie Interesse daran haben ReTest zu nutzen, dann melden Sie sich bei uns!

Wie sieht das Ergebnis von ReTest aus?

Derzeit erzeugt ReTest einfach automatische Tests, die wie gewohnt z.B. in den nächtlichen Build eingepflegt werden können. Für die Weiterentwicklung von ReTest denken wir über speziellere Formate nach.

Was passiert wenn ReTest einen Fehler findet?

Wenn ReTest einen Fehler findet, so erzeugt es einen minimalen Test um den Fehler zu reproduzieren. Handelt es sich um eine Änderung im Programmverhalten (also nicht um einen Crash oder einen Hangup), so muss manuell entschieden werden ob die Änderung beabsichtigt war oder nicht.

Was passiert wenn ReTest einen Fehler nicht findet?

Das Gleiche was auch passiert wenn ein manueller Tester einen Fehler nicht findet ... er endet im Produktivsystem. Die einzige Möglichkeit Fehlerfreiheit zu garantieren ist ein logischer Beweis der Fehlerfreiheit in Form einer Verifikation. Diese ist so aufwändig, dass sie nur bei extrem sicherheitskritischen Systemen (Militär, Luft-/Raumfahrt, Medizin) angewendet wird. Zudem stellt eine Verifikation nur sicher, dass ein Programm konform zu einer Spezifikation ist. Durch eine fehlerhafte Spezifikation können trotzdem Fehler im Programm verbleiben.

Welche Alternativen gibt es zu ReTest?

Bisher gibt es kein vergleichbares kommerzielles Programm. Um reines Monkey-Testing zu realisieren gibt es für Android UI/Application Exerciser Monkey, für Web-Applikationen Gremlins.js, und für Services einer SOA gibt es den NetFlix Chaos Monkey. Alle diese Alternativen implementieren jedoch reines Monkey-Testing, dass heißt reines Testen auf Robustheit. Andere Alternativen sind manuelles Testen z.B. via Crowd Testing oder herkömmliche Testautomatisierung. Falls Sie eine Alternative kennen, die uns bisher entgangen ist, so würden wir uns sehr freuen, wenn Sie uns darauf hinweisen!

Das hört sich alles unglaublich an. Könnt Ihr beweisen, dass das funktioniert?

Bei ReTest handelt es sich um einen Prototypen aus der Forschung in der Beta-Phase. Mehreren Publikationen beweisen, dass der Ansatz auf den bisherigen getesteten Programmen gut funktioniert. Wir sind momentan dabei diese Anzahl an Programmen zu vergrößern. Wenn Sie Interesse daran haben Beta-Partner zu werden, dann sprechen Sie uns an!

Kann man über die Benutzeroberfläche die komplette Anwendung testen?

Das hängt von der Anwendung ab. In den meisten Programmen gibt es Toten oder Unerreichbaren Code. Dieser kann natürlich nicht über die Benutzeroberfläche getestet werden. Da Fehler in diesem Code ebenfalls tot oder unerreichbar sind, ist dieser Umstand allerdings unerheblich und verschlechtert lediglich die Statistik. Zusätzlich gibt es in den meisten Anwendungen auch noch Schnittstellen zu anderen Programmen oder zur Hardware (wie z.B. eine "Drucken"-Funktion). Auch dieser Code kann meist nicht rein über die Benutzeroberfläche getestet werden. Bisher erreicht ReTest durchschnittlich eine Testabdeckung von 50-60% des Quellcodes, was in etwa der Abdeckung durch menschliche Tester entspricht.

Das Prinzip klingt einfach, wieso gibt es das noch nicht?

Dazu vielleicht ein einfacher Vergleich. Man kann das Prinzip der Glühbirne in einem Satz erklären: "Eine Glühbirne macht Licht, indem mittels Strom ein Draht so heiß gemacht wird, dass er glüht." Trotzdem hat es von den ersten Versuchen bis zur Serienreife 80 Jahre gedauert und Thomas Edison allein hat 2000 Versuche benötigt, um eine funktionierende Glühlampe zu konstruieren.
Ähnlich ist es bei ReTest. Die grundsätzlichen Ideen mit denen ReTest funktioniert (Monkey-Testing und Genetische Algorithmen) sind teilweise schon 30 Jahre oder älter. Trotzdem hat es bisher noch niemand geschafft, einen Prototypen zu bauen, der in endlicher Zeit sinnvolle Tests generiert. Auch wir haben dazu 4 Jahre intensive Forschung benötigt. Und damit sind wir nun weltweit die ersten und bisher einzigen.

Sucht ReTest Mitarbeiter?

ReTest ist ein wachsendes Unternehmen und immer auf der Suche nach guten Mitarbeitern. Mehr Infos dazu finden Sie unter Karriere. Nehmen Sie einfach Kontakt mit uns auf, wir freuen uns auf Sie!