Zu Beginn stellen wir folgende These auf: Moderne Softwareentwicklung kann es sich nicht leisten, den Fokus nur auf die umgesetzten Features zu legen und dann noch ein bisschen Qualität "reinzutesten". Intuitiv ist das klar. Und dennoch erleben wir, dass es im Alltag noch genügend Beispiele für diesen Ansatz gibt: Die Anforderungen sind noch nicht klar? Fangt doch trotzdem schon mal an. Die Schnittstellen zwischen den Komponenten sind noch nicht spezifiziert? Wir können doch trotzdem bereits mit der Integration anfangen, schließlich kennen wir unser Produkt doch. Oder steht die Projektleitung unter Druck, da die Software ausgeliefert oder wenigstens dem Kunden gezeigt werden muss? Dann muss auch irgendwie getestet werden. Das klingt sehr nach deadlinegetriebenem Arbeiten.
Qualitätssicherung muss umfassender gelebt werden. Denn all die genannten Beispiele sind von der Theorie her schon aus dem berühmten V-Modell klar: Ohne klare Anforderungen ist das Design der Architektur auf Sand gebaut, ohne klare Architektur ist die Implementierung schwierig und ohne die entsprechend beschriebenen Schnittstellen ist keine schrittweise Integration möglich. Letztendlich fehlt ohne klare Anforderungen auch die Basis für den funktionalen Test. Was sind die Gründe, diese Grundlagen zu ignorieren? Oft hören wir, dass die Anforderungen noch nicht final feststehen, dass der Kunde noch etwas liefern muss und dass sich dieser Aspekt blockierend auf alle Folgeaktivitäten auswirkt.
Anders als früher jedoch muss das gar nicht alles vollumfänglich zu Beginn feststehen. Agiles Arbeiten zum Beispiel per Plan-Do-Check-Act können auch bei Anforderungen und Architektur kurze Iterationen ermöglichen, ohne Folgeaktivitäten zu blockieren – wenn der Qualitätsblick ständig mit dabei ist. Von Anfang an! Denn dann können wir auf spontane Änderungswünsche von Kunden reagieren, mal schnell eine Demo zusammenbauen und auch die Testautomatisierung feinjustieren.
Wenn die Entwicklung also in mehrere Inkremente heruntergebrochen wird, dann können für jeden auch die entsprechenden Testaktivitäten sinnvoll angewendet werden. Für eine ganzheitliche Qualitätssicherung ist beides notwendig: der Qualitätsgedanke in jedem Arbeitsschritt und speziell für das Testen der Fokus auf Automatisierung im hohen Maß. Im agilen Kontext wird entsprechend davon gesprochen, dass das ganze Team für Qualität verantwortlich ist: durch Anforderungsreviews, statische Analyse, Code-Reviews, Teststufen, CI/CD, Testautomatisierung, explorative Tests und vieles mehr je nach Arbeitspaket. Wir testen dann auch nicht mehr nur kurz vor dem Ende, sondern fortlaufend und effizient die sinnvollen Inkremente.
In dieser Ausgabe legen wir den Fokus daher auf die Qualität in der gesamten Softwareentwicklung als Voraussetzung und die Automatisierung der Tests als Enabler für agiles Arbeiten. Wir wünschen Ihnen viel Freude beim Lesen und die ausgewählten Artikel als Inspiration und Ideengeber für Ihre Projekte. Dann wird vermutlich auch leichter klar, ob noch getestet oder Qualität gesichert werden muss.
Viel Freude beim Lesen. Lassen Sie sich inspirieren.
Ihre Dr. Stephan Weißleder und Richard Seidl (Chefredaktion)
