Was sollten Sie nicht automatisieren?

Wenn wir automatisierte Tests schreiben, wollen wir mit möglichst geringen Kosten oder Zeitaufwand einen maximalen Mehrwert schaffen. Die Gesamtzahl der Testfälle, um zu überprüfen, ob ein großes, modernes, komplexes System fehlerfrei ist, ist nahezu unendlich. „Alles“ kann nicht automatisiert werden. In diesem Beitrag sehen wir uns genauer an, was nicht automatisiert werden kann/sollte und warum.

Wir müssen strategisch denken, um eine begrenzte Anzahl von Tests auszuwählen, die automatisiert werden sollen. Diese Tests sollten einen möglichst großen Teil des Systems abdecken, einfach zu implementieren, stabil und zuverlässig und kostengünstig zu ändern und zu warten sein.

Bei der Testautomatisierung geht es darum, Teile der Testarbeit zu rationalisieren, zumindest die Teile, die am besten geeignet sind. Daher gibt es einige Kategorien von Tests, die wir nicht automatisieren sollten.

Tests, die Intelligenz und Emotionen erfordern

Einem Computer fehlt es völlig an Intelligenz, Geschmack, Geschmack und Gefühl. Daher ist es nicht möglich, gute, automatisierte Tests zu erstellen, um Dinge wie die folgenden zu bewerten:

• Ist das Layout lehrreich?
• Ist die Benutzererfahrung angenehm?
• Ist die Verwendung der Anwendung ergonomisch?
• Ist die Verwendung des Systems leicht verständlich?

Ist die Benutzeroberfläche optisch ansprechend?

Verschwenden Sie keine Zeit und Energie damit, auch nur Teile dieser Aspekte zu überprüfen. Einem Computer fehlt die Fähigkeit, diese Aspekte zu bewerten. Die Tests werden komplex und unzuverlässig und können, selbst theoretisch, nur einen vernachlässigbaren Bruchteil dessen überprüfen, was wir wünschen.

Anwendungen, die noch nicht stabil sind
(zu früh im Lebenszyklus)

Tests, die über die grafische Benutzeroberfläche (GUI) mit der Anwendung interagieren, reagieren sehr empfindlich auf Änderungen. Scheinbar kleine Änderungen an der Benutzeroberfläche der Anwendung führen dazu, dass die Tests nicht mehr funktionieren. Daher ist es keine gute Idee, Tests für eine Anwendung zu automatisieren, die noch nicht stabil ist. Die Tatsache, dass sie nicht stabil ist, bedeutet, dass sie geändert, modifiziert oder repariert wird, was dazu führt, dass die Tests nicht mehr funktionieren.

Tests, die über die grafische Benutzeroberfläche mit der Anwendung interagieren, sind im Vergleich zu anderen Arten automatisierter Tests komplex, umfangreich, zeitaufwändig und schwer zu ändern. Daher ist es eine gute Idee, mit der Implementierung dieser Art von Tests zu warten, bis sich das System stabilisiert hat und keine störenden Änderungen mehr zu erwarten sind.

Anwendungen, die das Tool nur schwer unterstützt (API, GUI)

Manchmal stoßen wir auf Komponenten oder Teile eines Systems, für die sich automatisierte Tests nur sehr schwer implementieren lassen. Dies kann verschiedene Gründe haben. Ein Beispiel ist die Sicherheit, bei der es darum geht, Bots oder unerwünschte automatisierte Manipulationen zu vermeiden. Ein weiteres Beispiel sind proprietäre Komponenten, bei denen die Implementierungsdetails unbekannt oder geheim sind.

Die Implementierung kreativer (oft komplexer) Lösungen zur Umgehung des Problems ist auf lange Sicht normalerweise eine schlechte Idee. Die Tests werden unvorhersehbar und komplex. Verbringen Sie also nicht übermäßig viel Zeit damit, sich mit Tests in fast unmöglichen Situationen herumzuschlagen, in denen die Ergebnisse schlecht ausfallen werden.

Verbringen Sie stattdessen Zeit und Energie damit, automatisierte Tests zu implementieren, wo dies einfach und erfolgreich ist. Was Nutzen und Wert bietet, sind Tests, die schnell ausgeführt werden, zuverlässig, robust und einfach zu ändern und zu warten sind.

Testfälle, die manuell nicht gut gelaufen sind

Wenn wir Tests haben, die bei manueller Ausführung nicht gut gelaufen sind, bedeutet das, dass die Anwendung noch nicht wirklich stabil ist. Scheinbar kleine Änderungen an der Benutzeroberfläche der Anwendung führen dazu, dass die Tests nicht mehr funktionieren. Daher ist es keine gute Idee, automatische Tests über die grafische Benutzeroberfläche (GUI) für eine Anwendung durchzuführen, bei der die manuellen Tests nicht gut gelaufen sind.

Andererseits gilt dies nicht für automatisierte Tests über eine API (z. B. WebServices wie REST oder SOAP). Denn automatisierte Tests über API sind im Vergleich zu automatisierten Tests über GUI vergleichsweise trivial, kurz und schnell zu implementieren und leicht zu ändern.

Wenn wir das System früh im Entwicklungszyklus über API testen können, ist es eine gute Idee, auf dieser Ebene mit der Durchführung umfassender Tests zu beginnen. Wenn das System begonnen hat, sich zu stabilisieren und keine revolutionären Änderungen mehr zu erwarten sind, ist es sehr erfolgreich, eine kleinere Anzahl automatisierter Tests über die grafische Benutzeroberfläche der Anwendung hinzuzufügen.

Informationen zur Funktionsweise des Systems und Unterstützung für den Testautomatisierungsingenieur fehlen

Der erfolgreichste Weg besteht darin, die automatisierten Tests parallel zur Implementierung des Systems durchzuführen. Die automatisierten Tests sollten auf einem möglichst niedrigen Testautomatisierungsniveau (Geräteebene, API-Ebene, GUI-Ebene) erfolgen, um Defekte so nah wie möglich an der Quelle (wo sie auftreten) zu erkennen.

Die Testautomatisierung auf GUI-Ebene erfolgt relativ spät in der Entwicklungskette. Wir möchten, dass sich die Entwicklung des Systems stabilisiert hat und keine radikalen Änderungen oder Neugestaltungen erwartet werden. Dies liegt, wie oben erwähnt, an der Komplexität und Größe dieser Tests sowie an den Kosten und der Zeit für Änderungen und Wartung.

Es ist wichtig, dass diejenigen, die die automatisierten Tests schreiben, wissen, wie das System im Detail funktionieren soll. Wenn das Wissen fehlt und das Team, die Organisation oder jemand anderes diese Informationen nicht vermitteln kann, wird es sehr schwierig sein, aussagekräftige automatisierte Tests zu erstellen.