Nur Bananen sollten Bananen sein - „Bananensoftware“ reift beim Kunden…
Jeder kann betroffen sein
Es gibt einige Fälle, fehlerhafter Software, die durchaus erzählenswert sind. Weil sie besonders teuer, gefährlich oder enttäuschend waren. Außerdem können sie „jeden treffen“, wie beispielsweise bei einem Fehler der automatisierten Preisanpassung auf Amazon. 2014 wurden hier hunderte Waren für 0,01 £ bzw. € verkauft. Ebenso automatisiert ist der Versand abgelaufen. Viele Händler fürchteten Konkurs, Kunden wurden enttäuscht und Amazon selbst hat Korrekturen und Beschwerden zu managen.
Solche automatischen Preisanpassungen sind üblich, und werden in der Regel auch softwareseitig „abgesichert“ also mit Grenzwerten versehen oder unabhängig gegengeprüft. Fehlerfreiheit ist hierdurch allerdings immer noch nicht garantiert.
Auch indirekt lauert Gefahr
Auch bei weniger offensichtlichen aber mindestens so schwerwiegenden Gelegenheiten wie der fehlerhaften Vertragsabwicklung von Healthcare.gov (Stichwort: „Obamacare“) gab es Software-Fehler. Hier wurden zwar 400 Mio. Dollar in die Hand genommen, aber das damals veraltete Portal stürzte bei mehr als 35000 Besuchern ab; erfasste keine Sozialversicherungsnummern; berechnete Zuschüsse falsch; ordnete Familienstände falsch zu usw.
Unzufriedenheit der User ist hier, wo es um die Krankenversicherung und damit um medizinische (nicht-)Versorgung geht, nicht das zentrale Problem. Letztlich ist Obamacare gescheitert. Ob gut oder schlecht, soll an dieser Stelle nicht gewertet werden, aber für die Planung, Entwicklung und Umsetzung sind viele erhebliche Aufwände betrieben worden. Für entsprechende Softwaretests scheinbar nicht.
Software testen ist teuer – nicht testen teurer!
Erhebliche Aufwände werden auch bei Industrie, Militär und Raumfahrt betrieben. Ob sensorische Luftüberwachung Sonnenstrahlen bzw. -reflexionen fehlinterpretiert, Kampfjets nicht abheben können oder „neue“ Airbus-Flieger die Triebwerke abschalten – je komplexer das System, desto vielfältiger werden die Fehlerquellen und entsprechend mehr Fehler „schleichen sich ein“. Alle hier genannten Beispiele werden bereits eine Qualitätssicherung auf die jeweiligen Projekte angesetzt haben. Trotzdem (!) lassen sich Fehler in schwindelerregendem Schwergewicht nicht verhindern, möchte man sich nicht ausmalen, wie solche Projekte ohne entsprechende Tests ausgehen könnten.
- Laut Michael Fagan reduzieren sich die aus Fehlern resultierenden Kosten bei frühzeitiger Entdeckung um 10-100%
- „Im Schnitt“ finden sich 10 Bugs in 1000 Code-Zeilen, natürlich abhängig von Komplexität, Entwickler-Erfahrung, Zielsetzung („kleines Programm“ oder Raumfahrt-Software) usw.
- Microsoft beschäftigt 50% Entwickler und 50% Tester (trotzdem werden Bug- & Hotfixes veröffentlicht – selbst bei solch hohem Testaufwand bleiben Fehler unentdeckt)
Auch wenn Haftungsfragen oft durch Versicherungen, Nutzungs- und Geschäftsbedingungen geklärt sind oder werden, bleiben im schlimmsten Fall Personenschäden, Datenverlust, negative Schlagzeilen, Unzufriedenheit und vieles mehr ungeklärt.
Testen bei netzkern
Über solche Themen haben wir im Rahmen eines Quality-Assurance-Brainstorming-Days als Einstieg gesprochen, um die große Relevanz für ausreichende Tests im Fokus zu haben. So haben wir uns gegenseitig überrascht, an wie vielen, mitunter sehr kritischen, Stellen unzureichende Softwaretests schlimme Konsequenzen nach sich zogen und ziehen.
Eine TÜV-Prüfung oder ein entsprechendes Siegel gibt es bei Drohnen oder Küchengeräten, die mit entsprechender Software betrieben werden. Bei einem Internetportal mit Kundendaten oder Applikationen auf Smartphones kann man sich nicht auf solch eine Prüfung „verlassen“.
Für zufriedene Kunden - und deren Kunden – möchten und müssen wir gewährleisten, dass Sicherheit, Funktionalität und Design getestet, optimiert, verbessert, wieder getestet…. und damit zeitgemäß, möglichst fehlerfrei und gleichzeitig budgetschonend umgesetzt wird. Nur so kann verhindert werden, dass „Bananensoftware“ überhand nimmt.
Quellen:
https://en.wikipedia.org/wiki/Fagan_inspection