Die beschriebenen Erfolgsfaktoren sind das Ergebnis persönlicher Erfahrungen. Dieser Artikel erhebt keinen Anspruch auf Vollständigkeit. Er soll Anregungen und Inspiration für die tägliche Arbeit geben.
Vor einiger Zeit fragte mich ein Kunde, was ich von Built-in Quality halte. In zahlreichen Organisationen wird viel darüber geredet, aber es fehlt an konkreten Handlungsempfehlungen, wie Qualität in ein Softwareprodukt eingebaut und langfristig sichergestellt werden kann. Mehr Buzzword-Bingo als Fokus auf die tatsächliche Umsetzung - das nervt!
Was also bedeutet Built-in Quality? Was sind die kritischen Erfolgsfaktoren für Built-in Quality?
Bevor wir uns der Beantwortung dieser Fragen widmen können, müssen wir klären, was Qualität überhaupt bedeutet. Qualität bedeutet etwas anderes, je nachdem, ob Software, Hardware oder etwas dazwischen entwickelt wird. Qualitätsanforderungen hängen oft von der Branche ab. Es macht einen Unterschied, ob das Produkt ein Online-Spiel, ein medizinisches Laborgerät oder eine Wertpapierhandelsplattform ist.
Dieser Artikel konzentriert sich auf Software, wobei einige Aussagen auch auf andere Produkte anwendbar sind.
Qualität
Bei der Definition von Qualität greife ich gerne auf die Norm ISO/IEC 25010:2011 zurück. Eigentlich bin ich keine Freundin von strengen Normen, aber diese hat mir schon mehrfach gute Dienste geleistet. ISO/IEC 25010:2011 unterstützt uns mit 8 konkreten Merkmalen bei der Definition von Qualitätsmerkmalen und den damit verbundenen Anforderungen an ein Softwareprodukt:
Funktionalität
Effizienz / Performance
Sicherheit
Kompatibilität
Zuverlässigkeit
Benutzbarkeit
Wartbarkeit
Portabilität
Leider wird bei der Anforderungserhebung oft vergessen, wie die Anforderungserfüllung, insbesondere der Merkmale 2 bis 8, gemessen werden soll - Stichwort: Nicht-funktionales Testen. Dabei sind diese Tests unerlässlich für ein qualitativ hochwertiges Produkt.
Genauso wichtig ist es, dass jedes Teammitglied die Qualitätsanforderungen kennt.
Angenommen, wir haben unsere Qualitätsanforderungen definiert. Warum sollten wir uns jetzt darum kümmern, Qualität einzubauen? Reicht es nicht, am Ende zu testen, die Probleme zu finden und sie zu beheben?
Eingebaute Qualität (Built-in Quality)
Kennt ihr euer «Why»? Warum ist Qualität und Built-in Quality für euch wichtig?
Ich möchte euch ermutigen, nach dem «Why» zu fragen. Fragt euch selbst, fragt euer Team, fragt eure Organisation. Denn am Ende geht es immer um das «Why». Niemand kauft «was» ihr tut, sondern warum («Why») ihr etwas tut.
Stellt sicher, dass ihr euer «Why», vor allem in Bezug auf Qualität kennt.
Als Beispiel möchte ich mein persönliches «Why» teilen, das wie folgt lautet:
Ich möchte das Leben einfacher machen - für unsere User:innen, Kund:innen, mein Team, für alle, die mit unserem Produkt in Berührung kommen.
Ich glaube, dass dies durch die Bereitstellung nachhaltiger und qualitativ hochwertiger Softwareprodukte erreicht werden kann. Um nachhaltige Produkte zu entwickeln, ist Built-in Quality nicht verhandelbar.
Aber was genau ist mit Built-in Quality gemeint? SAFe sagt dazu folgendes:
"Built-In Quality Praktiken stellen sicher, dass jedes Solution Element, in jedem Sprint während der gesamten Entwicklung angemessene Qualitätsstandards erfüllt.
Alle teams — Software, Operations, Marketing, Legal, Security, Compliance, etc. — teilen die Ziele und Grundsätze von Built-in Quality.
Die Praktiken variieren je nach Disziplin, aber alle unterstützen die agilen Werte."(1)
So weit, so gut. Das klingt alles sehr toll und ich teile diese Ansichten. Allerdings sind mir die obigen Aussagen zu abstrakt, zu vage, um damit im Daily Business zu arbeiten.
Deshalb habe ich die Erfolgsfaktoren aus meiner Projekterfahrung zusammengetragen, verdichtet und dabei ist folgendes Bild entstanden:
Die Eckpfeiler sind ganz klar Ownership, Shift-Left, eine gute Testpyramide und ein durchgängiges Quality-Mindset.
Diverse Automatisierungstools und agile Frameworks können unterstützend wirken.
Die Basis für all das ist aber immer der Mensch und die Organisation. Es braucht eine unterstützende Organisation, Kultur und motivierte Mitarbeitende. Ohne ein stabiles Fundament kann man das coolste vollautomatisierte Shift-Left-Setup haben, es wird das Grundproblem nicht lösen.
Ownership & Verantwortung
Ownership bedeutet, dass das gesamte Team für Qualität, Qualitätssicherung und Testing verantwortlich ist.
Eine gute Starthilfe für die Etablierung von Ownership ist die Schaffung gemeinsamer Grundsätze, so genannter «Quality Principles». Das Team einigt sich auf die wichtigsten Grundsätze im Bereich Qualität.
Inspiration, wie solche Prinzipien aussehen können, liefert z.B. das Testing Manifesto (2).
Unabhängig davon, ob ihr eigene Prinzipien für euer Team definiert oder das Testing Manifesto übernehmt, ist es wichtig, dass alle Teammitglieder den Prinzipien zustimmen und sich zu ihnen bekennen.
Sobald ihr euch im Team geeinigt habt, macht eure Grundsätze sichtbar. Achtet darauf, dass sie nicht in Vergessenheit geraten. Druckt sie aus, hängt ein grosses Poster im Büro auf, veröffentlicht sie auf eurer Confluence Homepage etc. Ihr wollt keine Ausreden hören, warum jemand eure Qualitätsgrundsätze nicht kennt.
Verantwortung
In der Vergangenheit war es oft so, dass eine Person für die Qualität des gesamten Produkts verantwortlich war. Das war nie fair und das wollen wir heute wirklich nicht mehr.
Vielmehr wollen wir, dass das gesamte Team, alle Disziplinen und Rollen, Verantwortung für die Qualität übernehmen und gemeinsam entscheiden, ob sie bereit sind zu liefern und welche Risiken das Team bewusst einzugehen bereit ist.
Um dieser Verantwortung gerecht zu werden, sollte das Team über professionelle QA/Testing Skills verfügen.
Dies kann durch Testing/QA Spezialist:innen im Team oder durch dedizierte Coaches erreicht werden. Welcher Weg gewählt wird, ist nicht relevant. Wichtig ist, dass das Team über alle notwendigen Skills inklusive Testing & QA verfügt, um das beste Produkt zu entwickeln und Fehler zu vermeiden. Jedes Teammitglied soll den Testerhut aufhaben und kritische Fragen stellen.
Shift-Left
Shift-Left im Prozess. Verschiebt das Denken über Qualität, Qualitätssicherung und Testen weiter nach links. Qualität muss von Anfang an und während des gesamten Lebenszyklus im Mittelpunkt stehen.
Was unbedingt vermieden werden muss, ist das Testen als Phase innerhalb eines Sprints zu sehen. Daraus resultiert ein Mini-Wasserfall und eine einzelne Person steht unter noch mehr Stress als in einem traditionellen Wasserfall-Setup. Die Wahrscheinlichkeit, dass Leute ausbrennen und es zu Engpässen im Prozess kommt, ist sehr hoch.
Testen ist eine Aktivität und immer Teil der Entwicklung. Es kann also nicht sein, dass etwas als «done» (fertig) gilt, ohne dass es getestet wurde. Das ist einfach nicht richtig.
Um das Testen als Aktivität und weiter links im Prozess anzusiedeln, können z.B. Test Driven Development (TDD) oder Behaviour Driven Development (BDD) eingesetzt werden.
Beide Ansätze haben den Vorteil, dass Tests definiert werden bevor Code geschrieben wird. Das heisst, ihr wisst, was ihr testen wollt, dann wird der Code geschrieben und wenn etwas nicht wie erwartet funktioniert, habt ihr sofort einen fehlgeschlagenen Testfall. Ihr habt also den Fehler super früh gefunden und solltet ihn im Normalfall an dieser Stelle kostengünstig beheben können.
Wenn ihr euch für BDD entscheidet, habt ihr noch einen weiteren Vorteil: BDD gibt euch eine gemeinsame Sprache, Gherkin. Gherkin hilft euch, ein gemeinsames Verständnis aufzubauen. Die einfache Syntax (Given-When-Then) ist extrem hilfreich, um alle im Team einzubeziehen. Es spart Zeit, motiviert und fördert den Teamgeist.
Bevor wir Tests schreiben, denken wir normalerweise über Anforderungen nach. Eine gute Methode, um an Anforderungen heranzugehen, sind die «3 Amigos».
Mit den «3 Amigos» sind die drei Perspektiven Business, Development und QA/Testing gemeint. Es geht um die unterschiedlichen Perspektiven und nicht per se um drei Personen. Es ist wichtig, die verschiedenen Perspektiven zu kennen und von Anfang an zu berücksichtigen. Der kollaborative Ansatz der «3 Amigos» kann die Teamleistung deutlich steigern, hilft sicherzustellen, dass keine Perspektive vergessen wird, fördert das gegenseitige Verständnis und reduziert den Raum für Missverständnisse und Fehler auf ein Minimum.
...und es macht auch noch richtig Spass - also probiert es aus!
Testpyramide
Eine Testpyramide kann wie ein Labyrinth wirken. Ich habe oft erlebt, dass nicht klar war, was mit einer bestimmten Teststufe gemeint ist und was auf dieser oder jeder Stufe in welchem Umfang getestet wird oder auch nicht.
Grund genug für mich, eine eigene Version der Testpyramide zu entwerfen. Man kann über die Form, die Stufen und den Automatisierungsgrad der Testpyramide diskutieren und es gibt sicher mehr als eine gültige Version. Wichtig ist, dass alle im Team dasselbe Verständnis von den Ebenen und dem Inhalt der Testpyramide haben. Alle müssen dasselbe unter z.B. Integrationstest oder Systemtest verstehen.
Ebenso wichtig ist Transparenz. Ihr wollt jederzeit wissen, was auf welcher Ebene und mit welcher Abdeckung getestet wird. Dieses Wissen macht effizient und schnell.
Zur Veranschaulichung ein Beispiel aus einem meiner Projekte:
Es war das klassische Problem mit grossen Quartals-Releases und einem schwerfälligen, in Silos organisierten Prozess. Jedes Release erforderte viele manuelle Tests, die eine gefühlte Ewigkeit dauerten. Das war mühsam, stressig und frustrierend. Der Feedback-Zyklus war inakzeptabel langsam.
Zu diesem Zeitpunkt war ich Embedded Testerin in einem agilen Team und hatte wirklich keine Lust mehr, so zu arbeiten.
Ich ging zu meinem Product Owner und sagte: «Ich möchte diesen grossen (manuellen) Testaufwand vor jedem Release so weit wie möglich reduzieren. Dazu muss ich unsere wichtigsten Use Cases aus Anwendersicht kennen».
Also sind wir zusammengesessen und haben gemeinsam die wichtigsten Use Cases high-level definiert.
Viel zu oft werden die wichtigsten Anwendungsfälle, der eigentliche Verwendungszweck einer Software vernachlässigt und nur auf User Stories, neue Features oder Epics fokussiert. Das Ergebnis sind viele ("one-time") Testfälle, die weit entfernt von gut organisierten Regressionssets sind.
Mit den wichtigsten Use Cases im Gepäck setzte ich mich mit meinen Entwicklerkolleg:innen zusammen und ging jeden Fall Schritt für Schritt durch. Wir tauchten in den Code ein, prüften, was bereits durch automatisierte Tests während der Entwicklung abgedeckt war und dokumentierten unsere Erkenntnisse entsprechend. Was noch nicht abgedeckt war, haben wir kontinuierlich ergänzt. Wir haben nicht nur Transparenz geschaffen, sondern gleichzeitig unsere Tests und die Testabdeckung erhöht und verbessert.
Ja, das hat Zeit gekostet, aber es hat sich gelohnt.
Bald hatte ich volle Transparenz über unsere Testabdeckung ab Unittest-Level. Ich überprüfte meine bestehenden manuellen Tests und konnte schliesslich 60 Prozent davon streichen. Krass, oder?
Diese Bereinigung setzte viele Ressourcen frei und ich hatte endlich Zeit mich mit spannenderen Dingen zu beschäftigen, als mich durch manuelle Testfälle zu klicken, z.B. echtes exploratives Testen.
Mein Team war begeistert und stolz auf unser gemeinsames Engagement zur Steigerung unserer Testabdeckung, unserer Effizienz und der Qualität unseres Produktes.
Ihr seht, Transparenz setzt Ressourcen frei und wenn man von Anfang an auf Transparenz achtet, können vorhandene Ressourcen sinnvoller eingesetzt werden.
Quality-Mindset
Jedes Teammitglied, unabhängig von Rolle oder Disziplin, sollte sich mit Testbarkeit und Qualität beschäftigen. Während der Design- oder Architekturphasen müssen Qualitätsmerkmale und deren Testbarkeit im Auge behalten werden.
Während der Entwicklung ist «Clean Code» das oberste Gebot. Stellt sicher, dass eure Kolleg:innen die Clean Code Standards kennen und befolgen.
Es gibt einige wenige allgemeine Regeln, die sehr leicht zu merken sind. Diese werden durch spezielle Regeln für bestimmte Bereiche wie Verständlichkeit, Benennung von Funktionen, Strukturierung des Quellcodes etc. ergänzt.
Hier findet ihr eine gute Zusammenfassung, die ihr mit eurem Team teilen könnt, so dass alle, nicht nur Entwickler:innen, die Grundlagen nachschlagen können: https://gist.github.com/wojteklu/73c6914cc446146b8b533c0988cf8d29
Ausserdem empfehle ich das Standardwerk zu Clean Code von Robert C. Martin (Clean Code, A Handbook of Agile Software Craftsmanship). Meiner Meinung nach eine Pflichtlektüre für alle, die Code schreiben.
Last but not least, holt euch Spezialist:innen ins Boot. Holt euch Expertise, alles was ihr braucht, um das beste Produkt zu entwickeln.
Egal ob ihr die Expertise schon im Projektteam habt oder nicht, holt euch die Leute, die ihr braucht. Je früher desto besser. Ihr wollt nicht erst kurz vor dem Release von obligatorischen Sicherheitsanforderungen erfahren.
Die frühzeitige und kontinuierliche Einbindung aller relevanten Disziplinen ist der Schlüssel für eine kontinuierliche Wertschöpfung.
Fazit
Built-in Quality hat viele Facetten. Meine Empfehlung an euch lautet:
Kennt euer «Why». Wisst, warum Built-in Quality für euch wichtig ist und begeistert andere dafür.
Etabliert ein Quality Mindset über alle Rollen und Disziplinen entlang des Produktlebenszyklus. Dies ist ein Schlüsselfaktor für kontinuierliche Wertschöpfung.
Baut eine transparente Testpyramide auf, damit ihr jederzeit wisst, was auf welcher Teststufe getestet wird. So können Ressourcen optimal eingesetzt werden.
Shift-Left. Verlagert das Bewusstsein für Qualität, Qualitätssicherung und Testing weiter nach links, an den Anfang des Prozesses. Das ermöglicht schnelles Feedback in kurzen Zyklen.
Und zu guter Letzt: Built-in Quality ist ein Teamsport. Es braucht das ganze Team. Es braucht jede/n Einzelne/n mit ihren/seinen ganz persönlichen Fähigkeiten und Erfahrungen. Vielfalt im Team ermöglicht es uns, Qualität von Anfang an einzubauen, das beste Produkt zu entwickeln und das Leben ein bisschen einfacher zu machen.
Quellen:
1 SAFe, https://www.scaledagileframework.com/built-in-quality/; übersetzt mit DeepL Translator.
2 Growing Agile, https://www.growingagile.co.za/
3 HBO Pictures, https://www.amazon.com/Three-Amigos-Steve-Martin/dp/B00287Z18Y
4 Zühlke Group, https://www.zuehlke.com/
Comments