Sollten Softwaretests vollständig automatisiert werden?

Was automatisierte Tests ermöglichen

Die meisten Testautomatisierungen lassen eine Anwendung durch einen Algorithmus laufen, mit einem Startpunkt, einer Änderung und einem erwarteten Ergebnis. Wenn diese Tests zum ersten Mal bestanden sind, ist die Automatisierung abgeschlossen, doch die Funktion wird erst ausgeführt, wenn die Tests laufen.

Die automatisierten Tests haben also noch keinen Wert geliefert. Die Test-Fix-Retest-Schleife hilft dabei, Tests schneller abzuschließen, und bietet klare Anweisungen für ein korrektes Verhalten. Wenn die automatisierten Tests erstellt werden, finden sie jedoch keine Probleme. Sobald alles die ersten Tests bestanden hat, treten Änderungen auf, damit die Software einen Bruch erkennen kann, wenn das erwartete Ergebnis nicht korrekt ist.

An diesem Punkt stoßen wir auf eine Maxime der Testwerkzeuge: Nach einer einzigen Änderung in der Software wird Testautomatisierung im Wesentlichen zur Änderungserkennung.

Dabei sollte bedacht werden: Die Aufgabe des Programmierers ist es, Änderungen zu erzeugen, und das wiederum verursacht Wartungsaufwand. Wenn jemand einen Test debuggen muss, muss er bestätigen, dass sich die Software tatsächlich geändert hat, und dann den Test aktualisieren – zum Beispiel, um beim Anlegen eines Benutzers das erforderliche Telefonnummernfeld hinzuzufügen.

Mit diesem grundlegenden Verständnis sieht man, wie automatisierte Tests Ihrer Organisation zugutekommen können. Allerdings stellt sich die Frage: Wie sehr sollte man Softwaretests automatisieren?

Wie viel Automatisierung ist ausreichend?

Nehmen wir an, Sie machen eine Softwaredemo für einen Kunden oder einen leitenden Angestellten. Das Produkt ist noch nicht in Produktion. Sie zeigen nur, was Sie getan haben, um Feedback für die nächste Iteration zu erhalten.

Der Finanzverantwortliche fragt dabei, was passiert, wenn Sie eine Rechnung erstellen, die am Tag ihrer Erstellung überfällig ist. Das ist eine gute Frage und im Wesentlichen eine Testidee – die Art von Dingen, an die vorher noch niemand gedacht hat. Wenn die Software in eine Richtung funktioniert, ist es in Ordnung. Wenn nicht, ist es eine Anfrage für neue Funktionen, nicht wirklich ein Fehler.

Die Person an der Tastatur versucht, die Frage zu beantworten. Sagen Sie ihm, dass er aufhören soll zu tippen? Dass Sie erst einen automatischen Test erstellen und ausführen müssen, bevor Sie diese Frage beantworten können? Ich hoffe nicht.

Es gibt eine Menge solcher Testideen, Dinge, die Ihnen im Moment einfallen, die Sie erforschen sollten, besonders wenn Sie eine neue Funktion testen, die Teil eines bestehenden Systems ist. Die meisten Ideen möchte man nur einmal testen. Diese Tests in Code zu automatisieren, der die ganze Zeit läuft, ist aufwendig und teuer. Ihr Chef möchte sicher nicht, dass jede kleine Idee umgesetzt wird.

Es gibt keinen magischen Kasten, in den Sie Anforderungen als Word-Dokumente eingeben und Testbedingungen und erwartete Ergebnisse herausspringen lassen können. Wenn die meisten Leute von automatisierten Tests sprechen, meinen sie in der Regel die automatisierte Testausführung und -auswertung und vielleicht auch die Einrichtung. Sie wollen auf eine Schaltfläche klicken, alle bereits vorhandenen Tests ausführen und Ergebnisse erhalten. Eine vollautomatische Teststrategie impliziert, dass ein Daumen hoch genügt, um ohne weitere Recherchen und Analysen zur Produktion überzugehen.

In Wirklichkeit ist das eine hundertprozentige Automatisierung von Regressionstests – Sie schließen Leistung, Sicherheit und die Unterstützung neuer Plattformen oder Browser aus und sagen einfach: Sobald eine Änderung isoliert getestet wurde, kann sie nach dem Durchlaufen der Werkzeuge in die Produktion übergehen. Einige der Unternehmen, mit denen ich zusammengearbeitet habe, haben diesen Standard erreicht. Allerdings bleibt immer noch das Problem der Testwartung bestehen.

Drei Möglichkeiten zur Testwartung

Es gibt zwei beliebte Ansätze, um die Wartung von Tests effizienter zu gestalten. Der erste besteht darin, kleine Feature-Bausteine zu schreiben, die schnell laufen und leicht zu debuggen sind, manchmal auch als DOM-to-Database-Tests bezeichnet. Ein anderer Ansatz besteht darin, den Code in Komponenten zu isolieren, die separat bereitgestellt werden und einfach keine automatisierten GUI-Überprüfungen haben, so dass sich die Automatisierungsbemühungen darauf konzentrieren, unter die Haube zu schauen.

Ein dritter, neuerer Ansatz ist der Einsatz von Machine Learning und Predictive Intelligence, um herauszufinden, ob die Software tatsächlich kaputt ist, und sich dann selbst zu reparieren. Manchmal wirkt sich eine Änderung der Benutzeroberfläche überhaupt nicht auf die Funktionen aus – sie ändert nur die Position der Elemente auf dem Bildschirm, wodurch die Locators ausfallen. In diesem Fall kann die Software eine Historie darüber verwenden, wo Elemente gespeichert sind, um im Wesentlichen die Position der Schaltfläche zum Absenden herauszufinden und erneut zu überprüfen.

Wenn die Software unter diesen Bedingungen den Test bestanden hat, kann die KI den Selbstheilungstest einstellen. Einige Unternehmen haben diesen Ansatz mit mäßigem Erfolg ausprobiert und dabei den Wartungsaufwand für den Test reduziert, ohne ihre False-Pass-Raten zu erhöhen.

Insgesamt ist mein Rat an Organisationen, die hundertprozentige Automatisierung in Frage stellen, einfach: Treten Sie einen Schritt zurück, und bedenken sie noch einmal alles. Stellen Sie vernünftige Fragen. Arbeiten Sie mit dem Chef zusammen, um Begriffe zu definieren, konzentrieren Sie sich auf die Endergebnisse und überlegen Sie sich die Mittel, um diese Ergebnisse zu erzielen – egal, wie weit automatisierte oder manuelle Tests erforderlich sind.