Sieben Grundsätze des Softwaretestens

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

Testen kann zeigen, dass Fehlerzustände vorliegen, aber es kann nicht beweisen, dass es keine Fehlerzustände gibt. Testen reduziert die Wahrscheinlichkeit, dass noch unentdeckte Fehler in der Software vorhanden sind, aber auch wenn keine Fehlerzustände gefunden werden, ist Testen kein Beweis für Korrektheit.

Dies ist ein, auch für Stakeholder des Testens, sehr wichtiger Grundsatz, um keine falschen Erwartungen an das Testen zu verfolgen.

2. Vollständiges Testen ist nicht möglich

Ein vollständiger Test, bei dem alle möglichen Eingabewerte und deren Kombinationen unter Berücksichtigung aller unterschiedlichen Vorbedingungen ausgeführt werden, ist nicht durchführbar (mit Ausnahme von sehr trivialen Testobjekten). Anstatt zu versuchen, vollständig zu testen, sollten Risikoanalyse, Testverfahren und Prioritäten genutzt werden, um den Testaufwand zu konzentrieren.

Hier wird die Notwendigkeit einer durchdachten Testplanung deutlich, bei der Testaufwände u.a. auf Basis von identifizierten und bewerteten Risiken (Stichwort Risikobasiertes Testen) geplant werden.

3. Frühes Testen spart Zeit und Geld

Um Fehlerzustände früh zu finden, sollten sowohl statische [z. B. Dokumenten-Reviews] als auch dynamische Testaktivitäten [z. B. Komponententests oder Abnahmetests] so früh wie möglich im Softwareentwicklungslebenszyklus gestartet werden. Frühes Testen wird oft als Shift left bezeichnet. Frühes Testen im Softwareentwicklungslebenszyklus hilft dabei, kostenintensive Änderungen zu reduzieren oder sogar vollständig zu vermeiden.

Frühes Testen (und Testen generell) hilft einem Unternehmen dabei, wirtschaftlich erfolgreicher zu agieren!

4. Häufung von Fehlerzuständen

Eine kleine Anzahl von Modulen ist oft verantwortlich für die meisten der Fehlerwirkungen im Betrieb einer Software oder enthält die meisten Fehlerzustände, die während des Testens in der Phase vor Inbetriebnahme entdeckt werden. Befürchtete Anhäufungen von Fehlerzuständen und die tatsächlich beobachteten Anhäufungen von Fehlerzuständen im Test oder im Betrieb sind ein wichtiger Beitrag zur Risikoanalyse, die genutzt wird, um den Testaufwand zu konzentrieren (wie in Grundsatz 2 erwähnt).

Eine Aufgabe für die Teststeuerung ist es also, Fehlerdichten zu messen und beim risikobasierten Testen (also dem Testen auf Basis befürchteter Fehler und Fehlerfolgen) mit einzubeziehen.

5. Vorsicht vor dem Pestizid-Paradoxon

Wenn die gleichen Tests immer wieder wiederholt werden, finden diese Tests irgendwann keine neuen Fehlerzustände mehr. Um neue Fehlerzustände zu finden, müssen bestehende Tests und Testdaten möglicherweise verändert werden und neue Tests geschrieben werden (Tests sind nicht länger effektiv im Erkennen von Fehlerzuständen, so wie Pestizide nach einer Weile nicht mehr effektiv in der Vernichtung von Insekten sind). In manchen Fällen, wie dem automatisierten Regressionstest, hat das Pestizid-Paradoxon einen vermeintlich positiven Effekt, der in der relativ geringen Anzahl von Regressionsfehlern liegt.

Oder noch einmal anders erklärt: Pestizide werden auf Feldern versprüht, um die angebauten Pflanzen vor Schädlingen zu schützen. Je häufiger man Pestizide versprüht, desto geringer ist die Wirkung, da die Schädlinge resistent werden.  Überträgt man diese Metapher in die Welt des Software-Testens, stehen die Pestizide für die Testfälle und die Schädlinge für die Fehlerzustände in der Software („Bugs“). Wenn die gleichen Tests wiederholt ausgeführt werden, finden diese irgendwann keine neuen Fehlerzustände (Bugs) mehr. Um neue Fehlerzustände zu finden, müssen bestehende Tests und Testdaten möglicherweise verändert und neue Tests geschrieben werden.

Also sollten rechtzeitig in der Testplanung, inklusive der Testaufwandschätzung, die Tätigkeiten zur Veränderung bestehender Tests und Testdaten eingeplant werden. 

6. Testen ist kontextabhängig

Je nach Einsatzgebiet und Kontext ist das Testen anzupassen. Zum Beispiel wird sicherheitskritische industrielle Steuerungssoftware anders getestet als eine mobile E-Commerce-Applikation. Ein weiteres Beispiel ist das Testen in agilen Projekten, das anders durchgeführt wird als das Testen in einem Projekt mit sequenziellem Softwareentwicklungslebenszyklus.

Der Kontext hat u.a. Einfluss auf Softwareentwicklungslebenszyklus-Modelle, Risikobewertungen, Testaufwände, Testverfahren und Testumgebungen.

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

Einige Unternehmen erwarten, dass Tester alle denkbaren Tests durchführen und alle denkbaren Fehlerzustände finden können. Doch die Grundsätze 1 und 2 lehren uns, dass dies unmöglich ist. Außerdem ist es ein Trugschluss, dass allein das Finden und Beheben von vielen Fehlern [im Rahmen der Verifikation] zu einem erfolgreichen System führt.

Denn trotz gründlicher Tests aller spezifizierten Anforderungen [Verifikation] und das Beheben der gefundenen Fehler kann ein System erstellt werden, das eine geringwertigere Qualität hat als vergleichbare Systeme oder das die Bedürfnisse und Erwartungen des Nutzers nicht erfüllt. Bei der Validierung würde es somit durchfallen.

Hier wird deutlich, dass es nicht ausreichend ist, ein Produkt nur zu verifizieren. Wenn am Ende einer Produktentwicklung ein Produkt herauskommen soll, dass die Bedürfnisse und Erwartungen der Benutzer ausreichend erfüllen soll, ist auch eine Validierung erforderlich.

Siehe Myers 2011, Kaner 2002, Weinberg 2008 und Beizer 1990 für Beispiele dieser und anderer Grundsätze des Testens.