Seite 2: Testen, testen, testen und immer an die Nutzer denken

Inhaltsverzeichnis

Die Softwareentwicklung – in der IT und anderen Branchen – muss ihre Bereitstellungsprozesse optimieren und ein strukturiertes Deployment etablieren. Dabei geht es nicht um vollständige Fehlerfreiheit, die sich ohnehin nicht erreichen lässt. Die Frage vom Anfang muss umformuliert lauten: Wie sieht ein pragmatischer und sinnvoller Standard für die Releasequalität aus, der Nutzern ein möglichst optimales und fehlerfreies Produkt gibt?

Die Antwort lautet: Er muss eine datenbasierte Entscheidung erlauben. Die wiederum setzt eine greifbare Kennzahl voraus, die das Qualitätsniveau angibt und die Entscheidung erleichtert – vergleichbar mit einem KPI (Key Performance Indicator). Er ist eine Möglichkeit, das Risiko von verfrühten Releases zu senken und verschafft dem Management einen besseren Einblick in den aktuellen Status eines Entwicklungsprojektes.

Das Software-Engineering kennt eine Vielzahl an unterschiedlichen Möglichkeiten, Software zu messen und zu bewerten. Ein einfacher Kennwert ist die Vollständigkeit, also die Übereinstimmung mit den definierten Anforderungen. Ein weiterer, gut messbarer Wert ist die Performance, also die Reaktionszeit der Software. Eng damit zusammen hängt auch die Effizienz eines Systems, gemessen als Umfang der belegten Systemressourcen. Weitere wichtige Kriterien für die Softwarequalität sind Verfügbarkeit, Wartbarkeit oder Portabilität.

Normalerweise prüfen Entwicklungsteams diese Kennzahlen anhand von Softwaretests. Das sind meist Standardtests, etwa Unit-Tests für alle Komponenten, Smoke-Tests für grundlegende Funktionen und Tests auf Systemebene, um Überlauffehler und andere Probleme aufzudecken. Schließlich geht das Release in die Qualitätssicherung, wo ein Mix aus manuellen und automatisierten Tests folgt.

Wenn an diesem Punkt keine Probleme festgestellt werden, ist die Software in den meisten Unternehmen bereit für das Deployment. Doch es ist sinnvoll, noch weitere und härtere Tests umzusetzen. So ist es beispielsweise nützlich, die Regressionstests bei jeder Änderung am Quellcode durch weitere spezifische Tests zu ergänzen. Sie müssen speziell auf den jeweiligen Code-Change zugeschnitten sein. Anschließend folgen dann explorative Tests, die über die Begrenzungen der geänderten Funktion hinausgehen. Sie suchen unter anderem nach unerwarteten Seiteneffekten in anderen Bereichen der Software oder der üblicherweise benutzten Systemumgebung.

Trotzdem bleibt die Freigabe des Release eine Sache der konkreten Entscheidung. Denn der einzige Weg, Fehler gänzlich zu vermeiden, ist, kein Release bereitzustellen. Deshalb muss es in jedem Entwicklungsprojekt Verantwortliche geben, die eine Entscheidung treffen. Ihnen wird im Rahmen eines formalen Bereitstellungsprozesses durch Kennziffern eine Möglichkeit gegeben, frei von subjektiven Einflüssen sachliche Entscheidungen zu fällen.

Drei Konzepte für Deployment-Prozesse

Strukturiertes Deployment sollte die drei folgenden Konzepte verwirklichen:

1. Quality Gates: Ein Release wird nur dann freigegeben, wenn es definierten Qualitätskriterien entspricht. Welche das sind, ist abhängig von Auftraggeber, Anwendungsbereich der Software und eingesetzten Technologien. Es gibt aber ein pragmatisches Kriterium, das sich in jeder Situation einsetzen lässt: Ist der aktuelle Build mindestens so gut wie der vorherige? Wenn es hier zu Diskussionen kommt, muss das Release zurück in die Entwicklung.
2. Zeitrahmen: Die Testphase zur Qualitätssicherung sollte regelmäßig und in einer bestimmten Zeitspanne durchlaufen werden. Dabei sollten so viele Fehler wie möglich beseitigt werden, was auf einen maximalen Testumfang hinausläuft. Trotzdem werden viele Funktionen nicht in jedem Release getestet. Betroffen sind oft spezielle Themen, wie etwa die Barrierefreiheit für Nutzer mit Einschränkungen. Diese Dinge sollten getestet werden, wenn noch Zeit bleibt. Sie sind vor allem bei der Gefahr von Regressionen wichtig.
3. Entscheidungspunkte schließen eine Testphase ab. Im Anschluss daran gibt es ein "Triage-Meeting" von Produktverantwortlichen, Entwicklern und Testern. Sie entscheiden, welche Probleme eine hohe und welche eine niedrige Priorität haben. Die Ergebnisse eines Regressionstests und die in neuen Funktionen entdeckten Fehler haben eine hohe Priorität, zufällig entdeckte Fehler eine niedrige. Ziel einer Testphase sollte sein, alle Fehler hoher und möglichst viele Fehler niedriger Priorität zu beheben. Ansonsten landet zu viel im Backlog und das Projekt baut immer mehr technische Schulden auf. Die Teilnehmer des Triage-Meetings müssen also entscheiden, ob sie das Risiko der Freigabe verantworten können. Andernfalls geht das Release zurück in die Entwicklung.

Ein solcher Prozess ist zeit- und ressourcenintensiv. Er benötigt Daten von verschiedenen Teams oder Abteilungen im Unternehmen, die – erst aufwendig zusammengesetzt – ein Gesamtbild liefern. Dabei fließen Fehlerberichte aus den Funktionstests mit Errorcodes und Informationen des Bugtrackers zusammen. Sie sollten in jedem Unternehmen an zentraler Stelle auflaufen, sodass Entscheider einen Überblick über die Qualität des gesamten Builds erhalten. Sofern noch nicht geschehen, sollten Entwicklungsabteilungen eine solche Rolle (oder ein Gremium) schaffen, um die Freigabe des Release auf eine objektivere Basis zu stellen.