Ob es sich um einen auf Ihrem Smartphone eingestellten Wecker oder die Bestellung einer Mahlzeit über eine App handelt, alles läuft über einen Code, und manchmal entgleist dieser Code!
Softwarefehler können harmlos sein, aber einige haben Milliarden gekostet, große Krisen verursacht und sogar Leben gefährdet.
Für die Tester sind diese Fehlschläge wertvolle Lektionen, die sie nie vergessen sollten.
In diesem Artikel untersuchen wir einige der bedeutendsten Software-Fehlschläge der Geschichte und die Lehren, die wir daraus ziehen können.
Am 4. Juni 1996 wurde in Kourou, Französisch-Guayana, zum allerersten Mal die Ariane-5-Rakete gestartet.
37 Sekunden nach dem Start kam sie vom Kurs ab, zerfiel mitten im Flug und explodierte, was zum Verlust von Material im Wert von über 370 Millionen Dollar führte - alles verursacht durch einen Softwarefehler.
Die Steuerungssoftware nutzte einen wiederverwendeten Codeteil der Vorgängerversion Ariane 4, und die Flugbedingungen der Ariane 5 waren grundlegend anders.
Bei der Umwandlung einer Gleitkommazahl in eine ganze Zahl trat eine unbehandelte Ausnahme auf.
Außerdem trat der Fehler in einem Softwaremodul auf, das nach dem Start nicht einmal mehr benötigt wurde, aber weiterhin aktiv war.
Dieser Fehler hätte bei realistischen Simulationen oder einer gründlichen Prüfung des Codes entdeckt werden können. In Wirklichkeit handelte es sich um eine bekannte Schwachstelle, die jedoch als unwahrscheinlich eingestuft worden war.
Die Lektion für Tester:
Gehen Sie niemals davon aus, dass alter Code zuverlässig ist, nur weil er schon einmal funktioniert hat. Jede Wiederverwendung von Code muss in den Kontext des neuen Systems gestellt werden.
Beim Testen geht es nicht nur darum, aktuelle Funktionen zu validieren, sondern auch darum, die Relevanz und Robustheit des Legacy-Codes zu bewerten, insbesondere in kritischen Umgebungen.
Ende der 1990er Jahre nahm ein scheinbar einfaches Problem weltweite Ausmaße an: die Verwaltung von Datumsangaben in Computersystemen.
Um Speicherplatz zu sparen, haben Entwickler Jahrzahlen jahrzehntelang oft mit nur zwei Ziffern codiert (z. B. "99" für 1999).
Viele befürchteten, dass Computer das Jahr 2000 als 1900 interpretieren würden, was zu massiven Fehlern z. B. bei Datumsberechnungen, Banksystemen oder Navigationssoftware führen würde.
Im Gegensatz zur vorherrschenden Panik war der 1. Januar 2000 kein weit verbreitetes Chaos.
Er hatte keine großflächigen Stromausfälle, keine Flugzeuge, die am Boden blieben, und keinen Zusammenbruch der Bankensysteme. Dennoch bedeutet dies nicht, dass der Bug überbewertet wurde oder keine Folgen hatte.
Hunderte Milliarden Dollar wurden vor allem von Regierungen, Banken, Krankenhäusern und Versicherungsgesellschaften in die Prävention investiert. Eine weltweite Kampagne zur Aktualisierung und zum Testen von Computersystemen wurde über mehrere Jahre hinweg durchgeführt.
Einige Bugs sind jedoch trotzdem aufgetreten:
Nichts Katastrophales, aber ausreichend, um zu zeigen, dass das Risiko sehr real war.
Die Lektion für die Tester :
Es ist entscheidend, zeitbezogene Grenzfälle zu testen und keine impliziten Annahmen im Code zu machen ("Wir werden nie das Jahr 2000 erreichen").
Er zeigt auch, dass präventive Tests, selbst wenn sie teuer und für den Endverbraucher unsichtbar sind, entscheidend sein können, um kolossale Krisen zu verhindern.
Am 27. März 2008 eröffnete der Flughafen London Heathrow sein neues Terminal 5, das das Erlebnis der Fluggäste revolutionieren soll.
Vom ersten Tag an gingen Zehntausende von Gepäckstücken verloren, Flüge wurden gestrichen oder verspätet, und das Image von British Airways wurde stark beschädigt - alles wegen eines neuen automatischen Gepäckmanagementsystems, das nicht ausreichend unter realen Bedingungen getestet worden war.
Die Fehler stammten aus einer Kombination von Softwareproblemen, mangelnder Koordination zwischen den verschiedenen Systemen (Gepäckaufzüge, Förderbänder, Scanner usw.) und schlecht ausgebildetem Personal.
Mehr als 42 000 Gepäckstücke gingen in wenigen Tagen verloren, und die Verluste wurden auf mehrere Dutzend Millionen Euro geschätzt.
Die Lektion für die Tester :
Ein System kann in einer Testumgebung perfekt funktionieren, aber in der Produktion versagen.
Die Tests müssen daher komplexe Szenarien und mehrere Systeme umfassen und menschliches Verhalten berücksichtigen.
Am 1. August 2012 setzt das auf Hochfrequenzhandel spezialisierte US-Unternehmen Knight Capital eine neue Software für den Handel auf den Finanzmärkten ein.
Weniger als eine Stunde später verliert das Unternehmen mehr als 440 Millionen US-Dollar.
Eine alte Testfunktion, die eigentlich deaktiviert werden sollte, war auf einigen Servern noch aktiv.
Die Software verschickte automatisch massive und inkonsistente Kauf- und Verkaufsaufträge für Hunderte von Aktien. Das System konnte die Anomalie nicht erkennen, da es keinen Rollback-Mechanismus oder eine Echtzeitüberwachung gab.
Das Unternehmen versucht, den Schaden zu begrenzen, aber der Schaden ist angerichtet. Der Fehler führt zu einer ungewöhnlichen Volatilität auf dem Markt, ruiniert Knight Capital buchstäblich und das Unternehmen wird einige Monate später aufgekauft.
All dies aufgrund eines Fehlers bei der Bereitstellung und fehlender Validierungstests nach der Freigabe. Es waren keine Tests unter realen Bedingungen auf allen Servern durchgeführt worden und die Fehler wurden nicht rechtzeitig eskaliert.
Die Lektion für die Tester :
Die Tests müssen die Bereitstellungsphase selbst umfassen, nicht nur die Funktionen. Es ist entscheidend, zu validieren, dass alle Umgebungen konsistent sind, dass alte Funktionen deaktiviert sind und dass die Monitoring-Tools aktiv sind.
Ein Konfigurationsfehler kann manchmal genauso große Auswirkungen haben wie ein funktionaler Fehler, und die kleinste Abweichung kann einen verheerenden Dominoeffekt auslösen.
Im Oktober 2018 bringt Microsoft ein Update für Windows 10 heraus, das die Stabilität des Systems verbessern soll.
Wenige Tage nach der Einführung meldeten Tausende von Nutzern einen besonders schwerwiegenden Fehler. Das Update löschte persönliche Dateien im Ordner "Dokumente" ohne Warnung oder Wiederherstellungsmöglichkeit.
Dieser Fehler war jedoch bereits Wochen vor der offiziellen Veröffentlichung von Testern gemeldet worden. Natürlich wurden die Rückmeldungen nicht rechtzeitig berücksichtigt und es wurden keine Korrekturmaßnahmen ergriffen.
Das Problem lag an einem Konflikt zwischen dem Tool für die Ordnerumleitung (Known Folder Redirection) und der Verwaltung von Duplikaten, einem bekannten Fall, der in den Tests jedoch schlecht gehandhabt wurde.
Microsoft wird das Update vorübergehend aussetzen und eine Korrektur veröffentlichen, aber der Schaden war bereits angerichtet und das Vertrauen der Benutzer erleidet einen Schlag!
Die Lektion für die Tester :
Es reicht nicht aus, nur die "normalen" Fälle zu testen. Sonderfälle, benutzerdefinierte Konfigurationen und das Feedback der Benutzer müssen ein fester Bestandteil des Testzyklus sein.
Ein guter QA-Prozess muss auch zuhören und schnell reagieren können.
Eine Software kann sehr wohl das tun, was man ihr aufgetragen hat, es aber in einem realen Kontext schlecht tun. Die Rolle des Testers besteht auch darin, sich vorzustellen, was schiefgehen könnte.
Nur weil ein Fall unwahrscheinlich ist, heißt das nicht, dass er es nicht wert ist, getestet zu werden. Die potenziellen Auswirkungen sollten die Testprioritäten ebenso leiten wie die Häufigkeit.
Die meisten größeren Bugs sind das Ergebnis mangelnder Kommunikation zwischen Teams, zwischen Entwicklern und Testern oder zwischen dem Unternehmen und seinen Nutzern.
Tools wie Mr Suricate ermöglichen es, No-Code-Testszenarien auf mächtige Weise zu automatisieren. Die Neugier des Testers, seine Fähigkeit, die richtigen Fragen zu stellen, bleibt dagegen unersetzlich.
Jeder entdeckte Fehler ist eine Lernchance. Das Dokumentieren von Ursachen, Auswirkungen und Lösungen hilft, das allgemeine Qualitätsniveau im Unternehmen zu erhöhen.
Bei Mr Suricate sehen wir jeden Tag, wie sehr die Automatisierung von No-Code-Tests den Entwicklungsteams hilft, Fehler schneller zu antizipieren, zu erkennen und zu beheben.
Wie Benjamin Franklin schon sagte: "A penny saved is a penny earned" (Ein eingesparter Penny ist ein verdienter Penny). In dieser Logik sind QA-Tests ein wesentlicher Bestandteil der Investitionsrendite von Unternehmen.
👉 Siehe den Artikel - ROI und Testautomatisierung: Welche Einsparungen und welcher Umsatz werden generiert?
Wenn Sie Ihren eigenen ROI berechnen und die Auswirkungen der Automatisierung auf Ihre Projekte messen möchten, bieten wir Ihnen eine kostenlose Schätzung an.