Definition

Immer, wenn Probleme mit einem Produkt auftauchen, wird der Ruf nach "dem Testen" laut. Das muss man mehr, besser, früher oder anders testen. Nur was heißt überhaupt "Testen"? Dieser Artikel soll sich dem Begriff nähern.

Unter "Testen" versteht man immer "Vergleichen! Ein Test ist nichts anderes als der Vergleich eines Zustandes des Testobjektes mit dem gewünschten bzw. verlangten Zustand. D.h. auf der anderen Seite, dass Debugging, also das schrittweise Abarbeiten eines Quellcodes innerhalb einer Entwicklungsumgebung, eben nicht "Testen" ist.

Ziele beim Testen

Oftmals hört man, dass das Ziel beim Testen ist, die Fehlerfreiheit eines Systems festzustellen. Leider ist das, auch nicht näherungsweise, möglich! Moderne Softwaresysteme haben eine quasi unendliche Zahl an Pfaden durch das System, die mit dutzenden unterschiedlicher Parametern durchlaufen werden können. Ein Schuh wird daraus, wenn man sich von der anderen Seite nähert. Ein Ziel beim Testen ist also nicht das Feststellen der Abwesenheit von Fehler (s.o.), sondern das Finden von Fehlern.

Ein paar Aussagen zu diesem Thema sollen hier noch stichpunktartig erfasst werden:

• Testen kann nicht garantieren, dass eine Software fehlerfrei ist.
• Man kann nicht alles testen.
• Man kann ein schlechtes Produkt nicht "gut"-testen.
• Jedes nicht-triviale Softwaresytem hat Fehler.
• Findet man einen Fehler in einer Software, ist die Wahrscheinlichkeit nahe 100%, dass ein weiterer Fehler in der Software ist.

 Weitere Ziele sind:

• Bestimmung der Produktqualität
• Stärkung des Vertrauens in das Produkt
• Analyse des Produkts und der Dokumente, um Fehlerwirkungen vorzubeugen

Dies sind Testziele, die eigentlich gesondert besprochen werden müssen. Dies würde aber diesen Artikel sprengen.

Testarten

Eine große Verwirrung herrscht nach wie vor bei den unterschiedlichen Testarten. Man kennt Lasttest, Unittest, Entwicklertest, Systemtests, Integrationstest, Abnmahmetest und vieles mehr. Um sich in den unterschiedlichsten Bezeichnungen nicht zu verirren, kann man die Testarten einfach in Kategorien einzuteilen.

1. Testziel: Benennung einer Testart nach dem Zweck des Tests (z.B. Lasttest)
2. Testmethode: Der Test wird nach der angewandten Methode benannt, die zur Durchführung oder Spezifikation des Tests angewandt wird (z.B. Geschäftsprozess orientierter Test)
3. Testobjekt: Die Benennung erfolgt nach dem zu testenden Objekt (z.B. GUI-Test, Unittest)
4. Teststufe: Der Test wird nach der Stufe des vorliegenden Vorgehensmodells benannt (z.B. Integrationstest)
5. Testperson: Die den Test durchführende Person benennt den Test (z.B. Entwicklertest)
6. Testumfang: Tests werden nach der Menge der durchgeführten Tests im Vergleich zu den zur Verfügung stehenden Tests benannt. (z.B. Regressionstest, Volltest)

Wie man sieht versteckt sich hinter nicht hinter jedem Begriff eine neue Testart, sondern je nach Zielsetzung desjenigen, der einen Begriff verwendet, wird ein Aspekt in den Vordergrund gerückt. 

Woher wir wissen, was wir testen

Mit welcher Begründung testen wir eigentlich eine Funktion einer Software? Nun, die Funktion ist halt in der Software vorhanden und sie ist deshalb vorhanden, weil ein Entwickler sie implementiert hat. Das wiederum hat er nur deshalb getan, weil er in der Spezifikation, den Anforderungen, dem Pflichtenheft davon gelesen hat. (Meinung des Autors: Ein Entwickler, der seiner Kreativität freien Lauf lässt und Funktionen entwickelt, die nicht verlangt und schon gar nicht bezahlt werden, gehört abgemahnt.) Also ist ein wichtiges Ziel, dass alle Anforderungen mit mindestens einem Testfall abgedeckt sind.

Aus dieser Forderung ergeben sich einige interessante Konsequenzen, die zu qualitativ besseren Produkten führen, wenn man sie ernsthaft befolgt:

1)      Es gibt kein, oder nur ein vages Pflichtenheft
Abhilfe: mit dem Kunden abstimmen! Wenn eine Abstimmung nicht möglich ist, z.B. weil sich einige beteiligte Parteien verweigern oder sich nicht festlegen wollen, muss die Testdurchführung so sauber dokumentiert werden, dass sie quasi als Ist-Aufnahme des Softwarestandes betrachtet werden kann.

2)      Fehlende und / oder unklare Anforderungen sind in der Regel ein Zeichen dafür, dass der Kunde selbst nicht genau weiß, was er will. Das kann im weiteren Verlauf eines Projektes zu erheblichen Mehraufwand führen (Nachpflegen und Umsetzung der sich dann stark ändernden Kundenanforderungen)

3)      Aussagen über Testabdeckung, Reifegrad, Prioritäten, Termine und Fertigstellung usw. werden möglich.

4)      Wenn man durch nichts in der Welt an die Requirements kommt, bleibt nur noch der Zugang des explorativen Testens, d.h. vereinfacht ausgedrückt: testen durch ausprobieren. Das ist aber ein Kunst für sich und wird gegebenenfalls in einem weiteren Artikel behandelt.