Agiles Testen in der erkenntnisgetriebenen Softwareentwicklung

Um agil testen zu können, muss nicht nur klar sein, wie sich agile Prinzipien wie die „Erkenntnisgetriebene Softwareentwicklung“ auf Testaktivitäten im Entwicklungsprozess abbilden. Vielmehr müssen auch die Anforderungen an die Organisation der Qualitätssicherung (QS) verstanden sein.

Im Software Engineering bedeuten Tests alle dynamischen Verfahren der QS. Ein System bzw. dessen Teile werden also zur Ausführung gebracht, um konkrete Eingabewerte zu übergeben und das Systemverhalten bzw. das erzeugte Ergebnis zu bewerten. Weil große Systeme aus vielen Bestandteilen aufgebaut sind und viele Schnittstellen zu anderen Systemen haben, sind Tests eine komplexe Aufgabe. Deshalb wird Software nicht erst vollständig entwickelt und dann als Ganzes getestet. Stattdessen wird Software – auch in klassischen Ansätzen – in einzelnen Teststufen (Unit Tests, Integrationstests, Systemtests, Abnahmetestes) mit jeweils unterschiedlichen Testumgebungen getestet.

Die Unterschiede zwischen klassischem und agilem Testen werden besonders dann deutlich, wenn das agile Prinzip der erkenntnisgetriebenen Softwareentwicklung hinzugezogen wird. Das heißt, Entscheidungen des Teams sollen auf Basis von Erkenntnissen getroffen werden – nicht auf der Basis von Plänen. Frühe Erkenntnisse, die auch für ein agiles Testen wertvoll sind, werden durch kurze Feedback-Zyklen gewonnen (siehe Abbildung). Hierzu werden ab Projektstart im Gegensatz zu plangetrieben Ansätzen nur eine kleine Teilmenge der Anforderungen durch das Entwicklungsteam analysiert, spezifiziert, implementiert und getestet. Scrum-Teams können zum Beispiel direkt Testfälle aus den Anforderungen ableiten, um das geplante Teilergebnis (in Scrum „Inkrement“ genannt) zu testen. Die Abstraktionsebene der Testfälle orientiert sich dabei an der Abstraktionsebene der Anforderung: Grobe Anforderungen werden zum Beispiel eher mit Black-Box-Tests geprüft, während detailliert ausgearbeitete Anforderungen sogar durch einzelne Unit-Tests abgedeckt werden können. Weil agile Teams typischerweise interdisziplinär zusammengesetzt sind, können sie diese Bandbreite an Tests gut abdecken.

Die einzelnen Tests können schnell durchgeführt werden, weil nur der im aktuellen Sprint entwickelte Softwareteil zu testen ist (zzgl. Regressionstests, versteht sich). Somit kann das Team schnell zu neuen Erkenntnissen über die tatsächlichen (!) Anforderungen gelangen. Ebenso kann das Team, z. B. im Rahmen einer Sprint-Retrospektive, früh feststellen, dass der Prozess grundsätzlich angepasst werden muss und sich so auf volatile Rahmenbedingungen einstellen.

Frühe Erkenntnisse unverzüglich zu liefern ist also das zentrale Ziel des agilen Testens. Aus diesem Ziel ergeben sich dessen charakteristische Merkmale des agilen Testens, wonach …

• … so früh wie möglich und so oft wie nötig zu testen ist,
• … möglichst viele Schritte zu automatisieren sind (bis auf explorative Tests durch Experten),
• … sich auf das Testen der grundlegenden Funktionalität zu konzentrieren ist und andere Testarten nach tatsächlichem Bedarf auszuwählen sind („first make it run, then make it fast“),
• … interdisziplinär zu arbeiten bedeutet, also je nach Art des Tests, auch die Entwickler einzubeziehen.

Das Einrichten einer Werkzeuginfrastruktur alleine befähigt eine IT-Organisation also noch nicht dazu, agil zu testen. Für agiles Testen in allen Teststufen müssen vor allem auch organisatorische Vorbereitungen getroffen werden (was im Übrigen eine Umstellung auf Agilität im laufenden Projekt ausschließt):

• Verlagerung des Testaufwands (weniger manuelle, mehr – automatisierte – Unit-Tests)
• Verlagerung der Testaufgaben auf die Entwickler
• disziplinierte Arbeitsorganisation des Testers
• durchdachtes Testdatenmanagement
• Verzahnung von Entwicklung und Betrieb
• Integration des Anwenders bei den Tests