Nach der Durchführung der Tests geht es darum zu entscheiden, ob der Test fehlgeschlagen ist oder nicht. Dahinter steckt die entscheidende Frage: liegt ein Fehler vor, so dass die Entwickler nachbessern müssen, oder liegt kein Fehler vor, so dass die Projektleitung sich entspannt zurücklehnen kann.
In der binären Logik gibt es folgende grundsätzlichen Möglickheiten
| |
Fehler gefunden |
Fehlern nicht gefunden |
| Fehler vorhanden |
echter Fehler |
false negativ |
| Fehler nicht vorhanden |
false positiv |
echt gut |
echt gut
In dem Fall sind alle zufrieden. Bei einer ausgereiften Software sollte das der Normalfall sein.
echter Fehler
Bei einem echten Fehler liegt ein konkretes Optimierungspotential vor, die Entwickler können aufgrund dieses Hinweises die Software verbessern.
false positiv
Hier hat der Test irrtümlicherweise einen Fehler festgestellt, der eigentlich keiner war. Eventuell liegt hier ein Durchführungsfehler vor, ansonsten wird der Fehler genauso gemeldet wie jeder anderer Fehler auch. Das führt zu Diskussion mit den Entwicklern. Im Optimalfall führt das zu einer Klärung und alle sind schlauer, oder die Entwickler sind genervt, dass sie unbegründet aus ihrer konzentrierten Arbeit gerissen worden sind, vor allem, wenn es immer wieder dieselben falschen Fehler sind.
false negativ
In diesem Fall wird fälschlicherweise ein vorhandener Fehler übersehen. Das führt zu keinen Diskussionen, alle sind glücklich bis dann irgendwann der Fehler in der Produktion auffällt. Nicht nur dumm-gelaufen, dadurch kann ein realer Schaden oder zumindest eine Reputationseinbuße der Firma und wenn das zu häufig vorkommt, ist der Arbeitgeber nicht mehr in der Lage, die Löhne zu zahlen - also ganz böser Fehler.
Für diesen Fehler ist man als Tester im Grunde blind. Wenn ein solcher Fehler einmal auffällt beispielsweise in einem Review, muss dieser unbedingt festgehalten werden und schleunigst behoben.
warum Fehler machen
Grundsätzlich sollte man davon ausgehen, dass niemand absichtlich Fehler macht. Dennoch passieren Fehler und das kann verschiedene Gründe haben:
technischer Fehler
Ein technischer Fehler liegt vor, wenn die eingesetzte Technik (Datenbanken, Netzwerkverbindungen, Sicherheitslücken) Fehler hat. Da eine etablierte Technik vielfach von vielen eingesetzt wird, darf diese Technik als stabil angesehen werden.
- Sicherheitslücken werden immer wieder gefunden, während es Betriebs werden diese durch Patches geschlossen
- Speicher- oder Rechnerlimits: die Grenzen werden beim Stresstest ermittelt, während des Betriebs wird darauf geachtet, dass die Anwendung nicht an die Grenzen stößt
- Pannen wie Stromausfall werden auch während des Betriebes weitgehend vermieden, wenn es dennoch passiert, sollte es hierfür Notfallpläne geben
Flüchtigkeitsfehler
Flüchtigkeitsfehler unterlaufen jedem, die meisten dieser Fehler werden bei gründlichem Korrekturlesen gefunden.
- orthographische Schreibfehler in der Spezifikation sind irrelevant, wenn jeder das richtige liest
- syntaktische Fehler werden vom Compiler sofort erkannt und damit sofort gefixt
- fehlerhafte Variablenzuordnungen: das kann durch einen Unittest oder späteren funktionalen Test aufgedeckt werden, wenn sie offensichtlich falsche Werte erhalten
Überforderung
Verständnisfehler
das Richtige richtig testen
Fehler erkennen
Um Fehler zu erkennen, hängt im wesentlichen vom Verständnis des Testgegenstandes ab.
Spezifikation
Während der Spezifikation hat der Spezifizierer das Thema frisch bearbeitet und damit das beste Verständnis. Dennoch kann es zu
und hat die konkrete Anforderung im Blick. Hier kann direkt die zentrale Erwartung formuliert und ggf. spezifiziert werden.
(Testfall-)Spezifikation
Erstauswertung
Bei der Erstauswertung geht es vor allem darum zu prüfen, ob die konkreten Anforderungen umgesetzt sind. Beim Blick links und rechts des Testzieles können andere Unstimmigkeiten auffallen. Da es dem Spezifizierer hauptsächlich darum geht, das Testziel zu erreichen, kann dieser einen Tunnelblick haben und die Unstimmigkeiten übersehen.
Ergebnisvorstellung (Review)
Wenn die wesentlichen Ergebnisartefakte dem Team vorgestellt wird, schauen mehrere Augen auf das Artefakt, die nicht nur das Testziel im Blick haben.
automatische Auswertung
manuelle Auswertung und Entscheidung
Ergebnisse vorstellen (Review)