fbpx

Eine Einführung in Agile Testing

Agile Vorgehensmodelle werden mittlerweile von vielen Unternehmen für ihre Softwareentwicklungsprojekte eingesetzt. Dadurch sollte auch das Software Testing an den neuen Kontext angepasst werden. In diesem Artikel schauen wir uns die Besonderheiten vom Agile Testing an. Gerade die Rahmenbedingungen in der agilen Softwareentwicklung bieten gute Voraussetzung, um zusammen als Team eine Software zu entwickeln, die der Nutzer gerne verwendet. 

Besonderheiten von Agile Testing

In diesem Abschnitt schauen wir uns die Besonderheiten von Agile Testing an. Denn die agile Softwareentwicklung bietet einige Möglichkeiten, die wir für das Software Testing positiv nutzen können.

agile-testing

Agiles Testing sollte eine Aktivität sein 

In der agilen Softwareentwicklung kann das Software Testing von Beginn des Softwareentwicklungsprozesses involviert sein. Es sollte keine Phase sein, die erst beginnt, wenn die einzelnen Features/Funktionen implementiert sind. Das agile Testing kann schon beim Definieren der Anforderungen, im Scrum Umfeld den User Storys, involviert sein. Der agile Tester kann die User Storys hinterfragen und Mehrdeutigkeiten, fehlenden und widersprüchlichen Informationen identifizieren. Dies hat den großen Vorteil, dass beim agilen Testen der Fokus auf der Fehlervermeidung und frühen Fehlerfindung liegen kann.

Agiles Testing fördert das Validieren 

Beim Validieren geht es darum, sich die Frage zu stellen „bauen wir das richtige System?“. Hier geht es darum, die Anforderungen nach dem Mehrwert zu hinterfragen und ob dieser tatsächlich für die Stakeholder gegeben ist.  Da der agile Tester schon von Beginn des Softwareentwicklungsprozesses involviert ist, kann er die Anforderungen hinterfragen, bevor die User Storys umgesetzt sind. Hier hat er die Möglichkeit, den Mehrwert der Funktionalität kritisch zu hinterfragen und ob sie einen wirklichen Mehrwert für die beteiligten Stakeholder liefert. Dies kann er tun, weil in der agilen Softwareentwicklung der Kunde oft teils des Teams ist und dadurch kann sich der agile Software-Tester direktes Feedback einholen. Des Weiteren gibt es in jedem Zyklus einige agile Events, in denen direkter Kunden-/Nutzerkontakt möglich ist. Frühes Feedback von der Kunden-/Nutzerseite ist ein großer Vorteil in der agilen Softwareentwicklung. Dies sollten wir gerade im agilen Testen nutzen. 

Agiles Testing aus Fehlern lernen

Da die Release-Zyklen in der agilen Softwareentwicklung in der Regel kürzer sind, bekommen wir in kurzen Intervallen Feedback, wie beispielsweise in Form von Bugs, die identifiziert wurden. Diese Informationen können wir für das agile Testen nutzen, um die Prozesse zu optimieren.  

Beispiel: 

Wenn der Kunde eine Fehlerwirkung identifiziert hat und ein Fehlerbericht erstellt wurde, sollten wir als agiles Team nicht nur daran denken, den Bug zu fixen. Wir sollten uns die Frage stellen, warum wir diesen Fehler nicht vorher gefunden haben und auf welcher Teststufe wir diese Fehlerwirkung hätten identifizieren können. Anschließend sollten wir die Prozesse anpassen, dass wir diese Art von Fehlern schon so früh wie möglich identifizieren können. 

Agiles Testing Fokus auf dem Fehler vermeiden 

Fehler zu finden ist gut, Fehler zu vermeiden ist besser. Wenn wir Fehler finden, müssen diese in einem Fehlerbericht festgehalten werden. Es müssen neue User Storys erstellt und die Änderungen implementiert werden. Zu guter Letzt müssen diese Änderungen neu getestet werden. Dies ist ein Prozess, der Zeit und Geld kostet. Als agile Software-Tester haben wir durch die unterschiedlichen agilen Events die Möglichkeit, Fehler, die in der Vergangenheit aufgetreten sind, zu analysieren und die Ursache davon zu identifizieren. Wir können anschließend zusammen mit unserem agilen Team die Prozesse optimieren, um die in der Vergangenheit aufgetretenen Fehler in der Zukunft zu vermeiden. 

 

Als agiles Team gemeinsam das beste System entwickeln 

Im agilen Vorgehensmodell Scrum sind wir als cross-funktionales Team an allen Schritten im Entwicklungsprozess beteiligt. Dies fördert das Mindset, dass wir uns als Scrum Team für das Produkt verantwortlich fühlen. Dies hat den großen Vorteil, dass wir nicht nur auf unseren Aufgabenbereich schauen, sondern zusammen mit dem Team alles Mögliche tun, um das beste System zu entwickeln, das der Nutzer gerne nutzt und das für alle Stakeholder einen Mehrwert liefert. 

Als Software-Tester erst involviert, wenn die Funktion implementiert ist

Nehmen wir ein Gegenbeispiel: Du bist als Software-Tester erst in den Softwareentwicklungsprozess involviert, wenn die Funktionalität implementiert ist und Deine einzige Aufgabe ist es, zu checken, ob die dokumentierten Anforderungen umgesetzt sind. Des Weiteren kommunizierst Du mit den Softwareentwicklern nur über ein Ticketsystem. 

In diesem Beispiel gibt es eine klare Trennung des Aufgabenbereiches und Du als Software-Tester wirst Dich in der Regel nur um Deinen Aufgabenbereich kümmern. Mit dem Erstellen des Fehlerberichts hast Du Deine Aufgabe erfüllt. In dem beschriebenen Kontext wirst Du selten versuchen, aus dem Fehler zu lernen und zu schauen, wo ihr den Fehler hättet früher identifizieren können. Das liegt oft daran, dass Du nicht in den ganzen Softwareentwicklungsprozess involviert bist und dadurch die einzelnen Aktivitäten des Prozesses gar nicht kennst oder Dich dafür gar nicht verantwortlich fühlst.

Nur checken, ob die dokumentierten Anforderungen erfüllt sind 

Bei Anforderungen sollte klar unterschieden werden, zwischen dem, was der Kunde/Nutzer wirklich benötigt und was als Anforderung dokumentiert wurde. Die dokumentierten Anforderungen sind nur eine Rekonstruktion, von dem, was der Kunde/Nutzer wirklich benötigt. Sie sind quasi eine Abbildung und können von der Realität abweichen. 

Wenn der/die Software-Tester nur die Verantwortung hat zu checken, ob die dokumentierten Anforderungen erfüllt sind, wird er sich oft gar nicht fragen, ob die Anforderung, so wie sie dokumentiert sind, Sinn ergeben. Die Verantwortung gibt er/sie hier an den Business-Analysten, Requirements Engineer und Product Owner ab. 

Nur über ein Ticketsystem kommunizieren 

Da Du als Software-Tester mit den Softwareentwicklern nur über ein Ticketsystem kommunizierst, kommt oft kein Teamgefühl auf, sondern eher eine klare Trennung der Aufgabenbereiche und jede Partei fühlt sich nur für den eigenen Aufgabenbereich zuständig. Nachdem wir unsere Aufgaben erledigt haben, geben wir oft die Verantwortung ab und fühlen uns für den Rest des Prozesses nicht mehr verantwortlich. Darüber hinaus leidet oft die Kommunikation zwischen den unterschiedlichen Rollen. Es wird auch in der Regel kein „wir“ als Teamgefühl aufkommen. Dies hat zum Nachteil, dass im besten Fall jeder für seinen Aufgabenbereich sein Bestes gibt, sich jedoch niemand für das große Ganze verantwortlich fühlt. Das große Ganze sollte am Ende immer sein, das bestmögliche System zu entwickeln, das für alle beteiligten Stakeholder einen Mehrwert liefert.

Die Rolle des agilen Testers

Der agile Tester nimmt eine ganz besondere Rolle im agilen Testen ein. Die Rolle ist eine der vielseitigsten in der gesamten Softwareentwicklung. Einerseits kennt ein guter agiler Tester die Geschäftsprozesse, die von der Softwareanwendung abgebildet werden und hat das Fachwissen. Andererseits hat ein guter agiler Tester oft fundiertes technisches Wissen und Fähigkeiten. Dies nutzt er für unterschiedliche Aufgaben, wie beispielsweise Implementierung der Testautomatisierung und das Testen des Backends einer Anwendung. Des Weiteren bringt er Fähigkeiten aus dem Software Testing mit. Ein guter agiler Tester besitzt Fähigkeiten aus vielen unterschiedlichen Disziplinen. Dies macht die Rolle des agilen Testers so interessant und spannend. Er arbeitet oft in sehr enger zusammen mit:

agiler-tester
  • Dem Fachbereich 
  • Business Analysten 
  • Requirements Engineer 

Im agilen Vorgehensmodell Scrum ist er oft direkte Ansprechpartner für den Product Owner. Mit dem Product Owner stimmt er sich zu den einzelnen User Storys ab und nimmt diese zusammen mit dem Product Owner ab. 

Überdies arbeitet der agile Tester auch sehr eng mit den Softwareentwicklern zusammen.  Deshalb ist ein technisches Wissen von Vorteil. 

Der agile Tester ist auch oft der Quality Coach des Teams. In dieser Rolle schaffte er ein Qualitätsbewusstsein in seinem Team und zeigt Optimierungspotenzial auf, welches er zusammen mit dem Team umsetzt.

Testautomatisierung 

Testautomatisierung nimmt in agilen Softwareentwicklungsprojekten einen großen Stellenwert ein. Ein Grund ist, dass die Release-Zyklen kürzer sind und alle Beteiligten frühes Feedback zum aktuellen Status quo der Softwareanwendungen benötigen vor jedem Release. Ein zweiter Grund ist, dass Software in agilen Vorgehensmodellen inkrementell entwickelt wird. Bei der inkrementellen Entwicklung wird das Softwareprodukt aufeinander aufbauend entwickelt. Das heißt, es kommen immer neue Funktionalitäten zur Softwareanwendung hinzu. Nachdem eine neue Funktionalität zur Softwareanwendung hinzugekommen ist, sollte in der Regel überprüft werden, ob die alte Funktionalität wie definiert funktioniert. Diese Tests heißen Regressionstest und es wird geprüft, ob durch die Änderungen keine negativen Seiteneffekte entstanden sind.

Wer ist für die Testautomatisierung in einem agilen Team verantwortlich? 

Dies hängt ganz von dem agilen Team ab. Wenn der agile Tester Fähigkeiten in der Programmierung besitzt, übernimmt er in der Regel bestimmte Testautomatisierungsstufen. Diese sind oft die End-2-End-Testfälle, die mit der Softwareanwendung über die Benutzeroberfläche interagieren. Die Softwareentwickler implementieren normalerweise die Unit-Tests und Integrationstests. Welche automatisierten Testfälle von den Softwareentwicklern oder Software-Testern implementiert werden, kann jedoch von Team/Projekt unterschiedliche sein. Wichtig ist jedoch eine gute Kommunikation aller Parteien, damit die am Software Testing Prozess beteiligten Personen einen Überblick über die Testabdeckung haben. Wenn der agile Tester technisch versiert ist, kann er auch die Testautomatisierung für weitere Teststufen übernehmen. Idealerweise ist das ganze Team an der Testautomatisierung beteiligt. Der agile Software-Tester sollte den Hut aufhaben und den Überblick darüber haben, welche Aspekte der Softwareanwendung auf welchen Stufen mit automatisierten Testfällen abgedeckt sind.

Test Driven Development 

Einen Ansatz, den manche agile Teams einsetzen, ist das Test Driven Development (TDD). Beim TDD werden die automatisierten Testfälle vor der eigentlichen Implementierung der Funktionalität erstellt. Das heißt, wir implementieren erst unsere automatisierten Testfälle und anschließend die Funktionalität und führen unsere automatisierten Tests, solange während der Implementierung aus, bis diese nicht mehr fehlschlagen. Dies hat unter anderem den Vorteil, dass wir die Testbarkeit der neuen Funktionalität bei der Implementierung berücksichtigen und durch die automatisierten Testfälle eine hohe Testabdeckung erreichen können.  

test-driven-development

Agil Testing – Testentwurfsverfahren

Der agile Tester setzt im agilen Testing unterschiedliche Testentwurfsverfahren ein, wie beispielsweise: 

  • Spezifikationsbasierte Testentwurfsverfahren 
  • Erfahrungsbasierte Testverfahren 

Spezifikationsbasierte Testentwurfsverfahren 

Die spezifikationsbasierten Testentwurfsverfahren sind Black Box Tests und werden im agilen Testing häufig dafür genutzt, um zu verifizieren, ob die dokumentierten Anforderungen (User Storys) richtig umgesetzt wurden. Diese Testfälle können anschließend auch automatisiert und für Regressionstests genutzt werden. Die spezifikationsbasierten Testing-Methoden werden auch in traditionellen Softwareentwicklungsprojekten eingesetzt. 

Einen Einblick in das spezifikationsbasierte Testen anhand von Äquivalenzklassen bekommst Du im Artikel: Äquivalenzklassenbildung

Erfahrungsbasierte Testverfahren 

Das überwiegend eingesetzte erfahrungsbasierte Testverfahren in agilen Teams ist das explorative Testen. Das explorative Testen lässt sehr viel Freiraum, um die Erfahrung des agilen Testers voll einzubringen. Beim explorativen Testen geht es nicht nur darum zu verifizieren, ob die dokumentierten Anforderungen (User Storys) richtig umgesetzt sind. Vielmehr erforscht der agile Tester die Softwareanwendungen aus unterschiedlichen Perspektiven, um Informationen über die Softwareanwendung zu sammeln, die beispielsweise nicht dokumentiert sind. Dabei setzt er vor der explorativen Testing Session seinen Fokus auf bestimmte Aspekte der Softwareanwendung. 

Der explorative Testprozess kann die nachstehenden Aktivitäten beinhalten:

vorgehen-exploratives-testen

Das explorative Testen wird häufig in agilen Softwareentwicklungsprojekten eingesetzt, weil die wiederkehrenden Testfälle automatisiert werden können. Dies lässt dem agilen Tester den Freiraum nicht nur zu prüfen, ob die dokumentierten Anforderungen umgesetzt wurden, sondern auch die Softwareanwendung explorativ zu analysieren und zu hinterfragen. 

Beispiel – wie die genannten Testverfahren im agilen Testing eingesetzt werden können

Der Sprint startet und der agile Tester nutzt die dokumentierten Anforderungen (User Storys) als Informationsquelle. Er verwendet die spezifikationsbasierten Testentwurfsverfahren, um logische Testfälle zu definieren. Diese definierten Testfälle kann er, sobald die Funktionalität implementiert ist, automatisieren. Diese Testfälle können anschließend als Regressionstests genutzt werden. Der agile Tester muss also im nächsten Sprint, die Regressionstests nicht manuell ausführen, sondern kann sich ganz auf die neue Funktionalität, die im neuen Sprint entsteht, fokussieren und diese anhand des explorativen Testen erforschen. 

Mehr Informationen zum explorativen Testen und dessen Vor- und Nachteile bekommst Du im Artikel: Eine Einführung in das explorative Testen

White Box Tests 

Diese werden auch strukturbasierte Tests genannt. Um diese Tests zu erstellen, ist Wissen über die interne Struktur der Software nötig. White Box Tests werden in der Regel von den Softwareentwicklern im agilen Team erstellt. Die White Box Tests werden normalerweise als automatisierte Tests erstellt und ausgeführt. 

Weiter Informationen über die unterschiedlichen Testverfahren bekommst Du im Artikel: Software Testing Methoden 

Testaufwand schätzen

In traditionellen Vorgehensmodellen wird der Testaufwand in der Regel für den vollständigen Testprozess vor Beginn der Testing Phase geschätzt. Im agilen Testing wird der Testaufwand oft für jede einzelne Iteration geschätzt; im Scrum beispielsweise sind die Iterationen zwischen 1 und 4 Wochen. Das Schätzen des Testaufwands ist auch Aufgabe des agilen Teams. Im Scrum kann das Backlog Refinement vom Team genutzt werden, um den Testaufwand zu schätzen. Hier wird jedoch nicht der Aufwand des Testens isoliert geschätzt, sondern es findet eine gesamte Schätzung der User Story statt. Diese wird in sogenannten Story Points geschätzt. Die Story Points werden vom gesamten Team vergeben und der Testaufwand wird schon eingerechnet.

agile-testing-testaufwand-schätzen

Zusammenfassung: Agile Testing

Die agilen Vorgehensmodelle bringen einige Vorteile für das Software Testing mit. Die kurzen Release-Zyklen tragen dazu bei, dass alle Beteiligten frühes Feedback zu dem Status quo der Software bekommen. Dieses Feedback kann genutzt werden, um die Prozesse zu optimieren. Der Kontext ermöglicht es, dass wir im agilen Testing Fehler früher finden und Fehler vermeiden können. Die enge Zusammenarbeit mit den Kunden/Nutzern ermöglicht weiteres Feedback, das genutzt werden kann, um eine Software zu entwickeln, die der Nutzer gerne benutzt und die für alle Stakeholder einen Mehrwert liefert. Die Rolle des agilen Testers ist sehr vielseitig, spannend und erfordert Wissen aus unterschiedlichen Disziplinen.

Gretel Engel-Finke

Gretel Engel-Finke

Test Engineer Qcademy UG (haftungsbeschränkt)

Gretel Engel-Finke ist als Quereinsteigerin ins Software Testing gestartet. Ihre Leidenschaft ist es, in Softwareentwicklungsteams dazu beizutragen, Software zu entwickeln, die der User gerne nutzt. Sie beschäftigt sich nicht nur beruflich mit dem Thema Software Testing, sondern schreibt in ihrer Freizeit gerne Artikel zum Thema Software Testing und Testautomatisierung.

 Oliver Jaworski

Oliver Jaworski

Test Engineer

Oliver Jaworski wurde von seinem Bruder mit der Leidenschaft für das Software Testing angesteckt. Am Software Testing begeistert ihn, dass er kontinuierlich Neues lernen kann und sich mit modernen Technologien auseinandersetzen kann.