Ganzheitliches Testen

Ganzheitliches Testen ist ein Ansatz, bei dem Qualitätsaktivitäten in jede Phase des Softwareentwicklungslebenszyklus eingebettet sind und sich nicht auf eine einzelne Phase beschränken. Er verbindet die Verantwortung des gesamten Teams für die Qualität mit dem Testen, das kontinuierlich durch Entdeckung, Planung, Erstellung, Einsatz und Beobachtung der tatsächlichen Nutzung des Produkts durch die Kunden in der Produktion erfolgt.

Das Wichtigste in Kürze

• Mangelndes gemeinsames Verständnis ist der Haupttreiber für Nacharbeit: Teams bauen und testen eine Funktion, nur um dann vom Product Owner abgelehnt zu werden, weil die Anforderung nie vollständig erforscht wurde.
• Testen gehört in jede Phase des Entwicklungszyklus, von der Bewertung von Geschäftsideen in der Entwicklung bis zur Beobachtung des Kundenverhaltens in der Produktion, nicht nur in eine spezielle Testphase.
• Die Risikobewertung während der Planung verhindert Fehlerzustände, bevor auch nur eine einzige Zeile Code geschrieben wird, doch viele Teams verzichten darauf, selbst wenn sie testgetriebene Entwicklung und kontinuierliche Integration praktizieren.
• Tester, die Beziehungen zu Betriebsingenieuren, Ingenieuren für Zuverlässigkeit und Designern aufbauen, erhalten einen Einblick in Risiken, die innerhalb des Entwicklungsteams allein nie auftauchen.
• Eine visuelle, gemeinsam erstellte Teststrategie auf einer Mind Map ist einem schriftlichen Dokument überlegen, weil die Teammitglieder sich mit ihr beschäftigen, sie aktualisieren und Ideen entwickeln, die sie beim Lesen allein nicht erreichen würden.

Was ganzheitliches Testen wirklich bedeutet

Ganzheitliches Testen verbindet zwei Ideen: Das ganze Team ist für die Qualität verantwortlich und das Testen findet während des gesamten Softwareentwicklungslebenszyklus statt. Es ist keine Phase am Ende und kein Mini-Wasserfall, der in den letzten Tag eines Sprints gestopft wird.

Lisa Crispin und Janet Gregory haben das Modell auf der unendlichen DevOps-Schleife aufgebaut, mit Testaktivitäten in jeder Phase. Inspiriert wurden sie dabei von Dan Ashbys Modell für kontinuierliches Testen aus dem Jahr 2016. Sie wollten es erweitern, denn die Standard-DevOps-Schleife, die man online findet, zeigt eine einzige “Testphase”, die die meisten Leute als automatisierte Tests in der kontinuierlichen Integration verstehen.

Diese enge Auslegung ist das Problem. Um Qualität in ein Produkt einzubauen, muss über den gesamten Zyklus hinweg gearbeitet werden. Die Reduzierung auf ein Kästchen in einem Diagramm vermittelt den Teams die falsche Vorstellung.

Lisa und Janet nennen sie absichtlich Phasen und nicht Abschnitte. Phasen sind nicht abgegrenzt, und es gibt keine Übergänge zwischen ihnen. Das Vokabular ist wichtig, denn der Begriff “Phase” verleitet dazu, die Arbeit über eine Mauer zu werfen.

Der Zyklus beginnt lange vor der ersten Code-Zeile

Die Arbeit an der Qualität beginnt bei der Entdeckung, wo das Unternehmen entscheidet, was als nächstes geändert werden soll. Schon hier kann jemand mit einer Denkweise des Testens schwierige Fragen stellen. Ist diese Idee kongruent mit dem, was das Unternehmen bisher getan hat? Welches Problem löst sie für das Unternehmen und welches Problem löst sie für den Kunden?

Die Planungsphase ist die Phase, in der du den größten Nutzen mit dem geringsten Aufwand erzielst. Das Team legt fest, was bei einem Feature am wichtigsten ist: für den Kunden, für das Team, das die Software wartet, und für das Unternehmen. Von dort aus wählst du die Qualitätsmerkmale aus, die am wichtigsten sind.

Qualitätsmerkmale bleiben oft unausgesprochen, weil die Geschäftsleute davon ausgehen, dass das Lieferteam schon wissen wird, was zu tun ist. IT-Sicherheit und Leistung fallen in diese Lücke. Lisa zieht den Begriff “Qualitätsattribute” den “nicht-funktionalen Anforderungen” vor, da die Bezeichnung “nicht-funktional” ein falsches Bild von der Wichtigkeit dieser Attribute vermittelt.

Das Denken in Risiken gehört in die Planung, nicht in die Nachbearbeitung. Lisa hat schon Teams erlebt, die testgetriebene Entwicklung, Test in Paaren und kontinuierliche Integration betreiben und dabei die Anforderungen, die ihnen das Produkt vorgibt, ohne zu hinterfragen übernehmen. Um Fehler zu vermeiden, muss man Risiken frühzeitig analysieren, die Arbeit aufteilen und Prioritäten setzen, denn ein menschliches Gehirn kann nicht mehr als sechs Prioritäten auf einmal berücksichtigen.

Die Planung auf Story-Ebene ist die nächste Ebene. Arbeite dich in jede Story ein und baue ein gemeinsames Verständnis von dem auf, was du bauen willst. Ein Großteil der Fehlerzustände kann vermieden werden, bevor jemand den Code schreibt.

Kleine Chargen senken dein Risiko

Häufiges Deployment in kleinen Stapeln ist der sicherere Weg, nicht der riskantere. Wenn du eine kleine Änderung einführst und sie nicht funktioniert, weißt du genau, was passiert ist.

Während der Entwicklung entscheidet das Team, wie der Code für die Überwachung und Beobachtbarkeit instrumentiert wird. Explorative Tests können bereits auf der Story-Ebene stattfinden. Sobald der Code eine produktionsnahe Testumgebung erreicht, kommen neben den automatisierten Prüfungen auch die Qualitätsmerkmale zum Zug.

Manche Tests können nur von Menschen durchgeführt werden. Explorative Tests, Zugänglichkeitstests und andere Arbeiten, bei denen der Mensch im Mittelpunkt steht, lassen sich nicht wegautomatisieren. Sie stehen neben der automatisierten Suite, nicht in Konkurrenz zu ihr.

Testen in Produktion ist eine Option, wenn der Bereich es zulässt. Wo das nicht der Fall ist, kannst du immer noch beobachten, was mit den Kunden passiert, oder eine Funktion zuerst einer kleinen Gruppe vorführen. Das Testen hilft dabei, Muster, Anomalien und Risiken zu erkennen, wenn Änderungen live gehen, damit das Team schnell reagieren kann.

Auf der rechten Seite der Schleife halten sich die Tester zurück

Viele Teams hören in dem Moment auf zu testen, in dem ein neues Feature veröffentlicht wird. Für sie ist die Arbeit getan, und sie gehen zum nächsten Punkt über. Das ist die Seite der Schleife, auf der die meisten Tester nie die Chance hatten, ihre Fähigkeiten zu entwickeln.

Der Grund dafür ist selten Faulheit. Die Leute sind überlastet und haben keine Zeit, darüber nachzudenken, was nach der Veröffentlichung passiert. Die Arbeit wird auf die Operabilität abgewälzt, damit das Team mit der nächsten Aufgabe beginnen kann.

Tester zögern hier oft, weil ihnen die Tools fremd sind. Sie befürchten, dass sie keine Logdateien lesen oder Dashboards für die Überwachung nutzen können. Viele dieser Tools sind heute wirklich einfach zu bedienen, und die Fähigkeiten, die Tester bereits haben, lassen sich direkt übertragen.

Wenn du nicht zu einem Team gehörst, das nach dem Motto “wir bauen es, wir betreiben es” arbeitet, baue Beziehungen zu den Leuten auf, die es betreiben. Frag die Zuverlässigkeitsingenieure und Betriebsspezialisten vor Ort, was sie in der Produktion sehen und welche Risiken das Team belasten. Lasse das Gelernte in die Teststrategie einfließen, damit sie diese Risiken abdeckt.

Der Ansatz des ganzen Teams reicht über das Auslieferungsteam hinaus. Du brauchst Beziehungen zu den Designern, zu den Marketingfachleuten, die für die Analysen zuständig sind, und zu den Plattformingenieuren, falls es in deinem Team keine gibt. Beobachte, wie die Kunden eine Funktion tatsächlich nutzen. Manchmal ignorieren sie es, manchmal nutzen sie es auf eine Art und Weise, die niemand erwartet hat, und in jedem Fall fließen die Erkenntnisse in die nächste Geschäftsentscheidung ein.

Qualität ist mehr eine Sache der Menschen als der Technik

Tools und technische Hilfsmittel machen Teams nicht erfolgreich. Lisa verweist auf dreißig Jahre Forschung, die zeigt, dass es auf die richtigen Leute ankommt, die in die Lage versetzt werden, ihre beste Arbeit zu leisten. Manchmal muss man ihnen einfach nur aus dem Weg gehen.

Tester neigen dazu, Fragen zu stellen, an die sonst niemand denkt. Diese eine Angewohnheit kann ein Team verändern. Wenn du dich beim Testen am Ende eines Sprints umbringst, befundest du eine Person, der es genauso geht, einen Entwickler, der das gleiche Problem sieht, und überlegst dir, wie du mehr Leute einbinden kannst.

Mach das Problem sichtbar und mach auch deinen Beitrag zur Qualität sichtbar. Wenn die Entwickler/innen verstehen, was passiert, wollen sie nicht, dass die Tester/innen am Ende jeder Iteration mit nervenaufreibender Arbeit beschäftigt sind. Die Leute wollen gute Qualität, und sobald die Kosten sichtbar werden, neigen sie dazu, das Problem gemeinsam zu lösen.

Lisa sieht den Tester als Übersetzer zwischen zwei Sprachen.

Als Tester habe ich oft das Gefühl, dass ich die Geschäftsleute und die Techniker zusammenbringen kann und sie in ein Gespräch verwickeln kann, in dem sie sich gegenseitig verstehen. Lisa Crispin

Für diese Rolle ist es nicht erforderlich, zu programmieren. Tester brauchen ein technisches Bewusstsein, ein Verständnis für die Produktarchitektur und die Fähigkeit, IDEs und Testmonitore zu benutzen. Das Team hat bereits starke Programmierer. Was oft fehlt, ist jemand, der mit dem Unternehmen in dessen Sprache und mit den Ingenieuren in deren Sprache sprechen kann.

Interne Qualität ist Sache des Teams, nicht des Product Owners

Interne Qualität ist das, was für die Leute wichtig ist, die die Software entwickeln, unabhängig von der externen Qualität, die für die Kunden wichtig ist. Kent Beck hat diese Linie schon vor Jahren gezogen, und die agilen Testquadranten führen sie fort.

Ein Product Owner sollte nicht vorschreiben, wie die Software implementiert wird. Das Team wurde für dieses Fachwissen eingestellt. Wie sie gehostet wird, wie sie containerisiert wird, ob testgetriebene Entwicklung betrieben wird - all das ist die Entscheidung des Entwicklungsteams.

Interne Qualität zahlt sich aus, denn die Teams lesen den Code viel mehr, als sie ihn schreiben. Schwer verständlicher Code führt zu ständiger Mühsal. Mache den Code klar, dokumentiere ihn intern gut, und ein neues Teammitglied weiß, wo die Dinge sind und wie der Prozess funktioniert.

Auch Installierbarkeit und Übertragbarkeit gehören zu diesem Thema. Wenn du Desktop-Software anbietest, solltest du die Installierbarkeit für dich und deine Kunden von Anfang an einbauen. Wenn das Produkt später auf andere Plattformen übertragen werden soll, solltest du jetzt schon an die Übertragbarkeit denken, anstatt es nachzurüsten.

Warum Nacharbeit ein Symptom für verpasste Gespräche ist

Die meisten Nachbesserungen sind auf ein mangelndes gemeinsames Verständnis zurückzuführen. Das Team glaubt zu wissen, was eine Story bedeutet, baut sie, testet sie, übergibt sie dem Product Owner und erfährt, dass sie nicht das war, was sie wollten.

Die Korrektur ist billig und die Fehlerwirkung ist teuer. Ein Team kann ein wenig mehr Zeit in die Planung investieren und viel Zeit im Nachhinein sparen. Wenn ein Fehlerzustand die Produktion erreicht, rufen die Kunden den Support an, und die Kosten steigen an.

“Das war kein richtiger Fehler, sondern eine fehlende Anforderung”, ist ein Satz, den Lisa oft hört und der nicht zutrifft. Eine fehlende Anforderung ist eine verpasste Konversation. Flussdiagramme, Zustandsdiagramme und Kontextdiagramme während der Planung decken diese Lücken auf, bevor sie zu Nacharbeit werden.

Mach die Strategie sichtbar, damit die Leute sie tatsächlich nutzen

Eine Teststrategie, die in einem Dokument vergraben ist, das niemand liest, hat wenig Wirkung. Lisa hat in den 1990er Jahren in Wasserfallprojekten aufwendige Testkonzepte geschrieben und war stolz darauf, aber niemand sonst hat sie sich angeschaut, nicht einmal ihre Tester-Kollegen.

Eine Mind Map auf einem gemeinsamen virtuellen Whiteboard funktioniert besser, weil sie zur Zusammenarbeit einlädt. Alle können gleichzeitig an der Tafel sein, Ideen hinzufügen und gemeinsam brainstormen. Test-Aktivitäten werden auf der Karte angezeigt, abgehakt und mit Screenshots oder Screencasts belegt, wenn etwas nicht funktioniert.

Visuelle Darstellungen regen das Denken an, was Prosa nicht kann. Etwas auf einem Whiteboard löst bei einem anderen eine Idee aus, die dem Team viel Zeit spart. Sie helfen Menschen, quer zu denken und ihre unbewussten Vorurteile zu umgehen.

Es geht darum, das Team in die Erstellung der Karte einzubeziehen, nicht nur darum, sie ihm zu zeigen. Wenn die Teammitglieder selbst zur Strategie beitragen, bleiben sie mit ihr verbunden und kehren eher eine Woche später zu ihr zurück.

Ein Team, mit dem Lisa gearbeitet hat, sträubte sich gegen Mindmapping bei einer Geschichte, die alle als einfach bezeichneten. Sie versuchten es trotzdem, denn eine einfache Geschichte lässt sich schnell mappen. Eine Stunde später hatten sie eine große Karte, die eindeutig mehr als nur eine Geschichte umfasste. Wer es einmal ausprobiert, erkennt oft den Wert.

Wo soll man anfangen, wenn das Team unter Druck steht?

Beginne in der Planungsphase. In einem Umfeld voller Fristen und gestresster Menschen ist die Planung der Punkt, an dem eine kleine Veränderung am meisten bringt, denn ein fehlendes gemeinsames Verständnis ist die Ursache für so viele spätere Probleme.

Das Modell enthält Beispiele für Test-Aktivitäten, aber es sind Aufforderungen, keine Gebote. Lisa betont ausdrücklich, dass ganzheitliches Testen ein Denkwerkzeug und keine Regel ist. Die Teams haben ihre eigenen Anliegen eingebracht, wie z. B. die intensive Arbeit am UX-Design, wenn das Benutzererlebnis das Produkt bestimmt.

Passe das Modell an deinen Kontext an und füge hinzu, was du brauchst. Die Aktivitäten auf der rechten Seite der Schleife verdienen ebenfalls Aufmerksamkeit, da die meisten Tester dort am wenigsten gelernt haben. Es gibt viele Ressourcen, um diese Lücke zu schließen.