Beim Wasserfallprojektmanagement werden Entwicklung und Tests in zwei verschiedene Schritte aufgeteilt: Entwickler entwickeln ein Feature und "schmeißen es dann über den Grenzzaun" zum Qualitätssicherungsteam (QA), damit dieses das Feature testen kann. Das QA-Team schreibt detaillierte Testpläne und führt diese aus. Es erfasst außerdem Fehler, wenn es gründlich nach Regressionen in vorhandenen Features sucht, die möglicherweise durch die neue Arbeit verursacht wurden.
Viele Teams, die diese Wasserfall- oder andere herkömmliche Testmodelle verwenden, stellen fest, dass die Menge der Tests exponentiell mit dem Produkt wächst – und das QS-Team ausnahmslos Probleme hat, Schritt zu halten. Project Owner stehen vor einer unliebsamen Entscheidung: das Release verschieben oder beim Testen nachlässig sein. (Du darfst einmal raten, welche Option zu 99 % gewinnt.) In der Zwischenzeit ist die Entwicklung zu einer anderen Aufgabe übergegangen. Es wachsen also nicht nur die technischen Schulden, sondern die Behebung der einzelnen Fehler macht ebenfalls einen aufwendigen Kontextwechsel zwischen zwei Teilen der Codebasis erforderlich. Eine verzwickte Situation.
Um das Ganze noch zu verschlimmern, werden QS-Teams üblicherweise danach belohnt, wie viele Bugs sie finden, was Entwickler in die Defensive drängt. Gibt es keinen besseren Weg für Entwickler und das QS-Team, die Anzahl der Bugs im Code zu reduzieren und gleichzeitig die unangenehmen Kompromisse zu vermeiden, die Projektinhaber eingehen müssen? Wäre dann nicht eine insgesamt bessere Software möglich?
Hier kommen Agile- und DevOps-Tests ins Spiel.
Übergang von herkömmlichen zu agilen Testmethoden
Das Ziel von Agile- und DevOps-Teams ist es, nachhaltig neue, qualitativ hochwertige Features zu liefern. Herkömmliche Testmethoden passen jedoch nicht zum Agile- oder DevOps-Framework. Die Entwicklungsgeschwindigkeit macht einen neuen Ansatz der Qualitätssicherung für jeden Build erforderlich. Bei Atlassian testen wir auf agile Weise. Lass dir von Penny Wyatt, Senior QA Team Lead bei Jira Software, unseren Testansatz im Detail vorstellen.
So wie wachsende Kreditkartenschulden beginnt alles mit einer kleinen Menge an Problemen, die aber schnell lawinenartig anwächst – und die wichtige Agilität des Teams untergräbt. Im Kampf gegen das lawinenartige Anwachsen von technischen Schulden ermöglichen wir es unseren Entwicklern (ach was, wir erwarten es von ihnen), große Verfechter der Qualität zu sein. Wir glauben, dass Entwickler über die Schlüsselkompetenzen verfügen, die Qualität im Produkt zu sichern:
- Entwickler sind großartig beim Beheben von Problemen mit Code.
- Entwickler, die eigene Tests schreiben, können diese einfacher korrigieren, wenn sie fehlschlagen.
- Entwickler, die die Feature-Anforderungen und ihre Testauswirkungen verstehen, schreiben im Allgemeinen besseren Code.
Wir glauben, dass für jede User Story im Backlog sowohl Feature-Code als auch Code für automatisierte Tests erforderlich sind. Einige Teams weisen den Entwicklern den Feature-Code zu, während das Testteam das automatisierte Testen übernimmt. Wir glauben jedoch, dass es effektiver ist, wenn ein einziger Entwickler den vollständigen Satz bereitstellt.
Du solltest Bugs in neuen Features und Regressionen in vorhandenen Features unterschiedlich behandeln. Wenn während der Entwicklung ein Bug auftritt, nimm dir die Zeit, den Fehler zu verstehen, ihn zu korrigieren und dann weiterzumachen. Wenn es zu einer Regression kommt (d. h. etwas, was zuvor funktioniert hat, funktioniert nicht mehr), wird diese wahrscheinlich erneut auftreten. Erstelle einen automatisierten Test, der in Zukunft vor dieser Regression schützt.
Dieses Modell bedeutet nicht, dass Entwickler allein arbeiten. Es ist wichtig, dass auch QA-Techniker im Team vorhanden sind. QA bringt eine wichtige Sichtweise in die Entwicklung eines Features ein. Gute QA-Techniker wissen, wo sich Bugs normalerweise verstecken, und können Entwickler an den Stellen beraten, an denen sie am wahrscheinlichsten fündig werden.
Menschliche Note durch exploratives Testen
In unseren Entwicklerteams arbeiten QA-Teammitglieder mit Entwicklern an explorativen Tests, ein wertvolles Verfahren zur Abwehr schwerwiegenderer Bugs während der Entwicklung. Ähnlich wie beim Code-Review konnten wir damit einen Testwissenstransfer im gesamten Entwicklerteam beobachten. Wenn Entwickler zu besseren Testern werden, wird gleich beim ersten Mal besserer Code bereitgestellt.
Aber bedeutet exploratives Testen nicht manuelles Testen? Nein. Zumindest nicht im selben Sinn wie bei manuellen Regressionstests. Exploratives Testen ist ein risikobasierter, kritischer Denkansatz, bei dem der Tester seine Kenntnisse in Bezug auf Risiken, Implementierungsdetails und Kundenanforderungen nutzen kann. Wenn diese Dinge bereits zu einem früheren Zeitpunkt im Testprozess bekannt wären, kann der Entwickler oder QA-Techniker Probleme schnell und umfassend erkennen, ohne skriptbasierte Testfälle, detaillierte Testpläne oder Anforderungen zu benötigen. Wir finden, dass dies wesentlich effektiver als das herkömmliche manuelle Testen ist, da wir Einblicke aus explorativen Testsitzungen zurück auf den ursprünglichen Code und die automatisierten Tests übertragen können. Exploratives Testen zeigt uns auch etwas über die Erfahrung, wenn das Feature auf eine Weise verwendet wird, die beim skriptbasierten Testen nicht möglich ist.
Um die Qualität aufrechtzuerhalten, ist eine Mischung aus explorativen und automatisierten Tests erforderlich. Wenn neue Features entwickelt werden, stellen explorative Tests auf eine breitere Weise als automatisierte Tests allein sicher, dass der neue Code die Qualitätsstandards erfüllt. Dazu zählen Benutzerfreundlichkeit, ein gefälliges visuelles Design und die allgemeine Nützlichkeit des Features sowie robuste Schutzmaßnahmen gegen Regressionen, die automatisierte Tests bereitstellen.
Änderungen können schwer sein – wirklich schwer
Ich schließe hier mit einer persönlichen Anekdote, die meine Erfahrungen mit dem agilen Testen gut zusammenfasst. Ich erinnere mich, dass ich zu Beginn meiner Karriere ein Entwicklerteam geleitet habe, das großen Widerstand gegen das Schreiben von automatisierten Tests leistete, weil "das Sache des QA-Teams" sei. Nach mehreren Iterationen mit fehlerhaftem Code und Anhören all der Begründungen, warum automatisierte Tests das Team beeinträchtigen würden, setzte ich mich durch: Jeder neue Code musste mit automatisierten Tests geprüft werden.
Nach einer einzigen Iteration wurde der Code besser. Und der Entwickler, der den größten Widerstand gegen das Schreiben von Tests geleistet hatte, war der Erste, der handelte, als ein Test fehlschlug! Über die nächsten Iterationen wuchsen die automatisierten Tests, wurden auf verschiedene Browser erweitert und verbesserten unsere Entwicklungskultur. Natürlich dauerte es länger, ein Feature herauszubringen. Aber Bugs und Nacharbeiten wurden deutlich reduziert, sodass wir letztendlich eine Menge Zeit sparten.
Änderungen sind selten einfach. Aber wenn du es schaffst, dich ins Zeug zu legen und neue Muster für dich zu finden, bleibt wie bei den meisten lohnenden Dingen nur die Frage, warum du das nicht früher getan hast.
