Natürlich sind wir bei Testbirds ein bisschen voreingenommen, was die Wichtigkeit von Testing anbelangt. Wir wissen, dass gute, umfassende und fortlaufende Tests dazu beitragen, die Qualität, Zuverlässigkeit, Sicherheit und Leistung von Produkten sicherzustellen.
Für alle, die sicherstellen wollen, dass ihr Produkt nicht kaputt ist, nicht abstürzt oder das Gerät ihres Benutzers beschädigt, dass ihre Software fehlerfrei ist, wie vorgesehen funktioniert, die Customer Journey des Benutzers nicht ruiniert wird und nicht für Datendiebstahl o.ä. missbraucht werden kann – ist Testen einfach unerlässlich.
Was noch dazu kommt: umfassendes Testen hilft zusätzliche Kosten zu vermeiden, Risiken zu minimieren, Prozesse zu optimieren und das Vertrauen der Kunden zu gewinnen.
Wir wollen heute ein paar Fälle betrachten, in denen so einiges schiefgelaufen ist. Sei es durch fehlende, ungenaue oder unvollständige Tests, interne Vorgaben, Shareholder, Kosten etc. Es gibt viele Situationen, in denen die Durchführung eines Tests so einige Kopfschmerzen (und sogar Tragödien) erspart hätte.
Testen oder nicht testen?
Das steht außer Frage: Produkte müssen getestet werden.
Schauen wir uns ein etwas abstraktes Beispiel an: Rohrkröten in Australien. Im Jahr 1935 wurden sie eingesetzt, um Käfer auf Zuckerrohrplantagen zu bekämpfen. Insgesamt wurden 2400 Kröten freigelassen, ohne dass überhaupt getestet wurde, ob sie die Zuckerrohrkäfer fressen oder am Ende die Umwelt schädigen könnten. Das Problem? Sie brüten viel, haben keine einheimischen Feinde, setzen ein Gift frei und … hatten letztendlich keinen Einfluss auf die Zuckerrohrkäfer-Population. Sie werden mittlerweile als wilde Spezies eingestuft und vergrößern ihre Reichweite jedes Jahr um mehr als 40 Meilen.
Eine anderer Fall: Der Autohersteller Tesla investiert mit seiner „Autopilot“-Funktion stark in automatisiertes Fahren. Seit der Veröffentlichung im Jahr 2015 gab es jedoch bereits zahlreiche Todesfälle. Während ihre Software- und Hardwaretests sicherlich robust sind, scheint der Name nicht getestet worden zu sein. Denn die Autos sind nicht selbstfahrend, sie automatisieren nur einige Fahraufgaben. Der Fahrer sollte immer aufmerksam sein. Das Wort „Autopilot“ impliziert jedoch volle Autonomie. Dieser Irrtum führt dazu, dass der Fahrer bei mindestens einem tödlichen Unfall nicht auf dem Fahrersitz saß und bei einem anderen ein Spiel auf seinem Telefon spielte. Würde ein einfacher Test zur „impliziten Bedeutung“ des Wortes zeigen, dass die Fahrer es als „vollautomatisiert“ ansehen? Wenn ja, hätte eine einfache Namensänderung Leben retten können.
Leider ist für einige Unternehmen, unabhängig davon, ob sie testen oder nicht, oder welche Ergebnisse diese Tests liefern, alles eine Frage des Kosten-Nutzen-Verhältnisses.
Was passiert, wenn Test-Ergebnisse ignoriert werden
Selbst wenn Tests richtig durchgeführt werden, können Probleme auftreten.
Nehmen wir den Ford Pinto. Entwickelt wurde er, um gegen japanische und deutsche Kleinwagen zu konkurrieren. Der Pinto ging mit einem kürzeren Design- / Entwicklungszeitplan als üblich in die Produktion. Der Prozess umfasste die Durchführung von Crashtests an Prototypen und der endgültigen Konstruktion, um sicherzustellen, dass sie den aktuellen Sicherheitsstandards entsprechen. Alle Crashtests am Heck des Autos schlugen fehl, was zu geplatzten Kraftstofftanks und auslaufendem Kraftstoff führte.
Die Tests zeigten eindeutig ein Problem. Wie William Shaw und Vincent Barry in ihrem Buch Moral Issues in Business feststellten „wusste Ford, dass der Pinto selbst bei Kollisionen mit niedriger Geschwindigkeit eine ernsthafte Brandgefahr darstellte, wenn er von hinten angefahren wird.“
Das Management von Ford genehmigte jedoch den Bau und der Pinto wurde ab 1971 an die Öffentlichkeit verkauft.
Auch hier ging es nur um die Kosten-Nutzen-Analyse.
Denn Ford berechnete, dass die Behebung des Konstruktionsfehlers 11 US-Dollar pro Auto kosten würde – Gesamtkosten von 137 Millionen US-Dollar. Die Auszahlungen an die durch solche Kollisionen Getöteten oder Verletzten wurden hingegen auf etwa 49 Millionen US-Dollar geschätzt. Die Schätzungen variieren, aber es ist klar, dass mindestens 27 Menschen gestorben sind.
Der Test hat funktioniert. Aber Ford hat die Test-Ergebnisse nicht beachtet und den Gewinn über die Sicherheit gestellt.
Ähnlich war es auch bei der NASA, als es um das fehlerhafte Design der O-Ringe des Space Shuttle Challenger ging. Alle O-Ringe wurden Jahre vor der Katastrophe getestet und zeigten, dass sie unter bestimmten Bedingungen (insbesondere bei Kälte – wie am Tag des unglücklichen Starts) ihre Funktionalität verloren.
Wenn das Produkt nicht wie gewünscht funktioniert
Beim Testen geht es auch darum zu prüfen, dass das, was Sie entworfen haben, auch letztendlich vom Endnutzer verwendet werden kann. Es gibt Fälle, in denen intern sehr gut und umfangreich getestet wurde, alle Fehler behoben wurden und alles einwandfrei funktioniert hat … nach der Veröffentlichung ist jedoch alles schiefgelaufen.
Dies geschah mit Bungies Videospiel Destiny 2 und seiner (damals) neuesten Erweiterung “Season of the Forge”.
Kurzer Zwischen-Exkurs: Testfehler in der Gaming-Industrie gibt es wie Sand am Meer:
2007 veröffentlichten RedOctane, die Macher von Guitar Hero 2, einen Patch für die Xbox 360. Das Problem? Es hat viele Konsolen zum Absturz gebracht und für eine beträchtliche Anzahl an Kunden ihre Xbox dauerhaft ruiniert.
Oder: Im Jahr 2020 veröffentlichte CD Project Red ihr mit Spannung erwartetes Cyberpunk 2077. Das Problem? Systemabstürze, mehrere Fehler, Skriptprobleme, Grafik- und Audioprobleme, mindere Leistung auf PCs, die Liste ist umfangreich. Das Spiel wurde sogar aus dem Playstation Store entfernt und gilt als einer der katastrophalsten Starts in der modernen Gaming Geschichte.
Es sind viel zu viele Fälle, um sie alle aufzuzählen. Sie können hier klicken, um einen interessanten Überblick über einige der schlechtesten Markteinführungen der Branche zu erhalten. Wir haben außerdem einen Blog-Artikel über die Herausforderungen in der Gaming Branche geschrieben: lesen Sie unserern Artikel über die Diversität in der Gaming-Branche.
Zurück zu Destiny und dem Fakt, dass es nicht immer ein Codierungsproblem ist, dass den Schaden anrichtet.
Destiny ist ein reines Online-Spiel, das vier Season Passes pro Jahr verkauft, um den Inhalt „frisch“ zu halten. In der “Season of the Forge” mussten die Spieler verschiedene Schmieden (Forge=Schmiede) freispielen, um neue Waffen und Rüstungen zu verdienen. Der Höhepunkt der Saison war die “Freischaltung” der vierten und letzten, Bergusia-Schmiede, die das Lösen eines komplexen siebenschichtigen Puzzles bedeutete. Ein einzelner Spieler konnte die Schmiede aber erst freispielen, wenn das Rätsel auch von den anderen Spielern im Team gelöst wurde. Klingt nach einer großartigen Idee, um Teamplay zu fördern und Interesse und Engagement zu fördern. Richtig?
Ja, wenn das Rätsel nur lösbar gewesen wäre.
Das Problem war, dass das Rätsel viel zu kompliziert war und überhaupt nichts mehr mit dem Spiel zu tun hatte: man musste dafür ein ziemlich obskures Victor-Hugo-Gedicht kennen, mit der Melodie von Frère Jacques vertraut sein und wissen, wie die Edelsteine auf dem Griff von Karls Schwert, Joyeuse, arrangiert wurden (Sie können sich die Lösung zu diesem Abschnitt hier ansehen – super einfach, oder?).
Wer könnte das Rätsel nicht mal eben schnell lösen? Nun, niemand, wie sich herausstellte. Die Spieler arbeiteten über 24 Stunden lang ohne Glück auf der siebten Ebene.
Da merkte auch Bungie den Fehler und schaltete das Level für die Spieler frei. Zwei Tage später gaben sie sogar zu, dass ein Textabschnitt aus dem Rätsel „unsachgemäß entfernt“ worden war … was eine Lösung auf jeden Fall unmöglich machte.
Es besteht kein Zweifel, dass das Puzzle intern getestet wurde, aber man kann davon ausghen, dass nur getestet wurde, dass “X zu Y führt” und nicht, ob es möglich ist als externe Person das Rätsel überhaupt zu lösen.
Das ist ein perfektes Beispiel dafür, dass beim Testen mit externen Testern Probleme gefunden werden können, die man selbst gar nicht sehen kann.
Wenn die „einfache Lösung“ alles kaputt macht
Kein Unternehmen tut gut daran, Millionen von Kundenaccounts zu sperren. Besonders wenn es um Bankkonten geht.
Genau das hat die britische TSB Bank 2018 bei einer IT-Migration auf ihre neue Bankenplattform getan.
TSB begann an einem Freitagnachmittag mit der Migration aller Datensätze und Konten und informierte die Kunden, dass sie bis Sonntag 18:00 Uhr auf nichts zugreifen können. Nach 18 Uhr wurde klar, dass einiges schiefgelaufen war.
Personen konnten sich nicht bei ihren Konten anmelden. Andere erhielten Informationen von den Konten anderer Personen. Einige erhielten ungenaue Belastungen und Gutschriften. Zwei Tage später hatten rund 1,9 Millionen Kunden keinen Zugang, und dies blieb in den nächsten Wochen so. Einige Kunden konnten bis zu einem Monat nach dem Upgrade nicht auf ihre Konten zugreifen.
Am Ende kostete dieser Fehler die Bank 461 Millionen Dollar und 80.000 Kunden.
Eine Untersuchung ergab, dass der massive Ausfall teilweise darauf zurückzuführen ist, dass nur eines der beiden neuen Rechenzentren getestet wurde (die anderen Gründe waren Managemententscheidungen). Darüber hinaus erklärte ein Bericht von IBM, dass die Tests, wie von Reuters festgestellt, “relativ schnell waren, keine ausreichenden Beweise für die Systemkapazität erbrachten und nicht die erforderlichen Kriterien angewendet wurden, um zu entscheiden, ob das System standhalten kann”.
Bei all den damit verbundenen Datenschutzproblemen, dem Geld, dem Betrugspotenzial, dem Rufschaden und vielem mehr, scheint es undenkbar, dass keine entsprechenden Tests durchgeführt wurden und dass die Geschäftsleitung dies nicht mit mehr Nachdruck gefordert hatte.
Das ist kein Einzelfall. Im Jahr 2012 wollte National Grid USA ihre Backoffice-Prozesse auf ein neues ERP-System von SAP umsiedeln.
Alles, was bei der Implementierung schief gehen konnte, ging schief es und kostete National Grid schließlich fast 1 Milliarde Dollar. Es besteht kein Zweifel, dass es auch hier keine angemessene Projektsteuerung, Risikominimierung oder Kontrolle gab, und später verklagte National Grid USA seinen Systemintegrator Wipro vor Gericht. Eine ihrer Behauptungen war, dass Wipro es versäumte, Probleme angemessen zu testen, zu erkennen und zu informieren. Mehr Infos darüber können Sie hier lesen.
Wenn Ihr Test nicht startet
Wenn Sie an die NASA denken, wissen Sie, dass Tests eine hohe Priorität haben müssen. Bei Hunderten von Millionen, die für einen bestimmten Start auf dem Spiel stehen, darf nicht mal der kleinste Fehler passieren.
Aber es sind viele passiert (nicht zu vergessen, die Challenger-Katastrophe).
1990 wurde das 1,5 Milliarden Dollar teure Hubble-Weltraumteleskop gestartet. Nachdem verschwommene Bilder zur Erde zurückgekehrt waren, war klar, dass es ein Problem gab. Es wurde festgestellt, dass ein Gerät während der Herstellung falsch kalibiert wurde und eine Aberration von einem Millimeter (0,039 Zoll) auf dem Spiegel des Teleskops verursachte. Wie in einem New Scientist-Artikel aus dem Jahr 1990 erwähnt, ignorierte der Hersteller „Warnungen über das Problem, das von einem gröberen Testinstrument erkannt wurde“. Es wurde zwar der Haupt- und der Sekundärspiegel getrennt getestet, jedoch „hat niemand das komplette Teleskop vor dem Start getestet“.
Sicherlich hatte die NASA nach einem so kleinen, aber teuren Fehler ihre Lektion über das Testen gelernt?
NÖ! 1998 wurde die 125 Millionen Dollar teure Raumsonde Mars Climate Orbiter nach einem einfachen Navigationsfehler zerstört. Flugbefehle wurden in englischen, nicht metrischen Einheiten gesendet, was dazu führte, dass das Fahrzeug zu nahe an der Marsatmosphäre flog und sich auflöste. Dies wirft die Frage auf: warum wurden vor und während des Fluges keine Testbefehle gesendet, um vorherzusagen, was mit dem Fahrzeug passieren würde?
Früh testen, oft testen, dann nochmal testen
Heutige Softwarelösungen können außerordentlich komplex sein. Oft sind viele verschiedene Arten von Tests erforderlich – sowohl automatisierte als auch manuelle – um sicherzustellen, dass alle potenziellen Probleme gefunden und behoben werden.
Der Testprozess sollte so schnell wie möglich begonnen und in jeder Entwicklungsphase fortgesetzt werden. Es ist viel besser, ein Problem lange vor dem Start zu lösen, als sich danach darum kümmern zu müssen.
Sobald der Schaden angerichtet ist, ist es nämlich schon zu spät.
Das Gute an den oben genannten Fehlern ist, dass wir daraus lernen können. Detaillierte und effektive Tests können Ihr Produkt, Ihr Unternehmen und Ihre Kunden schützen. Und darum ist Testen nicht nur wichtig, sondern unerlässlich.
