3-Sieben Grundsätze des Softwaretestens

1: Vollständiges Testen ist (i.d.R.) nicht möglich

2: Testen zeigt die Anwesenheit von Fehlerzuständen

3: Mit dem Testen frühzeitig beginnen

4: Fehler treten oft gehäuft auf

5: Wiederholungen haben keine Wirksamkeit

6: Tests sind abhängig vom jeweiligen Umfeld

7: Trugschluss: Keine Fehler gefunden → brauchbares System

Hierzu müssten alle denkbaren Konstellationen und Kombinationen möglicher Situationen und Rahmenbedingungen getestet werden. Dies wäre weder zeitlich noch finanziell machbar → Es wird immer nur ein Teil der denkbaren Testfälle berücksichtigt.

• Abweichungen während des Testens zeigen Fehlerwirkungen an, die von Fehlerzuständen verursacht werden.

• Erfolgreiche Tests beweisen nicht die Abwesenheit von Fehlerzuständen oder gar Fehlerfreiheit (vgl. Grundsatz 7)

• Fehler können z.B. maskiert sein

• Die frühe Fehlerbehebung ist deutlich günstiger als die späte.

• Ideal: Fehlerbehebung vor Fehlerhandlung

• „10er-Regel“

• Oft sind wenige Module für viele Fehlerzustände und -wirkungen verantwortlich

• Tests bei unverändertem Testobjekt (identische Version, identische Umgebung etc.) versprechen meist keinen zusätzlichen Erkenntnisgewinn.

• Ggf. kann sich eine Testautomatisierung lohnen.

• Einsatzgebiet und -risiken beeinflussen, wie ähnlich Test- und Produktivumgebung sein sollten.

• Je stärker die Testumgebung von der Produktivumgebung abweicht, desto geringer ist die Aussagekraft der Testergebnisse.

• Selbst in produktionsnahen Umgebungen kann sich eine Software anders verhalten als in einem Produktivsystem.

• Die wichtigsten Fehler sollen durch Testen gefunden werden, alle zu finden ist utopisch.

• Vorstellungen und Erwartungen der Nutzer können trotzdem vom (spezifizierten) Leistungsumfang abweichen → frühzeitige Einbindung der Nutzer erforderlich.

• Qualität muss hineinspezifiziert werden, nicht hineingetestet.