Non-Regression Tests mit QF-Test

Bezüglich wie weit wir bei der Integrierung von QF-Test in unsere Prozesse kamen: Unsere Non-Regression-Tests wurden fast vollständig unter QF-Test implementiert. Sie laufen ungefähr drei Stunden und das spart mir so Unmengen an Zeit.

Hinsichtlich des ROI gibt es mehrere Aspekte: Zeitersparnis: Ich brauchte einen ganzen Tag um die Non-Regression-Tests zum Laufen zu Bringen. Das wurde jetzt auf drei Stunden reduziert. Der große Unterschied ist, dass ich jetzt andere Dinge in der gesparten Zeit erledigen kann! Der direkte Nutzen ist, dass ich jetzt manche Tests auf verschiedenen Versionen unseres Systems parallel laufen lassen kann, was vorher unmöglich war (aufgrund von zu wenig Zeit).

Ein weiterer weniger offensichtlicher Punkt ist, dass es die Kommunikation mit den Software Entwicklern verbessert wird. Es gibt keine „Gefühle“ oder persönlichen Beurteilungen in der Bewertung der Ergebnisse. Das war davor der Fall und hing jeweils davon ab, wer die Tests durchführte. Dadurch waren die Ergebnisse geringfügig verschieden. Tatsächlich ist das – wie bereits erwähnt – ein Echtzeitsystem und abhängig davon, welche Aktion man zu welcher Zeit tat, das Verhalten des Systems muss nicht immer dasselbe gewesen sein. Nachdem die Tests automatisiert wurden, wurde dieses Zeitproblem behoben (oder verringert).

Die Software Entwicklungsabteilung kann nicht mehr sagen, dass man einen Fehler gemacht oder das System während der Tests nicht richtig verwendet hat (und einen bitten diese zu wiederholen und daher auch Zeit gewinnen…) Es werden immer dieselben Tests reproduziert und wenn die Ergebnisse voneinander abweichen, geschieht das nur, weil sich das System verändert hat. Manchmal gute Veränderungen (verbesserte Funktionalität, Bugfixes, schnellere Antwortzeiten…) aber die Automatisierung greift das heraus, was der springende Punkt beim Non-Regression-Testing ist: Änderungen erkennen.

Dennoch gibt es ein paar Nachteile von automatisierten Tests: Erstens müssen die Tests gewartet werden! Die Suite entwickelt sich weiter und die Komponenten müssten aktualisiert werden! Neue Funktionalitäten werden auch eingeführt und diese müssen in die Testläufe aufgenommen werden. Dann sind diese Tests nicht perfekt: Sie sind nicht unerschütterlich und manchmal kann eine Sache einen Dominoeffekt auslösen und somit bleibt das komplette Ergebnis aus. Wenn man während des Tests nicht vor dem Rechner sitzt, wird man das nicht sehen und wahrscheinlich drei Stunden verlieren. Jedes Mal, wenn das passiert, fixe ich den Test und füge mehr checks und Schutzmechanismen hinzu. Aber hin und wieder muss ich den Test neu aufsetzen.

Dann wird QF-Test nur die Dinge erkennen, die man ihm beigebracht hat zu erkennen. Im Vergleich dazu würde ein menschlicher Tester unregelmäßiges Verhalten des Systems erkennen. Es ist wieder einmal Echtzeit und mit viel Algorithmus. Nicht alles ist vorhersehbar. Das bedeutet, dass bestimmte Fehler von QF-Test nicht erkannt werden könnten (oder genauer gesagt die Testsuite, die ich gemacht habe). Das wird normalerweise dann etwas später in der Testkette erkannt (IBB, V&V Testing ...), aber dann kostet die Korrektur etwas mehr. Jedes Mal, wenn das passiert, versuche ich die Testsuite zu verbessern, was etwas Zeit kostet.

Sie werden sich sicherlich wundern, aber es gibt letzten Endes schon einen reellen Gewinn bei automatisierten Tests :-\.

Meine Zusammenfassung wäre immer noch ja, aber der ROI ist nicht bezüglich Zeit. Die Zeit, die sie nicht mehr ins Testen investieren, muss für andere Themen verwendet werden: Wartung, Verbesserungen, Analyse von dem, was man testen möchte und wie man es testen möchte (Das ist nicht immer so einfach, wie man denken würde.) Der Nutzen, den man davon hat, ist Qualität und Konsistenz.

Denis Gauthier Software Integration, Thales Australia, Melbourne