So arbeiten wir - mit effizienten QA Prozessen zur digitalen Exzellenz Hier gehts zum Beitrag!
Read time: ca. 5 min

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

Dominik

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 Tester:Innen 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 Tester:Innen in den agilen Entwicklungsprozess.

Das wird Whole-Team-Approach genannt: Alle Personen einer Entwicklung, also Stakeholder, Entwickler:Innen, die Fachbereiche und natürlich auch die Tester:Innen sind von Anfang an in den Planungs- und Entwicklungsprozess integriert. Dementsprechend sollten Tester:Innen, 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:Innen schreibt sich vielleicht Agile auf die Fahne, für echtes Agile Development ist ein:e Tester:In 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 eine:r agilen Tester:In 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 Nutzer:Innen 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 Tester:Innen, die den Testfortschritt gewährleisten müssen. Innerhalb dieser Vergegenwärtigung des Status einer Entwicklung ist die Beherrschung des Regressionsrisikos. Einfach gesagt, müssen Tester:Innen 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 Tester:Innen 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 Tester:In 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 Tester:Innen 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: Tester:Innen repräsentieren die Stakeholder

Vor zehn Jahren war diese ausgeprägte Rolle von Tester:Innen noch nicht abzusehen. Doch seither hat die Professionalisierung von Tester:Innen eine rasante Entwicklung gemacht: Als agile Tester:In repräsentieren wir die Kunden:Innen und die Endnutzer:Innen 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.