Software-Qualität als Haltung leben

“The problem is not the problem. The problem is your attitude about the problem.” - Captain Jack Sparrow

Egal ob in klassischen Software-Entwicklungsprojekten oder in agilen. Die Qualität der Software ist ein essentieller Faktor für den Erfolg. Mit ein bisschen methodischen Software-Testen ist es heute aber nicht mehr getan. Die Zeiten, wo man als Entwicklungsteam die Applikation einfach zum Testteam rübergeschoben hat, sind schon lange vorbei. Die knallharte Silotrennung funktioniert eben meist mehr schlecht als recht.

Wer heute exzellente Software kreieren möchte, denkt den Entwicklungsprozess ganzheitlich: Menschen, Methoden, Tools und Mindset – erst wenn alles in einem Flow zusammenspielt, entsteht Potentialentfaltung und Innovation. In so einem Entwicklungsprozess wird Qualität zur Haltung des Teams. Dies zu erreichen ist ein Veränderungsprozess, der Verständnis und Empathie für alle Beteiligten benötigt: Entwickler, Tester, Führungskräfte oder Stakeholder.

Wenn ich auf meine Projekte der letzten Jahre zurückblicke, gab es immer wieder Entwicklungs-Teams, die per se Top-Software-Qualität geliefert haben. Das Geheimnis? Das ganze Team lebt das Thema Software-Qualität. Es ist als Kultur verankert. Oft können dabei die einzelnen Team-Mitglieder gar nicht mehr alle Qualitätsaktivitäten konkret benennen – Qualität und Software-Test sind zum Mindset geworden. Nun fällt so ein Mindset nicht vom Himmel. Es ist ein Weg, eine Transformation, dahin zukommen. Für jedes Team ist dieser Weg ein sehr individueller. Dennoch lassen sich gewisse Meilensteine über die Zeit festmachen, die die Qualität auf die nächste Ebene bringen.

Basics – Software-Test Grundlagen nutzen

Der ersten Boost auf dem Weg zur qualitätsbewussten Haltung wirkt auf den ersten Blick ganz simpel: Die Nutzung der bewährten Testmethoden und -ansätze. So wie sie z.B. im ISTQB Certified Tester oder vergleichbaren Standards und in der Fachliteratur beschrieben sind:

• Definieren einer Teststrategie (Testziele, Teststufen, Testarten)
• Einsatz strukturierter Testfallmethoden wie Äquivalenzklassenbildung oder Entscheidungstabellen bis hin zu modellbasierten Ansätzen
• Einsatz von statischen Analysewerkzeugen für Code, Daten und Dokumente
• Laufende Reviews von Code, Architektur, etc.
• Stabile Testautomatisierung auf verschiedenen Ebenen

Das ist alles einleuchtend, der Nutzen dieser Aktivitäten seit vielen Jahren ein No-Brainer. Aber die Realität sieht dann gerne doch anders aus. Keine Zeit, keine Ressourcen oder “wofür brauchen wir das überhaupt?”. Gerade in agilen Projekten wird das manchmal ausgeblendet. Es muss ja kein 100-Seiten Testkonzept werden. Aber einmal auf einem Whiteboard zu skizzieren, was man wo und wie testen will, kann nicht schaden.

Reflexion – was machen wir hier eigentlich?

Spätestens wenn die Basics etabliert sind, meist sogar früher, setzt die nächste Stufe ein. Die Reflexion im Team. Ob als regelmäßige Retrospektive oder als gelegentlicher Workshop. Wenn das Team damit beginnt, die Qualitätsaktivitäten selbst zu bewerten, zu steuern und zu optimieren, wird es spannend. Denn jetzt beginnt sich, mit Selbstorganisation und -verantwortung, ein Weg aus den Best Practices anderer hin zu den eigenen zu entfalten.

Ich beobachte immer wieder, was für eine Kraft daraus entsteht. Aber auch Reibung. Und Konflikte. Das gehört an dieser Stelle dazu. Die Kunst als Führungskraft, Testmanager oder Quality-Coach besteht nun darin, dies in einen konstruktive Prozess zu leiten. Meist entsteht diese Phase aus Problemen heraus. Gründe sind z.B. fehlende Test-Infrastruktur, miserable Testdaten, schlechte Performance bei Testläufen. Zwangsläufig werden hier auch Projektgrenzen überwunden, es braucht für das Vorwärtskommen oft Unterstützung von außerhalb (Betrieb, Fachbereich, etc.). Sind diese dann selbst gelöst, geht es um Optimierung und Weiterentwicklung der Testaktivitäten. Durch die Reflexion der eigenen Prozesse und Themen verändert sich auch die Gruppendynamik. Bestehendes wird hinterfragt und oftmals steigt auch die Motivation und aus dem “wir müssen testen” wird ein “wir wollen testen”.

Experimente – neues Ausprobieren

Mit dem Selbstvertrauen, als Team mehr bewegen zu können, wächst auch der Mut. Und damit kann ein weiterer Qualitätslevel erreicht werden. Meist aus der Reflexion heraus, werden ganz neue Wege ausprobiert, für die es kaum Referenzen gibt. Z.B. im Bereich der Testautomatisierung. Das Team hat eine Idee, aber noch keinen Beweis, dass die Idee funktioniert und einen Nutzen bringt. Drum wird sie als Prototyp ausprobiert und “getestet”. Auch neue Testverfahren oder Prozessschritte lassen sich durch experimentieren schneller evaluieren, als durch große Pläne und extra Projekte. Teams, die diesen Level leben, erkennt man häufig daran, wie sie mit Fehl- und Rückschlägen aus diesen Experimenten umgehen. Bringt das Tool nicht den gewünschten Erfolg? Die Architekturänderung nicht mehr Testbarkeit? Der neue Generator keine besseren Testdaten? Experimente beinhalten Fehlschläge. Erfolgreiche Teams akzeptieren das, richten das Tester-Hütchen und weiter geht’s.

Mindset – wenn man nicht mehr drüber spricht

Aus Reflexion und Ausprobieren und wieder reflektieren der Testmethoden, Tools, neuen Ideen und Prozessänderungen entsteht mit der Zeit eine neue Kultur. Qualität wird nun zur Haltung. Hier verschwinden Sätze wie:

• “Ich bin fertig, ich muss nur mehr testen” oder
• “Die Zeit wird knapp wir sparen am Software-Test”.

Im Vordergrund steht der Projekterfolg: ein qualitativ hochwertiges Produkt abzuliefern. Und Testen gehört da dazu. Ebenso wie Entwickeln. Oder das Notwendigste dokumentieren. Und es muss gar nicht mehr explizit geplant, geschätzt, erwähnt werden. Es gehört einfach zu.

Beispielhaft dazu die Geschichte eines jungen Startups, für das ich ein Quality Assessment durchführen sollte. Sie wollten wissen, wie gut Sie denn im Bereich Testen/Qualität dastehen. Bei Interviews vor Ort war immer wieder zu hören “Nein, Testen…das machen wir eigentlich nicht so”. Ein Entwickler sagte “Ähm…extra Unittests schreibe ich nicht”. Tiefer reingesehen, kam die “Wahrheit” ans Licht. So viele Tests, Reviews und qualitätssichernde Maßnahmen habe ich selten in anderen Projekten gesehen. Dem Team war gar nicht bewusst, wieviel es schon in diese Richtung tat. Ja, und “extra Unittests” wurden nicht geschrieben, also nicht extra darüber hinaus, was einfach zur Software-Entwicklung dazugehört. Dieses Mindset habe ich auch bei meiner Zeit in den Tech-Unternehmen im Silicon Valley wahrgenommen. Qualität wird dort integral gelebt. Von der ersten Projektidee bis zum Launch. Trotz oder gerade wegen des Drucks schnell auf den Markt zu kommen, hat die nötige Qualität einen hohen Stellenwert.

Transformation – ein Weg, keine Arbeitsanweisung

Parallelen zu agilen Vorgehen sind da insgesamt nicht zufällig. Wenn es um Haltung geht, spielen all die Werte zusammen, die Qualität und Agilität ausmachen. Ich glaube, es stellt sich gar nicht mehr die Frage, ob dieser Weg gegangen wird. Die aktuellen und künftigen Herausforderungen machen es unumgänglich, sich als Team und Individuum weiterzuentwickeln. Die Veränderung kommt so oder so, die Frage ist, ob wir sie in Angststarre ignorieren oder aktiv gestalten. Und gerade im Bereich Qualität, Prüfen und Testen haben wir so viele Ressourcen in unseren Unternehmen, um hier zu gestalten. Und Qualität durchgängig als Haltung zu etablieren.