Wie teste ich das alles – Erkenntnisse aus der Qualitätssicherung bei d.velop

Neue Software verlässt das Labor und wird von Anwender:innen produktiv genutzt. Habe ich ihre Erwartungen erfüllt? Ist die Software stabil? Wie viele Bugs sind mir durchgerutscht? Die Erwartungen der Anwender:innen scheinen ständig zu steigen, genau wie die Komplexität von Software und der Umgebungen, in der sie lauffähig sein müssen. Dieser Blog-Beitrag berichtet über die Herausforderungen der Qualitätssicherung von Software bei d.velop und liefert praktische Tipps für die eigenen Produkte und Projekte.

Erwartungen und Herausforderungen

Mit Erwartungen fängt alles an. Was erwarte ich von der Software, was erwarte ich von diesem Blog-Beitrag, und was hat das mit dem „Afsluitdijk“ zu tun?

Der Afsluitdijk ist ein 32 Kilometer langer Damm in den Niederlanden und trennt das Ijsselmeer von der Nordsee. Sein Bau wurde beschlossen, um Amsterdam und weitere Gebiete vor Hochwasser und Sturmfluten zu schützen und ermöglichte Landgewinnung – seit 1986 gibt es die 12. Niederländische Provinz Flevoland. Es gibt zwei Tiedesperrwerke, welche den Ablauf des Süßwassers sowie den Schiffsverkehr steuern. Diesen kommt insbesondere bei Sturmfluten eine besondere Bedeutung zu. Ich habe früher bei einem Unternehmen gearbeitet, welche die Software für diese Schleusen entwickelt hat. Wie viele Bugs würden wir dieser Software zugestehen?

Bevor Software entwickelt und getestet wird, sollten wir uns überlegen, welches Qualitätslevel wir erwarten. Wird hiermit ein unternehmenskritischer Prozess abgedeckt, der jederzeit verfügbar sein muss, oder ist es verkraftbar, wenn die Software mehrere Tage ausfällt? Handelt es sich einen zentralen Dienst unseres Cloudangebotes, auf den alle Anwender:innen angewiesen sind, oder ist eine projektspezifische Entwicklung für 15 Mitarbeitende einer eigenständigen Abteilung?

Wichtige Meilensteine des strukturierten Testprozesses

Beim Entwickeln und Testen von Software verfolgt d.velop einen risikobasierten Ansatz. Je höher die negative Auswirkung eines Fehlers ist, je größer die Wahrscheinlichkeit, dass es zu einem Fehler kommt, desto besser muss getestet werden. Dies wirkt sich natürlich auf die Kosten aus. Daher spielt die Wirtschaftlichkeit hierbei eine große Rolle – fehlerfreie Software ist praktisch unbezahlbar.

Zurück zu Erwartungen – hierzu gehört auch, dass alle sie kennen und verstehen. Die gewünschten Funktionen der Software müssen dokumentiert sein, sonst kann sie nicht gut entwickelt und getestet werden. Im Projektgeschäft werden Anforderungen oft in Lasten- und Pflichtenheften festgehalten, in agilen Projekten und in der agilen Softwareentwicklung sind „User Stories“ üblich. Hierin werden überschaubare, in sich gekapselte Anforderungen beschrieben. Dabei hat sich, nicht nur bei d.velop, folgender Aufbau etabliert:

• Titel: Als <Rolle> möchte ich <Funktionalität>, damit ich <Grund>
• Beschreibung: (wenn der Titel nicht schon sprechend genug)
• Akzeptanzkriterien: Niedergeschriebene, fachliche Anforderung, welche zum Zeitpunkt der Abnahme erfüllt sein muss
• Aufwandsschätzung: $$$

Effektives Projektmanagement in der Softwareentwicklung: Warum kurze Zyklen entscheidend sind

Zeit hat man nie genug, schon gar nicht zum Testen. Wer kennt nicht die folgenden Aussagen? „Die Entwicklung hat sich verzögert, es blieb keine Zeit zum Testen“ oder „Das nächste Projekt startet bereist, bevor das aktuelle fertig war“. Dazu fällt mir immer eines meiner Lieblingsaussagen aus dem Projektmanagement ein: „Sag mir, wie Dein Projekt startet, und sich sage Dir, wie es endet!“ Planung ist also alles!

Klassischerweise gibt es in der Softwareentwicklung die Schritte Spezifikation, Entwicklung, Test und zum Abschluss das Release bzw. Deployment oder Produktivsetzung. Die Praxis zeigt aber, dass es hier mehrere Konfliktstellen gibt: Was kommt nach Entwicklung? Nein, nicht Test, sondern noch mehr Entwicklung – die Zeit fürs Testen schrumpft.

Endlich kann getestet werden, der Plan sieht danach die Produktivsetzung vor – nicht aber, dass auch Fehler gefunden werden. Also zurück zur Entwicklung, vielleicht auch mehrmals, bis die Tests endlich das gewünschte Ergebnis bringen. Jetzt aber Produktivsetzung, Release oder Deployment, FERTIG! Wirklich fertig? Leider nein. Der Echtbetrieb ist immer anders als die Simulation, die Anwender:innen finden Abweichungen zum Wunschzustand, also: Zurück zur Entwicklung.

Ist Planung also wirklich alles? Pläne sind immer schwierig, besonders, wenn sie die Zukunft betreffen. Daher hat sich bereits seit vielen Jahren die Lieferung von Entwicklungsergebnissen in möglichst kleinen Häppchen etabliert – auch im Projektgeschäft. Je kleiner die Inkremente, desto genauer kann verstanden werden, was sich ändert, und je eher und genauer erhalte ich Feedback. So werden in d.velop Projekten Teilergebnisse oft wöchentlich vorgestellt, und die d.velop Cloud erfährt oft mehrere Updates täglich. Planung bleibt wichtig, kurze Zyklen sind aber wichtiger!

Qualitätssicherung bei Software: Testen in der Praxis

Wenn strukturiert getestet wird, kommen wir zwangsläufig an den folgenden Stationen vorbei:

• Testplanung / Analyse: Was ist zu testen?
• Testentwurf / Testrealisierung: Wie wird getestet und ist jetzt alles für den Test bereit?
• Testdurchführung: Regression Ausführung
• Testabschluss: Testergebnisse sammeln
• Testüberwachung & -steuerung: Übergreifendes Testmanagement

Bei kleineren Vorhaben oder Projekten ist dies vielleicht zu viel des Guten. Es lohnt sich aber immer, einen Plan zu haben und die Testergebnisse festzuhalten. Im einfachsten Fall ist dies ein und dasselbe Dokument, z.B. eine Excel-Tabelle mit den folgenden Spalten:

• Testnummer
• Ablaufbeschreibung
• Erwartetes Ergebnis
• Testdatum
• Tester
• Testergebnis
• Bemerkungen

So bleibt nachvollziehbar, was getestet wurde und der Projektleiter oder die Projektleiterin hat etwas in der Hand, wofür er oder sie Geld verlangen kann. Wenn ich weiß, was ich testen soll, stellt sich immer noch die Frage nach dem Wie. Die:Der geneigte Endanwender:in nimmt sich die Maus und klickt alle Funktionen durch, doch es gibt noch viele andere Wege.

Bei einmaligen oder seltenen Vorhaben ist der manuelle Test über die Benutzeroberfläche der richte Weg. Wird Software jedoch komplexer und stetig weiterentwickelt, ist es auf Dauer zu aufwändig, täglich alle neuen Funktionen aufs Neue durchzuklicken. Hier können die automatisierten Tests Linderung schaffen. Bei der Darstellung der verschiedenen Testarten wird häufig eine Pyramide genutzt:

In der Standard-Softwareentwicklung haben sich Unit-Tests etabliert. Zu jeder programmierten Funktion wird auch eine Testfunktion geschrieben. Wird bei der Weiterentwicklung die Funktion gestört, schlägt die Testfunktion fehl und die Entwicklerin oder der Entwickler kann unmittelbar eingreifen.

Um die Zusammenarbeit von mehreren Funktionen, Microservices oder Applikationen zu testen, reichen Unit-Tests nicht aus. Hier greifen automatisierte Integrations- und API-Tests. Noch weiter oben in der Pyramide befinden sich UI (User Interface), End-to-End und Akzeptanz-Tests.

Testpyramiden und Teststrategien: Die Balance zwischen Aufwand und Aussagekraft

Je weiter oben in der Pyramide, desto aufwändiger und damit teurer ist ein Testdurchlauf. Dafür sind die Tests aussagekräftiger, da das Gesamtverhalten mit allen Abhängigkeiten getestet wird. Um aus beiden Welten die Vorteile zu ziehen, hat sich in der agilen Softwareentwicklung die aufrecht stehende Pyramide etabliert. Dies ist aber nicht der einzige richtige Weg! Je nach Anwendung und Anwendungszweck kann auch die umgekehrte Pyramide richtig sein, oder ganz andere geometrische Figuren wie hexagonal, hourglass, trophy oder house of testing. Hilfreich ist aber, dies nicht dem Zufall zu überlassen, sondern eine Teststrategie zu entwickeln und für den individuellen Anwendungsfall die optimale Testabdeckung der Codes zu erreichen.

Ist die Testautomatisierung der heilige Gral und manuelles Testen ein Relikt aus der Vergangenheit? Sicher nicht! Automatisierung lohnt sich, je häufiger getestet werden muss und je häufiger sich eine Anwendung ändert. Aber Testautomatisierung hat nicht nur Fix-, sondern auch laufende Kosten! Tests müssen nicht nur erstellt, sondern auch gepflegt werden. Dieser Aufwand wird oft unterschätzt. Eine Untersuchung (Forrester Analytics Business Technographics Develeoper Survey, 2023, Base: 2,177 Developers) hat ergeben, dass nur zwischen 20% und 25% der Tests automatisiert sind – da sind wir bei d.velop deutlich besser.

Shift Left und Shift Right: Strategien für effektives Testen und Fehlerbehebung

Neben dem Wie stellt sich auch die Frage nach dem Wann. Unter „Shift Left“ versteht man den Ansatz, so früh wie möglich im Entwicklungsprozess zu testen – je eher ein Fehler gefunden wird, desto günstiger kann er behoben werden. Das heißt: Fehler vermeiden oder früh erkennen, so früh und so umfangreich wie möglich testen.

Die Praxis – erst recht beim Betrieb von komplexen Cloud-Lösungen – hat jedoch gezeigt, dass auch mit maximalen Anstrengungen nicht alle Fehler vor dem produktiven Betrieb gefunden werden können. Unter „Shift Right“ gibt es daher den Ansatz, die Produktion so gut wie möglich im Auge zu behalten. Fehler sollen so schnell wie möglich entdeckt, und – was noch wichtiger ist – so schnell wie möglich behoben werden. Das bedeutet, dass eine Codeänderung bestenfalls innerhalb weniger Minuten getestet und produktiv genommen werden kann. Ist ein Problem durch eine neue Version entstanden, sollte ein Rollback auf die noch funktionierenden Vorgängerversion innerhalb von Sekunden möglich sein. Ist das Kind ganz tief in den Brunnen gefallen und z.B. Dateninkonsistenzen aufgetreten, muss jederzeit klar sein, wie ein Desaster Recovery möglich ist.

Qualitätssicherung von Software bei d.velop

Von der Theorie zur Praxis: Wie sieht die Qualitätssicherung bei der d.velop Produktentwicklung aus? Software entsteht bei uns in rund 30 Entwicklungsteams, in jedem von diesen gibt es eine Person, die sich hauptverantwortlich für die Softwarequalität zeigt. Dabei ist das nicht in allen Teams ein Vollzeit-Job, oft ist es eine Rolle neben z.B. der Entwicklertätigkeit. Bei d.velop sind es aber 18 Personen, die sich ausschließlich um Qualitätssicherung kümmern.

Über 200 Applikationen wollen bei d.velop getestet werden, hierum kümmern sich unter anderem rund 80.000 Tests, die nächtlich automatisiert ausgeführt werden. Beim Testen kommt unserer d.velop Cloud eine besondere Rolle zu: Da hier oft mehrmals täglich Änderungen live genommen werden, muss engmaschig getestet werden, damit zwei parallele Updates miteinander kompatibel bleiben. Hierfür werden stündlich über 60 Tests zur Absicherung von gegenseitigen Abhängigkeiten durchgeführt.

Wie beschrieben, hat bei d.velop die Testautomatisierung einen hohen Stellenwert. Hierbei kommen für sehr unterschiedliche Einsatzzwecke verschiedene spezialisierte Werkzeuge zum Einsatz, das folgende Bild fasst die wesentlichen zusammen.

Sicherheitsprozesse und statische Codeanalyse: Grundlagen der Qualitätssicherung

Die statische Codeanalyse spielt insbesondere für die Sicherheit unserer Software eine entscheidende Rolle.

Die Basis von sicherer Software sind die Prozesse, die dieser zugrunde liegen. Hierfür haben wir zugehörige Zertifizierungen, was uns zusätzliche Sicherheit gibt. Diese sichern wir ab, indem wir mindestens jährlich mit unseren Teams Sicherheits- und Qualitätsreviews durchführen. Auch unserer Software erfährt jährlich Sicherheitsreviews in Form von Penetrationstests: Wechselnde externe Prüfer:innen suchen nach Sicherheitslücken. Eine dritte Säule von Software, der man vertrauen kann, sind die oben angesprochenen Codeanalysen: Hier wird periodisch mit Spezialwerkzeugen nach Sicherheitslücken gesucht, die Versionen der eingesetzten Fremdkomponenten mit Sicherheitsdatenbanken abgeglichen und nach versteckten, nicht ausreichend geschützten Zugangsdaten (Secrets) gesucht. Bei dieser Gelegenheit werden auch die Lizenzen der eingesetzten Fremdkomponenten überprüft, damit sowohl wir als auch unsere Kunden „Compliant“ bleiben.

Wie verändert KI den Testprozess?

In aller Munde ist die Frage, wie künstliche Intelligenz bzw. AI unsere Leben, aber natürlich auch Entwicklung und Test von Software verändern wird. Forrester spricht hier von „TuringBots“, welche den Menschen bei ihrer Arbeit unterstützen werden. Während diese bislang nur in einzelnen Fällen unterstützen und für überschaubare Produktivitätssteigerungen sorgen, werden sie sich in den nächsten Jahren zu gleichberechtigten Begleitern entwickeln. Ab 2028 rechnet Forrester damit, dass TuringBots die Aufgaben in der Softwareentwicklung eigenständig übernehmen und der Mensch lediglich die Aufsicht übernimmt.

KI hilf uns also bereits jetzt bei Entwicklung und Test. Dies funktioniert ganz konkret z.B. bei der Überprüfung von Code oder der automatisierten Erstellung eines Unit-Tests. Auch bei der Testdatengenerierung gibt es bereits viele Anwendungsszenarien. Auf Basis von natürlicher Sprache können aus User Stories Dokumentationen erstellt werden. Unsere Analysen bestätigen die Sicht von Forrester: Aktuell ist der Nutzen noch überschaubar und die Technik steckt in den Kinderschuhen, die Aussichten sind aber vielversprechend.

Bei d.velop begleitet uns Künstliche Intelligenz schon seit vielen Jahren. 2007 habe ich ein Projekt bei einer großen deutschen Versicherung geleitet, bei dem Eingangspost automatisiert klassifiziert und der richtigen Sachbearbeiterin oder dem richtigen Sachbearbeiter vorgelegt wurde. Bereits hier war zu erkennen, dass KI komplexe Entscheidungen in hoher Geschwindigkeit treffen und hiermit Menschen, in diesem Fall die Poststelle, entlasten kann. Aber auch erkennbar war, dass Entscheidungen nicht immer eindeutig sind, abhängig von Eingangs- und Trainingspost auch Fehler passieren und auf den ersten Blick die Ursache nicht eindeutig ist. Entscheidungen von Künstlicher Intelligenz sind – ähnlich derer von natürlicher Intelligenz – oft nicht leicht nachvollziehbar. Hier kommen wir wieder zurück zur Risikobetrachtung: Was wäre die Auswirkung einer falschen Entscheidung: Muss die Sachbearbeiterin oder der Sachbearbeiter das Poststück weiterleiten oder schließt die Schleuse beim Afsluitdijk zu spät? Fehler müssen einkalkuliert, deren Auswirkung bewertet werden.

Qualitätssicherung von Software: Was könnt ihr mitnehmen?

Also zurück zum Afsluitdijk, zurück zu Erwartungen. Konnte ich Deine Erwartung an diesen Blog-Beitrag erfüllen? Gerne fasse ich zusammen, was Du hoffentlich zum Thema Qualitätssicherung von Software mitnehmen konntest – und vielleicht ein wenig mehr: Frag Anwender:innen, was sie erwarten. Sie müssen schließlich mit der Software arbeiten. Kenn die Anforderungen und Risiken der Software und des Projektes. Kleine Projekte sind beherrschbar – sie erzeugen nur kleine Fehler, die schnell behoben werden können. Hab eine Strategie, überlege, wie und was Du testest, und auch warum. Überwache den Betrieb, Du wirst nicht alle Fehler vor dem Livebetrieb finden. Du wirst nicht belohnt, wenn das System sicher ist, aber gehängt, wenn es gehackt wird. Bereite Dich auf KI vor, sie wird kommen und alles ändern. Testsystem = Produktivsystem: Sorge dafür, dass Tests realitätsnah sind. Last, but not least: Feiere Erfolge!