Bewährte Methoden für das Testen mit agilen Methoden und warum sie so wichtig sind

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.

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.

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. Bei der Entwicklung neuer Features sorgen explorative Tests (statt automatisierte Tests allein) auf umfassendere Weise dafür, dass der neue Code die Qualitätsstandards erfüllt. Das gilt für die Benutzerfreundlichkeit, ein ansprechendes visuelles Design und die allgemeine Nützlichkeit der Features sowie robuste Schutzmaßnahmen gegen Regressionen, die automatisierte Tests bereitstellen.

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.