Die sieben Grundsätze des Softwaretestens

Das Testen von Software ist unerlässlich und sollte als Prozess während des gesamten Softwarelebenszyklus aktiv sein. Wichtige Begriffe, die hier zu nennen sind, ist die Fehlhandlung, der Fehlerzustand und die Fehlerwirkung.

Die Fehlhandlung ist eine menschliche Handlung, die einen Fehler in der Software auslöst. Die Handlung kann versehentlich, unwissentlich oder absichtlich durchgeführt werden [1].

Eine Fehlhandlung führt zu einem Fehlerzustand in der Software. Dies ist ein Zustand, in der die Anforderung oder Spezifikation der Software nicht eingehalten wird [1].

Die Fehlerwirkung beschreibt, dass das System Funktionen nicht mehr im spezifizierten Rahmen ausführt. Nicht jeder Fehler in der Software muss zu einer Fehlerwirkung führen. Fehlerwirkungen sind nicht nur das Resultat von Softwarefehlern, sondern können auch durch Umgebungsbedingungen hervorgerufen werden [1].

Die Folgen von Softwarefehlern können gravierend sein. Mögliche Folgen sind:

  • Personenschäden / Tod
  • Sachschäden
  • Imageverlust
  • Geldverlust

Natürlich haben nicht alle Softwarefehler solch drastische Folgen. Die genannten Beispiele sollen jedoch verdeutlichen, wie wichtig es ist, Software zu testen.

Nun stellt sich die Frage, wie man am besten die Testaktivitäten plant. Hier kann man die sieben Grundsätze des Softwaretestens als Leitlinie betrachten [2].

1. Grundsatz – „Testen zeigt die Anwesenheit von Fehlern“

Mit Softwaretests können Fehlerzustände ausfindig gemacht werden. Dadurch kann das System verbessert werden und die Wahrscheinlichkeit, dass unentdeckte Fehlerzustände auftreten, wird reduziert. Mit Softwaretests kann jedoch nicht bewiesen werden, dass das System fehlerfrei ist.

2. Grundsatz – „Vollständiges Testen ist nicht möglich“

Die heutigen Systeme wachsen stetig in ihrer Komplexität. Ein vollständiges Testen ist daher nicht möglich. Vollständiges Testen würde bedeuten alle möglichen Testfälle durchzuführen. Durch eine hohe Anzahl der Testfälle, steigt aber auch die benötigte Zeit und somit die Kosten, weshalb der Testaufwand immer unter Berücksichtigung des Risikos und der Priorität angepasst werden muss. Tests sind deshalb auch immer nur Stichproben.

3. Grundsatz – „Mit dem Testen sollte möglichst frühzeitig begonnen werden“

Je früher Fehlerzustände erkannt werden, desto günstiger ist deren Behebung. Deshalb sollten Testaktivitäten im Softwarelebenszyklus so früh wie möglich beginnen.

Die Kosten der Fehlerbehebung

10er-Regel der Fehlerkosten [3]

4. Grundsatz – „Häufung von Fehlern“

Ein Fehler kommt selten allein. Hat man bereits eine Fehlerwirkung nachgewiesen, kann es in diesem Modul zu weiteren Fehlern kommen. Die Anzahl der Testfälle sollte deshalb proportional an die zu erwartende Fehlerdichte der Module angepasst werden. Weicht die zu erwartende Fehlerdichte von der beobachteten Fehlerdichte ab, muss der Testaufwand flexibel angepasst werden können.

5. Grundsatz – „Wiederholungen haben keine Wirksamkeit“

Wiederholt man Testfälle, können keine neuen Erkenntnisse daraus gewonnen werden. Testfälle müssen deshalb regelmäßig überprüft und gepflegt werden. Auch neue Testfälle müssen, wenn nötig ergänzt werden.

6. Grundsatz – „Testen ist abhängig vom Umfeld“

Softwaretests sind abhängig von deren Umfeld. Das bedeutet, dass z. B. Medizingeräte anders getestet werden als Unterhaltungselektronik, da es sich meistens um sicherheitskritische Systeme handelt. Softwaretests sind also immer ans Umfeld und dessen Kontext anzupassen.

7. Grundsatz – „Trugschluss: Keine Fehler bedeuten ein brauchbares System“

Allein das Beheben aller Fehlerzustände führt noch lange nicht zu einem brauchbaren System. Die Benutzbarkeit und die Anforderungen des Kunden müssen zwingend berücksichtigt werden.

Fazit

Der Artikel soll zeigen, wie wichtig es ist, Software zu testen. Fangen Sie in einem Projekt so früh wie möglich an, die Testaktivitäten zu planen. Die 7 Grundsätze des Softwaretestens können Ihnen dabei helfen.

Falls Sie Fragen oder Anmerkungen haben oder Ihre Erfahrungen zum Thema teilen möchten, schreiben Sie gerne einen Kommentar oder melden Sie sich bei uns.

Quellen

[1] ISTQB®: ISTQB® Glossar-App multilingual https://glossary.istqb.org/de/search/ (Zugriff 07.01.2021)

[2] Spillner A., Linz A.: Basiswissen Softwaretest, dpunkt.verlag, 2010

[3] Steinhoff F., Pointner T.: FAQ Lean Management, Weka Media Gmbh & Co. Kg, 2018

Kontaktieren Sie uns!

Autor

  • Daniel Saffer

    Daniel Saffer war als Firmwareentwickler für die MEDtech Ingenieur GmbH tätig. Zu seinen Aufgabengebieten gehörte die Entwicklung der Embedded Software eines Nervenstimulationsgeräts, sowie eines Systems zur drahtlosen Steuerung eines C-Bogens. Eine weitere Aufgabe war die Erstellung von Risikobetrachtungen und Assessments aus Cybersecurity-Sicht für verschiedene Medizinprodukte.

Auch interessant:

Embedded Softwarearchitektur (ego)zentrisch: Datapool

Im vorangegangenen Blog-Post (Architektur in Feierlaune) habe ich eine SW-Architektur beschrieben, die hilft, die Kommunikation zwischen Komponenten zu vereinfachen. Einen Punkt habe ich in dem Zusammenhang allerdings noch nicht angesprochen: Die Datenhaltung. Wenn Daten zwischen Modulen hin- und hergereicht werden müssen, ginge das mit der althergebrachten Methode - tonnenweise getter-…
Getagged mit: , , , ,