Ja, man findet sie noch. Projekte, in denen die alleinige Verantwortung für Qualität beim Tester liegt. Oder beim Testmanager. Manchmal vielleicht noch ein klein wenig beim Entwickler. Aber bloß nicht mehr, er soll ja Produktivcode schreiben. Der agile Aufbruch Anfang der 2000er hat hier positiver Weise zwar Bewegung reingebracht, aber von einer gemeinsamen Quality-Ownership sind Teams oft weit entfernt. Frei nach dem Motto "Hinter mir die Sintflut" - (die dann bei Release auch manchmal kommt).
Das ging früher noch gut. Die Projekte waren überschaubar, die Systeme relativ simpel. Ursache und Wirkung klar erkennbar. Da haben am Schluss ein paar Tests genügt um ein sicheres Gefühl zu bekommen und den Installer auf Diskette zu packen. Aber die Welt hat sich verändert: Hochsprachen, Abstraktionen, Cloud, Vernetzung, Infrastruktur, fachliche und technische Anforderungen - alles ist mit der Zeit leistungsfähiger und komplexer geworden. All das stellt massive Anforderungen am die Qualität auf allen Ebenen.
Schnellere Releasezyklen, kurz getaktete Kundenwünsche und Time-to-Market befeuern die Projekte noch obendrein. Da ist mit etwas „rumtesten“ am Ende nichts mehr zu machen.
Von Testing zu Agile Testing zu Agile Quality
Wenn ich so zurückschaue ist es eigentlich ein schöner Prozess. Zuerst haben sich die Testaktivitäten auf den Weg gemacht. Früher Testen. Neue Methoden. Näher an die Anforderungen ran. Mehr Testautomatisierung durch Entwickler. Aus Testen wurde agiles Testen. Aber es ging noch weiter. Denn es braucht mehr als Testen um die Qualität zu steigern und zu halten. Analysen, Reviews, Kollaboration....für alle Artefakte im Software-Entwicklungsprozess. Auch hier gibts schon viel vorzuweisen. Ist halt alles auch ein Veränderungsprozess.
Und rund wird es dann, wenn nicht nur mehr Tester oder Quality Engineers und Entwickler Qualität leben, sondern alle im crossfunktionalen DevOps-Team. Also auch Business Analysten, UX-Designer, Architekten, Product Owner, Scrum Master,...
Qualität als Team leben
Und wie kommt man denn da hin? Nun, führen mehrere Wege nach Rom. Eigeninitiative. Begleitung durch einen Agile (Quality) Coach, Retrospektiven & Workshops...
Aber nicht zu vergessen: Das ist wie so vieles ein Veränderungsprozess. Das dauert, braucht Energie und die richtige Steuerung um Vorbehalte, Ängste und Blockaden zu lösen und zu transformieren.
Ein guter Start ist alle Beteiligten einmal auf "einen Nenner" zu bringen. Zu erklären, was diese ganzheitliche Qualität denn bedeutet, was es überhaupt heißt Qualität in DevOps umzusetzen und einen gemeinsamen Sprachgebrauch und ein gemeinsames Verständnis zu erschaffen, das eben nicht nur Qualitätsmenschen und Entwickler verstehen - sondern alle im Team.
Diese Basis zu schaffen, unterstützt z.B. ein Seminar bzw. die Zertifizierung TMAP®: Quality for cross-functional teams. Hier ist der Anspruch, alle mit an Bord zu holen, eine gemeinsame Qualitätssicht zu entwickeln und Qualität im gesamten DevOps-Prozess zu beleuchten. Von Modellen, zu Methoden und Metriken bis hin zur integrierten CI/CD-Pipeline. Und das nicht nur theoretisch. Sondern auch mit viel praktischer Anwendung.
Und dann beginnt der Spaß so richtig, nämlich das gewonnene Wissen peu à peu im Tagesgeschäft umzusetzen.
Bis alle im Team überall im Projekt das Qualitätsfähnchen hochhalten :-)
Ihr Richard Seidl
Über den Autor
Richard Seidl ist Software-Test-Experte, Agile Quality Coach und Autor. Er hat in seiner beruflichen Laufbahn schon viel Software gesehen: gute und schlechte, große und kleine, neue und alte. Software so schön, dass man weinen könnte und auch solche die die Fußnägel aufrollt. Für ihn ist klar: Wer heute exzellente Software kreieren möchte, denkt den Entwicklungsprozess ganzheitlich: Menschen, Kontext, Methoden und Tools – erst wenn alles zusammenspielt, entsteht ein Mindset für Potentialentfaltung und Innovation.
