Automatisiertes Testen: Welche QA-Prozesse sollten auf die Validierung von Testcode ausgerichtet sein?

Idealerweise sollte die Testautomatisierung dem gleichen Grad an Validierung unterliegen, wie der Produktionscode – was natürlich zu dem Problem führt, dass der Testcode den Testcode testet, der den Testcode testet, der den Testcode testet… ad infinitum.

Was ich als brauchbare Alternative gefunden habe, ist eine Sammlung von Praktiken und Strategien, die im Allgemeinen funktionieren, um die Testautomatisierung in vernünftiger Ordnung zu halten. Es ist sicherlich keine umfangreiche Liste, aber eben das, was ich in 25 Jahren Quality Assurance erlernen konnte:

• Code-Reviews – entweder ein Entwickler oder ein anderer Testautomatisierer (letzteres ist besser, es sei denn, der Entwickler ist mit der Codebasis der Automatisierung vertraut) überprüft jeden neuen Code. Dies hilft, die “return true”-Probleme zu vermeiden, und ermöglicht auch Vorschläge zur Verbesserung der Codestruktur, Hinweise auf Hilfsbibliotheken, die bereits Funktionen enthalten, die ein Tester neu erstellen möchte (dies geschieht, wenn die Testcodebasis groß genug ist – ich habe es getan und musste dann die Funktionen bereinigen und vereinheitlichen), und so weiter.
• Ergebnisanalyse – jemand geht jeden Durchlauf durch und prüft, ob es sich bei allen nicht bestandenen Ergebnissen um tatsächliche Probleme handelt. Dies kann bei schlecht geschriebener Testautomatisierung sehr zeitaufwendig sein (ich habe es selbst erlebt…) und dient als Anreiz, den Automatisierungscode zu bereinigen, damit es einfacher ist, die erste Abweichung von den Erwartungen festzustellen. In meiner vorherigen Position habe ich 10 Jahre alten Automatisierungscode geerbt, der als Aufzeichnungs-Wiedergabe mit Tastendrucken begonnen hatte, um die Anwendung im Test zu manipulieren, und oft war der einzige Weg, um herauszufinden, was schiefgelaufen war, den Lauf (alle 4+ Stunden davon…) erneut abzuspielen und zu beobachten, bis etwas passierte. Ich hoffe aufrichtig, dass dieses spezielle Skript veraltet ist…
• Prüfungen: Führt eine Zusammenfassung der Ergebnisse im Laufe der Zeit durch – dies kann sehr hilfreich sein, wenn es darum geht, die Zuverlässigkeit eures Automatisierungscodes zu bewerten. Wenn ein Skript viele Fehlalarme verursacht, ist es ein guter Kandidat für ein Refactoring.
• Pflege: Plant Zeit für die Pflege der Automatisierungscodebasis ein – Dies ist ein entscheidender Punkt, der meiner Erfahrung nach oft vergessen wird. Wenn alle eurer Automatisierer Zeit für die Wartung der Automatisierungscodebasis aufwenden müssen, wird diese mit der Zeit immer anfälliger, selbst wenn die vom neuen Code betroffenen Bereiche durch Refactoring ergänzt werden. Ich würde empfehlen, jemanden dafür freizustellen, einfach ein paar Wochen lang zu überwachen, wie viel Zeit er für die Wartung des Automatisierungscodes aufwendet, um eine Vorstellung davon zu bekommen, wie viel Zeit eure Codebasis benötigt, und diese Zahl dann als Grundlage für eine nicht verhandelbare Zeitzuweisung von x Stunden pro Woche zu verwenden.
• Unit-Tests für Testcode: Es ist wichtig, dass der Testcode selbst durch Unit-Tests abgedeckt wird, um sicherzustellen, dass er korrekt funktioniert. Diese Tests sollten die erwarteten Ergebnisse überprüfen und sicherstellen, dass der Testcode die beabsichtigte Funktionalität abdeckt.
• Testabdeckungsmetriken: Verwendet Tools zur Messung der Testabdeckung, um sicherzustellen, dass der Testcode ausreichend viele Codezeilen oder Funktionalitäten abdeckt. Dies hilft dabei, Lücken in der Testabdeckung zu identifizieren und sicherzustellen, dass alle relevanten Bereiche des Codes getestet werden.
• Wartbarkeit und Lesbarkeit des Testcodes: Der Testcode sollte gut strukturiert, leicht verständlich und wartbar sein. Verwendet aussagekräftige Namen für Testfälle und -methoden, kommentiert komplexe Teile des Codes und haltt euch an gängige Konventionen und Stilrichtlinien.
• Automatisierte Testausführung und Berichterstattung: Automatisiert die Ausführung der Tests und die Erstellung von Testberichten. Dadurch wird sichergestellt, dass die Tests regelmäßig und konsistent ausgeführt werden, und ermöglicht es euch, schnell auf Fehler zu reagieren und den Testfortschritt zu überwachen.
• Regressionstests: Stellt sicher, dass der Testcode als Teil des Regressionstestprozesses regelmäßig ausgeführt wird, um sicherzustellen, dass vorhandene Funktionalität weiterhin wie erwartet funktioniert. Dies hilft, Regressionen zu erkennen und sicherzustellen, dass Codeänderungen keine unerwünschten Auswirkungen haben.
• Integration mit CI/CD-Pipelines: Integriert den Testcode in Ihre kontinuierlichen Integrations- und Bereitstellungspipelines, um sicherzustellen, dass die Tests bei jeder Codeänderung automatisch ausgeführt werden. Dadurch wird eine schnelle Rückmeldung ermöglicht und die Qualität des Codes überwacht.
• Dokumentation: Dokumentiert den Testcode, um anderen Teammitgliedern zu helfen, den Code zu verstehen und ihn gegebenenfalls zu erweitern oder anzupassen. Beschreibt die Testfälle und deren erwartetes Verhalten sowie etwaige Abhängigkeiten oder spezielle Konfigurationen.