Finger weg vom roten Knopf

Bild: Flickr/Włodi - CC BY-SA 2.0

Zu den verhängnisvollsten Missverständnissen im QA-Bereich gehört die Annahme, dass es möglich wäre automatisierte Testfälle "aufzunehmen". Die Aussicht klingt aber auch zu verheißend: man drückt auf einen roten Aufnahmeknopf und führt z.B. auf einer Website eine Aktion durch. Diese wird von einem Computerprogramm aufgezeichnet und kann jetzt beliebig oft "abgespielt" werden, wodurch sehr schnell eine Testsuite mit hoher Abdeckung entsteht - und für deren Erstellung braucht man nicht einmal ein besonderes IT-Verständnis. Verschiedene Test-Tools verfügen sogar über eine solche Aufnahmefunktion, etwa HP Unified Functional Testing oder Selenium IDE. Ich durfte auch bereits miterleben wie versucht wurde darauf eine Teststrategie aufzubauen. Mit verheerendem Ergebnis. Und für dieses Scheitern gibt es auch Gründe, von denen ich hier einige aufführen möchte¹.

Dynamische und verschlüsselte IDs, Klassen, etc.
Auf vielen Internetseiten werden die IDs von Elementen nicht fest vergeben sondern bei jedem Aufruf dynamisch generiert. Der Compose-Button mit dem man bei Gmail Emails erstellt hat zum Beispiel eben nicht die ID id=composebutton sondern je nach Aufruf eine zufällige wie id=:gz, id=:dc oder id=:dn. Wenn dieser Button jetzt während der Testaufzeichnung mit einer dieser IDs identifiziert wird, beim nächsten Aufruf aber eine andere generiert wird, dann schlägt der Test natürlich fehl - obwohl das Element da ist und funktioniert wird es nicht erkannt. Der gleiche Effekt tritt auf wenn der HTML-Code verschlüsselt ist, was etwa bei Banken ein Sicherheitsstandard ist.

Verifizierungsschritte
Im Grunde können nur zwei Arten von Aktionen aufgenommen werden, nämlich Mouseclicks und Tastatureingaben. Für einen brauchbaren Testfall sind die aber nicht ausreichend, es fehlen die Verifizierungsschritte. Wenn beispielsweise eine Datei erstellt und abgespeichert wird muss auch überprüft werden ob sie danach tatsächlich vorhanden ist. Bei manueller Durchführung muss man nach dem Speichern nur nachsehen ob sie angezeigt wird, da das aber lediglich mit dem Auge geschieht kann das Testprogramm das nicht nachvollziehen. Stattdessen müssen Befehle wie |ensure|do|verifyElementPresent|on|id=product| (Selenium IDE/Xebium) oder Browser("x").Page("y").WebEdit("z").Waitproperty "visible", True, 5000 (HP UFT) separat eingegeben werden. Von Hand.

Parametrisierung
Um einen wirklichen Nutzen aus automatisierten Tests zu ziehen müssen diese auch in verschiedenen Kontexten wiederverwertbar sein, etwa in verschiedenen Entwicklungsumgebungen, die über unterschiedliche URLs aufgerufen werden. Im Fall von HP UFT müsste dazu zunächst über den Befehl Dictionary.Add "LoginURL", Environment.value("LoginURL") der URL-Parameter in die Ausführungsinstanz geladen und dann mit SystemUtil.Run "C:\Programme\Mozilla Firefox\firefox.exe", Dictionary.Item("LoginURL"),"","",3 in einen Ausführungsschritt eingesetzt werden. Auch das kommt nicht über die Aufnahmefunktion in die Testskripte sondern nur manuell.

Aber warum?
Diese kurze Liste hier ist natürlich nicht erschöpfend und könnte sicher erweitert werden, aber um Vollständigkeit soll es hier gar nicht gehen. Interessanter wäre die Frage warum trotz der offensichtlichen Unzulänglichkeit und Unmöglichkeit noch immer das Phantom des reinen "Testfälle Aufnehmens" durch manche Projekte geistert. Ist manchen Managern und Testern der Unsinn dieses Vorhabens nicht bewusst? Die wahrscheinliche und erschreckende Antwort ist: Leider nein, dafür fehlt ihnen häufig die IT-Affinität. Das zu besprechen würde jetzt aber zu weit führen.


¹Genannt werden im Folgenden die Gründe gegen die "Aufnahme-Illusion". Dass Oberflächentests alleine keine ausreichende Testabdeckung ergeben ist nochmal ein gesondertes Thema.