Es stellt sich aber immer auch die Frage, wie die Qualität nicht nur eingebaut, sondern auch in so schnellen Zyklen überprüft werden kann. Das Quality Management muss also ebenfalls Lean daherkommen, damit es den Anforderungen von kurzen Durchlaufzeiten in modernen Softwareentwicklungsprozessen genügt.
In unseren Projekten haben wir im Wesentlichen drei Stoßrichtungen identifiziert, deren Bearbeitung zu einer erfolgreichen Umsetzung eines Lean Quality Management führen kann:
- Fokussierung: Das Quality Management muss sich auf die wichtigen Dinge fokussieren und von der Vollständigkeitsdenke wegkommen.
- Automatisierung: Automatisierung muss weiter vorangetrieben werden. Das wissen alle, aber nur wenige machen das auch konsequent.
- Expansion: Quality Management darf sich nicht nur auf das klassische Überprüfen der Umsetzung von Anforderungen durch Testing beschränken, sondern muss näher an den Nutzer des Produkts heranrücken.
Im Folgenden werden die Potenziale dieser drei Stoßrichtungen jeweils anhand eines konkreten Beispiels aufgezeigt.
Fokussierung
In vielen Beratungssituationen findet man eine völlig überdimensionierte Suite an Testfällen vor, deren Abarbeitung sich in keiner Weise mit dem Ziel kurzer Release-Zyklen vereinbaren lässt. Dadurch bleibt es in vielen Fällen bei halbjährlichen oder quartalsweisen Release-Zyklen, obwohl die bereits agilisierten Entwicklungszyklen in hoher Frequenz PSIs (Potentially Shippable Increments) abliefern. Nicht nur im Falle von manuellem Testing, sondern auch bei automatisierten Regressionstest-Suites begegnet man dieser Problematik sehr häufig.
Ein wichtiger Ansatz für die Reduktion dieser großen Testfall-Suites ist es, diese von Redundanzen zu befreien. In der Regel wird man darüber zwar die Anzahl der Testfälle verkleinern können, der große Wurf kann damit aber nicht gelingen. Es sind daher radikalere Einschnitte in die Testfall-Suite über eine risikobasierte Betrachtung von Nöten. Hier ist Kreativität, Verständnis für den Kunden und dessen Business sowie eine gute Kenntnis des zu testenden Systems erforderlich.
In einem Projekt bei einer großen Rückversicherung, deren zentrales Geschäftssystem naturgemäß einer regelmäßigen Wartung und Weiterentwicklung unterliegt, haben wir bei der Reduktion der Testfall-Suite mit der Strategie gute Erfahrungen gemacht, in den hochfrequenten Regressionstests diejenigen Testfälle nach und nach zu eliminieren, die regelmäßig keine Fehler finden.
In einem ersten Schritt wurden hierbei die Testreports eingesammelt und diese auf Anzahl von Testausführungen und Anzahl entdeckter Defects pro Functional Area hin ausgewertet. Nach Eliminierung der False Positives wurden die Functional Areas identifiziert, für welche die Testfälle Fehler gefunden haben. Bei den unmittelbar folgenden Testzyklen hat das Testteam dann auf die Durchführung der erfolglosen Teil-Suiten verzichtet und diese bezüglich Effektivität auf den Prüfstand gestellt (siehe Abbildung 1).
Abb. 1: Reduktion der Testfall-Suite durch Fokussierung auf effektive Test-Szenarien
Mit dieser Strategie war das Testteam in der Lage, die folgenden Potenziale zu erschließen:
- Verkleinerung der Durchlaufzeiten des Regressionstests,
- Eliminierung der Wartungs- und Betriebskosten für ineffektive Testfallszenarien,
- Erhöhung der Kapazitäten für die Entwicklung effektiverer Testfallszenarien.
Neben dieser eher businessorientierten Vorgehensweise zur Fokussierung gibt es auch vielversprechende Ansätze, die die Entwickler-Seite beziehungsweise den von den Entwicklern erstellten Code in die Betrachtung einbeziehen.
Durch Einsatz einschlägiger Tools lässt sich über Instrumentierung des Quellcodes identifizieren, welche Teile des Codes seit dem letzten Test verändert oder ergänzt, aber noch nicht getestet wurden, sodass sich die Aufmerksamkeit des Tests genau auf diese Lücken lenken lässt („Test Gap Analysis“). Dadurch eröffnet sich die Möglichkeit, immer nur sehr kleine Anteile umfangreicher Regressionstest-Suiten laufen zu lassen und damit trotzdem den größten Teil der Risiken abzudecken („Test Impact Analysis“).
Automatisierung
In den meisten IT-Organisationen unternehmen die Entscheidungsträger Anstrengungen, für erfolgskritische Anwendungen in das Continuous Delivery Regime zu kommen.
Dafür werden mit unterschiedlichem Erfolg neben vielen anderen Maßnahmen Automatisierungslösungen für die Unterstützung des gesamten Software Development Life Cycle eingeführt. Dies ist überwiegend bereits der Fall für Versionierung, Umgebungsaufbau und Deployment, was ohne Frage eine wesentliche Voraussetzung für kurze Durchlaufzeiten von neuen Softwareversionen darstellt.
Wie der World Quality Report 2018/2019 ([WQR], S. 26: „Test automation – The single-biggest enabler of maturity in QA and testing”) deutlich macht, gibt es aber grundsätzlich noch deutliches Potenzial, was die Automatisierung im Testing angeht. Nach Einschätzung der Umfrageteilnehmer lag zu diesem Zeitpunkt der Automatisierungsgrad in allen abgefragten Feldern (Functional, API, Performance, Security usw.) durchwegs unter 20 Prozent, während ca. zwei Drittel der Teilnehmer in jeglicher Hinsicht Vorteile bei der Testautomatisierung sehen. Hier liegt momentan fraglos noch ein großes Potenzial brach, welches durch entsprechende Überzeugungsarbeit bei den Entscheidungsträgern, die gegebenenfalls die Anfangsinvestition bei der Testautomatisierung scheuen, gehoben werden kann.
Bei der Einführung einer einheitlichen CRM-Lösung bei einem großen Unternehmen in der Automobilindustrie sind wir gegenüber den klassischen Automatisierungsansätzen noch einen Schritt weitergegangen. Während in der Regel neben der statischen Code-Analyse die Durchführung von dynamischen Testfällen im Fokus der Automatisierung steht, wurde in diesem Projektkontext eine Lösung zur automatisierten Erstellung von Testfällen aufgesetzt. Dadurch war es möglich, in einem hochagilen Umfeld bereits im Stadium noch nicht gefestigter Anforderungen, in dem ein hoher Automatisierungsgrad aufgrund von häufig erforderlichen Testfallanpassungen nicht anzuraten ist, Aufwände und Durchlaufzeiten im Testprozess niedrig zu halten.
Voraussetzung hierfür ist es, Architektur und Design der Use-Cases toolunterstützt zu modellieren und daraus über eine implementierte Logik Testfälle abzuleiten. Im konkreten Fall hat das Team die Modellierung in MagicDraw aufgesetzt. Für die Verwaltung der Testfälle kommt Jira/Xray ins Spiel. Beide Systeme sind so gekoppelt, dass nach einer Überarbeitung eines Use-Cases in MagicDraw auf Knopfdruck angepasste Testfälle in Jira/Xray generiert werden können.
Die Rundreise (siehe Abbildung 2), detailliertere Ausführungen hierzu unter [Nin20], beginnt mit dem Product Owner (PO), der ein neues Epic in Jira erstellt. Anschließend wird das Epic in das als digitaler Zwilling des Systems fungierende Modell in MagicDraw gezogen, wo der Analyst die Use-Cases identifiziert, die vom Epic betroffen sind, und Abhängigkeiten vermerkt.
Abb. 2: Rundreise durch den Entwicklungszyklus mit automatisierter Testfallerstellung
Gelangt das Epic in einen Implementierungs-Sprint, prüft der Designer den Ablauf und passt ihn bei Bedarf an. Parallel oder danach prüft der Tester die betroffenen Testkonfigurationen und passt diese ebenfalls bei Bedarf an. Dazu stellt er Wertbelegungen für vordefinierte Testparameter bereit und ordnet Testpfade zu.
Startet man den Testgenerator, dann erzeugt dieser je Kombination aus Testpfad und Testkonfiguration einen instanziierten Testfall. Zudem werden die Testdetails mit Testdaten und erwarteten Ergebnissen pro Testschritt ergänzt. Da generierte Tests automatisch mit ursprünglichen Epics verknüpft werden, lässt sich in Jira auf einfache Weise die Überdeckung von Epics mit Testfällen oder nach Ausführung der Testfälle die Testabdeckung ermitteln. Dadurch kann auch der PO sehr leicht dem Fortschritt folgen. Durch Einsatz dieser Lösung zur Entlastung bei der Testfallpflege konnten die Fachtester ihre Kapazitäten verstärkt anspruchsvollen explorativen Tests widmen.
Automatisierung im Testumfeld ist also nicht nur beschränkt auf das, was man gemeinhin darunter versteht, nämlich die Implementierung einer automatisierten Ausführung von Testfällen. Neben der Ausdehnung der Automatisierung auf die Testfallerstellung sehen wir als weitere Ansatzpunkte in diesem Zusammenhang zum Beispiel den Einsatz von KI zur Automatisierung von Prozessschritten im Defect Management (Automatisches Routing von Defects) oder in der Verwendung von White Box Fuzzing zur Automatisierung von Entwicklertests.
Expansion
Ob ein Softwareprodukt oder ein IT-Service erfolgreich ist, wird letztendlich daran gemessen, wie es/er vom Anwender angenommen wird. Qualität muss daher von Anfang an vom Anwender her gedacht werden. Das bedeutet, dass die unterstellten Nutzenpotenziale und die Erfüllung von Akzeptanzmerkmalen möglichst frühzeitig im Software Development Life Cycle überprüft werden müssen.
In einem kürzlich abgeschlossenen Projekt bei einem globalen Versicherungsunternehmen konnten wir dies erfolgreich mit einem entsprechend adaptierten Schnitt von Teststufen umsetzen. Vor wenigen Jahren hat der Versicherer den erfolgreichen Sprung in die Welt der Lifestyle-Apps gewagt. Es stand fest, dass er es sich nicht leisten kann, den Kunden lange warten zu lassen und anschließend mit einem Produkt zu überraschen, von dem nicht klar ist, ob es beim Kunden positiv ankommt.
Die Herausforderung bestand also darin, einen Weg zu finden, der ausgewählten Kunden einen kontrollierten Zugang zu noch nicht fertigen Produkten gewährt, mit dem Ziel, konstruktives Kundenfeedback zu erhalten, ohne dabei zu viele Informationen an die Konkurrenz preiszugeben oder das positive Image aufgrund von nicht ausgereifter Software zu verlieren.
Zur Lösung dieses Problems hat das Team eine abgesicherte und kontrollierte Spielwiese aufgebaut, zu welcher in zwei Stufen projektfremden Anwendern der Zugang gewährt wurde, nachdem der interne Test durch Entwickler und Tester des Projektteams während der agilen Iterationen abgeschlossen war (siehe Abbildung 3).
Abb. 3: Teststufen zur frühen Einbeziehung von Business und Kunden in den Test
In der ersten Stufe unterzogen nach Bestehen der Ausgangskriterien des internen Tests und Deployment des Produkts auf die Spielwiese Mitarbeiter des Unternehmens mit spezifischem Fachwissen das Produkt einem ausgiebigen Test. Im Falle der Umsetzung einer User-Story zur Abrechnungslogik waren dies beispielsweise projektfremde Mitarbeiter aus der Finanzabteilung.
In einer zweiten Stufe durften ausgewählte Kunden testen. Mit Aufnahme in das Pilotprogramm wurde diesen hierzu ein zeitlich begrenzter Zugriff auf die Spielwiese gewährt. Das daraus resultierende Feedback konnte entwicklungsbegleitend verarbeitet werden, sodass dadurch das Projektteam bei Produktivsetzung zuversichtlich mit einer hohen Nutzerakzeptanz rechnen konnte, weil aufgrund dieser Vorgehensweise
- kritische Issues nicht nur in der App, sondern auch in den Anforderungen entdeckt werden konnten und
- frühzeitig vor Go-Live gezeigt werden konnte, worauf sich Operations und Service vorbereiten müssen.
Der nächste angestrebte Entwicklungsschritt für diese Art des Testings ist die Verwendung von einschlägigen Werkzeugen und Plattformen für die Umsetzung von Crowdtesting. Diese unterstützen die Abwicklung von Tests durch Testkapazitäten, die nicht in eine bestehende Organisation eingebunden sind, besser als klassische Testmanagementwerkzeuge (insbesondere Rekrutierung, Feedback-Verarbeitung, Incentivierung). Darüber hinaus bieten diese die Möglichkeit, nicht erst während des Entwicklungsprozesses, sondern bereits bei der Prüfung von Anforderungen oder noch weitgehender bei der Findung von lohnenswerten neuen Anforderungen das Feedback von Stichproben von (potenziellen) Kunden und Anwendern einzubeziehen.
Fazit
Die richtigen Dinge richtig zu tun, ist auch die Maxime bei der Verschlankung von Test und Quality Management. Zur Effizienzsteigerung Automatisierung, zur Steigerung der Effektivität Fokussierung und Expansion.
Referenzen
[Nin20]
U. Nink, Model-Driven Test Generation with VelociRator, Blog, 31.8.2020, siehe:
https://udonink.de/272/
[WQR]
Capgemini, Micro Focus, Sogeti: World Quality Report, siehe:
https://www.capgemini.com/research/world-quality-report-2019/
