Systemtest im agilen Entwicklungsprozess - Vortrag ASQF Testing Day

Einen interessanten Vortrag auf dem Testing Day hielt Dr. Hehn von Methodpark zum Thema Systemtest im agilen Entwicklungsprozess. Als Diskussionsgrundlage, mit Bezug zu einem realen Projekt, wurde die agile Methode SCRUM heangezogen (Wikipedia: Scrum).
Der Systemtest in agilen Projekten fristet immer noch ein stiefmütterliches Dasein. Wird er erst ganz zum Ende des Projektes durchgeführt, kann dies natürlich viel zu spät sein (man kann die Erkenntnisse nicht mehr in der Software berücksichtigen - z. B. Performanceprobleme). Also ist es eine Notwendigkeit, schon früher im Softwareprojekt den Systemtest zu berücksichtigen.

Folgende Thesen bzw. Anregungen enthielt der Vortrag:

• Schon im ersten Sprint werden für den Systemtest Testkonzepte erstellt.
• Da in jedem Sprint (ab Sprint 2) auch Systemtests durchgeführt werden, werden diese idealerweise automatisiert (Skripte erstellen ab Sprint 1).
• Der Systemtest wird im Prinzip der Legobausteine entwickelt. In jedem Sprint wird der Systemtest mit neuen Bausteinen erweitert (er wächst also mit).
• Die Ausführung des Systemtests findet im Folgesprint statt.
• Idealerweise entwickelt ein "Systemtest-Team" parallel zur Implementierung den Systemtest (vor allem die automatisierten Bestandteile)
• Der Anteil der automatisierten Tests sollte idealerweise 60% betragen. 30% wären ein Minimum.

Damit sieht die Vorgehensweise so aus:

Ansatz: Systemtest im agilen Entwicklungsprozess

Leider bestand nach dem Vortrag keine Gelegenheit mehr mit dem Referenten zu diskutieren. Deshalb ein paar Gedanken und Fragen an dieser Stelle:

• Prinzipiell erst mal ein guter Ansatz, der den Systemtest im agilen Projekt verankert. Und mit den Testaktivitäten sollte von Anfang begonnen werden.
• Stört ein separates "Systemtest-Team" nicht den Ansatz der agilen Projekte? Alle Teammitglieder sollten doch "voll integriert" sein. Sind die Systemtester dann nicht Störfaktoren im Daily Scrum?
  Ich meine schon. Der Systemtest sollte durch ein Mitglied des Scrum-Teams wahrgenommen werden.
• Warum schon zu Beginn der Entwicklung den hohen Aufwand der Automatisierung tragen? Die erstellten Bauteile unterliegen vermutlich noch vielen Änderungen. Deshalb müssen die bereits erstellten automatisierten Tests permanent angepasst werden. Wer will diesen Aufwand (Kosten) schon tragen?
  Testautomatisierung ja. Aber zu einem späteren Zeitpunkt, oder?
• Warum den Systemtest erst im Folgesprint duchführen? Es wird weiterentwickelt, auch wenn der Test große Probleme offenbaren würde. Die Entwicklung würde z. B. erst in Sprint 3 auf die Probleme aus Sprint 1 reagieren.
  Damit: am Ende des Sprints den Systemtest durchführen.