Wie mache ich automatisierte Testfälle effizienter?

Vielfach eine Frage, wie man hier vorgehen kann.  Grundsätzlich sind automatisierte Testfälle durchaus effizient, aber eben auch anfällig für Änderungen und Anpassungen. Hier sind wir dann wieder beim Thema Abhärtung von Testfällen.

• Parallelisiert eure Tests auf mehreren Rechnern bzw. in mehreren Pipelines. Erleichtert die Auswahl einer Teilmenge eurer Tests, sodass ihr einen Testlauf in mehrere Mini-Läufe aufteilen könnt, und lasst einen Scheduler die Zuweisung dieser Mini-Läufe zu mehreren Rechnern bzw. Pipelines übernehmen. Ihr müsst entscheiden, ob ihr die gleichen Tests immer auf den gleichen Rechnern oder Pipelines durchführen wollt, um Konsistenz zu gewährleisten, oder ob ihr wechseln wollt, um eine größere Abdeckung zu erreichen (einige Fehler können nur auf bestimmten Rechnern auftreten).
• Unterscheidung zwischen Funktionstests und End-to-End-Tests. Bei Funktionstests braucht euer den Benutzer nicht zu simulieren, bis ihr die zu testende Funktion erreicht habt, aber bei einem End-to-End-Test müsst ihr die gesamte Strecke simulieren. Bei Funktionstests könnt ihr euch während der Einrichtung schnell bewegen, während des eigentlichen Tests verlangsamen und simulieren und dann während der Aufräumarbeiten wieder beschleunigen.
• Verwendung konfigurierbarer Konstanten für die Zeitspannen zwischen den Aktionen. Dadurch könnt ihr nicht nur die Laufzeit leicht anpassen, wenn ihr feststellt, dass die Geschwindigkeit wichtiger wird (und dann vielleicht am Wochenende einen „langsamen“ Lauf durchführen), sondern ihr erhaltet auch eine bessere Abdeckung, indem ihr die Dinge so rekonfigurieren, dass sie gelegentlich mit unterschiedlichen Geschwindigkeiten ablaufen (einige unangenehme Fehler treten nur auf, wenn ihr Dinge schneller als normal ausführt).
• Wir haben zeitaufwändige Berechnungen ausgelassen, sodass wir eine „Test“-Phase hatten, in der nur die Daten protokolliert wurden, und eine „Analyse“-Phase, in der die Informationen sortiert wurden, um nützliche Statistiken zu erhalten. Es handelte sich um Leistungstests für die grafische Benutzeroberfläche, sodass wir eine Menge Datenanalysen durchführten – das gilt vielleicht nicht für Ihre Situation.
• Notiert euch die Priorität für jeden Test und führt nicht alle Tests jede Nacht durch, wenn die Zeit knapp ist. Ihr könnt Tests mit niedriger Priorität nur einmal pro Woche durchführen, um Ressourcen zu sparen. Oder ihr führt die Tests in der Reihenfolge ihrer Priorität durch, damit ihr die wichtigsten Ergebnisse zuerst erhaltet.
• Macht euch Notizen zu den langsamen Teilen, gebt euch eine grobe Zeitvorgabe für die Bearbeitung.
• Schnelle Rückkopplungsschleifen sind gut. Je schneller die Rückkopplungsschleife, desto schneller könnt ihr auf Fehler reagieren. Wenn man davon ausgeht, dass es sich um einen nächtlichen Testlauf handelt, sind 24 Stunden eine lange Feedbackschleife, vor allem, wenn man in einer agilen Umgebung arbeitet.
• Wiederverwendbare Codesegmente werden die zukünftige Automatisierung beschleunigen. Schreibt eine schnelle und effiziente Funktion zur Überprüfung von Dropdown-Listen, mit dieser ihr die gesuchten Daten übergebt. Wenn ihr diese Funktion für jeden Test wiederverwendet, habt ihr nicht nur viel langsamen und ineffizienten Code entfernt, sondern auch den Aufwand für künftige Tests von Auswahllisten verringert. Es ist einfacher, ein Codesegment zu refaktorisieren, das in mehreren Tests verwendet wird. Selbst wenn es also im Moment nicht das effizienteste Codestück der Welt ist, können ihr in Zukunft immer wieder darauf zurückkommen, und die Verbesserung seiner Effizienz wird euch einen Geschwindigkeitsschub in jedem Test geben, den ihr geschrieben habt und der diese Funktion nutzt.
• Ihr bekommt mehr Testzeit, wenn die Entwickler frühzeitig wissen, dass euer Code fehlerhaft ist. Wenn ihr alle möglichen Einsparungen erzielt habt, ist der nächste Schritt, die Spreu vom Weizen zu trennen und eure Tests parallel laufen zu lassen. Durch die Erstellung von zwei Test-Slices könnt ihr die Laufzeit halbieren (vorausgesetzt, ihr geht dabei intelligent vor und platziert die Tests entsprechend ihrer Laufzeit). Jedes zusätzliche Slice, das ihr hinzufügt, verkürzt die Testzeit und hilft euch, die magischen 15-30 Minuten Laufzeit zu erreichen. Wenn ihr nun einen CI-Server einrichtet und in Betrieb nehmt, könnt ihr den Entwicklern innerhalb von 30 Minuten nach dem Einchecken eures Codes mitteilen, dass etwas nicht in Ordnung ist; ihr habt die Geschichte noch frisch im Gedächtnis und solltet in der Lage sein, schnell zum Code zurückzukehren und die Probleme für euch zu beheben. Bei einer 24-Stunden-Feedback-Schleife sind die Entwickler wahrscheinlich schon mit etwas anderem beschäftigt und haben vergessen, was sie gestern gemacht haben; es dauert länger, bis sie herausgefunden haben, wo sie waren, und länger, bis sie das Problem behoben haben. Als Tester steht ihr am Ende des Entwicklungszyklus, und wenn eine Frist kurz bevorsteht, wird eure Zeit knapp, damit das Projekt die Frist einhalten kann. Wenn ihr die Tests wie oben vorgeschlagen beschleunigt, habt ihr mehr Zeit zum Testen. Wenn man davon ausgeht, dass die Entwickler jedes Problem innerhalb von 15 Minuten beheben, könnte eurer CI-Server, der alle 15 Minuten läuft, im Laufe eines Tages 14 verschiedene Fehler aufspüren, für die er zwei Wochen gebraucht hätte, wenn ihr die Tests nachts durchgeführt hättet.