English French Swedish Deutsch
JETZT KONTAKT AUFNEHMEN
JETZT KONTAKT AUFNEHMEN
English French Swedish

KI-gestütztes Testing

Quality Engineering

SAP Quality Assurance

Cybersecurity

Finanzdienstleistungen & Banking

QESTIT Cybersecurity

QESTIT Academy

QESTIT Systems

Blogs

Case Studies

Whitepapers

Webinare & Events

News & Presse

Über QESTIT

Zertifizierungen & Partner

QESTIT Referenzen
Bundles

Arbeiten bei QESTIT

Stellenangebote
JETZT KONTAKT AUFNEHMEN
move-left Back
🌍 All Regions
Quality Assurance Engineering

Was sollte man nicht automatisieren?

Wenn wir automatisierte Tests schreiben, möchten wir mit möglichst geringem Aufwand und Zeitaufwand einen maximalen Mehrwert erzielen. Die Gesamtzahl der Testfälle, mit denen sich sicherstellen lässt, dass ein großes, modernes und komplexes System fehlerfrei ist, ist nahezu unendlich. „Alles“ lässt sich nicht automatisieren. In diesem Beitrag schauen wir uns genauer an, was nicht automatisiert werden kann bzw. sollte und warum.

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

Bei der Testautomatisierung geht es darum, Teile der Testarbeit zu rationalisieren – zumindest diejenigen Teile, die sich dafür am besten eignen. Daher gibt es einige Testkategorien, die wir nicht automatisieren sollten.

Tests, die Intelligenz und Emotionen erfordern

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

  • Ist das Layout lehrreich?
  • Ist die Benutzererfahrung angenehm?
  • Ist die Nutzung der Anwendung ergonomisch?
  • Ist die Bedienung 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. Ein Computer ist nicht in der Lage, 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.

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 korrigiert 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, zeitaufwendig und schwer anzupassen. Daher ist es ratsam, mit der Implementierung dieser Art von Tests zu warten, bis sich das System stabilisiert hat und keine weiteren einschneidenden Änderungen mehr zu erwarten sind.

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

Manchmal stoßen wir auf Komponenten oder Teile eines Systems, für die sich automatisierte Tests nur sehr schwer umsetzen lassen. Dies kann verschiedene Ursachen haben. Ein Beispiel ist die Sicherheit, bei der es vor allem darum geht, Bots oder unerwünschte automatisierte Manipulationen zu verhindern. 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 meist keine gute 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 ohnehin schlecht ausfallen werden.

63+++

Investieren Sie stattdessen Zeit und Energie in die Implementierung automatisierter Tests dort, wo dies einfach und erfolgreich ist. Nutzen und Wert bieten Tests, die schnell laufen, zuverlässig und robust sind sowie sich leicht anpassen und warten lassen.

Testfälle, die manuell nicht gut gelaufen sind

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, automatisierte Tests über die grafische Benutzeroberfläche (GUI) für eine Anwendung zu implementieren, bei der die manuellen Tests nicht gut verlaufen sind.

Dies gilt hingegen 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 die GUI relativ einfach, kurz und schnell zu implementieren sowie leicht anzupassen.

Wenn wir das System bereits früh im Entwicklungszyklus über die API testen können, ist es sinnvoll, auf dieser Ebene mit der Implementierung umfassender Tests zu beginnen. Sobald sich das System stabilisiert hat und keine grundlegenden Änderungen mehr zu erwarten sind, hat es sich als sehr erfolgreich erwiesen, dies durch eine geringere Anzahl automatisierter Tests über die grafische Benutzeroberfläche der Anwendung zu ergänzen.

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

Am erfolgreichsten ist es, die automatisierten Tests parallel zur Implementierung des Systems durchzuführen. Die automatisierten Tests sollten auf einer möglichst niedrigen Testautomatisierungsebene (Geräteebene, API-Ebene, GUI-Ebene) angesiedelt sein, um Fehler so nah wie möglich an der Quelle (dort, 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 mehr zu erwarten sind. Dies liegt, wie oben erwähnt, an der Komplexität und dem Umfang dieser Tests sowie an den Kosten und dem Zeitaufwand für Änderungen und Wartung.

Es ist wichtig, dass diejenigen, die die automatisierten Tests schreiben, genau wissen, wie das System im Detail funktionieren soll. Fehlt dieses Wissen und kann das Team, das Unternehmen oder eine andere Person diese Informationen nicht vermitteln, wird es sehr schwierig sein, aussagekräftige automatisierte Tests zu erstellen.

Tags

Quality Assurance Engineering All Industries All Business Units