Agile Testing II – kein Agile Development ohne Agile-Test-Integration

Woher der Begriff des Agile Developments kommt und wie sich Methoden wie Scrum und Kanban entwickelt haben, betrachteten wir in unserem letzten Artikel. Dabei wurde auch deutlich, dass der Anspruch von Agile Development erst dann erfüllt werden kann, wenn TesterInnen von Anfang an mit im Prozess integriert werden.

Der Standard für Testing

Den Standard für Testing setzt das International Software Testing Qualifications Board (ISTQB) in ihrem Tester-Zertifikat und vermittelt dort auch die Grundlagen für eine Implementation von TesterInnen in den agilen Entwicklungsprozess.

Das wird Whole-Team-Approach genannt: Alle Personen einer Entwicklung, also Stakeholder, Entwickler, die Fachbereiche und natürlich auch die TesterInnen sind von Anfang an in den Planungs- und Entwicklungsprozess integriert. Dementsprechend sollten TesterInnen, wie auch der Rest des Teams, bei den täglichen Meetings dabei sein, ihre Fortschritte kommunizieren, sich über den Fortschritt der Entwicklung informieren und in den Sprints klare Aufgaben übernehmen.

Merke: Eine DevOps ohne Tester schreibt sich vielleicht Agile auf die Fahne, für echtes Agile Development ist ein Tester aber unerlässlich. Ohne diese Rolle im Team wird den Tests nicht genügend Zeit und Wichtigkeit eingeräumt. Wenn nämlich im klassischen Scrum-Setting alle auch für das Testen verantwortlich sind, dann wird es erfahrungsgemäß weniger priorisiert und hinten angestellt. Nur so können entstehende Bedarfe in der Entwicklung in Echtzeit mitgedacht werden.

Teststrategie – die Etappen des agilen Testings

Die Hauptaufgabe einer agilen TesterIn ist das Planen von Tests entlang des Entwicklungsprozesses unter Berücksichtigung des tatsächlichen Ist-Standes. Je nach Teststufe ergeben sich verschiedene Testarten, die entweder automatisiert oder manuell durchgeführt werden müssen. Geht es um reine Funktionalitäten wie Konnektivität, die Skalierung von Apps auf verschiedene Device-Formate oder das Durchspielen bestimmter Prozesse (z.B. eines Warenkorb-Prozesses), bieten sich quantitative Methoden an, bei denen Testgeräte durch einen Computer emuliert werden.

Bei Appmatics haben wir allerdings die Überzeugung, dass eine Automatisierung nur auf echten Geräten sinnvoll ist, bestimmte Fehler lassen sich auf virtuellen Geräten aufgrund ihrer fehlenden Materialität gar nicht entdecken. Und letztlich bildet man mit der Emulation von Geräten exakt 0% der tatsächlichen NutzerInnen ab. Um die verschiedenen möglichen Anwendungen, Design und User Experience zu testen, sind manuelle Tests notwendig. Für das Finden nicht bedachter Nutzungsszenarien muss das geführte Testing auf Basis von Test Cases durch exploratives Testing ergänzt werden. Die Einzelnen Testarten, ob manuell oder automatisiert, gehen hierbei Hand in Hand. Je weiter die Entwicklung voranschreitet und je näher man eine release-fähige App kommt, desto nötiger werden manuelle Tests.

Teststatus bestimmen – Reagieren und Agieren in einem dynamischen Testumfeld

Für das Festhalten eines Status verwenden Agile Teams Task-Boards oder Burndown-Charts. Die Task-Boards sind dem Scrum-Board nachempfunden: Alle Aufgaben und die Story-Cards (also die Funktionen für den Endnutzer) sind hier festgehalten und werden in Spalten ihrem Status zugeordnet. Ein Burndown-Chart hingegen zeigt die noch zu bearbeitenden Aufgaben in Verhältnis zur verfügbaren Zeit an.

In Anbetracht von zahlreichen verschiedenen Faktoren ist diese Komplexitätsreduktion eine wesentliche Aufgabe von TesterInnen, die den Testfortschritt gewährleisten müssen. Innerhalb dieser Vergegenwärtigung des Status einer Entwicklung ist die Beherrschung des Regressionsrisikos. Einfach gesagt, müssen TesterInnen im Auge behalten, ob bereits funktionale Teile einer Anwendung nach einem neuen Entwicklungsschritt noch funktionieren, ob identifizierte Fehler behoben oder verschlimmbessert wurden.

Gerade hierfür müssen TesterInnen im Agile Development in der Lage sein, Parameter eines Tests so zu formalisieren, dass sie in nächsten Phasen automatisiert stattfinden können oder eine Einschätzung treffen, welche Regressionstests manuell ausgeführt werden.

Qualitätssicherung und Aufwände

Wie aus den hervorgehenden Paragraphen klar geworden sein sollte: Als Testerinnen schätzen wir oft ein, welche Aufwände realistisch sind. Je weiter eine Entwicklung voranschreitet, desto besser kennen wir ein Produkt und wissen auch, welches Testing an welcher Stelle Sinn ergibt.

Das große Ziel und die Aufgabe ist natürlich die Qualität im Sinne der User Stories zu sichern. Mit Blick auf das große Ganze erlangen Testerinnen so die Fähigkeiten Risiken einzuschätzen und notwendige Entwicklungen bzw. Bugfixes rechtzeitig einleiten zu können, um so Zeit und Ressourcen zu sparen.

Fazit: Testerinnen repräsentieren die Stakeholder

Vor zehn Jahren war diese ausgeprägte Rolle von Testerinnen noch nicht abzusehen. Doch seither hat die Professionalisierung von TesterInnen eine rasante Entwicklung gemacht: Als agile Tester repräsentieren wir die Kunden und die Endnutzer einer Entwicklung. So nehmen wir eine wichtige Perspektive auf den Entwicklungsprozess ein, die zum einen zu Priorisierungen und Fokussierung der Arbeit führt, Effizienzzugewinne und Ressourceneinsparungen zufolge hat und zum anderen immer auch die Stakeholder-Ansprüche berücksichtigt.