Agilität à la Quality Master

Testautomatisierung in agilen Entwicklungsprojekten

In der agilen Softwareentwicklung organisieren sich die Teams selbständig. Jeder plant, implementiert und testet in eigener Verantwortung. In kurzen Zyklen entstehen neue Produktzwischenstände, die regelmässig und ad hoc getestet werden müssen. Das ständige Refactoring hat zur Folge, dass neben den Unit-Tests unbedingt auf die System- und Integrationstests geachtet wird, um die Wechselwirkung mit anderen Komponenten zu prüfen. Der RapidRep Quality Master unterstützt neben dem konventionellen Vorgehen gemäß V-Modell auch die aus agiler Sicht weniger formelle ad hoc Arbeitsweise.

Die RapidRep Test Suite unterstützt die Automatisierung von Testfällen im Quality Master sowohl über die interaktive Test Runner GUI als auch im Stapelbetrieb. Auch andere Produkte, die die RapidRep Quality Master API unterstützen, können verwendet werden. Das Erstellen von Auswertungen und Managementreports ist eine Aufgabe, für die die Reporting Suite bestens geeignet ist.

Unter agilem Testen versteht man das Testen von Software in einem agilen Entwicklungsprojekt. Die Auswirkungen auf die Arbeitsweise eines Testers und Testmanagers sind weitreichend. Die agile Softwareentwicklung, wir beziehen uns in diesem Beitrag nur auf das Projektmanagementframework Scrum als populärsten Vertreter, lässt den Teams deutlich mehr Freiheiten und fordert im Gegenzug, dass sich die Teams selbst und eigenverantwortlich organisieren. Damit das gelingt, enthält das Scrum-Framework sinnvolle Vorgaben, denn auch ein agiles Team benötigt Spielregeln.

Dem Kunden kann es letztlich egal sein, ob sein Produkt nach V-Modell oder agil entwickelt wird. Die Anforderungen an die Qualität der Software sind davon unberührt. Agile Vorgehensweisen wirken sich stark auf die Umsetzung der Qualitätssicherung und das Qualitätsmanagement (siehe dazu Normen gemäß ISO 9000 ff.) insgesamt aus. Die Qualitätssicherung, und damit der Test von Software, verliert die Unabhängigkeit, denn der Test wird zu einer interdisziplinären Aufgabe im Team. Jeder Entwickler ist gleichzeitig für die Qualität seiner Artefakte verantwortlich.

Die Softwareentwicklung in Scrum liefert in regelmäßigen Abständen (z.B. monatlich) ein Produktrelease, dessen Funktionsumfang mit jedem sog. Sprint zunimmt. Es ist typisch, dass durch das ständige Refactoring bereits existierende Komponenten häufig geändert werden und laufend neue Komponenten hinzukommen. Schnelles Feedback im Test ist daher essentiell. Werkzeuge für den automatisierten Test sind deshalb sehr wichtig.

Im Gegensatz zum konventionellen Testvorgehen müssen die Tests in jedem Sprint nachweisen, dass

• die einzelnen Komponenten funktionieren (Unit-Tests)
• die Wechselwirkung mit anderen Komponenten reibungslos klappt (Integrationstests)
• und das System, wenn es als Ganzes in eine Testumgebung deployed wird, den bisher umgesetzten Anforderungen entspricht (Systemtests).

Agile Testprojekte setzen für den Komponenten- und Integrationstest fast immer Testtools zur Automatisierung ein, die auf xUnit basieren (z.B. JUnit für Java, Nunit für .NET). Die Notwendigkeit, Defekte anzulegen tritt in Scrum stark in den Hintergrund, denn die Fehler sind beliebig reproduzierbar und werden durch den ständigen Austausch im Team schnell kommuniziert und behoben. Fehler, die nicht automatisiert feststellbar sind oder im aktuellen Sprint nicht zu beheben sind, sollten gemäß IEEE 829 dokumentiert werden.

Der Nutzen der Testautomatisierung kann deutlich gesteigert werden, wenn sich das Team die Denkweise der testgetriebenen Anwendungsentwicklung (test-driven development/test-first programming) aneignet. Hierbei wird erst Code geschrieben, um die neue Funktion zu testen. Erst danach wird die eigentliche Programmerweiterung umgesetzt.

Die Automatisierung von Systemtests ist deutlich komplexer und aufwendiger. Das liegt daran, dass das Programm nicht unter Laborbedingungen untersucht wird, sondern in einer komplexen Testumgebung, die dem Produktivsystem sehr nahe kommt, getestet werden muss. Das Endprodukt muss am Ende z.B. mit den Eingaben aus einer graphischen Benutzeroberfläche zurechtkommen, benötigt die Anbindung an ein Datawarehouse oder kommuniziert mit einer Middleware.