Agiles Testen

Agiles Testen folgt den vier Leitsätzen des agilen Manifests, die 2001 von Ken Schwaber, Jeff Sutherland und anderen formuliert wurden:

• Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.
• Funktionierende Software ist wichtiger als umfassende Dokumentation.
• Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen.
• Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans.

Im Vergleich zu sequentiellen Vorgehensmodellen bestehen agile Projekte aus Iterationen. Zum Ende jeder Iteration wird ein Teilprodukt ausgeliefert. Anstatt einer ausgiebigen Planungs- und Dokumentationsphase, wird früh mit der Entwicklung angefangen. Die Anforderungen werden nicht in Form eines Lastenhefts definiert, sondern können sich zur Projektlaufzeit mehrmals ändern. Somit sind Software und die zugehörigen Testfälle häufiger Änderungen ausgesetzt, womit klassische Testmethoden an ihre Grenzen stoßen. Aus diesem Grund wurden im agilen Umfeld neue Methoden etabliert. Bevor wir einige dieser Methoden betrachten, schauen wir uns folgendes Zitat an:

“The fact remains: Good design is testable, and design that isn’t testable is bad.”

Michael Feathers – Autor und Softwareentwickler

Das Zitat verdeutlicht, dass eine strukturierte Implementierung das Erstellen von Testfällen vereinfacht. Zur frühzeitigen Vermeidung und Erkennung von Fehlern in Design und Funktionalität eignet sich deshalb der Test-First-Ansatz. Dabei werden bereits vor Beginn der Entwicklung Testfälle implementiert. Agile Tester spielen eine Schlüsselrolle bei der Etablierung dieses Ansatzes und sollten deshalb sehr früh in das Projekt einbezogen werden.

Test-First-Ansatz

Die Methoden Test-Driven Development, Acceptance-Test-Driven Development und Behaviour-Driven Development dürfen heutzutage in agilen Projekten nicht fehlen. Sie sind nicht als konkurrierende, sondern sich als ergänzende Methoden zu verstehen, die jeweils in den verschiedenen Test-Ebenen (Unit, System, Integration und Akzeptanz) eingesetzt werden können. Sie haben die gemeinsame Eigenschaft, dass Tests definiert werden, bevor Code geschrieben wird. Auch nachher können natürlich Testfälle hinzugefügt werden, um einen hohen Abdeckungsgrad an Testfällen zu erreichen.

Test-Driven Development (TDD)

Bei der testgetriebenen Entwicklung werden sogenannte Unit-Tests erstellt, die den zu erstellenden Code auf der niedrigsten Ebene testen soll.
Der Prozess für testgetriebene Entwicklung ist:
– Testimplementierung. Tests schlagen am Anfang fehl, da kein Code implementiert wurde.
– Code implementieren und Tests in wiederkehrenden Schleifen ausführen bis sie bestanden werden.
– Bei Bedarf Code überarbeiten (refactoring) und Tests erneut ausführen und sicherstellen, dass sie weiterhin bestanden werden.

Dieser Vorgang wird für neu implementierten Code wiederholt.

Die Tests sind automatisiert und werden im Rahmen der Continous Integration (CI) verwendet. Die Verantwortung und Implementierung obliegen dem Entwickler.

Behaviour-Driven Development (BDD)

BDD ist eine gängige Methode in agilen Projekten und kombiniert Prinzipien aus dem Domain-Driven Design und dem eingangs beschriebenen TDD. Im Gegensatz zu TDD wird bei BDD die Software auch aus Sicht des Anwenders betrachtet. Es eignet sich hervorragend, um die Lücke zwischen Fachabteilung und Testautomatisierer zu schließen. Dabei fokussiert man sich auf die Funktionsweise von Komponenten (besteht aus mehreren Units). Die Tests werden mit Hilfe einer gemeinsamen Terminologie in strukturierter Weise geschrieben. Man redet auch in diesem Kontext von Behaviour Driven Testing (BDT).

Dazu eignet sich die Given-When-Then Schreibweise, um fachliche Akzeptanzkriterien zu definieren, die mithilfe von geeigneten BDD-Testframeworks in Akzeptanztests transformiert werden können.

• Gegebene Ausgangslage (Given)
• Wenn eine Situation eintritt oder eine Aktion ausgeführt wird (When)
• Dann werden erwartete Ergebnisse zurückgeliefert (Then)

Beispiel mit der gängigen Gherkin-Sprache und dem Testframework Cucumber:

Funktionalität: Loginmaske auf der Startseite
	Szenario 1: Login mit gültigen Daten
		Angenommen ich befinde mich auf der Startseite
		Und ich gebe in das Feld Nutzernamen "Testkunde" ein
                Und ich gebe in das Feld Kennwort "1234" ein
		Wenn ich auf den Button einloggen klicke
		Dann bin ich eingeloggt und werde auf den Kundenbereich weitergeleitet

Acceptance-Test-Driven Development (ATDD)

ATDD leitet sich aus der BDD Methode ab und wird hauptsächlich bei der Dokumentierung von Akzeptanzkriterien innerhalb von User Stories verwendet. Es empfiehlt sich die Given-When-Then Schreibweise zu verwenden. Dies ermöglicht zum einen den Entwicklern die Implementierung anhand der Akzeptanzkriterien voranzutreiben und zum anderen den Testern die Akzeptanzkriterien direkt zu automatisieren. Der Zyklus dazu könnte folgendermaßen aussehen:

• Product Owner (PO) und Business Analyst (BA) definieren in Zusammenarbeit mit dem Team Akzeptanzkriterien mit der Given-When-Then Schreibweise.
• Tester transformiert diese mithilfe von geeigneten Testwerkzeugen (siehe unten) in automatisierte Testfälle.
• Entwickler implementieren die gewünschte Funktion.
• Tester führen die automatisierten Tests durch. Erst wenn die Tests erfolgreich sind, kann die User Story abgenommen werden.

Testwerkzeuge für ATTD und BDD:

Gauge | RSpec | Lettuce | Behat | Concordion | SpecFlow | FitNesse | JBehave | easyb | Thucydides | Spectacular

Pyramide der Testautomatisierung

Die Pyramide der Testautomatisierung nach Mike Cohn veranschaulicht wie der Anteil von automatisierten Tests auf verschiedenen Teststufen aussehen sollte, damit die Wirtschaftlichkeit der Qualitätsmaßnahmen gewährleistet wird.

Demnach sollte der Anteil der Unittests am höchsten sein, da die Kosten und die Ausführungszeiten gering sind. In den höheren Testebenen erhöhen sich Kosten und Ausführungszeiten, da die Interaktion zwischen verschiedenen Domänen die Komplexität der Testfälle erhöhen. Daraus resultierend sollte die Anzahl der Testfälle in den höheren Ebenen proportional abnehmen. Ich habe Projekte erlebt, bei denen anstelle einer Pyramide eine Kegel-Form oder eine Sanduhr-Form vorlag. Dies sollte unbedingt aus Gründen der Wirtschaftlichkeit und Ausführungszeiten vermieden werden.

Die vier Testquadranten des agilen Testens

Falls Sie sich fragen welche Testarten berücksichtigt werden sollten, um nach einer Iteration qualitative Software auszuliefern, dann können Sie sich an den vier Testquadranten des agilen Testens (von Brian Marick) orientieren. Die Nummerierung der Quadranten stellt keine Reihenfolge dar, die strikt abzuarbeiten ist, sondern dient lediglich der Kategorisierung. Das Modell kann vor einer Iteration helfen alle relevanten Testarten zu identifizieren und benötigte Ressourcen einzuplanen.

Quadrant 1: Technisch orientiert und teamunterstützend

Im ersten Quadranten befinden sich die durch die TDD Methode entwickelte Unit- und Komponententests. Die Entwickler erhalten schnelle und aufwandsschonende Rückmeldungen. Die Testfälle sind Bestandteil der Regressionstests.

Quadrant 2: Fachlich orientiert und teamunterstützend

Im zweiten Quadranten kommen die BDD und ATDD Methoden auf der Integrations- und Systemtestebene zum Einsatz. Unter Berücksichtigung der Testpyramide sollte die Anzahl dieser Testfälle geringer ausfallen als auf der Unit- und Komponentenebene. Auch Prototypen oder Simulationen können zum Einsatz kommen, um die Interaktion der Anwender zu analysieren.

Quadrant 3: Fachlich orientiert und produkthinterfragend

Im dritten Quadranten kommen überwiegend manuelle Tests zum Einsatz. Testgetriebene Methoden (z.B. TDD, BDD, ATDD) spielen dabei keine Rolle. Der Fokus liegt eher auf der Interaktion mit realen Anwendern, die neben der Evaluierung der Fachlichkeit auch Usability-Aspekte berücksichtigen.

Quadrant 4: Technisch orientiert und produkthinterfragend

Im vierten Quadranten liegt der Fokus hauptsächlich auf den Tests der nichtfunktionalen Anforderungen, wie z.B. Performanz und Robustheit. Dabei werden automatisierte Tests auf der Systemebene mithilfe spezieller Testwerkzeuge durch Experten aus dem Gebiet Last- und Performance-Test ausgeführt.

Bei weiteren Fragen können Sie mich gerne kontaktieren.