Stolpersteine im Test-Reporting

Test Management, oder vielmehr Testing allgemein, stellt das Bindeglied zwischen Auftraggeber und Projekt mit dem Fokus auf die Feststellung der vom Projekt gelieferten Qualität dar. Dabei spielt es eher eine untergeordnete Rolle, ob Testing ein Service an das Projekt ist, den Auftraggeber im Abnahmetest direkt und ausschliesslich unterstützt oder integraler Bestandteil eines agilen Teams ist.

Nun gibt es in dieser Konstellation hin und wieder Teilnehmer, die das “Testing” als behindernden, wenn nicht sogar als verhindernden Beitrag zur Entwicklung bezeichnen würden. Die Begründungen sind hierbei vielfältig und nicht selten kommt als Argument fehlendes fachliches Know-How oder eine mangelnde Toleranz gegenüber der festgestellten Abweichung.

Kill the Messenger – Wie man schlechte Nachrichten besser nicht überbringt

Der eine oder andere zum Intellekt geneigte Leser (Anmerkung des Autors: kleiner Scherz) hat bestimmt schon selbst festgestellt, dass man Software nicht gesund testen kann. Auch der ISTQB hat zu diesem Thema eine klare Meinung, die in der Praxis allzu oft untergeht: “Das Test-Team stellt die Qualität des Testobjekts fest, ist aber nicht für die Qualität des Testobjekts verantwortlich”. In diesem Beitrag möchte ich gerne dem Leser etwas mit auf dem Weg geben, das mir in all den Jahren als Test Manager sehr geholfen hat: “Die Aussagen zur festgestellten Qualität müssen gewaltfrei und belastbar sein”. Und das aus verschiedenen Perspektiven.

Der Testmanager von heute ist ein Integrationselement im Konglomerat der Projektteilnehmer. Er ist DIE verbindende Rolle im Projekt, wenn es darum geht festgestellt Abweichungen zu bewerten und daraus resultierende Risiken zu erkennen. Er macht dies gewaltfrei und vermeidet Adjektive wie zum Beispiel “schlimm, unbrauchbar, katastrophal, …”. Eine gewaltfreie Kommunikation ist die Basis für einen respektvollen Umgang innerhalb des Projekts und fördert voll allem die Motivation der Betroffenen, sich dem identifizierten Thema anzunehmen und dies zum Erfolg zu führen. Im Gegensatz zur NLP (Neuro-Linguistische Programmierung) versucht man nicht die andere Seite zu einer bestimmten Handlung zu bewegen, sondern fokussiert sich auf eine wertschätzende Beziehung und dem damit verbundenen gemeinsamen Ziel. Qualitätsaussagen müssen aus jeder Perspektive belastbar sein. Wie schafft man das? Man nimmt sämtliche emotionalen Begriffe aus dem Teststatus-Report heraus und verweist auf die zugrunde liegenden Zahlen. Hierbei würde ich zwischen Status- und Trendzahlen unterscheiden:

• Statuszahlen spiegeln die aktuelle Situation des Projekts wider: Wie hoch ist der Anteil an “failed” Testfällen? Wie viele Testfälle der Risikoklasse A wurden erfolgreich ausgeführt? Wie erfolgreich waren in dieser Iteration die Nachtests? Wie hoch ist derzeit der Anteil der Fehler im Bereich XY?
• Trendzahlen geben einen Ausblick über eine mögliche Entwicklung der bisher festgestellten Qualität. Sinkt die Anzahl der Fehler oder steigt sie? Haben die neuen Massnahmen gegriffen und konnte die Nachtest-Rate gesenkt werden? Können sämtliche Testfälle bis zum Endtermin ausgeführt werden?

Diese Beispiele könnten beliebig erweitert werden. Wichtig ist hierbei, dass die im Teststatus-Report dokumentierten Aussagen zur Bewertung der aktuellen Qualitätssituation nur und ausschliesslich auf diesen Zahlen basieren und möglichst wenig Raum für Interpretationen zulassen. So entzieht man einer möglichen emotionsbehafteten Diskussion die Grundlage und schafft den Boden für eine zielgerichtete und erfolgsorientierte Diskussion. Aber Achtung: Es erfordert einige Übung und den einen oder anderen Review-Partner, bis man sich einen Wortschatz zugelegt hat, der die oben genannte Idee konsequent umsetzt. Manchmal ist es auch hilfreich, den Test-Report einige Zeit (z.B. 2h) liegenzulassen, anschliessend zu redigieren und erst dann final an die jeweiligen Projektteilnehmer zu versenden.

Test-Reporting – Gemeinsam erfolgreich sein

Ein weiterer, wenn nicht sogar essenzieller, Tipp wäre, sich über die Ziele und deren zugrunde liegenden Metriken im Vorfeld des Projekts Gedanken zu machen und diese klar, abgestimmt und für alle Beteiligten verständlich transparent zu dokumentieren. Ähnlich wie die Definition-of-Done von einem Scrum-Arbeitspaket sollten auch Metriken und Ziele vor der Realisierung definiert werden. Im Laufe der Jahre und den damit verbundenen Test-Projekten hat sich herauskristallisiert, dass reine Statuszahlen (Anzahl von XY) wenig oder nur oberflächlich Einblicke in das Testvorgehen widerspiegeln. Viel interessanter und aufschlussreicher sind Trendzahlen (Werteverlauf) und Verhältniszahlen (z.B. durchschnittliche Nachtestrate). Ein empfehlenswertes Vorgehen wäre hier der GQM-Ansatz (Goal-Question-Metric). Dies würde allerdings den Rahmen dieses Artikels bei weitem sprengen und wird in einem späteren Beitrag von mir behandelt.

… übrigens, das Zitat: “Traue keiner Statistik, die du nicht selbst gefälscht hast.” wird üblicherweise Winston Churchill zugeschrieben. Eine Evidenz hierfür ist uns die Zitate- und Sprichwort-Forschung (ja, die gibt es wirklich) bis heute schuldig geblieben.