Warum beisst sich SCRUM so oft mit Testen? Dank angepasstem Testmanagement können auch SCRUM Projekte erfolgreich sein! Vers.2.1

Dominique Portmann Leiter Testengineering, Noser Engineering

Wie erlebe ich SCRUM?

Inhalt des Referats

Sie erfahren, welchen Einfluss SCRUM auf das Testen hat und wie angepasstes Testen und cleveres Testmanagement SCRUM erfolgreich unterstützt.

Was ist/soll Testen überhaupt?

Ein Softwaretest prüft und bewertet Software auf Erfüllung der für ihren Einsatz definierten Anforderungen und misst ihre Qualität.

Quelle: WIKIPEDIA

Des Pudels Kern…

Ein Softwaretest prüft und bewertet Software auf Erfüllung der für ihren Einsatz definierten Anforderungen und misst ihre Qualität.

Quelle: WIKIPEDIA

…ist unabhängig von der gewählten Methode, auch bei SCRUM!

Was meint das STB

Weitere Testaktivitäten sind vor und nach der Testdurchführung angesiedelt. Dazu gehören: Planung und Steuerung der Tests, Auswahl der Testbedingungen, Testfallspezifikation, Ausführung der Testfälle, Überprüfung der Ergebnisse, Auswertung der Ausgangskriterien, Berichten über den Testprozess und das zu testende System sowie nach Abschluss einer Testphase Abschlussarbeiten zu Ende zu bringen.

Der Einfluss von Projektmethoden

Wasserfall RUP SCRUM

Test-Planung Viel Zeit Testen als Phase

Eigene Disziplin

Ad hoc

Entwicklung vers. Test-Team

2 Welten Getrennt Integriert

Test- Infrastruktur

Viel Zeit für Vorbereitung

Kann vorbereitet werden

Gleichzeitiges Testen und Infrastruktur bauen

Change Request Grosser Impact CR kann verloren gehen

Iterationsweise Muss sehr gut verwaltet (Backlog) und kommuniziert werden, inkl. Testtasks!

Teststrategie Hat Zeit und Raum

vorgesehenes Artefakt

Kommt zu kurz!

SRUM bringt (nötige) Veränderungen

• Andere und neue Rollen

• Mehr Transparenz

• Dynamischere Planung

• Intensivere und bessere Kommunikation

Wird dank SCRUM besser kommuniziert?

Bestellen Sie zuerst einen Kranken-wagen, dann suchen Sie einen Freiwilligen, der dem Tester mitteilt, dass er seit 2 Sprints auf der falschen DB testet!

Probleme: SCRUM bedeutet oft auch…

• Juhee, es braucht keine Dokumentation! -> Anforderungen sind unklar, nicht beschrieben

• Die Einplanung von Regressionstests wurde vergessen -> Die Menge an Regressionstest wird zu gross

• Testmanagement fehlt, es gibt keinen Testhut -> SCRUM kennt die Rolle Testmanager nicht!

• Es fehlt eine Teststrategie -> Es wird planlos das Falsche zu oft getestet

• Unbrauchbares Reporting -> Das Reporting blendet den Testfortschritt aus

Problemfeld: «keine Dokumentation»

Quelle:

Dieser Teil des Manifests wird oft als Freipass verwendet, keine Dokumentation zu erstellen.

…das Manifest, zweiter Teil

Problemfeld «Experimentieren»

Testen unterscheidet sich von Experimentieren dadurch, dass es beim Testen eine Erwartung gibt die belegt werden soll, während das Ergebnis beim Experimentieren offen ist oder nur vermutet werden kann.

Die SCUM - Zone

Grafik gemäss SoDa HSLU, Prof. M. Jud Modell aus Jenny «Projektmanagement»

SCRUM-Zone NO SCRUM NO SCRUM

Tipp #1: TestCases entstehen iterativ

Die TestCases wachsen mit jeder Iteration, sie beschreiben die Bedürfnisse des Product Owners, und beinhalten messbare Kriterien für den Entscheid: «Done»

Iteration 1 Pro UC / UserStory ein TC, im Minimum der Titel plus ev. Testziel Iteration 2 Hauptvariante mit genauer Beschreibung des Ablaufs Erwartete Resultate sind beschrieben Mögliche Varianten mit Titel beschrieben Iteration 3 Hauptvariante mit weiteren Daten ergänzen (Grenz- u. Negativwerte). Ziel: Personenunabhängig! Iteration 4 Weitere Varianten mit Beschreibung und Daten, Automatisierung prüfen!

«Explosives» Problem mit Iterationen

Das Dilemma: Mit jeder Iteration kommt ein kleiner Teil an neuen «Features», aber der Teil an Regressionstest wächst!

Die Testtätigkeit muss eingeplant und als Tätigkeit im Backlog und in der Sprintplanung «manifestiert» sein.

Entwickler müssen Testautomaten bauen!

Regelmässig reine Test-Sprints, ohne neue Features, es wird nur getestet, Tests beschrieben und automatisiert.

Dies bedarf einer übergeordneten Testplanung einer Teststrategie

Es gibt keinen Test-Hut

Der «Product-Owner» validiert die Sprints, d.h. er entscheidet «Done» resp. Go/NoGo.

Sicher kennt er das Business, aber oft fehlt der methodische Testhintergrund.

Im SCRUM fehlt die Testmanagement-Disziplin. Professionelles Testmanagement entlastet Führungspersonen, auch «Product-Owner» . Daher muss die Rolle des Testmanagers zusätzlich definiert und zugeordnet werden.

Dies ist eine Schlüsselstelle, welche über ein erfolgreiches SRCUM-Projekt entscheidet!

Tipp #2: Testen braucht eine Strategie

«Die Praxis soll das Ergebnis des Nachdenkens sein, nicht umgekehrt.»

Hermann Hesse Schriftsteller und Testmanager

Was kann das Testmanagement

• Testschritte gemäss Testprozess für SCRUM adaptieren

• Erstellen der Teststrategie (z.B. Risikoanalyse)

• Pflegen der Definition of Done

• Etablieren und Pflegen von relevanten und jederzeit aktuellen Führungskennzahlen

Tipp #3: «Definition of Done»

• ist eine Checkliste von Aktivitäten, die zur Implementierung einer User Story gehören und die Qualität der Software beeinflussen

• Verlangt das Schreiben von Kommentaren, Unit Tests und Design-Dokumenten

• hilft zu Beginn eines Sprints, die Anzahl und den Umfang der Tasks festzulegen

• Dient am Ende des Sprints neben den Anforderungen für eine spezifische User Story dazu, zu entscheiden, ob eine User Story als done akzeptiert wird.

Tipp #4: Gute Planung der Tests 1/2

Neue Funktion

Retest

Ungetestet fehlende Funktion

Gute Planung der Tests 2/2

Sprint 1 Sprint 2 Sprint 3

1.0.0

1.0 Abnahmetest

BU

G

BU

G

1.0.1

1.0.1

1.1 Abnahmetest

1.1.0

automatisieren

Sprint 3

Features BUG – fixing Features BUG – fixing plus Testunterstützung plus Testunterstüt.

1.0.1

Tipp #5: richtiger Mix von Testarten

Testart Fokus Nutzen

Formale Eintrittskriterien

Sind alle Vorbereitungen getroffen und belegt

Voraussetzungen für Testaufwand sind gegeben

Vitalität Schnelle Übersicht Prüfen ob Testaufwand nötig

Neue Funktionen Funktioniert Neues? Ist der Weg der richtige?

Gefixte BUGs Fatal und Urgent Bugs binden Ressourcen!

«Nur leicht modifiziert» Gibt es Kollateralschäden? Stabiles System

Retest / Regression Funktioniert es noch Stabiles System

Monkey und negativ Gewohnte Pfade verlassen Nicht nur Schönwetter

Unvorhergesehenes Management Quick WIN und Akzeptanz

Tipp #6: Testtiefe und Testumfang

Tipp #7: Entwickler in die Pflicht nehmen!

Wird ein Fehler gefunden, wird er im Scrum-Team besprochen. Dabei soll insbesondere untersucht / geklärt werden, warum der Fehler nicht eine Teststufe früher entdeckt wurde.

Wollen / können wir es uns leisten, Fehler so spät zu finden ?

Ein bewährtes Beispiel:

Code kann nur eingecheckt werden, wenn:

• Ein Bezug zu einer Anforderung da ist

• der Code nach dem 4-Augen Prinzip gereviewt wurde («Reviewed by» ist ein Pflichtfeld)

Der Product Owner ist auf gutes Reporting angewiesen

Tipp #8: Reporting ist mehr als Burndown

Wird genügend getestet , flacht die Kurve ab, hat es noch Fehler?

…gutes Testreporting

Summary

• Testhut / Rolle zuweisen

• Angepasste Teststrategie erstellen: Risikogerechtes Testen, «Definition of done»

• Testen als Tätigkeit einplanen

• Tests iterativ erstellen

• Testautomatisierung früh einplanen

• Angepasstes Reporting

Dominique Portmann Leiter Testengineering

Danke für die Zeit sowie die Aufmerksamkeit,

die Sie als Schlüsselpersonen

dem Testen schenken. Gerne beantworte ich jetzt

(oder auch später) Fragen….