Das
Testen von Software bzw. eines fertigen Teilprodukts (Product Increment) ist
ein fester Bestandteil der agilen Softwareentwicklung und somit auch ein
festes Element während eines Sprints.
Gerade
bei Testfällen, die sehr oft wiederholt werden, ist eine Automatisierung
sinnvoll (z.B. Regressionstests, testgetriebene Entwicklung oder schwer
durchführbaren Tests). Viel
zu oft wird gerade bei nicht automatisierten Tests die Anwendung nicht
ausgiebig genug getestet.
Folgende
Grundsätze sollten daher angewendet werden:
- So viel Testautomatisierung wie möglich, damit bei vielen neuen oder sich ändernde Anforderungen ein lauffähiges System gewährleistet wird. Darunter fallen Unit Tests, System- und Akzeptanztests.
- Die Rolle "Tester" innerhalb des Entwicklungsteam verteilen, damit die Zuständigkeit innerhalb des Entwicklerteams gleich ist. Keine strikte Trennung zwischen Entwickler und Tester aufbauen!
- Teststufen des V-Modells (Einordnung von Testzyklen) aufheben, da dies innerhalb eines Sprints nicht umsetzbar ist und einen zu hohen zeitlichen Aufwand bedeutet. Die einzelnen Teststufen (Komponententest, Integrationstest usw.) sollte als kleine Einheiten innerhalb der einzelne User-Stories integriert oder teilweise als einzelne User-Story je Sprint geplant werden
- Der finale Abnahmetest (User Acceptance Test) erfolgt jeweils am Ende eines Sprints durch den eigentlichen Auftraggeber oder Product Owner.
- Continuous Integration, der Prozess des fortlaufenden Zusammenfügens von Komponenten hin zu einer Anwendung, hat das Ziel zur Steigerung der Softwarequalität. Hier erfolgt ein Zusammenspiel von einem Versionsverwaltungssystem z.B. SVN oder GIT, einem Artifactory z.B. Nexus, automatisierter Tests (z.B. JUnit) und einem Tool (z.B. Jenkins ) zur Verwaltung der Continuous Integration (bauen von Pakten und deployen der Anwendung). Dieser Prozess wird z.B. automatisch durch Einchecken einer Codeänderung in das Versionsverwaltungssystem gestartet.
