Wir haben in der Softwarebranche einen langen Weg hinter uns, aber es gibt immer noch Raum für weitere Innovationen. Das Aufkommen agiler Methoden und die Einführung von DevOps-Praktiken haben sich in den letzten zehn Jahren zu einem wahren Gamechanger entwickelt. Diese Veränderungen ebnen den Weg für die Einführung verschiedener Praktiken wie kontinuierliche Integration, Bereitstellung, Überwachung und – noch wichtiger – kontinuierliche Tests. Die Testautomatisierung hat diesen Wendepunkt möglich gemacht. Allerdings birgt sie auch eine ganze Reihe von Herausforderungen. Die selbstreparierende Testautomatisierung treibt die nächste Stufe der Innovation voran, indem sie für eine kürzere Entwicklungszeit und eine geringere Fehleranfälligkeit der Tests sorgt.
So hat die Testautomatisierung die Branche verändert
Die Softwareindustrie war auf der Suche nach einer Alternative zu mühsamen manuellen Tests, und so wurde die Testautomatisierung geboren. Aus verschiedenen Gründen hat sich die Testautomatisierung gegenüber dem manuellen Testen immer mehr durchgesetzt und ist nun eine der wichtigsten Triebfedern für Veränderungen und die De-facto-Testmethodik. Sie verspricht denjenigen, die sie einsetzen, eine unvergleichliche Effizienz und eine schnellere „Markteinführung“.
Zum einen kann die Testautomatisierung mit einer Fülle von Technologien durchgeführt werden, sowohl mit kommerziellen Standardprodukten (Commercial Off-the-Shelf, COTS) als auch mit Open-Source-Produkten. Bei der Automatisierung der grafischen Benutzeroberfläche (GUI) besteht das wichtigste Designprinzip für die Testautomatisierung unabhängig vom verwendeten Tool darin, die Eigenschaften der Oberflächenelemente in einem Objekt-Repository zu erfassen und zu speichern, sie dann in einem Automatisierungs-Framework zu verwenden und so Benutzeraktionen zu imitieren. Das Testskript kann also auf eine UI-Schaltfläche klicken, Werte in ein Textfeld eingeben, Werte in einem Listenfeld auswählen usw.
Der zweite Grund, warum die Testautomatisierung so beliebt geworden ist, liegt in der Integration von Teams. Die Entwicklungs- und Testteams, die früher getrennt an einem Projekt arbeiteten, sind jetzt alle Teil desselben Feature-Teams, als SDEs und SDETS, die miteinander zusammenarbeiten.
Integrierte Teams und der Schwerpunkt auf regelmäßiger Build-Erstellung und Tests bringen jedoch einige Herausforderungen mit sich. Die Teams stehen unter großem Druck, regelmäßig hochwertige Produkte zu liefern.
Das Problem wird noch verschärft, wenn sich die getesteten Anwendungen ständig weiterentwickeln und verändern. Die automatisierten Testskripte hängen von einer gültigen Eigenschaft des UI-Objekts ab, die sich häufig ändert, was zu anfälligen und fehlerhaften Tests führt. Ein Testskript bricht ab, wenn sich die Eigenschaften des UI-Objekts ändern. Ein Automatisierungsingenieur muss dann die Entwicklung eines neuen Skripts stoppen, um den Fehler zu beheben. Dieses Problem wird noch verstärkt, wenn es Hunderte von automatisierten Tests gibt, und das Automatisierungsteam kann dadurch während eines Sprints insgesamt weniger Arbeit erledigen.
Derzeit gibt es einen manuellen Prozess zur Behebung dieses Problems. Zunächst debuggen die Automatisierungstechniker die Skriptfehler manuell. Dann untersuchen sie das UI-Element und finden neue Eigenschaften, die zur Aktualisierung des Skripts oder des Objekt-Repositorys verwendet werden. Schließlich führen sie den Test erneut durch.
In den letzten Jahren hat sich im Testing ein Prinzip immer mehr durchgesetzt. Während die Tests selbst automatisiert werden, werden die Nebenaktivitäten, die zum gesamten Testlebenszyklus gehören – beispielsweise die Skriptpflege, die Auswirkungsanalyse, die Fehlersuche usw. – immer noch überwiegend manuell durchgeführt. Der Rückgriff auf manuelle Prozesse verlangsamt so den Softwareentwicklungsprozess. Daher beobachten wir jetzt einen Paradigmenwechsel in der Philosophie, der die „Testlebenszyklus-Automatisierung“ und nicht nur die „Testautomatisierung“ umfasst. Das Aufkommen von KI-/ML-Techniken in Kombination mit Programmierfähigkeiten trägt wesentlich zu dieser neuen Philosophie bei.
Die selbstreparierende Testautomatisierung ist ein wichtiger Teil in diesem Unterfangen.
Was ist selbstreparierende Testautomatisierung?
Für Webanwendungen gibt es mehrere Lokatoren, die zur Identifizierung eines UI-Elements verwendet werden können: ID, Name, Xpath, CSS-Lokator, Klasse, Tag, Linktext oder Teillinktext. Je nach Situation können sich ein oder mehrere Lokatoren für ein UI-Element ändern, und die entwickelten Algorithmen sollten in der Lage sein, diese Änderungen zu verarbeiten.