Sieben Grundsätze des Softwaretestens

1. Testen zeigt das Vorhandensein, nicht die Abwesenheit von Fehlerzuständen

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

Vollständigkeit ist ein schönes Ziel. Aber bei allen möglichen Eingabewerten und deren Kombinationen unter Berücksichtigung aller unterschiedlichen Vorbedingungen ist das Ziel nicht erreichbar  - 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. Fehlerzustände treten gehäuft auf

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. Tests nutzen sich ab (früher Pestizid-Paradoxon)

Wenn dieselben Tests viele Male wiederholt werden, werden sie bei der Erkennung neuer Fehlerzustände zunehmend ineffektiv. Um diesen Effekt zu überwinden, müssen bestehende Tests und Testdaten möglicherweise modifiziert und neue Tests geschrieben werden. Wenn immer dieselben Wege gegangen werden, kann kaum noch neues entdeckt werden.

In einigen Fällen kann die Wiederholung der gleichen Tests jedoch zu einem positiven Ergebnis führen, z. B. bei automatisierten Regressionstests.

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.

Quelle: ISTQB® Certified Tester Foundation Level Lehrplan V 4.0

Um Software erfolgreich zu testen, ist eine gründliche Planung, Umsetzung und Dokumentation von entscheidender Bedeutung. Ebenso muss das Testteams flexibel sein und sich an sich ändernde Anforderungen und Bedingungen anpassen können, insbesondere in agilen Entwicklungsumgebungen.
Durch unsere optimal ausgerichteten Outsourcing Dienstleistungen, ist es unseren Kunden möglich, ohne Qualitätsverlust Kosten und Zeit zu sparen. Erfahren Sie, wie Sie durch unsere individuellen Ansätze und standortnahen Teams Ihre Softwaretestprozesse optimieren können.

Anfrage Softwaretest Dienstleistungen