Klassische Test Governance
In gut geführten größeren Organisationen sind – meist innerhalb eines generellen Rahmens für IT-Prozesse – die Anforderungen an den Test von IT-Systemen in einem organisationsübergreifend gültigen Regelwerk festgelegt. Sinn und Zweck dieser Regeln ist es, eine zentrale Steuerung primär für Softwarequalität zu ermöglichen und sekundär die damit verbundenen Produkt- und Projektrisiken im Griff zu behalten. Motiviert wird dies einerseits intrinsisch durch die strategischen Ziele einer Organisation (Gewinnmaximierung, Reputation usw.), andererseits extrinsisch durch behördliche Vorgaben, die zum Schutz der Interaktionspartner der Organisation und im Falle von systemrelevanten Organisationen zur Vermeidung von negativen Effekten auf volkswirtschaftlicher Ebene aufgestellt werden.
Das einer Test Governance unterlegte Regelwerk adressiert typischerweise Dokumentation, Prozesse, Methoden und Tools. Beispielhaft für das Thema Dokumentation sei hier das Regelwerk in Anlehnung an die Test Governance eines großen international aufgestellten Unternehmens aus der Energie-Branche angeführt (Übersicht siehe Abbildung 1).
Abb. 1: Beispielhaftes Regelwerk für Testdokumentation
Im konkreten Beispiel ist festgelegt, dass eine unternehmensweite Test Policy oder ein Testhandbuch vorhanden sein muss, welches aus dem Qualitätshandbuch des Unternehmens abzuleiten ist. Für einzelne Sub-Domänen, Geschäftsbereiche oder Programme wiederum sind daraus Teststrategien, die jeweils deren Besonderheiten berücksichtigen, abzuleiten. Diese sind dann die Basis für Testkonzepte, die für Projekte, Produkte oder Services zu erstellen sind, welche wiederum gegebenenfalls in Stufentestkonzepte herunterzubrechen sind. Als wichtigste operative Dokumentationsbausteine sind hier Testpläne, Testfälle und Defects definiert. Für alle diese Dokumenttypen ist im Rahmen der Governance in Form von Guidelines und Checklists geregelt, welchen Mindestanforderungen an Form und Inhalt sie genügen müssen.
Eine Test Governance umfasst aber nicht nur einen Satz von Regeln, sondern auch ein Verfahren, mit dem die Einhaltung der Regeln forciert wird. Hierzu steht typischerweise ein Überwachungs- und Maßnahmenrahmen zur Verfügung, der zum einen durch Instrumente wie Regelberichte, Quality Gates, Audits usw. Transparenz zur Einhaltung der Regeln schafft. Zum anderen enthält dieser Rahmen Methoden zur Durchsetzung der Regelkonformität, die im Falle von Abweichungen zur Anwendung kommen, wie Sanktionen und Auflagen, aber auch Unterstützungsangebote, für den Fall, dass die Regelverstöße auf mangelndes Know-how zurückzuführen sind. Ein beispielhafter Überwachungsrahmen ist im Überblick in Abbildung 2 dargestellt.
Abb. 2: Beispiel für einen Überwachungsrahmen
Zur Durchsetzung des Regelwerks ist hier ein Prozess zur Begleitung des Produktlebenszyklus definiert. Er enthält Gateways, im Rahmen derer die Einhaltung der Regeln überprüft wird, und zwar durch Sichtung von Dokumentation und Interviews mit den Verantwortlichen. Diese Gateways sind an den entscheidenden Übergangsstellen im Produktlebenszyklus eingebaut, zum Beispiel gleich in der Phase der Projektinitiierung, nach der Erstellung des Testkonzepts, nach Abschluss der Testvorbereitungen, nach Abschluss der Testdurchführung und am Ende des Projekts mit den Lessons Learnt.
Clash mit Agilität und Continuous Delivery
Eine klassisch angelegte Test Governance, wie oben in Ansätzen beispielhaft angedeutet, ist in der Regel sehr langsam und steht somit im Konflikt mit Vorgehensweisen nach Prinzipien der Agilität und von DevOps. Ein Blick auf die agilen Werte zeigt dies sehr deutlich:
- Agilität setzt vornehmlich auf Individuen und Interaktionen. Eine klassische Governance hingegen ist so aufgebaut, dass sie primär Vorgehensweisen, Prozesse und Tools vorschreibt.
- Funktionierende Software stellt im agilen Umfeld ein wichtigeres Ziel dar als eine umfassende Dokumentation. Eine Governance wird jedoch immer darauf Wert legen, dass Konzepte und Tätigkeiten möglichst vollständig dokumentiert und damit überprüfbar sind.
- Ein gemeinsames Verständnis mit dem Partner zu erreichen, ist dem agilen Team wichtiger, als Dinge vertraglich festzulegen. In der Welt der Governance gibt es aber immer vertragliche Konstrukte, zum Beispiel in Form von Handshakes und Vereinbarungen, deren Einhaltung dann im Rahmen von Gateways oder Audits überprüft werden.
- Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans – der Kernwert im agilen Manifest. In der klassischen Governance-Umsetzung hingegen wird regelmäßig im Rahmen von Prüfungen ein Vergleich hergestellt zwischen dem, was man sich als Plan vorgenommen hat, und dem, was tatsächlich erreicht wurde.
In allen vier Fällen gibt es hier also einen grundsätzlichen Konflikt zwischen einem klassischen Kontrollinstrument und dem agilen Mindset, der regelmäßig zu Ineffizienzen und Motivationseinbußen führt. Der Konflikt gipfelt in der Unvereinbarkeit von schwergewichtigen Kontrollprozessen mit dem Paradigma der Minimierung von Time to Market, dem sich DevOps-Organisationen verschrieben haben und dem sie sich mit Continuous Delivery nähern. Letztendlich mündet er in lähmende Diskussionen und Auseinandersetzungen zwischen einem Product Ower, Projektleiter oder Applikationsverantwortlichen und den Angehörigen der Governance Organisation.
Lean Test Governance
Was tun in dieser Situation? Wie gestaltet eine IT-Organisation ihre Test Governance so, dass sie diesen Konflikt auflösen kann und dabei trotzdem noch grundsätzlich ihren Aufgaben gerecht wird? Es bieten sich drei Ansatzpunkte an:
- Verschlankung des Regel- und Kontrollapparates,
- Erweiterung des Unterstützungsapparates,
- Beschleunigung durch Automatisierung.
Verschlankung
Es gibt viele Möglichkeiten, das Regelwerk zur Test Governance leichtgewichtiger zu gestalten. Im Hinblick auf die Dokumentation sind zum Beispiel Erleichterungen bei den Formvorschriften beispielsweise als lebende Dokumente in Wiki-Form, die Bereitstellung von Konzept-Templates, die auf agile Anforderungen ausgelegt sind, und eventuell optional der vollständige Wegfall von Dokumenttypen denkbar (siehe Abbildung 3).
Abb. 3: Verschlanktes Regelwerk für Testdokumentation
Auch der Kontrollapparat lässt sich verschlanken, dadurch dass je nach erforderlicher Intensität Prüfpunkte und Gates zu einzelnen Schritten des Software Development Life Cycle vereinfacht werden oder vollständig entfallen können (Tayloring). Dafür werden unterschiedliche Intensitätsniveaus definiert, die dann auf Projekte mit unterschiedlicher Kritikalität angewandt werden (siehe Abbildung 4).
Abb. 4: Verschlankter Kontrollapparat in Abhängigkeit von der Kritikalität
Die Kritikalität lässt sich zum Beispiel festmachen am Projektvolumen, Produktrisiken, Anzahl von Schnittstellen zu anderen Produkten und Services, möglichen Workarounds und Rollbacks. Level 3 könnte beispielsweise ein Projekt mit einem Budget im hohen zweistelligen Millionenbereich sein, in dem an einer Software gearbeitet wird, die über mehr als 100 Schnittstellen in die Systemlandschaft eines Unternehmens verwoben ist und ohne die geschäftlichen Kernprozesse zum Stehen kommen (z. B. Montageband bei Automobilhersteller). Ein Beispiel für Level 0 wäre die Entwicklung einer Mobile App durch Praktikanten, die es diesen ermöglichen soll, ihre Stundenbuchungen und -abrechnungen außer über eine Web-Applikation auch über eine Mobile App vorzunehmen.
Je nach Kritikalität kann man dann auf Checks ganz verzichten oder es kann reichen, dass man nur am Anfang und am Ende eines Projekts einen Check durchgeführt, anstatt ihm eine intensive Begleitung über den gesamten Produktlebenszyklus angedeihen zu lassen.
Erweiterung
Die Erweiterung des Unterstützungsapparates verringert nicht nur die Widerstände, die eine Test Governance im Wertschöpfungsprozess verursacht, sondern erzeugt durch die Förderung der Motivation der Beteiligten ein zusätzliches Momentum zur Beschleunigung. Unterstützung besteht zum einen darin, dass eine zentrale Testmanagementeinheit neben der Wahrnehmung von klassischen Governance-Aufgaben Hilfsmittel bereitstellt und auch selbst in konkreten Situationen involviert wird. Beispiele hierfür sind:
- Bereitstellung von Dokumentations-Templates für Testkonzepte, Teststrategien, Testfallbeschreibungen, Defect-Beschreibungen usw.,
- Bereitstellung von Anleitungen zur Bedienung von Test-Tools, zum Design von Testprozessen, zur Verwendung von Vorlagen usw.,
- Bereitstellung von Tool-Lösungen und Frameworks für Testmanagement und Testautomatisierung,
- Coaching von Projektleitern, Testmanagern, Test-Teams in Testmethodik und insbesondere im Lean beziehungsweise Agile Testing,
- Beseitigung von Barrieren und Hemmschwellen durch initiales Aufsetzen von Tools, Durchführung von POCs, Design und Implementierung von Prozessen,
- operative Unterstützung bei Testaktivitäten durch Stellung von Testpersonal im Falle von Kapazitätsengpässen.
Unterstützung besteht zum anderen auch darin, die in den Delivery-Teams eingesetzten Mitarbeiter zu entwickeln, das heißt, ihre Fähigkeiten und Fertigkeiten mittel- bis langfristig zu vertiefen und zu verbreitern. Dies kann beispielsweise geschehen durch:
- Angebot von Trainings zu Test-Methoden und -Tools,
- Bereitstellung von Lern-Videos zu Prozessabläufen im Test,
- Bespielung und Aktivierung von Communities zum gegenseitigen Austausch von Erfahrungen im Testumfeld.
All diese zusätzlichen Unterstützungsmaßnahmen zahlen darauf ein, dass der im Sinne der Governance richtige Weg auch der für die Delivery-Verantwortlichen am einfachsten zu beschreitende Weg wird.
Automatisierung
Ohne Automatisierung von Tests – wie auch von allen anderen Deployment-Schritten – hat man im Continuous-Delivery-Umfeld mit kurzen Deployment- und Release-Zyklen keine Chance, weil keine Zeit für große manuelle Testaktivitäten bleibt.
Das Gleiche gilt für die Kontrollen, die im Überwachungsrahmen der Governance für das Testing vorgesehen sind, zum Beispiel zum Zustand von Testumgebung, Testdaten und Testfällen sowie der Testergebnisse und der Testabdeckung. Diese können nicht mehr manuell durchgeführt werden, wenn ein Change in wenigen Minuten durch die CD-Pipeline gejagt wird. Die zu überwachenden Parameter wie zum Beispiel Testausführungsstatus (auf Unit-/Integrations- und System-Ebene) und Ergebnisse der Code-Analyse (manuell und automatisch) müssen daher automatisch kontrolliert werden.
Dafür reicht es nicht, dass nach Durchführung der geforderten Aktionen durch die dafür eingesetzten Tools (Testautomatisierungsframeworks, Quellcode-Repository-Verwaltungen, Linting-Software) diese dort festgehalten und an ein CI-Tool gemeldet werden. Dieses kann dann zwar nach einem positiven Soll-/Ist-Abgleich den jeweiligen Schritt freigeben, wird aber die Ergebnisse der Prüfung in der Regel nicht revisionssicher persistieren. Hierfür haben sich in den vergangenen Jahren Automated Governance Frameworks etabliert (häufig basierend auf Open-SourceTools wie Grafeas oder Hygieia), welche die Meldungen von den Kontrollpunkten integritätsgeprüft übermittelt bekommen und diese mit Zeitstempel versehen als unveränderliche Datensätze in einer Audit-Datenbank abspeichern (siehe Abbildung 5).
Abb. 5: Revisionssichere Sammlung von Prüfergebnissen aus der CD-Pipeline in einer Audit-Datenbank
Conclusio
Auch im Zeitalter von extrem kurzen Release-Zyklen muss die Governance von Testprozessen nicht zu kurz kommen. Die Antwort auf automatisierte Prozesse muss auch eine automatisierte Governance sein. Die frei werdenden Governance-Kapazitäten können gut investiert werden in Konzeption und Weiterentwicklung von Regelwerk und Kontrollapparat sowie insbesondere in die Erweiterung des Unterstützungsapparates.
