Teil 6: Testautomatisierung – Best Practices

Im fünften Teil der RFC Blogreihe Testautomatisierung beschäftigten wir uns mit den Einsatzmöglichkeiten für die Testautomatisierung.

Im letzten Blog zu diesem Thema geht es um die Vor- bzw. Zusammenstellung von Best Practices, die auf der umfangreichen Projekterfahrung der RFC Berater beruhen.

Die Testautomatisierung kann – richtig eingesetzt – aufwendige manuelle Testaktivitäten übernehmen und den Testprozess erheblich beschleunigen, da weniger Zeit damit verbracht wird, aufwendige bzw. repetitive Tests manuell auszuführen. Dadurch steht mehr Zeit zum Beispiel für die Erstellung neuer Tests zur Verfügung, um weitere Fehlerquellen in der zu testenden Anwendung zu finden.

Unsere Erfahrung hat gezeigt, dass die Umsetzung der Testautomatisierung in Softwareprojekten jedoch mit vielen Schwierigkeiten verbunden ist und Automatisierungsvorhaben oft trotz großer Anstrengungen bzw. Investitionen scheitern. Die Gründe dafür sind vielfältig. Aus einer falsch getroffenen Entscheidung in der Planungsphase können elementare Probleme in späteren Phasen resultieren, deren Behebung sehr viel Aufwand und Kosten erzeugen können. Das Fehlen von Experten mit ausreichend Know-how für den effizienten Aufbau einer effektiven Automationslösung kann dazu führen, dass die definierten Ziele nicht erreicht werden und kein Vertrauen bzgl. Testautomatisierung im Unternehmen geschaffen wird. Die nachfolgend in diesem Blog vorgestellte Auswahl an RFC Best Practices sollen zur Vermeidung derartiger Probleme beitragen.

Proof of Concept (PoC)

Bevor mit einem Automatisierungsvorhaben begonnen wird, sollte möglichst eine Machbarkeitsstudie (Proof of Concept – PoC) durchgeführt werden, um die prinzipielle Durchführbarkeit zu belegen. Dazu sollte ein fachlich einfaches, aber technisch „interessantes“ Beispiel für die Prüfung der Automatisierbarkeit ausgewählt werden. Es ist darauf zu achten, dass die Umsetzung im Rahmen bestehender Konzepte und Prozesse erfolgt. Da oftmals die unterschiedlichen Akteure bzw. Organisationseinheiten/Abteilungen (Fachbereich, Tester, Testautomatisierer) erstmalig zusammenarbeiten, dient der PoC auch dazu, sich kennenzulernen, sich offen auszutauschen, die verschiedenen Erwartungshaltungen frühzeitig zu klären und ein gemeinsames Verständnis für die Vorteile der Testautomatisierung zu schaffen. Ein PoC ist somit eine Chance, das Interesse zu wecken, gemeinsam eine bestmögliche Automationslösung zu erarbeiten, wovon alle Beteiligten schlussendlich profitieren.

Stringente Vorgehensweise (Traceability)

Auch bei der Testautomatisierung ist – analog zu manuellen Tests – bei der Implementierung der zu automatisierenden Testfälle auf die Rückverfolgbarkeit (Traceability) der Testfälle und Anforderungen zu achten. Mit der Automatisierung sollte immer erst dann begonnen werden, wenn sowohl die Testfälle als auch die referenzierten Anforderungen gut dokumentiert sind.

Eine hohe Quantität an Testfällen bedeutet nicht automatisch eine hohe Qualität. Das gilt auch für eine Testautomatisierung. Eine gute Grundlage ist daher ein strukturierter Plan, der nicht nur Zeitpunkt und Aspekt des jeweiligen Tests berücksichtigt, sondern auch Vorbedingungen hinsichtlich Konfiguration oder Testdaten.

Als Einsteiger sollte man mit einem Bereich beginnen, der möglichst einfach zu automatisieren ist. Wenn ausreichend Erfahrung vorhanden Ist, dann bieten sich die folgenden Bereiche an:

  • höchstes technisches Risiko
  • höchster Business Value
  • häufigster Testbedarf bzw. größter manueller Aufwand

Welcher Ansatz auch immer gewählt wird: Man startet klein und baut kontinuierlich aus.

Testumfang – Auswahl der zu automatisierenden Testfälle

Im ersten Schritt sollten zunächst die Ziele der Testautomatisierung definiert werden, um sich dann auf die Auswahl der „richtigen“ Testfälle zu konzentrieren. Dabei geht es auch um die Frage, welche Testarten für die Testautomation gut geeignet sind und die Entscheidung, was genau automatisiert werden soll. Dadurch werden unnötiger Aufwand und weitere Probleme vermieden, die eigentlich mit der Testautomatisierung eingespart bzw. gelöst werden sollen. Tests, die sehr wenig zeitlichen Aufwand erfordern und schnell manuell durchgeführt werden können, fallen zwar augenscheinlich nicht unter die Kategorie Automatisierung, jedoch bei einer großen Testfallanzahl und/oder häufigen Testwiederholungen (ggf. auf unterschiedlicher Hardware, mit unterschiedlichen Laufzeitparametern und/oder Testdaten) lohnt sich evtl. dennoch eine Überprüfung. Auch bei sehr langen Laufzeiten und den sich daraus ergebenden Wartezeiten kann durch eine Testautomatisierung häufig Zeit eingespart werden.

Im Prinzip lässt sich jeder Softwaretest automatisieren. Man sollte sich aber immer die Frage stellen, ob es nicht günstiger ist, einen Test manuell durchzuführen, anstatt ihn aufwändig zu automatisieren und entsprechend zu warten. Dieser Aufwand sollte in erster Linie für jene Tests betrieben werden, die ein Maximum an Rentabilität versprechen. Nachfolgend ist eine Kriterienliste zusammengestellt, die die Auswahl von zu automatisierenden Testfällen unterstützt:

  • Regressionstests
  • Je höher die Wiederholungsfrequenz von Regressionstests ist, desto mehr lohnt sich die Automatisierung solcher Testfälle meist noch vor allen anderen Tests
  • Smoke Tests
  • Je nach Anzahl und Umfang der Regressionstests kann es sinnvoll sein, nicht alle Regressionstests bei jedem neuen Build auszuführen. Smoke Tests sind eine Unterkategorie von Regressionstests. Sie dienen dazu, zu überprüfen, ob ein neuer Build stabil ist, bevor Zeit in weitere Tests investiert wird. Typische Tests im Rahmen eines Smoke Tests sind z.B. der Anwendungsstart und das Einloggen sowie die korrekte Ausführung von Basisfunktionen ggf. verbunden mit der Verarbeitung eines „Standard“-Testdatenportfolios. Diese Tests sollten Teil der kontinuierlichen Integration (continuous integration CI) sein und bei jedem neuen Build möglichst automatisch durchgeführt werden.
  • Features Tests
    • Stabilität
    • Solange eine Funktionalität sich noch in der Entwicklungs- bzw. Programmierphase befindet, sollten die dazugehörigen Tests besser manuell ausgeführt werden, da dies ansonsten aufgrund des zu erwartenden Anpassungsbedarfs bei den automatisierten Tests zu hohen Wartungskosten führen kann.
    • Impact
    • Mit der Durchführung einer Risikoanalyse können die Features identifiziert werden, die das größte Risiko bergen, d.h. bei fehlerhafter Ausführung die meisten Kosten verursachen würden. Die Tests für diese Funktionalitäten sind dann zu automatisieren und in den Regressionstest einzubinden.
  • Datengetriebene Tests
  • Jeder Test mit Wiederholungscharakter eignet sich besonders zur Automatisierung. Datengetriebene Tests sind hierfür ein sehr gutes Beispiel. Anstatt bei jedem Durchlauf manuell verschiedene Datensets wie z.B. Benutzername, Passwort, Konto, Zahlungsart usw. einzugeben, um diese Felder dann zu validieren, ist es vorteilhaft, diese Tests zu automatisieren.
  • Lasttests
  • Lasttests können als eine spezielle Art von datengetriebenen Tests angesehen werden. Sie überprüfen, wie das System auf eine bestimmte theoretische Datenlast reagiert. Diese Last lässt sich simulieren, indem man einen datengetriebenen Test mit einem Tool kombiniert, das die Testaktivitäten parallel verteilt, in mehreren Iterationen mit steigender Last ausführen kann.
  • Cross-Browser-Tests
  • Mit Cross-Browser-Tests kann sicherstellen werden, dass eine Webanwendung unabhängig vom verwendeten Browser bzw. der Browserversion korrekt arbeitet. Normalerweise ist es nicht nötig, alle Tests auf sämtlichen Browser- und Geräte-Kombinationen durchzuführen. Stattdessen reicht es üblicherweise, sich auf die Risiko-Features und die zurzeit gängigsten Browserversionen zu konzentrieren und diese Tests zu automatisieren.
  • Technologie-Kombinationen-Tests
  • Häufig kommen bei den zu testenden Applikationen verschiedene Technologien zum Einsatz, beispielsweise in einer Web-Applikation mit einer Datenbank im Backend. Um in solchen Umgebungen End-to-End-Tests einfacher zu gestalten, sollte am besten ein Automatisierungsframework implementiert werden, das sämtliche verwendete Technologien unterstützt.
  • Schwierig zu automatisierenden Tests
  • Das Automatisieren der folgenden Testarten stellt häufig eine Herausforderung dar. Das bedeutet allerdings nicht zwingend, dass sie nicht automatisiert werden können bzw. sollten. Es muss aber mit höheren Kosten bei der Erstellung und Wartung gerechnet werden. Die Schwierigkeit der Automatisierung hängt stark von der Technologie der zu testenden Anwendung ab. Bereits bei der Evaluierung eines Automatisierungstools oder der Durchführung eines PoC sollte überprüft werden, ob und wie ein Tool unterstützen kann.
    • Dynamische Inhalte
    • Es gibt viele Arten von dynamischen Inhalten, wie zum Beispiel Internetseiten, die sich abhängig von Benutzereinstellungen verändern. Das Testen von solchen Inhalten gestaltet sich herausfordernd, da der aktuelle Zustand des Inhalts zum Zeitpunkt der Testausführung nicht bekannt bzw. konstant ist.
    • Umgang mit Wartezeiten
    • Der Umgang mit Wartezeiten ist wichtig. Automatisierte Tests dürfen nicht direkt fehlschlagen, nur weil das System langsamer als sonst reagiert. Gleichzeitig muss aber auch sichergestellt sein, dass der Test fehlschlägt, wenn nach einer möglichst konfigurierbaren Zeitspanne nichts geschieht.
    • Benachrichtigungen / Popups
    • Automatisierte Tests können auch aufgrund von unerwarteten Benachrichtigungen oder Popups fehlschlagen. Die davon betroffenen Tests sind so zu konfigurieren, dass sie mit dieser Art von Ereignis umgehen können.
    • Komplexe Workflows
    • Das Automatisieren von Workflows ist oft eine Herausforderung, da i.d.R. solch ein Test aus einer Serie von Testfällen besteht, die jeweils einen Schritt im Workflow abdecken und sequenziell ausgeführt werden. Schlägt ein Schritt fehl, können alle weiteren nicht ausgeführt werden (negativer Dominoeffekt). Da jeder Workflow nur einen bestimmten Pfad durch die Anwendung darstellt, besteht das Risiko, dass Fehler nicht entdeckt werden. Um diese Probleme zu vermeiden, ist es wichtig, die Testfälle modular und unabhängig voneinander aufzubauen. Mit einer schlüsselwortgetriebenen Testfalldarstellung können eine Vielzahl von unterschiedlichen Abläufen abgedeckt werden.
  • Tests, die nicht automatisiert werden sollten
  • Manche Arten von Tests können oder sollten nicht automatisiert werden. Das schließt solche Tests ein, die für die Automatisierung mehr Zeit und Arbeit beanspruchen, als sie später potenziell einsparen würden. Solche Tests sollten immer manuell ausgeführt werden.
    • Einmalige Tests
    • Es dauert oft länger, einen einmalig durchzuführenden Test zu automatisieren als ihn einfach manuell auszuführen.
    • Unvorhersehbare Ergebnisse
    • Es sollten nur Tests automatisiert werden, die objektiv nachvollziehbare, messbare Ergebnisse erzeugen. Wenn ein Test keine objektiven Erfolgskriterien hat, ist es besser, ihn manuell auszuführen.
    • Nicht automatisierbare Features
    • Manche Features sind so konzipiert, dass sie sich nicht automatisieren lassen, wie z.B. CAPTCHAs in Web-Foren. Statt also Zeit auf die Automatisierung dieses Features zu verschwenden, ist es besser, diese in der Testumgebung zu deaktivieren oder zu umgehen. Nur wenn das nicht möglich ist, sollte dieser Testschritt manuell von einem Tester durchgeführt werden und die nachfolgenden Testschritte dann wieder automatisiert ablaufen. Dazu muss der Test so konfiguriert werden, dass er pausiert, bis der manuelle Testschritt erfolgreich ausgeführt wurde.
    • Instabile Features
    • Instabile Funktionalitäten sollten immer manuell getestet werden. Sinnvoll ist es, erst dann Zeit in die Automatisierung zu investieren, wenn die Entwicklung des Features einen stabilen Zustand erreicht hat.

Wartbarkeit früh einplanen

Viele Testautomatisierungsprojekte scheitern häufig daran, dass die Automatisierung irgendwann nicht mehr wartbar ist, weil sie z.B. im Laufe der Zeit zu teuer oder technisch zu komplex wird. Um dieses Problem zu vermeiden, sollte man möglichst frühzeitig mit Projektstart Techniken zur Maximierung der Wartbarkeit (wie z.B. Namenskonventionen, Modularisierung und Parametrisierung etc.) einplanen.

Wartungstechnisch ist es sinnvoll, die Testdaten von der technischen Verarbeitungslogik zu trennen sowie die Kapselung der Erkennungsdefinitionen von GUI-Elementen durch Einsatz eines Object Repository. Der Einsatz eines Code-Analysetools ist eine effektive Methode, um die Qualität von Quellcodes zu prüfen.

Man sollte sich auch frühzeitig darüber Gedanken machen, wie der Testprozess sinnvoll und effektiv gestaltet werden kann. Häufig werden Tool-Entscheidungen vor den Prozess-Entscheidungen getroffen, um dann den Prozess an das Tool anzupassen. Dies führt häufig zu Irritationen bei den am Testprozess beteiligten Organisationseinheiten bzw. Mitarbeitern und Mitarbeiterinnen.

Zu einer guten Wartbarkeit eines Systems gehört immer eine gute Dokumentation. Dies gilt auch für die Testautomatisierung. Leider fehlt oft eine (gute) Dokumentation der automatisierten Testfälle und Workflows sowie des Automatisierungsframeworks. Bei einer Veränderung der Teamstruktur stehen dann nicht nur bisherige Teamkollegen, sondern auch neue Mitarbeiter vor der Situation, dass sie relevante Informationen für die Arbeit nicht vorfinden und nur mit viel Zusatzaufwand die Informationslücken schließen können. Riskant wird es, wenn auf ungeprüften Annahmen weitergearbeitet wird.

Die Dokumentation sollte möglichst immer zeitnahe zur durchgeführten Tätigkeit erfolgen. Das spart Zeit und Aufwand für alle Beteiligten. Unterstützen können bei dieser Arbeit technische Hilfsmittel wie kollaborative Software oder Wikis. Wichtig ist, für das Thema Dokumentation entsprechend Zeit einzuplanen, um Klarheit zu schaffen, wann was und wie dokumentiert wird. Auch die automatisierte Dokumentation der Testdurchführung wie z.B. das Erstellen von Screenshots oder Log-Dateien mit Protokollierung der einzelnen Testschritte kann sehr hilfreich sein.

Fachliches Know-how – das Produkt verstehen

Testautomatisierung ist nicht in allen Szenarien sinnvoll. Gerade bei stetig zunehmender Funktionalität und Komplexität eines Softwareprodukts kann der Einsatz von Testautomation zwar erheblichen Vorteil bringen, jedoch auch erhebliche Aufwände bei geringem Nutzen verursachen. Je besser man das Produkt und seinen Entwicklungszyklus versteht, desto besser lässt sich ermitteln, wann und wie einzelne Bereiche automatisiert getestet werden sollten. Funktionalität, die vor allem repetitive Tests durchläuft (insbesondere inkrementeller Regressionsanteil bei agiler Entwicklung), ist optimal geeignet. Das gilt auch für Features, die bereits fest definiert sind und höchstwahrscheinlich keine großen Änderungen mehr durchlaufen müssen. Grundsätzlich ist es wichtig, eine konkrete Vorstellung zu haben, was und mit welchem Ziel getestet werden soll.

Technisches Know-how – nicht jeder kann automatisieren

Testautomatisierung kann nicht auf Anhieb von jedem durchgeführt werden. Es erfordert ein gewisses Know-how, um die teilweise sehr speziellen Tools optimal einsetzen zu können. Wenn niemand in dem Testteam über die erforderlichen Kenntnisse verfügt, dann ist es sinnvoll, einen externen Spezialisten mit der nötigen Expertise in das Projekt einzubinden.

Kommunikation

Kommunikation ist bei einem Testautomatisierungsvorhaben das A und O. Viele Fehler bei der Automatisierung entstehen dadurch, dass die Mitarbeiter – Fachexperten in ihrem Gebiet – nicht oder nicht ausreichend miteinander kommunizieren. Meistens entstehen aufgrund von mangelhaften Informationen Interpretationsannahmen, die zu falschen Ergebnissen führen. Eine klare, zielgerichtete und rechtzeitige Kommunikation ist daher fest im Testprozess zu etablieren. Insbesondere die enge Zusammenarbeit zwischen Testanalyst (Fachbereich), Tester und Testautomatisierer (IT-Bereich) ist elementar und kann durch räumliche Nähe gefördert werden. Hilfreich ist eine einheitliche Kommunikationsplattform, die alle im Projekt nutzen. Dabei können Kommunikationsschulungen der Mitarbeiter unterstützend wirken.

Fazit

Die richtige Vorgehensweise sowie Auswahl der zu automatisierenden Tests bestimmt maßgeblich den Erfolg eines Automatisierungsvorhabens. Ein PoC ist eine Chance, um neben der Machbarkeit auch die unterschiedlichen Erwartungshaltungen zu klären. Neben der erforderlichen methodischen Kompetenz im Bereich der Testautomatisierung wird der Erfolg aber auch immer maßgeblich von der Quantität und Qualität der Kommunikation beeinflusst.

Die vielen Best Practices zeigen auf, dass dem Thema Testautomatisierung viel Beachtung geschenkt werden muss und eine professionelle Herangehensweise zwingend erforderlich ist.

RFC unterstützt Sie gerne mit der Kompetenz seiner Berater und Beraterinnen bei der erfolgreichen Umsetzung Ihres Vorhabens in der Testautomatisierung.

__________________________________________________________________________________

Übersicht aller Blogs unserer RFC Blogreihe Testautomatisierung

Blog 1: Einleitung der Blogreihe: Testautomatisierung – Was ist die Motivation für den Einsatz von automatisierten Testverfahren?

Blog 2: Der Testprozess – Aspekte der Automatisierung

Blog 3: Was ist bei der Konzeption eines Automatisierungsframeworks zu beachten?

Blog 4: Wie funktioniert die Integration in die Organisation?

Blog 5: Welche Einsatzmöglichkeiten gibt es für die Testautomatisierung?

Blog 6: Testautomatisierung – Best Practices

Hat Ihnen unsere Blogreihe gefallen? Haben Sie Fragen, Probleme, Anmerkungen oder neue Ideen? Dann möchte RFC Sie gerne zu einem Anfang nächsten Jahres geplanten WEB-Events einladen, um mit Ihnen über das Thema Testautomatisierung zu diskutieren. Sie können sich gerne schon jetzt vormerken lassen, (mailto:kompetenz[at]rfc-professionals.com), damit wir Sie direkt einladen können.

Steffen Hahn

Steffen Hahn

Hans Willhoeft

Hans Willhöft

Quelle: Basiswissen Testautomatisierung, dpunkt.verlag