Wer braucht schon Testing?

Fast jeder hatte schon einmal Berührungspunkte mit Softwaresystemen, welche nicht ordnungsgemäß oder wie erwartet funktioniert haben. Dabei sind diese im heutigen Leben kaum wegzudenken: von Fachanwendungen, welche z.B. im Bankwesen Anwendung finden, bis hin zu alltäglichen Produkten wie Ampelanlagen oder Autos lassen sich Softwaresysteme finden. Software, die nicht korrekt arbeitet, kann zu vielfältigen Problemen wie Geld-, Zeit- oder Imageverlust führen. Systeme, welche im direkten Zusammenhang mit dem menschlichen Leben stehen, können durch Fehler sogar Verletzungen oder Tod zur Folge haben. Testen ist ein Mittel, die Qualität von Software zu beurteilen und das Risiko einer Fehlerwirkung im Betrieb zu reduzieren. 

Die Einschätzung, dass Testen ausschließlich darin besteht, Tests auszuführen, sprich die Software zu verwenden und die Ergebnisse zu prüfen, ist ein weitverbreiteter Irrtum. Softwaretesten ist ein Prozess, welcher darüber hinaus Aktivitäten wie Planung, Analyse, Entwurf sowie die Realisierung von Tests beinhaltet. Ebenfalls ist das Berichten über Testfortschritt und -ergebnis und die Beurteilung der Qualität eines Testobjekts von äußerster Wichtigkeit. 

Es existieren die „7 Grundsätze des Testens“, welche über mehrere Jahrzehnte hinweg entwickelt wurden und welche als generelle Leitlinien für das Testen gelten: 

1. Testen zeigt die Anwesenheit von Fehlerzuständen, nicht deren Abwesenheit

2. Vollständiges Testen ist nicht möglich 

3. Frühes Testen spart Zeit und Geld 

4. Häufung von Fehlerzuständen 

5. Vorsicht vor dem Pestizid-Paradoxon 

6. Testen ist kontextabhängig 

7. Trugschluss: „Keine Fehler“ bedeutet ein brauchbares System 

Mit der Einhaltung dieser Grundsätze kann das Testen auf einem gewissen Niveau gehalten und Fehler beim Testen vermieden werden. Was kann schon passieren, wenn man doch zu wenig testet? 

Mariner-1-Rakete 

1962 brach die Mariner-1-Rakete zu einer Mission zur Venus auf – und triftete kurz nach dem Start von ihrer geplanten Laufbahn ab. Die Mariner 1 musste zerstört werden, über 18 Millionen US-Dollar wurden in den Sand gesetzt. 

Grund: 
Ein Programmierer übertrug eine Formel nicht korrekt von einem handgeschriebenen Dokument in den Quellcode. 

Der Schokoladenberg 

Das ERP-System des britischen Schokoladenherstellers Cadbury verursachte durch einen Bug eine Überproduktion von Schokoladenriegeln, die nicht abgesetzt werden konnten. 48 Millionen Euro soll der Bug dem Unternehmen gekostet haben. 

Bei solchen IT-Katastrophen dürften sich die meisten von uns erleichtert zurücklehnen und über die belanglosen Bugs im eigenen System lächeln. Tatsächlich zeigen Untersuchungen, wie der von der Standish Group veröffentlicht Chaosreport, dass nur etwa ein Drittel der IT-Projekte erfolgreich, im Rahmen des festgelegten Budgets und Zeitplans abgeschlossen wurde und dabei auch noch die Anforderungen erfüllte.