In den letzten Jahren ist ein "agiler" Sturm über die Welt der Softwareentwicklung hinweggefegt. Viele Entwicklungsabteilungen ließen sich von dem Versprechen deragilen Modelle locken. Schneller und effizienter, lautete das Motto. Dokumentations- und Spezifikationspflichten galten als unnötig, waren ungeliebt und damit verzichtbar.
Doch wie verträgt sich die neue Form der Entwicklung mit dem Bedürfnis der Unternehmen nach Funktionssicherheit? Lässt sich ein bislang meist sequentiell stattfindendes Testen in die Software-Entwicklung integrieren?
Nehmen wir zum Beispiel das omnipräsente Scrumund die XP-Methode (eXtreme Programming), die heute vor allem die agile Welt prägen. Scrum definiert eine agile Softwareentwicklungsmethode und verbindet Rollen, Prozessdefinitionen und Prozeduren mit Aktivitäten wie dem "Planungspoker". Erforderlich ist ein eindeutiges Commitment der Interessenvertreter und des Scrum-Teams.
Hinzu kommen ein gutes Design bei Applikation sowie Architektur, definierte Rollen und Anforderungen aus einem Product Backlog. Last bot not least, basiert die SCRUM-Methode auf Teamarbeit (möglichst in einem Raum), lebt von ständiger Kommunikation, schreibt automatisierte Tests vor (soweit möglich) und organisiert sich in täglichen Meetings und schnellen Entwicklungszyklen, den sogenannten Sprints.
Ähnlich sieht es bei XP aus, mit etwas mehr Detaillierung an der ein oder anderen Stelle und einem 4-Augen-Prinzip. Codes und Testfälle werden parallel entwickelt und ein am Tage erstellter Code gilt als fertig, wenn am Nachmittag die parallel erstellten Tests erfolgreich durchgeführt werden können.
Beide Modelle sind – regelgerechte und saubere Durchführung vorausgesetzt – anwendbar, um ein Software-Produkt zu erzeugen. Funktionale Tests sind dadurch jedoch nicht überflüssig geworden. Sie brauchen aber einen anderen Ansatz.
Vom Testingenieur zum Testanalyst
Wenn man der "Agile Alliance" Glauben schenkt, wandelt sich der heutige Testingenieur in der agilen Welt zum Testanalyst mit erweiterten Aufgaben und Pflichten. Was bleibt, ist also die Pflicht:
Qualitätssicherung der Projektdokumente
Analyse und Review der Anforderungsdefinitionen
Testdesign für Unit und Modultests sowie Systemtest und Akzeptanztest
Dokumentation des Testprozesses und Durchführung der Tests
Monitoring der wöchentlichen Builds und automatisierten Tests
Speicherung und Archivierung der Testware.
Was neu hinzukommt, ist die Kür. Der Testanalyst muss höheren Anforderungen genügen als der bisherige Testingenieur. Er braucht methodische Kompetenz, Wissen über Qualitätssicherung, Erfahrung in der Softwareentwicklung und gutes technisches Verständnis der Architektur des geplanten Produkts. All dies sollte bei ihm zudem noch fundierter sein als bei dem klassischen Testingenieur. Der gerne verfolgte Ansatz des "einfachen und billigen Testers" kann hier also nicht mehr angewendet werden.
Neben seinem individuellen Know-how und den persönlichen Fähigkeiten gilt es aber, Standardtestmethoden wie TMap Next und TPI in der agilen Welt einzusetzen. Sie können ohne Zweifel dem Testanalyst helfen, seine erweiterten Aufgaben in der erforderlichen Art und Weise zu erfüllen. Denn es ist egal, ob man sich in einem traditionellen Wasserfallmodell oder in einem agilen Projekt befindet. Der Testprozess ist nahezu identisch.
Wesentliche Unterschiede sind die Zeit, die zur Verfügung steht, um eine Aufgabe zu erfüllen. Denn in einem agilen Projekt hat man zwei Stunden für die Erstellung logischer Testfälle, keine vier Tage.
Weiter bestehen Spezifikationen in der agilen Welt oft aus Use Cases, Klassenmodellen und Zustandsdiagrammen, also eher visuellen Beschreibungen des zu entwickelnden Produktes, was sich von den klassischen Anforderungsbeschreibungen unterscheidet, die in IEEE oder ISO/IEC verwendet werden. Daher benötigt der Testanalyst Wissen zur Softwareentwicklung, den Beschreibungssprachen und verwendeten Tools.
Gut ausgebildete Testspezialisten benötigt
Offensichtlich benötigt der agile Ansatz also gut ausgebildete Testspezialisten. Sie müssen in der agilen Welt der "crossfunctional teams" in der Lage sein, alle nötigen Aufgaben für hochwertige Softwareprodukte erfüllen. Die einzelnen Schritte vom ersten Programmcode bis zur vollständigen, funktionierenden Integration einer Software in den Unternehmensalltag sind immer weniger voneinander trennbar. Ein Testanalyst muss also ebenso kompetent in agilen Methoden und Design sein, wie in seinem angestammten Testumfeld.
Anhand der zu erkennenden Erweiterung der Rollen in der Qualitätssicherung wird somit schnell klar, dass funktionale Tests und Tester auch in agilen Methoden nicht überflüssig werden, ja sogar erforderlich sind. Und es ist beruhigend, dass der Einsatz von Methoden möglich und sinnvoll ist, die auch in der "klassischen Welt" erprobt sind. Gemeinsam mit agilen Methoden sichern sie die notwendige Qualität. Um die Methoden aber effizient zu nutzen, benötigt man gut ausgebildete und erfahrene Testexperten.
Klaus Kilvinger ist Mitglied der Geschäftsleitung von Sogeti in Deutschland.
Arbeitet Ihre IT-Abteilung schon mit der Software-Entwicklungsmethode Srcum? Beteiligen Sie sich doch an unserer CIO-Umfrage.