Warum Testen?
Alles, was schiefgehen kann, wird schiefgehen…
Murphy’s Law
Das klingt zwar auf den ersten Blick äußerst pessimistisch, ist aber auf den zweiten Blick nur als Warnung gedacht, potentielle Fehlerquellen auf keinen Fall zu unterschätzen.
Niemand ist perfekt und mit zunehmender Digitalisierung und Vernetzung unserer Welt, ist es umso wichtiger geworden, ein umfassendes Qualitätsmanagement in der Softwareentwicklung zu etablieren.
Viele haben es vor ein paar Tagen selbst zu spüren bekommen. Einer der bis dato größten IT-Ausfälle der Geschichte hat Mitte Juli 2024 Millionen von PCs auf der ganzen Welt lahm gelegt.
Bei diesem Vorfall ist keine Branche verschont geblieben. Krankenhäuser mussten in den Notbetrieb wechseln, Flugpassagiere strandeten auf Flughäfen weil Check-ins nicht mehr möglich waren, große Schnellimbiss-Ketten konnten keine Bestellungen mehr aufnehmen und ganze Industriebetriebe waren gezwungen, ihre Produktion zu stoppen.
Und das nur weil ein kleines Glied in der Kette gerissen ist. Die Ursache des technischen Blackouts konnte nämlich auf ein systemrelevantes Sicherheits-Unternehmen zurückgeführt werden, das möglicherweise aus Nachlässigkeit und Unachtsamkeit – bestimmt verbunden mit Zeitdruck – ein fehlerhaftes Systemupdate in Windows-Installationen ihrer Kunden eingespielt hat, wodurch beim Starten immer wieder ein sog. Blue Screen angezeigt wurde.
Rien ne va plus
An dieser Stelle sei angemerkt, dass dieser Bug nichts mit (automatischen) Updates zu tun hatte. Aktuelle Software einzusetzen ist natürlich trotzdem wichtig und richtig. Schon alleine aus Security-Sicht, weil veraltete und ungepatchte Systeme ein enormes Risiko darstellen und Kompromittierung oder sogar Verlust von Daten zur Folge haben können.
Leider passieren Fehler und wenn diese auftreten, hilft es nicht, mit dem Finger auf andere zu zeigen oder Schuldzuweisungen vorzunehmen. Man kann nur daraus lernen.
Ein erster Schritt ist die Kenntnis der Grundsätze des ordnungsgemäßen Testens (nach ISTQB®):
- Testen zeigt die Anwesenheit von Fehlerzuständen, nicht deren Abwesenheit
- Vollständiges Testen ist nicht möglich
- Frühes Testen spart Zeit und Geld
- Fehlerzustände treten gehäuft auf
- Tests nutzen sich ab
- Testen ist kontextabhängig
- „Keine Fehler bedeutet ein brauchbares System“ ist ein Trugschluss
Sinngemäß ist hier gemeint, dass man als Entwickler achtsam bleiben muss weil die Verantwortung nicht vollständig ausgelagert werden kann – selbst wenn ein eigenes Test-Team vorhanden ist.
Real artists ship!
Das hat Steve Jobs schon in den 80er Jahren richtigerweise erkannt und bei Teambesprechungen im Zuge der Entwicklung des Macintosh immer wieder betont.
Leider haben IT-Projekte seit jeher den Ruf, Zeitpläne nicht einzuhalten oder sogar gänzlich zu scheitern. Deswegen die Digitalisierung zurückzufahren ist natürlich keine Lösung und man darf am Ende auch nicht so weit gehen, gute Ideen zu verwerfen, wichtige Entscheidungen aufzuschieben oder aus Angst vor potentiell vorhandenen Bugs gar nicht zu liefern.
Optimale Vorbereitung ist alles und zur Vermeidung von technischen Schulden und damit verbundenen Bugfixes hat es sich bewährt, größere Änderungen immer schrittweise auszurollen, um Feedback einholen zu können. Wenn doch einmal etwas schiefgeht, sollte bei fatal Errors im Bedarfsfall zumindest der ursprüngliche Zustand wiederhergestellt werden können.
Gut etablierte Applikationen wie u.a. WordPress zeigen vor, dass es durchaus Stand der Technik ist, automatische Updates relativ friktionsfrei auszuliefern, dabei potentielle Fehler so gut wie möglich abzufangen, Änderungen im Notfall sogar rückgängig zu machen und dem Administrator eine kurze Statusmeldung zuzusenden. Alles ganz vollautomatisch und wie von Zauberhand.
Wie kann der Druck im Projektteam herausgenommen werden?
Dies liegt in der Verantwortung des Projektmanagements. Eine grundlegende Analyse der Stärken, Schwächen, Chancen und Risiken gehört heutzutage zu einer strategischen Organisationsplanung einfach dazu. Das bedeutet, sich niemals auf den Lorbeeren auszuruhen, Prozesse und Tools laufend zu optimieren und immer wieder an neue Herausforderungen anzupassen:
☝️ Informieren
- Einen Kommunikationsplan erstellen
- Notfallpläne bereitstellen und diese turnusmäßig evaluieren
- Eine positive und offene Fehlerkultur etablieren, um daraus lernen zu können
- Verantwortung übernehmen, Feedback ernst nehmen und mit aufgezeigten Schwachstellen transparent umgehen
🤞 Vorbeugen
- Vertrauen ist gut, eine mehrstufige Qualitätssicherung mit Kontrolle ist besser
- Pair-Programming oder Peer-Reviews können zur Verbesserung der Code-Qualität beitragen
- Soweit wie möglich automatisierte Tests integrieren und idealerweise ein Test-Driven-Development etablieren
- Automatisierte periodische Backups, Wartungen und Sicherheits-Updates durchführen
✋ Fördern
- Problemlösungsfähigkeiten verbessern
- Ausbau der internen (Test-)Expertise und Wissenstransfer durch regelmäßige Schulungen
- Zukunftssicherheit im Code von Anfang an einbeziehen
- Abhängigkeiten auf das Nötigste reduzieren und kritische Bereiche möglichst eigenständig halten – unter Umständen sogar redundant
Noch einmal zurück zu Murphy’s Law und zur ISTQB-Grundlage des Testens #1. Selbst wenn alle Regeln der Kunst befolgt werden… Probleme werden früher oder später auftauchen, weil Anforderungen (an moderne Anwendungen) einfach immer anspruchsvoller werden, Abhängigkeiten (mit Third-party Paketen) notgedrungen entstehen und in Folge die Komplexität (von Code) immer weiter zunimmt. Alle sollten sich darüber im Klaren sein, dass ein Softwareprojekt nie fertig entwickelt ist, sondern ständig gepflegt werden muss.
Zudem gilt: Je früher ein Bug entdeckt und gefixt wird, desto weniger Zeit, Kosten und Frustration entstehen. Und gravierende Fehler mit negativen Auswirkungen auf das Gesamtsystem dürfen es erst gar nicht in die Produktivumgebung schaffen.
Hier ist eine gute Planung entscheidend, denn die Ausarbeitung einer umfassenden Teststrategie unter Einbindung des gesamten Projektteams, mit Formulierung von Mindestanforderungen und Testzielen, konsequentem Einsatz von Test-driven Development und Prozessautomatisierung, bringt Ordnung und Struktur in die Softwareentwicklungsorganisation.