Warum beisst sich SCRUM so oft mit Testen?

Größe: px

Ab Seite anzeigen:

Download "Warum beisst sich SCRUM so oft mit Testen?"

Catharina Zimmermann
vor 8 Jahren
Abrufe

1 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

2 Wie erlebe ich SCRUM?

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

4 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

5 Des Pudels Kern ist unabhängig von der gewählten Methode, auch bei SCRUM! Ein Softwaretest prüft und bewertet Software auf Erfüllung der für ihren Einsatz definierten Anforderungen und misst ihre Qualität. Quelle: WIKIPEDIA

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

Ausführung der Testfälle, Überprüfung der Ergebnisse, Auswertung der Ausgangskriterien, Berichten über

7 Der Einfluss von Projektmethoden Test-Planung Entwicklung vers. Test-Team Test- Infrastruktur Wasserfall RUP SCRUM Viel Zeit Testen als Phase Eigene Disziplin Ad hoc 2 Welten Getrennt Integriert Viel Zeit für Vorbereitung Change Request Grosser Impact CR kann verloren gehen Teststrategie Hat Zeit und Raum Kann vorbereitet werden Iterationsweise vorgesehenes Artefakt Gleichzeitiges Testen und Infrastruktur bauen Muss sehr gut verwaltet (Backlog) und kommuniziert werden, inkl. Testtasks! Kommt zu kurz!

Integriert Viel Zeit für Vorbereitung Change Request Grosser Impact CR kann verloren gehen Teststrategie Hat Zeit und Raum

8 SRUM bringt (nötige) Veränderungen Andere und neue Rollen Mehr Transparenz Dynamischere Planung Intensivere und bessere Kommunikation

9 Wird dank SCRUM besser kommuniziert? Bestellen Sie zuerst einen Krankenwagen, dann suchen Sie einen Freiwilligen, der dem Tester mitteilt, dass er seit 2 Sprints auf der falschen DB testet!

10 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

an Regressionstest wird zu gross Testmanagement fehlt, es gibt keinen Testhut -> SCRUM kennt die Rolle

11 Problemfeld: «keine Dokumentation» Quelle: Dieser Teil des Manifests wird oft als Freipass verwendet, keine Dokumentation zu erstellen.

12 das Manifest, zweiter Teil

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

Erwartung gibt die belegt werden soll, während das

14 Die SCUM - Zone NO SCRUM SCRUM-Zone NO SCRUM Grafik gemäss SoDa HSLU, Prof. M. Jud Modell aus Jenny «Projektmanagement»

15 Tipp #1: TestCases entstehen iterativ Iteration 1 Iteration 2 Iteration 3 Iteration 4 Pro UC / UserStory ein TC, im Minimum der Titel plus ev. Testziel Hauptvariante mit genauer Beschreibung des Ablaufs Erwartete Resultate sind beschrieben Mögliche Varianten mit Titel beschrieben Hauptvariante mit weiteren Daten ergänzen (Grenz- u. Negativwerte). Ziel: Personenunabhängig! Weitere Varianten mit Beschreibung und Daten, Automatisierung prüfen! Die TestCases wachsen mit jeder Iteration, sie beschreiben die Bedürfnisse des Product Owners, und beinhalten messbare Kriterien für den Entscheid: «Done»

Hauptvariante mit weiteren Daten ergänzen (Grenz- u. Negativwerte). Ziel: Personenunabhängig!

16 «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

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

17 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!

Im SCRUM fehlt die Testmanagement-Disziplin.

18 Tipp #2: Testen braucht eine Strategie «Die Praxis soll das Ergebnis des Nachdenkens sein, nicht umgekehrt.» Hermann Hesse Schriftsteller und Testmanager

19 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

Risikoanalyse) Pflegen der Definition of Done Etablieren und

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

Design-Dokumenten hilft zu Beginn eines Sprints, die Anzahl und den Umfang der Tasks festzulegen Dient am Ende des

21 Tipp #4: Gute Planung der Tests 1/2 Neue Funktion Retest Ungetestet fehlende Funktion

22 BUG BUG Gute Planung der Tests 2/ Abnahmetest automatisieren 1.1 Abnahmetest Sprint 1 Sprint 2 Sprint 3 Sprint 3 Features BUG fixing Features BUG fixing plus Testunterstützung plus Testunterstüt.

23 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

24 Tipp #6: Testtiefe und Testumfang

25 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?

26 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)

27 Der Product Owner ist auf gutes Reporting angewiesen

28 Tipp #8: Reporting ist mehr als Burndown Wird genügend getestet, flacht die Kurve ab, hat es noch Fehler?

29 gutes Testreporting

30 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

31 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. Dominique Portmann Leiter Testengineering

Ähnliche Dokumente

Gelebtes Scrum. Weg vom Management hin zur Führung

Gelebtes Scrum. Weg vom Management hin zur Führung Gelebtes Scrum Weg vom Management hin zur Führung Herausforderungen Was ist Scrum? Wer? Pigs Chicken Bild: http://www.implementingscrum.com/ Nein Danke, ich würde da voll drinstecken, aber du wärest