Qualitätssicherung in Windeseile

Von der Qualitätssicherung zur Qualitätsunterstützung

Laura Daly Laura Daly

Es ist schwierig, herkömmliche Testmethoden an eine agile Kultur anzupassen. Die Teams sehen sich gezwungen, die Qualität ihres Produkts einer schnellen Auslieferungsgeschwindigkeit zu opfern.

Um dem entgegenzuwirken haben die Teams bei Atlassian einen neuen Ansatz zum agilen Testen entwickelt, der als Qualitätsunterstützung bezeichnet wird. Anstatt eines separaten Testteams, das für die Qualität verantwortlich ist, schult ein kleines Qualitätsunterstützungsteam das Entwicklerteam in nachhaltigen Testmethoden. Hier erfährst du mehr über diesen Wandel und erhältst Antworten auf folgende Fragen:

  • Wie schaffe ich eine Kultur der Qualität?
  • Wie gebe ich die Verantwortung für das Testen zurück an die Entwickler?
  • Wie vermeide ich Bugs von Anfang an, anstatt sie im Nachhinein aufzuspüren?

Q&A-Runde

In der Q&A-Runde dieser Präsentation erfährst du mehr darüber, wie ein Team von 65 Entwicklern mit nur sechs QS-Mitarbeitern qualitativ hochwertige Produkte erstellen und diese schnell ausliefern.  

F1: Wie lange braucht ein Entwickler, bis er diese Denkweise verinnerlicht hat?

A1: Es ist schwieriger, die Kultur eines ganzen Teams zu verändern, als Einzelpersonen zum Umdenken zu bewegen. Im Jira Software-Team hat es fünf Jahre gedauert, um die heutige qualitätsorientierte Denkweise zu etablieren. Doch nicht jeder neue Entwickler benötigt so lange, bis er auf demselben Stand ist. Neue Entwickler übernehmen schnell die Denkweise ihrer alteingesessenen Kollegen und lernen die Testfertigkeiten in der paarweisen Zusammenarbeit und in Workshops. Das Schwierigste ist, sich das umfangreiche Wissen zu Risiken und zum Produkt anzueignen. Dies kann Jahre dauern, aber wir versuchen den Prozess zu beschleunigen, indem wir unser Wissen in QS-Kickoff-Meetings und QS-Demos teilen.

F2: Besteht weiterhin ein Bedarf an Testfällen oder beschränken sich diese auf Regressions- bzw. automatisches Testen?

A2: Skriptbasierte manuelle Testfälle sind in unserer Strategie überhaupt nicht vorgesehen. Wenn ein Test nur einer schnellen Überprüfung dienen soll – also aus einer vordefinierten Abfolge an Schritten und einer definierten Annahme besteht –, halten wir es für effizienter und weniger fehleranfällig, wenn ein Computer statt eines Menschen diesen Test übernimmt. Echte Tests, die kritisches Denken, freie Nachforschungen und Risikobewertungen erfordern, führen wir lieber als Teil explorativer Tests durch, um über die nötige Freiheit und Intelligenz für diese Tests zu verfügen.

F3: Entwickler kosten in der Regel mehr als Tester. Wenn wir also Entwickler als Tester einsetzen, ist dies doch eine ineffiziente Nutzung von Budget/Personalressourcen?

A3: Ja, in der Tat ist es teuer und eine Verschwendung wertvoller Entwicklerzeit, wenn Entwickler als Tester einen separaten Testschritt durchführen. Aber ein separater Testschritt an ist grundsätzlich teuer und eine Verschwendung von Entwicklerzeit, auch wenn er von Testern durchgeführt wird. Jedes Mal, wenn eine Story oder ein Bug von den Testern zurück an die Entwickler gegeben wird, entstehen nicht nur Testkosten, sondern auch Entwicklungskosten. Durch die Minimierung der Ablehnungsrate von100 % auf 4 % sparen wir sehr viel Entwicklungszeit ein, die vor dem Release für die Überarbeitung von Storys und Korrektur dummer Fehler vergeudet wurde. Wir sparen die Zeit ein, die früher für das Nachforschen, Melden, Sichten, Bewerten, Reproduzieren und Beheben von intern entdeckten Bugs aufgewendet wurde. Darüber hinaus wurde der Code von Grund auf so konzipiert, dass er sich besser testen lässt. Die Entwickler wissen schließlich, dass sie diejenigen sein werden, die ihn testen müssen. Unsere DoT (Developer on Testing)-Phase war ein Übergangsschritt auf dem Weg, die Qualität schon frühzeitig im Prozess zu sichern, um den separaten Testschritt völlig zu beseitigen. Diese vorübergehende Investition hat sich mehr als bezahlt gemacht.

F4: Bei uns arbeiten Entwickler und QS-Tester in verschiedenen Zeitzonen. Würde dieses Modell nur in derselben Zeitzone funktionieren? Wie arbeitet man mit Remote-Teams?

A4: Wir haben Remote-Qualitätsunterstützung von Teams in Polen und Vietnam mit einem QS-Mitarbeiter in Australien durchgeführt. Dies ist natürlich nicht so effektiv wie kompetente QS-Mitarbeiter vor Ort, da ein Großteil der Arbeit eines guten Qualitätsunterstützungsspezialisten der Aufbau einer persönlichen Beziehung mit den Entwicklern ist. Ein Remote-QS-Mitarbeiter bleibt leicht außen vor und kann die allgemeine Teamkultur viel schwieriger einschätzen. Trotzdem waren unsere Remote-QS-Demos, -Kickoffs und Einzelsitzungen per Videoanruf – einfach direkt vom Rechner des Entwicklers zu dem des QS-Mitarbeiters mit einem gemeinsamen Bildschirm –ein voller Erfolg.

F5: Werden die QS-Hinweise für jede einzelne Story erstellt oder sammelt ihr die QS-Notizen in einer Wissensdatenbank? Wie werden wiederkehrende Risiken behandelt?

A5: Die QS-Hinweise werden für jede Story separat erstellt. Deshalb fallen den QS-Mitarbeitern Muster wiederkehrender Risiken als erstes auf. Dies wird mit der Zeit immer schwieriger, da unser Jira Software-QS-Team gewachsen ist und nicht unbedingt jeder QS-Mitarbeiter weiß, was die anderen wissen. Bis jetzt haben wir dem entgegengewirkt, indem wir wöchentliche Meetings zum Wissensaustausch durchführen und auf Wiki-Seiten häufige und überraschende Risiken festhalten. Wir erreichen aber bald einen Punkt, wo dies nicht länger ausreicht. Im Moment arbeiten wir an einer strukturierteren Wissensdatenbank mit Regeln, die wir dann über jeden Commit laufen lassen. Wenn die Regeln beispielsweise feststellen, dass du das Objekt "Benutzer" in deinem Jira Software-Code verwendest, wird im Issue der folgende Kommentar hinzugefügt: "Das Objekt "Benutzer" kann Null sein, wenn der aktuelle Benutzer anonym ist. Achte bitte darauf." Auf diese Weise zapfen wir das Wissen aus den Köpfen der QS-Mitarbeiter an und machen im Idealfall QS-Demos und -Kickoffs überflüssig. Das wäre sehr hilfreich!