Software-Qualität als Haltung

„The problem is not the problem. The problem is your attitude about the problem.“ —
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 methodischem
Software-Testen ist es heute aber nicht mehr getan. Die Zeiten, in denen 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 und andere 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. Nur fällt so ein Mindset nicht vom Himmel. Man muss einen Weg, eine
Transformation, hinter sich bringen, um dahinzukommen.

Für jedes Team ist dieser Weg ein sehr individueller. Dennoch lassen sich gewisse
Meilensteine über die Zeit festmachen, welche die Qualität auf die nächste Ebene bringen.

Basics – Softwaretest-Grundlagen nutzen

Der erste 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 sowie 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 und der Nutzen dieser Aktivitäten seit vielen Jahren selbstverständlich.

Aber die Realität sieht dann gerne doch anders aus. Keine Zeit, keine Ressourcen oder die ständige Frage „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 konstruktiven Prozess zu leiten.

Meist entsteht diese Phase aus Problemen heraus. Gründe sind z.B. fehlende Test-
Infrastruktur, miserable Testdaten oder 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 Probleme dann 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, 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, steigt 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. Darum 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 eigene Projekte. Teams, die diese Qualitätsebene 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 gehts.

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 dazu.

Beispielhaft dazu die Geschichte eines jungen Startups, für das ich ein Quality Assessment durchführen sollten. 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 die Richtung tat. Ja, und „extra Unittests“ wurden nicht geschrieben, also nicht extra über das 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 hin 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 in den Bereichen 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.

Richard Seidl

ist Berater, 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, wo es 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.