Warum und was automatisieren
Kurz gesagt: Ein automatisierter Test ist ein Programm, das das System ausführt und das Ergebnis vergleicht, ohne dass ein Mensch beteiligt ist. Er lohnt sich für Regeln, die sich selten ändern, bei jeder Änderung geprüft werden und Geld kosten, wenn sie kaputtgehen. Er lohnt sich nicht für eine einmalige Prüfung, für eine Seite, die sich noch ändert, oder für alles, was menschliches Urteil braucht. Seine echten Kosten sind die Wartung.
Problem
Zwei Tage manuelle Tests jede Woche
Der Shop bringt jeden Freitag eine neue Version heraus. Vor jeder Freigabe geht QA 120 Testfälle von Hand durch: Lieferung, Warenkorb, Gutscheincodes, Rückgaben. Das dauert zwei Tage.
Letzte Woche war ein Feiertag, und es blieb Zeit für 80. Die 40, die ausgelassen wurden, waren „die alten, die gehen nicht kaputt“. Am Montag zahlte ein Kunde bei einer Bestellung von genau 50,00 € Lieferkosten. Die Änderung war in der Logik des Gutscheincodes, und sie hat die Lieferungsgrenze kaputt gemacht.
Die Idee
Testautomatisierung
Testautomatisierung ist ein Programm, das das System ausführt, ihm die Eingabe aus dem Testfall gibt und das Ergebnis mit dem erwarteten vergleicht. Ohne einen Menschen, und bei jedem Lauf gleich.
Was sie bringt:
- Regression wird billig. 120 Fälle laufen in Minuten, bei jeder Änderung, nicht einmal pro Woche über zwei Tage;
- jedes Mal dasselbe. Ein Programm wird bei Fall 80 nicht müde und überspringt „die alten“ nicht;
- schnelle Rückmeldung. Der Programmierer erfährt fünf Minuten später, dass die Grenze kaputt ist, solange er noch weiß, was er angefasst hat;
- lebende Dokumentation läuft. Die Szenarien aus dem Gherkin-Modul sind nicht mehr Text in einem Ordner: Sie werden zu einer Prüfung, die besteht oder fehlschlägt.
Die Automatisierung erfindet keine Tests. Ein Mensch schreibt weiter den Testfall. Die Automatisierung wiederholt ihn.
Die Idee
Was sich lohnt und was nicht
Ein automatisierter Test wird einmal bezahlt, wenn er geschrieben wird, und dann bei jeder Änderung. Er lohnt sich also, wenn er oft läuft und sich selten ändert.
Er lohnt sich für:
- Regeln, die sich nicht jede Woche ändern: Lieferung, Warenkorb-Limit, Rabatte;
- Prüfungen vor jeder Freigabe (Regression);
- viele Beispiele derselben Regel: zehn Beträge um die Grenze;
- Stellen, an denen ein Fehler Geld oder Vertrauen kostet.
Er lohnt sich nicht (oder noch nicht) für:
- eine einmalige Prüfung: eine Datenmigration, die einmal passiert;
- eine Seite, die der Designer noch jeden Tag ändert;
- alles, was Urteil braucht: Ist das Formular klar, sieht es richtig aus, ist es bequem. Das ist Usability, und Menschen schauen darauf;
- exploratives Testen: Dort wird die Frage beim Testen erfunden.
Probier es aus
Automatisieren oder nicht?
Die Idee
Die Risiken
Die Automatisierung scheitert oft nicht am Werkzeug, sondern an den Erwartungen:
- „Sie findet alle Fehler.“ Ein Test prüft nur, woran jemand gedacht hat. Wenn niemand an den leeren Warenkorb gedacht hat, prüft ihn die Automatisierung nicht, egal wie oft sie läuft. Die Mutanten im Gherkin-Modul sind genau so durchgerutscht.
- Unterschätzte Wartung. Tests sind Code. Wenn die Schwelle 60 € wird, ändern sich die Szenarien, die Schritte und die Tests. Wenn sie niemand pflegt, ist die Hälfte einen Monat später rot, und das Team hört auf hinzuschauen.
- Ein Test, dem niemand traut. Wenn ein Test „manchmal“ fehlschlägt, lassen ihn die Leute wieder laufen, bis er besteht. Dann rutscht auch ein echter Fehlschlag durch.
- Alles über die Oberfläche. Tests über den Browser sind langsam und gehen kaputt, wenn ein Button wandert. Die meisten Prüfungen gehören weiter nach unten.
- Das Werkzeug als Ziel. „Wir haben ein Werkzeug gekauft“ ist keine Strategie. Zuerst kommt, was geprüft werden muss, dann, womit.
Genauer, für Neugierige
Der ISTQB CTFL v4.0.1 behandelt Werkzeuge in Kapitel 6. Abschnitt 6.2 listet den Nutzen auf, darunter weniger wiederholte manuelle Arbeit, mehr Konsistenz, schnellere Rückmeldung und mehr Zeit für neue Tests, und die Risiken, darunter unrealistische Erwartungen, ungenaue Schätzungen von Zeit und Kosten (einschließlich Wartung), den Einsatz eines Werkzeugs dort, wo manuelles Testen besser passt, zu starkes Vertrauen auf ein Werkzeug unter Missachtung menschlichen kritischen Denkens und die Abhängigkeit vom Hersteller des Werkzeugs oder von Open-Source-Software, die aufgegeben werden kann.
Für alle, die Automatisierung beruflich schreiben werden, hat der ISTQB ein eigenes Advanced-Zertifikat: CTAL-TAE (Test Automation Engineering). Es handelt von der Architektur der Automatisierung und gehört nicht zu diesem Kurs.
Die Idee
Welche Stufe für welche Prüfung
Die Pyramide aus dem Modul über Stufen sagt, wie viele Tests auf welcher Stufe. In der Automatisierung wird sie konkret:
- Szenarien (die nächste Lektion) prüfen die Regel in den Worten des Geschäfts. Sie sind die lebende Dokumentation;
- Komponententests prüfen ein Stück Code, schnell und mit vielen Beispielen: zehn Beträge um die Grenze in Millisekunden;
- API-Tests schicken echte Anfragen an den Server des Shops, ohne Browser;
- UI-Tests öffnen einen Browser und klicken wie der Kunde. Nur wenige, für die Pfade, die nicht kaputtgehen dürfen.
In diesem Modul bleibt die Regel durchgehend dieselbe: Die Lieferung ist ab 50,00 € einschließlich kostenlos, sonst kostet sie 4,90 €, und ein leerer Warenkorb wird abgelehnt. Du siehst sie auf jeder Stufe automatisiert, in Java, C#, Python und JavaScript, und du siehst, welcher Test welchen Fehler fängt.
Hier musst du Code in einer der vier Sprachen lesen können. Was du brauchst, steht im Programmierkurs, bis zum Modul „Programme in der echten Welt“: Klassen, Exceptions und Komponententests.
Probier es aus
Der Weg einer Regel
Bringe den Weg der Lieferregel in die richtige Reihenfolge, von der Vereinbarung bis zum Bericht.
Die Tests laufen bei jeder Änderung am CodeDer Bericht sagt, was fehlgeschlagen ist und warumDie Regel wird auch mit Komponententests geprüftDie Regel wird vereinbart und als Szenario aufgeschriebenDas Szenario wird über Schritte mit dem Code verbunden
Das ist auch der Plan des Moduls: die Schritte, die Komponententests, die API und die Oberfläche, dann CI und der Bericht. Das Szenario steht am Anfang, weil es die vereinbarte Regel ist. Der Testcode kommt danach.
Übung
Ein Automatisierungsplan
1. Was zuerst und warum. Der Shop fängt gerade mit der Automatisierung an.
Test