Einige von euch mögen sich noch an Adrian Stolls Beitrag „Scrum still Rocks – Testing still Sucks“ erinnern. Dank konsequenterem Einsatz moderner Techniken und Möglichkeiten rockt Scrum jetzt noch mehr. Dank Continuous Integration (CI) kann jederzeit der aktuellste Stand der Software in einer hohen Code Qualität getestet werden. Hier ist ein kleiner Praxisbericht, wie es funktionieren und richtig viel Spass machen kann.

Der Fokus dieses ersten Beitrags liegt dabei auf dem Teil des manuellen Testens. Eine Fortsetzung zum Thema automatisiertes Testen erfolgt durch Alexander Würmlin.

Umgebungsvariablen

Die Ausführungen dieses Praxisberichts basieren auf einem agilen Projekt mit folgenden Rahmenbedingungen:

• Ein Scrum Team mit sechs Entwicklern, einem manuellen Tester, einem Testautomatisierer, Product Owner, Scrum Master und GUI Designer
• Alle typischen Scrum Meetings werden durchgeführt, Scrum ist etabliert und funktioniert
• Wir befinden uns in Sprint 12 und die Sprintlänge beträgt drei Wochen
• Das Team arbeitet Hand in Hand zusammen und ist eingespielt
• Entwickelt wird eine Microsoft .NET Webanwendung im Bundesumfeld, welche HERMES – konform dokumentiert werden muss
• Im Einsatz sind Microsoft Team Foundation Server (TFS) 2015 sowie HP ALM 12

Eine weitere Rahmenbedingung ist natürlich meine Person. Ich bin ein erfahrener Tester und übernehme in diesem Projekt das manuelle Testen. Ich bin bekannt dafür, viele Fehler zu finden. Manche Leute nennen es Bug-Hunting.  Die Fehler, die ich finde, erfasse ich normalerweise auch – es gibt wenige Ausnahmen. Der Vorteil vom Erfassen vieler Fehler liegt meiner Meinung nach darin, dass ich den Retest nicht vergesse. Weiterhin finde ich beim Retest oft Folgefehler. Die Erfassung vieler Fehler ist für mich somit ein Werkzeug, um die Produktqualität so hoch wie möglich zu halten!

Mein Testtag im Projekt

Der Praxisbericht beschreibt einen typischen Tag während des Sprints. Da ich viele Fehler erfasse und das Entwicklungsteam den Anreiz hat, Fehler möglichst schnell zu korrigieren, werfe ich als erstes einen Blick auf den Homescreen vom TFS. Hier sehen wir eine Kachel mit dem Titel „Open Bugs“:

Beim Klick auf die Kachel werden dabei die fünf dargestellten Bugs aufgelistet. Es ist sehr einfach zu erkennen, welche der Bugs bereits von der Entwicklung korrigiert wurden.

Ein weiterer Vorteil ist, dass neue Bugs „highly visible“ sind. Jeder Mitarbeiter im Projekt kann mit einem Klick die Anzahl offener Bugs sehen. Die Entwickler finden neue Bugs sofort und können diese korrigieren. Der Produkt Owner sieht sofort, dass zwar viele Bugs offen, diese aber bereits in Arbeit oder Ready for Retest sind. Die Detailansicht hinter der Kachel ist folgende:

Wichtig sind für mich nur die Bugs mit dem Status Committed. Der Status mag nicht ganz passend klingen aber dabei handelt es sich um die Bugs, welche bereit sind für den Retest. In diesem Beispiel ist nur einer von fünf Bugs im Status Committed, somit lohnt es sich nicht extra einen Testfall für die Retests zu starten. Approved Bugs sind in Arbeit bei der Entwicklung, New Bugs wurden noch nicht von der Entwicklung bearbeitet oder gesehen.

Da sich ein Bug Retest also nicht lohnt, schaue ich als zweites in den Sprint Backlog. Das sieht ungefähr so aus:

Dieser Screenshot ist beispielhaft. Er zeigt ein Produkt Backlog Item (PBI) (Blau) mit drei Tasks (Gelb) und einem offenen Bug (Rot). Dieses PBI werde ich erst wieder anschauen, wenn der Bug vom Entwicklungsteam auf Committed gesetzt wird. Wer aufgepasst hat konnte feststellen, dass dieser eine Bug bereits in den Details der Kachel „Open Bugs“ zu sehen war.

Im täglichen Betrieb würde ich nun die PBI’s suchen, bei denen der „Functional Testing“ – Task den Status New hat und alle anderen Tasks den Status Done haben. Das bedeutet, die Entwicklung ist abgeschlossen und das PBI ist Ready for Test.

Wenn ich nun ein PBI gefunden habe, das ich testen kann, folgt der dritte Schritt: Ich mach mir mal schnell ein Deployment. Ja genau, richtig gelesen! Ich mache das selbst. TFS macht’s möglich.

Das Deplyoment bzw. meinen neuen Build erstelle ich folgendermassen:

1. Im TFS oben auf BUILD klicken
2. Das Dropdown bei „Test with deploy“ (=die Definition für’s Deployment auf meine Testumgebung) öffnen
3. Klick auf „Build zur Warteschlange hinzufügen“
4. Es öffnet sich ein modales Fenster, in dem ich das Deployment mit OK bestätigen muss
5. Etwa 15 Minuten warten bis der Build Prozess abgeschlossen ist

Während dem Build Prozess werden alle Unit Tests durchgeführt. So ist sehr schnell ersichtlich, dass der Build in Ordnung ist. Neben dem manuellen Test-Deploy steht noch ein CI-Deploy zur Verfügung. Dieser läuft mehrmals täglich nach jedem grossen Commit. Des Weiteren gibt es einen Nightly Build, bei dem neben den Unit Tests zusätzlich alle automatisierten GUI-Tests ausgeführt werden. Jeder Deploy geht dabei auf seine eigene Umgebung, so dass zum Beispiel der CI-Deploy keinen Effekt auf meine manuellen Tests hat.

Nun habe ich alles, was ich brauche und kann mit dem Testen beginnen. Der Test wird dabei mit dem HP Sprinter gestartet. Dieser dokumentiert jeden Klick mit Text und Screenshot, was zu einer lückenlosen und HERMES-konformen Dokumentation führt. Das ist insbesondere nötig, da es sich um explorative Tests und nicht um strukturierte Testfälle handelt.

Da mir die Prozesse und Tools erlauben, vieles selber zu machen, habe ich mehr Zeit um mit den Entwicklern kritische Sachverhalte, wie zum Beispiel fehlgeschlagene Deployments zu besprechen. Ich muss sie nicht von der Arbeit abhalten um herauszufinden, welches PBI oder welcher Bug fertig ist oder wenn ich heute schon zum dritten Mal ein Deployment haben will. Es gibt den regelmässigen Austausch im Daily Meeting und bei allen anderen Herausforderungen kommunizieren wir einfach direkt.

Kurz und knapp: Darum rockt es

Was noch fehlt ist jetzt die Frage, warum Scrum immer noch rockt oder warum es aufgrund von CI noch mehr rockt. Die Antworten konnten hoffentlich schon aus dem Praxisbericht herausgelesen werden. Scrum mit CI rockt weil:

• Testen in einem Scrum Projekt und mit einem eingespielten Scrum Team mir schon immer Spass gemacht hat.
• Die Tools sind heute viel weiter und lassen sich einfacher benutzen: Meine Testausführung wird quasi von selbst dokumentiert und sogar mein Deployment erstelle ich selbst.
• Ich kann selbstständig herausfinden, was ich heute tun muss. Somit kann ich mir die Zeit auch selbst einteilen und damit selbst entscheiden, wo ich viele Fehler erwarte und somit mehr Zeit investieren möchte.
• Aufgrund der Testautomatisierung bei jedem Deployment (darauf wird Alexander Würmlin’s Blog-Beitrag detailliert eingehen) kann ich das langweilige Thema der Regressionstests grösstenteils umgehen. Im Gegenteil kann ich Vorschläge für mögliche Regressionstests geben.
• Ich muss die Entwickler nur „nerven“, wenn es echte Probleme gibt.

Diese Liste hat viel Potential für weitere Punkte. Testen macht Spass, Scrum macht Spass und die Kombination ist unschlagbar. Falls sich offene Fragen ergeben haben, können diese gerne hier gestellt und beantwortet werden.

Übrigens : Gemäss dem SwissQ T&B – Report aus dem Jahr 2015 wird Continuous Integration bereits in 62,2 Prozent der agilen Projekte angewendet!