Die Literatur ist voller Key-Performance-Indicators (KPIs) für die Testautomatisierung. Leider messen die meisten von ihnen den Fortschritt und den Status des Tests. Ich würde behaupten, dass Testautomatisierungsmetriken wie Automation Progress, Coverage, Number of Defects, Test Duration etc. in einer frühen Phase eines Testautomatisierungsprojekts nicht geeignet sind. Diese Metriken treffen keine Aussage zur Arbeit, die erforderlich ist, um solche Testfortschritte zu erreichen. In Testautomatisierung wird investiert, um die Geschwindigkeit zu erhöhen, Kosten zu reduzieren und die Qualität zu verbessern. Wenn Sie Ihre Automatisierungszeit für Testfälle nicht messen, wissen Sie weder, ob Ihre Investition sich auszahlt, noch können Sie Ihre Testautomatisierung systematisch verbessern. Es ist wichtig, eine Feineinstellung für jede Minute vorzunehmen, die Sie für die Automatisierung eines Testfalls aufwenden, also quasi den Ausführungsschritt für einen Testfall in einzelne Sekunden zu unterteilen – bringen Sie Maßnahmen aus dem kontinuierlichen Verbesserungsprozess in Ihr Testautomatisierungsprojekt.
Ich beleuchte zwei spezifische Metriken zu Beginn eines neuen Testautomatisierungsprojekts: die Testfallautomatisierungszeit und die Testfallwartungszeit. Sie messen die Effizienz des Testautomatisierungsprozesses. Das obige Verlaufsdiagramm stammt von einem echten Projekt und zeigt eine Testfallautomation von 82 Testfällen über die ersten zehn Wochen. Zu Beginn lag die Dauer für die Automatisierung eines Testfalls nahe bei 60 Minuten; später schrumpfte sie dank mehrerer kleinen Innovationen und Feinabstimmung des Prozesses auf 20 Minuten. Wenn Sie sich den Verlauf genauer ansehen, gibt es drei wichtige Verbesserungszyklen, die im Diagramm sichtbar sind und die etwas über die strategische Herangehensweise an die Testautomatisierung aussagen:
- Starten Sie die Automatisierung mit einfachen Testfällen, um die Testautomatisierungsbasis für das Projekt zu errichten, z. B. zuverlässige, einfache und wiederverwendbare Schlüsselwörter.
- Wenn Sie mit der Zeit zufrieden sind, die für die Automatisierung einfacher Testfälle benötigt wird, legen Sie Ihren Fokus auf automatisierte Testdaten und Umgebungsmanagement sowie auf Prozeduren vor und nach den Testfällen. Ich werde später in der Blogreihe nochmals auf dieses Thema eingehen und ein Navigationskonzept namens „AppState“ erläutern. Werfen Sie im Vorfeld schon einmal einen Blick auf die Dokumentation zu AppState in Pace.
- Die beiden ersten Schritte stellen eine gute Basis für ein erfolgreiches Testfallautomatisierungsprojekt dar. Die meisten getesteten Anwendungen haben einige Anwendungsfälle, die sich nur schwierig automatisieren lassen. Jetzt ist die Zeit, um die Anwendungsfälle zu bearbeiten, deren Schwierigkeitsgrad überdurchschnittlich ist. Wenn Sie sie lösen können, dann betrachten Sie Ihr Testautomatisierungssystem als zu 80 % bereit für die Produktion, d. h., dass automatisierte Testfälle Teil der CI/CD-Pipelines werden.
„Testautomatisierungssystem als zu 80 % bereit“ – was soll das heißen? Es heißt, dass Sie loslegen können. Ihr Testautomatisierungssystem ist niemals perfekt, sondern es erfordert fortwährende Entwicklung und Wartung, genauso wie jedes andere Softwareentwicklungsprojekt. Wenn Sie Test Automation as a Service oder Open-Source-Testautomatisierungsframeworks verwenden, sollten Sie Ihre Testautomatisierung an die neuen Features anpassen, auf die Sie dann Zugriff haben. Gleiches gilt für die regelmäßig veröffentlichten Bugfixes. Wenn Sie dann aber den Punkt erreicht haben, an dem 80 % erledigt sind, sollten Sie auch die Systembeschränkungen kennen, die Ihnen die Sicherheit geben, mit dem Testautomatisierungssystem fortzufahren.
Metriken beim Skalieren der Testautomatisierung
Wenn die Testautomatisierung betriebsbereit ist, müssen Sie unter Umständen immer noch an Prozessen arbeiten. Nehmen wir an, Ihr Projekt ist von mittlerer Größe und es sind mehr als zehn Personen in das Testen involviert, z. B. separate Personen oder Teams für Testfalldesign, Testfallautomatisierung und Entwicklung und Wartung des Testautomatisierungssystems. Bei kleineren Projekten übernehmen normalerweise ein bis zwei Personen alle Aufgaben, aber wenn Sie ein Team oder mehrere Teams involviert haben, ist es – wieder einmal – wichtig, über die Prozesse nachzudenken.
Die Vorlaufzeit bei der Automatisierung eines Testfalls ist eine gute Metrik, die die Prozesszeit der Testfallautomatisierung angibt. Sie werden beim Testfalldesign oftmals auf Probleme wie fehlende Details in einem Testfall, einem Anwendungsfall oder in Geschäftsprozessbeschreibungen stoßen. Dadurch können Testautomatisierungsingenieure daran gehindert werden, die Testfälle effizient zu automatisieren. Es gibt keinen klaren Leitfaden, was den Detaillierungsgrad angeht, da dieser von der Kompetenz des Testautomatisierungsingenieurs und seinem Wissen über das zu testende System abhängt. Ein Anwendungsfall für ein System wie Siebel CRM kann beispielsweise über 200 Schritte haben. Nur wenige Testautomatisierungsingenieure kennen die Anwendungslogik so gut, dass sie solche Testfälle entwerfen können. Testfälle werden oft von Subject Matter Experts (SME) entworfen, die unter Umständen keine Testautomatisierungsexperten sind. Die Schlüssel zum Erfolg sind die Kooperation zwischen Testautomatisierungsingenieuren und SMEs sowie ein minimales, aber brauchbares Ausmaß an Dokumentationszeit.
Unterschiedliche Spezifikationen und Automatisierungstechniken wie beispielsweise Acceptance Test Driven Development (ATDD) oder Behavior Driven Development (BDD) helfen dabei, eine gute Testabdeckung zu erreichen, aber nicht dabei, Automatisierung zu effizientem Arbeiten zu bringen. Die Verwendung von ATDD und BDD führt tendenziell zu einer zu hohen Anzahl der Schlüsselwörter bzw. Funktionen der Testautomatisierung. Folglich führt ein niedriger Wiederverwertbarkeitsprozentsatz des Schlüsselworts zu einem erhöhten Wartungsaufwand. Wenn Ihr Testautomatisierungssystem gesund bleiben soll, müssen Sie also die Anzahl der Schlüsselwörter bzw. Funktionen der Testautomatisierung niedrig halten.
Diese Skalierungsgesetze haben ihre Gültigkeit unabhängig davon, ob Sie ein einzelner Automatisierungskünstler in einem Scrum-Team oder Mitglied eines größeren Automatisierungsteams sind. Für die Gesetze der Testautomatisierungseffizienz oder Metriken gilt ziemlich genau dasselbe, egal ob es sich um eine Person oder dutzende Testautomatisierungsingenieure handelt, die in den Automatisierungsprozess des Testfalls involviert sind.
Wartungsaufwand
Testfallautomatisierungszeit und Testfallwartungszeit waren die Schlüsselmetriken früherer Stufen. Die Testfallautomatisierungszeit ist am Anfang wichtig, um zu überprüfen, ob die Reife des Testfallautomatisierungsprozesses gut genug ist; in späteren Phasen wird sie aber kaum beachtet. In der Produktionsphase zeigen Testmetriken wie die kumulative Anzahl an Testfällen den Fortschritt an. Sollten hier Probleme auftreten, müssen sie behoben werden. Die andere Metrik, die Testfallwartungszeit, wird in Minuten gemessen, um einen effizienten Testfallwartungsprozess zu Beginn des Projekts sicherzustellen – im Beispielprojekt wurde das Ziel auf sieben Minuten gesetzt. Während der Produktionsphase verhält sich der Wartungsaufwand (%) relativ zu der Gesamtzahl der Arbeitsstunden, somit ist es am einfachsten, eine Wartungs-Subtask im Zeiterfassungstool des Projekts anzulegen. Zusätzlich zur Testfallwartungszeit sollte die Entwicklung und Wartung des Testautomatisierungssystems getrennt und verfolgt werden. Schauen wir uns die folgenden Metriken anhand von Beispielen an:
- Wartungsaufwand des Testautomatisierungssystems (Personenstunden, %)
- Wartungsaufwand der automatisierten Testfälle (Personenstunden, %)
Ich habe keine genauen Wartungsziele definiert gefunden, aber es ist ein ganz gutes Ziel, beide unter 20 % zu halten. Wenn Sie ein Team mit 10 Personen haben, die in der Testautomatisierung arbeiten, dann sollten maximal zwei Vollzeitkräfte für die Wartung und Entwicklung des Testautomationssystems abgestellt werden. Hinsichtlich der Testfallwartungszeit sollte ein Maximum von 1,5 Stunden je Tag und Testautomatisierungsingenieur veranschlagt werden. Diese Zahlen erwecken den Eindruck, dass sie nicht sonderlich schwer zu erreichen sind, aber je mehr automatisierte Testfälle Sie haben, desto mehr Zeit wird für Wartung benötigt. Ich erinnere mich an ein Projekt mit nur 3000 automatisierten Testfällen und 15 Testautomatisierungsingenieuren – der Wartungsaufwand lag bei 100 %, d. h., das Team konnte aufgrund der Komplexität der Testautomatisierungsarchitektur mit hunderten oder gar tausenden von Testautomatisierungsschlüsselwörtern keine neuen Testfälle veröffentlichen. Bei einem anderen Projekt gab es über 18.000 automatisierte Testfälle, und der Wartungsaufwand für die Testfälle lag bei 14,3 %. Je weniger Schlüsselwörter, desto weniger Wartung. Die Diskussion – oder Debatte – unter Testautomatisierungsexperten über die Schlüsselwortstruktur wird unter meinen Favoriten unter „ferner liefen“ aufgeführt. Ich komme darauf später in dieser Blogreihe zurück.
Messen, was zählt
Im Internet gibt es gute Testautomatisierungs-KPI-Leitfäden, aber ich möchte an dieser Stelle die Bedeutung des Metrikenpaars herausstellen, das ich zusätzlich zum normalen Set von Qualitätssicherungsmetriken verwende. Obwohl ich hauptsächlich über benutzerschnittstellenbasierte Testfallautomatisierungszeiten schreibe, sind sie gleichermaßen oder sogar mehr beim Modul- und Integrationstest von Bedeutung. Eine Geschichte von früher: Ich war Produktmanager eines Produkts namens Min Test Framework, Maemo/MeeGo, das die xUnit-Syntax unterstützte, aber als Hauptmerkmal auch über fortschrittliche Scripting-Unterstützung für Integrationstests verfügte. In der frühen Entwicklungsphase schaute ich eine Sprint-Demo an. Die Erstellung eines Testfalls dauerte 1 Minute 53 Sekunden. Ja, ich habe auf die Uhr geschaut. Ich habe den Zielwert auf 30 Sekunden gesetzt, und nach mehreren Sprints konnte ich erfreut ein ausführbares Testfall-Skeleton sehen, das innerhalb von 27 Sekunden generiert worden war. Die Vorlaufzeit verschiedener Prozesse ist der Kern des kontinuierlichen Verbesserungsprozesses, d. h. eine der Schlüsselmetriken, wenn wir effizient sein wollen. Schlussendlich heißt das: Die richtigen Metriken korrekt zur richtigen Zeit zu verwenden ist die Basis für eine erfolgreiche Testautomatisierung.
Die Literatur ist voller Key-Performance-Indicators (KPIs) für die Testautomatisierung. Leider messen die meisten von ihnen den Fortschritt und den Status des Tests. Ich würde behaupten, dass Testautomatisierungsmetriken wie Automation Progress, Coverage, Number of Defects, Test Duration etc. in einer frühen Phase eines Testautomatisierungsprojekts nicht geeignet sind. Diese Metriken treffen keine Aussage zur Arbeit, die erforderlich ist, um solche Testfortschritte zu erreichen. In Testautomatisierung wird investiert, um die Geschwindigkeit zu erhöhen, Kosten zu reduzieren und die Qualität zu verbessern. Wenn Sie Ihre Automatisierungszeit für Testfälle nicht messen, wissen Sie weder, ob Ihre Investition sich auszahlt, noch können Sie Ihre Testautomatisierung systematisch verbessern. Es ist wichtig, eine Feineinstellung für jede Minute vorzunehmen, die Sie für die Automatisierung eines Testfalls aufwenden, also quasi den Ausführungsschritt für einen Testfall in einzelne Sekunden zu unterteilen – bringen Sie Maßnahmen aus dem kontinuierlichen Verbesserungsprozess in Ihr Testautomatisierungsprojekt.
Ich beleuchte zwei spezifische Metriken zu Beginn eines neuen Testautomatisierungsprojekts: die Testfallautomatisierungszeit und die Testfallwartungszeit. Sie messen die Effizienz des Testautomatisierungsprozesses. Das obige Verlaufsdiagramm stammt von einem echten Projekt und zeigt eine Testfallautomation von 82 Testfällen über die ersten zehn Wochen. Zu Beginn lag die Dauer für die Automatisierung eines Testfalls nahe bei 60 Minuten; später schrumpfte sie dank mehrerer kleinen Innovationen und Feinabstimmung des Prozesses auf 20 Minuten. Wenn Sie sich den Verlauf genauer ansehen, gibt es drei wichtige Verbesserungszyklen, die im Diagramm sichtbar sind und die etwas über die strategische Herangehensweise an die Testautomatisierung aussagen:
- Starten Sie die Automatisierung mit einfachen Testfällen, um die Testautomatisierungsbasis für das Projekt zu errichten, z. B. zuverlässige, einfache und wiederverwendbare Schlüsselwörter.
- Wenn Sie mit der Zeit zufrieden sind, die für die Automatisierung einfacher Testfälle benötigt wird, legen Sie Ihren Fokus auf automatisierte Testdaten und Umgebungsmanagement sowie auf Prozeduren vor und nach den Testfällen. Ich werde später in der Blogreihe nochmals auf dieses Thema eingehen und ein Navigationskonzept namens „AppState“ erläutern. Werfen Sie im Vorfeld schon einmal einen Blick auf die Dokumentation zu AppState in Pace.
- Die beiden ersten Schritte stellen eine gute Basis für ein erfolgreiches Testfallautomatisierungsprojekt dar. Die meisten getesteten Anwendungen haben einige Anwendungsfälle, die sich nur schwierig automatisieren lassen. Jetzt ist die Zeit, um die Anwendungsfälle zu bearbeiten, deren Schwierigkeitsgrad überdurchschnittlich ist. Wenn Sie sie lösen können, dann betrachten Sie Ihr Testautomatisierungssystem als zu 80 % bereit für die Produktion, d. h., dass automatisierte Testfälle Teil der CI/CD-Pipelines werden.
„Testautomatisierungssystem als zu 80 % bereit“ – was soll das heißen? Es heißt, dass Sie loslegen können. Ihr Testautomatisierungssystem ist niemals perfekt, sondern es erfordert fortwährende Entwicklung und Wartung, genauso wie jedes andere Softwareentwicklungsprojekt. Wenn Sie Test Automation as a Service oder Open-Source-Testautomatisierungsframeworks verwenden, sollten Sie Ihre Testautomatisierung an die neuen Features anpassen, auf die Sie dann Zugriff haben. Gleiches gilt für die regelmäßig veröffentlichten Bugfixes. Wenn Sie dann aber den Punkt erreicht haben, an dem 80 % erledigt sind, sollten Sie auch die Systembeschränkungen kennen, die Ihnen die Sicherheit geben, mit dem Testautomatisierungssystem fortzufahren.
Metriken beim Skalieren der Testautomatisierung
Wenn die Testautomatisierung betriebsbereit ist, müssen Sie unter Umständen immer noch an Prozessen arbeiten. Nehmen wir an, Ihr Projekt ist von mittlerer Größe und es sind mehr als zehn Personen in das Testen involviert, z. B. separate Personen oder Teams für Testfalldesign, Testfallautomatisierung und Entwicklung und Wartung des Testautomatisierungssystems. Bei kleineren Projekten übernehmen normalerweise ein bis zwei Personen alle Aufgaben, aber wenn Sie ein Team oder mehrere Teams involviert haben, ist es – wieder einmal – wichtig, über die Prozesse nachzudenken.
Die Vorlaufzeit bei der Automatisierung eines Testfalls ist eine gute Metrik, die die Prozesszeit der Testfallautomatisierung angibt. Sie werden beim Testfalldesign oftmals auf Probleme wie fehlende Details in einem Testfall, einem Anwendungsfall oder in Geschäftsprozessbeschreibungen stoßen. Dadurch können Testautomatisierungsingenieure daran gehindert werden, die Testfälle effizient zu automatisieren. Es gibt keinen klaren Leitfaden, was den Detaillierungsgrad angeht, da dieser von der Kompetenz des Testautomatisierungsingenieurs und seinem Wissen über das zu testende System abhängt. Ein Anwendungsfall für ein System wie Siebel CRM kann beispielsweise über 200 Schritte haben. Nur wenige Testautomatisierungsingenieure kennen die Anwendungslogik so gut, dass sie solche Testfälle entwerfen können. Testfälle werden oft von Subject Matter Experts (SME) entworfen, die unter Umständen keine Testautomatisierungsexperten sind. Die Schlüssel zum Erfolg sind die Kooperation zwischen Testautomatisierungsingenieuren und SMEs sowie ein minimales, aber brauchbares Ausmaß an Dokumentationszeit.
Unterschiedliche Spezifikationen und Automatisierungstechniken wie beispielsweise Acceptance Test Driven Development (ATDD) oder Behavior Driven Development (BDD) helfen dabei, eine gute Testabdeckung zu erreichen, aber nicht dabei, Automatisierung zu effizientem Arbeiten zu bringen. Die Verwendung von ATDD und BDD führt tendenziell zu einer zu hohen Anzahl der Schlüsselwörter bzw. Funktionen der Testautomatisierung. Folglich führt ein niedriger Wiederverwertbarkeitsprozentsatz des Schlüsselworts zu einem erhöhten Wartungsaufwand. Wenn Ihr Testautomatisierungssystem gesund bleiben soll, müssen Sie also die Anzahl der Schlüsselwörter bzw. Funktionen der Testautomatisierung niedrig halten.
Diese Skalierungsgesetze haben ihre Gültigkeit unabhängig davon, ob Sie ein einzelner Automatisierungskünstler in einem Scrum-Team oder Mitglied eines größeren Automatisierungsteams sind. Für die Gesetze der Testautomatisierungseffizienz oder Metriken gilt ziemlich genau dasselbe, egal ob es sich um eine Person oder dutzende Testautomatisierungsingenieure handelt, die in den Automatisierungsprozess des Testfalls involviert sind.
Wartungsaufwand
Testfallautomatisierungszeit und Testfallwartungszeit waren die Schlüsselmetriken früherer Stufen. Die Testfallautomatisierungszeit ist am Anfang wichtig, um zu überprüfen, ob die Reife des Testfallautomatisierungsprozesses gut genug ist; in späteren Phasen wird sie aber kaum beachtet. In der Produktionsphase zeigen Testmetriken wie die kumulative Anzahl an Testfällen den Fortschritt an. Sollten hier Probleme auftreten, müssen sie behoben werden. Die andere Metrik, die Testfallwartungszeit, wird in Minuten gemessen, um einen effizienten Testfallwartungsprozess zu Beginn des Projekts sicherzustellen – im Beispielprojekt wurde das Ziel auf sieben Minuten gesetzt. Während der Produktionsphase verhält sich der Wartungsaufwand (%) relativ zu der Gesamtzahl der Arbeitsstunden, somit ist es am einfachsten, eine Wartungs-Subtask im Zeiterfassungstool des Projekts anzulegen. Zusätzlich zur Testfallwartungszeit sollte die Entwicklung und Wartung des Testautomatisierungssystems getrennt und verfolgt werden. Schauen wir uns die folgenden Metriken anhand von Beispielen an:
- Wartungsaufwand des Testautomatisierungssystems (Personenstunden, %)
- Wartungsaufwand der automatisierten Testfälle (Personenstunden, %)
Ich habe keine genauen Wartungsziele definiert gefunden, aber es ist ein ganz gutes Ziel, beide unter 20 % zu halten. Wenn Sie ein Team mit 10 Personen haben, die in der Testautomatisierung arbeiten, dann sollten maximal zwei Vollzeitkräfte für die Wartung und Entwicklung des Testautomationssystems abgestellt werden. Hinsichtlich der Testfallwartungszeit sollte ein Maximum von 1,5 Stunden je Tag und Testautomatisierungsingenieur veranschlagt werden. Diese Zahlen erwecken den Eindruck, dass sie nicht sonderlich schwer zu erreichen sind, aber je mehr automatisierte Testfälle Sie haben, desto mehr Zeit wird für Wartung benötigt. Ich erinnere mich an ein Projekt mit nur 3000 automatisierten Testfällen und 15 Testautomatisierungsingenieuren – der Wartungsaufwand lag bei 100 %, d. h., das Team konnte aufgrund der Komplexität der Testautomatisierungsarchitektur mit hunderten oder gar tausenden von Testautomatisierungsschlüsselwörtern keine neuen Testfälle veröffentlichen. Bei einem anderen Projekt gab es über 18.000 automatisierte Testfälle, und der Wartungsaufwand für die Testfälle lag bei 14,3 %. Je weniger Schlüsselwörter, desto weniger Wartung. Die Diskussion – oder Debatte – unter Testautomatisierungsexperten über die Schlüsselwortstruktur wird unter meinen Favoriten unter „ferner liefen“ aufgeführt. Ich komme darauf später in dieser Blogreihe zurück.
Messen, was zählt
Im Internet gibt es gute Testautomatisierungs-KPI-Leitfäden, aber ich möchte an dieser Stelle die Bedeutung des Metrikenpaars herausstellen, das ich zusätzlich zum normalen Set von Qualitätssicherungsmetriken verwende. Obwohl ich hauptsächlich über benutzerschnittstellenbasierte Testfallautomatisierungszeiten schreibe, sind sie gleichermaßen oder sogar mehr beim Modul- und Integrationstest von Bedeutung. Eine Geschichte von früher: Ich war Produktmanager eines Produkts namens Min Test Framework, Maemo/MeeGo, das die xUnit-Syntax unterstützte, aber als Hauptmerkmal auch über fortschrittliche Scripting-Unterstützung für Integrationstests verfügte. In der frühen Entwicklungsphase schaute ich eine Sprint-Demo an. Die Erstellung eines Testfalls dauerte 1 Minute 53 Sekunden. Ja, ich habe auf die Uhr geschaut. Ich habe den Zielwert auf 30 Sekunden gesetzt, und nach mehreren Sprints konnte ich erfreut ein ausführbares Testfall-Skeleton sehen, das innerhalb von 27 Sekunden generiert worden war. Die Vorlaufzeit verschiedener Prozesse ist der Kern des kontinuierlichen Verbesserungsprozesses, d. h. eine der Schlüsselmetriken, wenn wir effizient sein wollen. Schlussendlich heißt das: Die richtigen Metriken korrekt zur richtigen Zeit zu verwenden ist die Basis für eine erfolgreiche Testautomatisierung.
Der Autor:
Antti Heimola ist Senior Automation Architect bei Qentinel Oy in Finnland. Er hat mehr als 25 Jahre Erfahrung in der HW/SW-Automatisierung, einschließlich mehrerer Innovationen in diesem Bereich. Er hat in verschiedenen Funktionen gearbeitet, wie HW/SW-Designer, SW-Architekt, Programm-/Produktmanager, Testmanager und in der Agile/Lean-Berater. Coaching und die Weitergabe von Wissen liegen ihm heute besonders am Herzen.
Diese Blogreihe wird Stories zu den Themen Testautomatisierung, W-Modell und Agile vorstellen, insbesondere aber auch Dinge, die beim Aufbau einer Testautomatisierung berücksichtigt werden müssen – vom Ein-Mann-Betrieb bis zum tausendfachen Service wie bei dem Produkt https://qentinel.com/ Pace, das ich als Beispiel für die Themen Scripting-Techniken für Testautomatisierung und Test Automation as a Service verwende.
0 Kommentare