Wenn wir automatisierte Tests schreiben, wollen wir mit möglichst geringem Zeit- und Kostenaufwand einen maximalen Mehrwert erzielen. Die Gesamtzahl der Testfälle, mit denen überprüft werden kann, ob ein großes, modernes und komplexes System fehlerfrei ist, ist nahezu unbegrenzt. "Nicht alles" kann automatisiert werden. In diesem Beitrag werfen wir einen genaueren Blick darauf, was nicht automatisiert werden kann/sollte und warum.
Wir müssen strategisch denken und eine begrenzte Anzahl von Tests für die Automatisierung auswählen. Diese Tests sollten einen möglichst großen Teil des Systems abdecken, einfach zu implementieren, stabil und zuverlässig sein, Außerdem, die Tests sollen 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.
Einem Computer fehlt es völlig an Intelligenz, Geschmack und Gefühl. Daher ist es nicht möglich, gute und automatisierte Tests zu erstellen, um folgendes zu bewerten:
Verschwenden Sie keine Zeit und Energie darauf, 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 uns wünschen.
Tests, die mit der Anwendung über die grafische Benutzeroberfläche (GUI) 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 die Anwendung noch nicht stabil ist, bedeutet, dass sie geändert bzw. modifiziert wird oder Fehler bereinigt werden, 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 von automatisierten Tests komplex, umfangreich, zeitaufwändig und schwer zu ändern. Daher ist es ratsam, mit der Implementierung dieser Arten von Tests zu warten, bis sich das System stabilisiert hat und keine störenden Änderungen mehr zu erwarten sind.
Manchmal stoßen wir auf Komponenten oder Teile eines Systems, für die es sehr schwierig ist, automatisierte Tests zu implementieren. Das kann verschiedene Gründe haben. Ein Beispiel ist die Sicherheit, bei der es darum geht, Bots oder unerwünschte automatische Manipulationen zu verhindern. Ein weiteres Beispiel sind proprietäre Komponenten, deren Implementierungsdetails unbekannt oder geheim sind.
Die Implementierung kreativer (oft komplexer) Lösungen zur Umgehung des Problems ist in der Regel auf lange Sicht keine gute Idee. Die Tests werden unberechenbar und komplex. Verbringen Sie also nicht unverhältnismäßig viel Zeit damit, sich mit Tests in fast unmöglichen Situationen herumzuschlagen, bei denen die Ergebnisse schlecht sein werden.
Investieren Sie stattdessen Zeit und Energie in die Implementierung automatisierter Tests, die einfach und erfolgreich sind. Nützlich und wertvoll sind Tests, die schnell ausgeführt werden, zuverlässig und robust sind und sich leicht ändern und warten lassen.
Wenn wir Tests haben, die bei der manuellen 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 zu implementieren, 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 eine API sind im Vergleich zu automatisierten Tests über eine grafische Benutzeroberfläche trivial, kurz und schnell zu implementieren und leicht zu ändern.
Wenn wir das System schon früh im Entwicklungszyklus über die API testen können, ist es eine gute Idee, mit der Implementierung umfassender Tests auf dieser Ebene zu beginnen. Wenn sich das System stabilisiert hat und keine revolutionären Änderungen mehr zu erwarten sind, ist es sehr erfolgreich, mit einer kleineren Anzahl automatisierter Tests über die grafische Benutzeroberfläche der Anwendung zu ergänzen.
Der erfolgreichste Weg ist es, die automatisierten Tests parallel zur Implementierung des Systems durchzuführen. Die automatisierten Tests sollten auf einer möglichst niedrigen Testautomatisierungsebene durchgeführt werden (Geräteebene, API-Ebene, GUI-Ebene), um Fehler so nah wie möglich an der Quelle (wo sie auftreten) zu erkennen.
Die Testautomatisierung auf der GUI-Ebene erfolgt relativ spät in der Entwicklungskette. Wir wollen, dass sich die Entwicklung des Systems stabilisiert hat und keine radikalen Änderungen oder Umgestaltungen zu erwarten sind. Dies ist, wie bereits erwähnt, auf die Komplexität und den Umfang dieser Tests sowie auf die Kosten und den Zeitaufwand für Änderungen und Wartung zurückzuführen.
Es ist wichtig, dass diejenigen, die die automatisierten Tests schreiben, wissen, wie das System im Detail funktionieren soll. Wenn dieses Wissen fehlt und das Team, die Organisation oder jemand anderes diese Informationen nicht vermitteln kann, ist es sehr schwierig, sinnvolle automatisierte Tests zu erstellen.
Viktor Laszlo ist Experte für Automatisierung und arbeitet seit mehr als 22 Jahren an der Optimierung von Softwaretests und -entwicklung sowohl international als auch in Schweden. Viktor verfügt über umfassende Kenntnisse in der Systementwicklung und Programmierung sowie in der Entwicklung von Tools für Funktions- und Leistungstests.
In recent years, the emergence of low-code and no-code platforms has significantly transformed application development processes, democratizing access to development and addressing the demand for rapid delivery.
Low code and No code testing are methods to automate tests with minimal or no
The Essentials of Modern Software Engineering Building, testing, and maintaining software is becoming increasingly complex,