Mit agiler Software-Entwicklung werden die Wünsche des Kunden fortlaufend adressiert. Statt ihm am Ende eines Software-Projekts ein fixfertiges, aber nicht zufriedenstellendes Resultat vorzusetzen, liefert die IT ständig neue Software aus. Ändern sich die Anforderungen des Kunden, können Entwickler schnell darauf reagieren und in kürzester Zeit Anpassungen am Produkt vornehmen.
Damit die Software auch gleich produktiv genutzt werden kann, muss sie kontinuierlich getestet werden – und zwar schnell. Ansonsten verliert agile Software-Entwicklung ihre Wirkung. Manuelle Regressionstests sind dafür zu langsam: «Wer in kurzen Zyklen immer wieder neue Software liefern will, kann in vielen Bereichen nicht mehr auf manuelle Verfahren setzen. Das gilt auch für das Testing», erklärt Urs Enzler, Fachleiter Agile und Architektur bei bbv. Deshalb verlangt agile Software-Entwicklung zwingend nach agilen und möglichst vollautomatisierten Tests, die ein schnelleres Ausliefern ermöglichen.
Die IT muss sich bereits von Projektbeginn an darüber im Klaren sein, welche Testmöglichkeiten überhaupt zur Verfügung stehen: «Man erstellt eine Auslegeordnung aller möglichen Tests», erklärt Enzler. Das können Unit-, Acceptance- oder Performance-Tests sein, die für die Software in Frage kommen. Danach wird situativ entschieden, in welchem Umfang die einzelnen Tests überhaupt durchgeführt werden müssen. Idealerweise werden Software und die dazugehörigen automatisierten Tests parallel entwickelt. Tests und Testskripte lassen sich zwar von Hand schreiben, es gibt aber auch gute Frameworks und Tools, die für die Testerstellung eingesetzt werden können. In jedem Fall sind automatisierte Tests mit einem gewissen Initialaufwand verbunden; die Zeitersparnisse, die in der Praxis erreicht werden, machen das aber allemal wett.
Wissensaustausch anstatt Silo-Denken
Schlanke Prozesse sind besonders wichtig, um Agilität und «Continuous Delivery» so gut wie möglich umzusetzen. Das erfordert viel Kommunikation und Zusammenarbeit zwischen Entwicklung und Qualitätssicherung. Der Tester muss genau wissen, welche Tests die Entwicklung bereits durchgeführt hat. Ansonsten kommt es entweder zur Testüberlappung, was mit zusätzlichem Wartungs- und Entwicklungsaufwand verbunden wäre. Oder es entstehen Testlücken, wodurch sich Bugs einschleichen können, die unentdeckt bleiben.
Das «Silo-Denken» ist dabei ein typischer Stolperstein: «Man denkt immer noch in den Kategorien ‘Entwickler’ und ‘Qualitätssicherung’», erklärt Enzler. «Der Entwickler ist der Meinung, er müsse nicht testen, der Tester hingegen glaubt, er mache nichts anderes. Beim agilen Testen darf man aber erwarten, dass ein Entwickler auch viel übers Testing weiss und umgekehrt.» Analog zum Pair-Programming, wo zwei Entwickler am gleichen Rechner arbeiten, können auch Tester und Entwickler gemeinsam Tests schreiben. Das minimiert nicht nur das Risiko redundanter Tests. Der Entwickler kann auch gleich Programmieränderungen vorschlagen, durch die sich ein Test einfacher durchführen lässt.
Ausserdem führt diese Arbeitsweise zum erforderlichen Wissensaustausch: «Der Entwickler lernt, wie Tests funktionieren und ist im besten Fall nach einer gewissen Zeit selbst in der Lage, Tests zu schreiben», erklärt Enzler. «Im Gegenzug versteht ein Tester zunehmend, wie Software gebaut ist und wie er mit seinen Tests besser unterstützen kann. Dieser Austausch ist für agiles Testen und letztlich für agile Software-Entwicklung elementar.»
Der Experte
Urs Enzler
Urs Enzler ist als Expert Software-Architekt .NET bei bbv tätig. Als agil gesinnter Softwareentwickler spricht er an Konferenzen und Communityanlässen gerne über architektonische Herausforderungen und über das Lernen im Team. Enzler ist Co-Gründer der .NET Usergroup Zentralschweiz.