100 % Testautomatisierung mag wünschenswert sein, aber ist sie praktikabel?

Von Jonny Steiner, Produktmarketingmanager

 

Wenn ich eine Zeitmaschine oder sogar ein Zeitfernglas in die Hände bekäme, mit dem man auf magische Weise durch die Zeit blicken kann, das ich gerade erfunden habe, würde ich damit eine Menge Dinge tun. Für diesen Blogbeitrag möchte ich mein Zeitfernglas jedoch verwenden, um in die Zukunft zu blicken. Insbesondere möchte ich sehen, ob wir beim kontinuierlichen Testen jemals einen Punkt erreichen, an dem wir 100 % Automatisierung erreichen.

100 % automatisierte Tests könnten unmöglich sein

Jeder möchte das. Die kontinuierliche Testautomatisierung zu 100 % ist der Traum jedes Mitglieds eines QA- und Testteams. In mancher Hinsicht ist dies jedoch eine echte Herausforderung. Zunächst einmal ist ein Teil des Codes zu komplex, um Automatisierungstests dafür zu schreiben. Andererseits ist ein Teil des Codes nicht wichtig genug, um Automatisierungstests zu benötigen. Die Idee dahinter ist, dass ein risikobasierter Ansatz zur Testautomatisierung sicherstellt, dass auf die wichtigsten Teile einer bestimmten Software geachtet wird.

Einige Experten raten dazu, vom 100-prozentigen Automatisierungsziel Abstand zu nehmen. Sie sagen, dass im sich ständig ändernden Softwareentwicklungsprozess keine Zeit für eine vollständige Automatisierung bleibt. Der Fokus sollte auf dem ROI liegen und auf dem, was Unternehmensleiter und Stakeholder glücklich macht.

What If?

Nehmen wir an, es wäre möglich, Ihre kontinuierlichen Tests zu 100 % zu automatisieren. Es gibt Anzeichen dafür, dass einige Organisationen dies bereits versuchen. Mit dem Wachstum der codefreien Entwicklung sowie autonomer Testlösungen wurde der Grundstein für eine Zukunft gelegt, in der eine Anwendung entwickelt und dann durch einen vollständig automatisierten Testprozess geführt wird. Die einzige menschliche Interaktion wäre, jeden Testlauf neu zu starten, wenn ein neuer Build fertig ist oder ein Defekt behoben wurde.

Der Vorteil wäre, dass die Release-Geschwindigkeit weiter erhöht werden könnte, während gleichzeitig Fehler frühzeitig im Prozess ohne menschliches Eingreifen beseitigt werden könnten. Wie wir jedoch sehen werden, schafft automatisiertes Testen Mehrwert, aber nicht immer auf die erwartete Weise.

Der „Wert“ der Testautomatisierung

Der automatisierte Testprozess läuft wie folgt ab. Tests werden unter Verwendung eines Startorts, einer Änderung und eines erwarteten Ergebnisses ausgeführt. Wenn ein Testlauf abgeschlossen ist, bedeutet das, dass die Automatisierung ausgeführt wurde, die zu testende Funktion jedoch noch nicht abgeschlossen ist. Erst wenn die Kontrollen durchgeführt sind. Der Wert ergibt sich aus dem Prozess des Testens/Reparierens/erneuten Testens. Durch diesen Prozess entstehen klare Anweisungen zur Fehlerbeseitigung.

Es ist wichtig zu verstehen, dass, wenn automatisierte Prüfungen erstellt werden, die anfängliche Testausführung abgeschlossen ist, Änderungen implementiert werden und die Tests erneut ausgeführt werden, die Tests dann Fehler erkennen, wenn das erwartete Ergebnis falsch ist.

In der Welt des kontinuierlichen Testens gibt es ein altes Sprichwort: „Eine Softwareänderung verwandelt die Testautomatisierung in Änderungserkennung.“

Automatisierung als Ausgangspunkt all Ihrer Probleme

Einfach ausgedrückt kann kontinuierliches Testen zu weiteren Herausforderungen führen. Sobald eine Änderung an der Anwendung in der Entwicklung vorgenommen wird, ist die automatisierte Testsuite veraltet. Die Testwartung, die oft übersehen wird, ist ebenfalls unerlässlich. Ein Problem, unter dem einige Organisationen leiden, ist die mangelnde Übersicht über die Wartung vorhandener Tests und die Löschung veralteter Tests, was zu Testschulden führt.

Auch beim automatisierten Testen ist die Testabdeckung wichtig. Jedes Szenario muss abgedeckt werden, sonst ist ein Test, der „bestanden“ wurde, möglicherweise nicht so genau, wie Sie denken. Sicher, Sie haben vielleicht 100 % Ihrer Tests bestanden, aber was ist mit den Szenarien, die Sie verpasst haben? Sie werden nicht einbezogen.

Dann gibt es noch das Problem fehlgeschlagener Tests. Diese müssen alle untersucht werden. Was die Sache noch schwieriger macht, ist, dass Tests manchmal aus Umweltgründen und nicht aus technischen Gründen scheitern. In einer Welt, in der jede eingesparte Minute kostbar ist, sind „falsch negative“ Tests kostbar.

Es sind auch Testfehler zu berücksichtigen, da jeder einzelne untersucht werden muss. Einige Tests sind „falsch negativ“ – z. B. ein Test, der aus irgendeinem Grund aufgrund eines Umweltproblems abbricht. Das kostet Zeit, anstatt sie zu sparen.

Die letzte Herausforderung bei der Testautomatisierung besteht darin, dass die Tests nicht selbstständig denken. Sie folgen dem Weg, der ihnen vorgegeben wurde und wofür sie kodiert wurden. Auf diese Weise interagieren Menschen nicht mit Anwendungen. Wir lassen uns ablenken, ablenken und klicken manchmal auf die falschen Dinge. Ein automatisierter Test deckt nur vorab ausgewähltes Verhalten des Benutzers ab.

Wie viel Automatisierung ist genug?

Von Unternehmensleitern und Führungskräften bis hin zu Entwicklern und Qualitätssicherung kommen Menschen ständig auf Ideen, die sie testen und erkunden können, wenn sie ihre Anwendungen verwenden oder darin navigieren. Versuchen Sie es vielleicht nur einmal, um zu sehen, ob es funktioniert. Was Sie nicht tun werden und was niemand tun sollte, ist, einen Test für all diese kleinen Szenarien zu entwickeln.

Wir sind noch nicht ganz auf dem Niveau der Anforderungen an unsere Testtools und warten auf die erwarteten Ergebnisse. Wir sind jedoch an dem Punkt angelangt, an dem Tester ihre Tests mit einem Klick ausführen und Ergebnisse erhalten möchten. Wenn wir davon sprechen, unsere Tests zu 100 % zu automatisieren, würde das bedeuten, dass eine bestandene Ausführung bedeutet, dass die Software ohne weitere Analyse direkt in die Produktion gehen kann.

Die gute Nachricht ist, dass ich gerade automatisierte Regressionstests beschrieben habe. Dies schließt Leistungs- und Sicherheitstests aus, bedeutet aber, dass eine App in die Produktion übertragen werden kann, sobald der Test isoliert durchgeführt wurde und dieser Test bestanden wurde.

Mit der Wahrheit leben

Daher ist eine 100-prozentige Testautomatisierung möglicherweise nicht möglich. Es ist eine gute Idee, aber nicht die praktischste. Es wird immer Code geben, der zu schwierig ist, um automatisierte Tests zu schreiben, und der möglicherweise schwer zu lesen ist, aber manchmal ist ein Codeabschnitt für die Automatisierung nicht wichtig genug. Der risikobasierte Ansatz, den ich hier befürworte, konzentriert sich auf die wichtigsten Teile der Software.

Vielleicht ist es besser, im Hinblick auf den ROI zu denken. Überlegen Sie, welchen Versicherungsschutz Ihr Unternehmen wirklich benötigt. Messen Sie die Temperatur Ihrer Führungskräfte und Führungskräfte, um zu sehen, wie hoch deren Risikobereitschaft im Verhältnis zur entwickelten Software ist.

Denken Sie daran, dass nicht alle Fehler gleich sind und daher nicht alle Tests automatisiert werden müssen.