“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.
Häufig gestellte Fragen
Warum reicht es nicht, die fertige Software vom Entwicklungsteam an ein Testteam zu übergeben?
Die knallharte Silotrennung funktioniert meist mehr schlecht als recht. Wer exzellente Software will, denkt den Entwicklungsprozess ganzheitlich: Menschen, Methoden, Tools und Mindset müssen zusammenspielen. Qualität wird dann zur Haltung des Teams statt zur Aufgabe einer nachgelagerten Abteilung. Der Weg dorthin ist ein Veränderungsprozess, der Verständnis und Empathie für Entwickler, Tester, Führungskräfte und Stakeholder verlangt.
Braucht ein agiles Team ein ausformuliertes Testkonzept?
Ein 100-Seiten-Dokument braucht es nicht. Es hilft aber schon, einmal auf einem Whiteboard zu skizzieren, was wo und wie getestet werden soll. Die bewährten Grundlagen bleiben dieselben: Testziele, Teststufen und Testarten, strukturierte Testfallmethoden wie Äquivalenzklassenbildung oder Entscheidungstabellen, statische Analyse von Code, Daten und Dokumenten, laufende Reviews und stabile Testautomatisierung auf mehreren Ebenen.
Was verändert sich, wenn ein Team seine Qualitätsaktivitäten selbst bewertet?
Es entsteht ein eigener Weg statt übernommener Best Practices anderer. Sobald ein Team in Retrospektiven oder gelegentlichen Workshops seine Testaktivitäten selbst steuert und optimiert, wachsen Selbstorganisation und Verantwortung. Bestehendes wird hinterfragt, die Gruppendynamik verschiebt sich, und häufig steigt die Motivation: Aus einem “wir müssen testen” wird ein “wir wollen testen”.
Sind Konflikte ein schlechtes Zeichen, wenn ein Team seine Testprozesse hinterfragt?
Nein, Reibung und Konflikte gehören zu dieser Phase. Sie beginnt meist aus konkreten Problemen heraus: fehlende Test-Infrastruktur, miserable Testdaten, schlechte Performance bei Testläufen. Die Aufgabe von Führungskraft, Testmanager oder Quality-Coach besteht darin, das in einen konstruktiven Prozess zu leiten. Oft braucht es dafür Unterstützung über Projektgrenzen hinweg, etwa aus Betrieb oder Fachbereich.
Wie gehen Teams sinnvoll mit gescheiterten Experimenten im Testumfeld um?
Sie kalkulieren Fehlschläge ein und machen weiter. Wer neue Wege in der Testautomatisierung, bei Testverfahren oder Prozessschritten geht, hat keinen Beweis für den Nutzen: Deshalb der Prototyp. Bringt das Tool nicht den erhofften Erfolg oder liefert ein neuer Generator keine besseren Testdaten, wird das akzeptiert. Experimente evaluieren solche Ideen schneller als große Pläne und Extraprojekte.
Woran erkennt man ein Team, für das Qualität zur Haltung geworden ist?
Daran, dass kaum noch darüber gesprochen wird. Die Mitglieder können ihre Qualitätsaktivitäten oft gar nicht mehr vollständig aufzählen, weil Testen selbstverständlich zur Entwicklung gehört und nicht mehr eigens geplant, geschätzt oder erwähnt wird. Sätze wie “Ich bin fertig, ich muss nur mehr testen” oder “Die Zeit wird knapp, wir sparen am Software-Test” verschwinden.
Leidet die Qualität, wenn der Druck hoch ist, schnell auf den Markt zu kommen?
Nicht zwangsläufig. Bei einem Quality Assessment in einem jungen Startup hieß es in den Interviews zunächst, Testen mache man eigentlich nicht so. Tatsächlich fanden sich dort mehr Tests, Reviews und qualitätssichernde Maßnahmen als in vielen anderen Projekten. Auch in den Tech-Unternehmen im Silicon Valley wurde Qualität von der ersten Projektidee bis zum Launch integral gelebt.
