Eine Einführung in 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.