Continuous Testing

Oft wird im Zusammenhang mit Scrum von ein automatisiertem Testing gesprochen. Abgeleitet ist der Ansatz vom eXtreme Programming - Test Driven Development (TDD).
Während TDD die Strategie verfolgt, dass man einen Test "schreibt" bevor man die Entwicklung beginnt geht automatisiertes Testing noch einen Schritt weiter- man automatisiert die Tests auf täglicher Basis, ähnlich einem nigthly build.

Wie kommt man zu den Tests und was wird getestet?
Entgegen einem Modul-Test mit JUnit werden beim Testing in Verbindung mit Scrum die Akzetpanz getestet. Voraussetzung ist eine User Story. An der User Story werden Notes und Contraints vermerkt. Daraus lassen sich Akzeptanztests ableiten.
Beispiel-User Story:
Man kann mit Kreditkarte bezahlen
Note: MasterCard, Visa
Contraint: Betrag > 0, Karte nicht abgelaufen oder gesperrt

Daraus ergeben sich folgende Tests, die vor der Implementierung "geschrieben" werden.
Kartezahlung mit MasterCard und Visa.
Kartenzahlung mit Betrag <>
Kartenzahlung mit abgelaufener Karte.
Kartenzahlung mit gesperrter Karte.

Die Definition von "geschrieben" wird vom Team bestimmt. Oft ist es so, dass man dabei lediglich von einer Notiz in Papierform ausgeht, nicht von JUnit Test Implementierungen. Die Idee ist, dass man zusammen mit dem Product Owner die Aufgabe hinterfragt und somit die Abnahmekriterien definiert. Man spricht dann von User Acceptance Tests, wobei unter User in diesem Zusammenhang der Product Owner verstanden wird.
Ziel ist es, dass jeder im Team versteht, was der Kunde möchte.

Diese Tests werden dann nach der Realisieriung mit einem FIT (Framework for Integrated Tests) Tool aufgezeichnet und automatisiert.

Warum soll man automatisiert Testen?
Durch die interative Arbeitsweise hat der Kunde stets die Möglichkeit seine Prioritäten zu verlagern bzw. neue Wünsche ins Produkt aufzunehmen. Das Team in einem Sprint-Arbeitstakt an den Wünschen des Kunden. Damit kann von Sprint zu Sprint die Code-Basis bis zu 50% ändern, da man Synergien nutzen kann, die es vorher nicht gabt oder Vereinfachungen und Widerverwendung zum Tragen kommen.
Oft ist wird eine User Story erst nach mehreren Sprints vollständig abgeschlossen. Mit Akzeptanztests kann sichergestellt werden, dass alle bisher entwickelten Funktionen noch immer den Wünschen des Kunden entsprechen.

Wann sollte man Testen?
Gemäss der "Done" Definition sollen alle Funktionen lauffähig sein. Dazu gehört aber auch, dass alle bereits vorgeführten Funktionen auch noch laufen. Demnach kann man eine User Story erst als Done markieren, wenn alle Tests erfolgreich waren, d.h. vor dem Check-In müssen alle Akzeptanztest erfolgreich sein.

Wieviel sollte man Testen?
Es ist unmöglich, 100% zu testen. Im Vordergrund stehen die Tests, deren Akzeptanz vom Kunden erforderlich ist. Wenn man 60% des gesamten Produkts mit Akzeptanztest testen kann, hat man schon sehr viel erreicht!