Kennen Sie die Situation, wenn lange auf einen Software-Release hingearbeitet wird und alles (scheinbar) nach Plan läuft, bis wenige Tage vor dem Release-Termin ein richtig „dicker“ Fehler entdeckt wird? In der ausbrechenden operativen Hektik steht dann häufig die Frage im Vordergrund, wie man das Ergebnis noch retten kann – die viel wichtigere Frage ist jedoch, warum das Problem bis zu diesem Zeitpunkt unentdeckt blieb.
Mit dieser Frage beschäftigt sich „Continuous Quality Management“. Es steht für die kontinuierliche Überwachung und Verbesserung der Qualität über den gesamten Softwarelebenszyklus moderner Softwareentwicklung mittels möglichst viel Automatisierung.
Quality Gates für Application Lifecycle
Ein Grundsatz beim Softwaretesten lautet: „Frühes Testen spart Zeit und Geld“. Die Qualitätssicherung muss also schon in frühen Phasen der Softwareentwicklung beginnen. Gute Anforderungen sind der Schlüssel zum besseren Verständnis im Team, nicht nur zum guten Software-Design sondern auch für eine fundierte Projektplanung. Im agilen Kontext wird das Upfront-Design als fortlaufende Aktivität in die Iterationen verteilt. Definition-of-Ready-Kriterien stellen sicher, dass die User Storys vom Team verstanden werden und diese umsetzbar, schätzbar und testbar sind. Product Owner sorgen dafür, dass die Backlog Items nach und nach den „Ready“-Status erreichen und dabei die inhaltliche Auseinandersetzung des Teams die möglichen Lücken oder Missverständnisse in den Anforderungen frühzeitig aufdeckt, bevor diese sich in weiteren Aktivitäten fortpflanzen.
In der Softwareentwicklung sagt man: „Die Wahrheit steckt im Code“. Und dieser entsteht durch einen höchst komplexen Prozess. Im agilen Kontext sind es kurze Iterationen, in denen die Planung, Umsetzung, Test und Integration stattfindet, was zur Folge hat, dass jeder dieser Schritte sehr schnell und möglichst automatisiert ablaufen muss. Manuelle Tests werden in Nachfolge-Inkrementen zu automatisierten Tests überführt. Eine klassische Rollenteilung zwischen „Entwickler“ und „Tester“ ist hier weder möglich noch sinnvoll – vielmehr muss jedes Teammitglied Verantwortung für die eigenen Module und die Qualität des gemeinsamen Ergebnisses übernehmen. Selbstgesetzte Definition-of-Done- Kriterien helfen, das gemeinsame Qualitätsverständnis zu dokumentieren und schaffen einen objektiven Maßstab für das Erreichen dieser Qualität.
Der neue Trend in der Softwareentwicklung ist das Zusammenrücken der Entwicklungs-Teams (Dev) und der Betrieb-Teams (Ops), um schneller auf die Ereignisse aus dem Betrieb zu reagieren. Da merkt man: „Qualitätssicherung geht über die Entwicklung hinaus“. Die Betriebsmechanismen wie Skalierung, Ausfallsicherheit und Recovery müssen genauso wie die Fachlichkeit vor dem Go-Live getestet und mittels geeigneter Monitoring-Verfahren abgesichert werden.
Automatismen, wo immer möglich
Die schnelllebige agile Welt der Softwareentwicklung zeigt uns immer wieder: Während die Entwicklungszyklen kürzer werden, steigen die Qualitätsanforderungen. Die Quality Gates in verschiedenen Tätigkeiten lassen sich allein mit manuellen Mitteln nicht mehr bewältigen. Hierzu haben sich Werkzeuge für DevOps und Continuous Integration (z.B. git, Jenkins, TeamCity) als sehr nützlich erwiesen, insbesondere bei der Automatisierung von Code-Integration und Paketierung. Dabei werden auch Entwicklertests und Code-Qualitäts-Messungen automatisiert durchgeführt. Eine Herausforderung hierbei ist die gezielte Definition von Anforderungen an die Testabdeckung und die Code-Qualität. Alleine der Einsatz von Standard-Regeln (z.B. spezifiziert durch SonarQube) oder die Anvisierung von 80% Testabdeckung (wie in der Literatur oft empfohlen) reichen noch nicht aus, um den erwünschten Qualitäts-Effekt im eigenen Umfeld zu erzielen. Hier bietet sich an, individuelle Team- und Produkt-spezifische Quality Gates zu definieren und diese nach und nach zu schärfen.
Die neuartigen Technologien zur Virtualisierung, Docker, OpenShift und Co. ermöglichen, Software auf unterschiedlichen Umgebungen flexibel zu verteilen und diese zu verwalten. Neben dem Deployment profitiert auch die Testautomatisierung von der Virtualisierung, indem funktionale und nicht-funktionale Tests auf mehreren Servern gleichzeitig durchgeführt werden können. Cross-Plattform-Tests sowie Last- und Performance-Tests werden dadurch mit wenig Aufwand skalierbar. Darüber hinaus können die vor- und nachbereitenden Testaktivitäten (z.B. Bereitstellung von Testdaten und Testkonfigurationen, Persistieren und Archivierung von Testergebnissen) von „Test-Infrastructure-as-Code“ profitieren. Somit bringen die in hohem Maße automatisierten Prozesse einen echten Mehrwert bei der frühzeitigen Identifikation und Vermeidung von Qualitätsproblemen. Der optimale Einsatz der Automatisierung erfordert eine konzeptionelle, architektonische und methodische Auseinandersetzung mit den vielfältigen Themen der kontinuierlichen Softwareentwicklung und die bedarfsgerechte Anpassung der bekannten Technologien an die eigenen Prozesse. Sonst droht ein Ergebnis, wie Mark Fewster es in den 90’er Jahren formuliert hat: „Automatisierung von Chaos ergibt nur schnelleren Chaos“.
Ansprechpartner: Dr. Baris Güldali
