Grundsätzlich läuft etwas falsch, wenn euer Testteam im aktuellen Produkt keine Fehler findet. Denn dann ist das Team eventuell betriebsblind oder zu unerfahren. Auch andere Faktoren spielen hier in diesen Kontext mit ein.
Selbst in der perfekten Welt, in der die Software die Hände der Entwickler zu 100 % fehlerfrei und mit vollständigen Funktionen verlässt, ist das einfach nicht wahr. Ja, wenn ihr in der 11. Stunde einen geschäftskritischen Fehler finden, ist das großartig, und ihr seid der Held. Aber wenn ihr alle ausgezeichneten Testfälle ausführt und keine Fehler entdecken, habt ihr etwas von gleichem oder höherem Wert geschaffen. Das ist Qualitätssicherung.
- Ihr könnt den Arbeitsaufwand für eine neue Funktion nicht mit Sicherheit abschätzen. Denn ein Fehler könnte sich direkt unter der Oberfläche einer kritischen Komponente verstecken.
- Ihr könnt einen Änderungssatz nicht effizient testen. Denn ohne eine Vertrauensbasis muss jeder Test ein vollständiger Regressionstest sein.
- Ihr könnt euer Produkt nicht an seriöse Kunden verkaufen, weil euer Entwickler auf die Frage, ob es XYZ kann, antwortet: „Nun, theoretisch schon.
Ich denke, das Testmanifest hat es auf den Punkt gebracht. Konzentriert euch auf die Fehlervermeidung und nicht auf die Fehlersuche. Wenn Fehler die Produktion erreichen, sollten Sie eine Ursachenanalyse durchführen und verhindern, dass ähnliche Fehler in Zukunft auftreten.
Dazu gibt es auch noch weitere Informationen:
https://less.works/less/technical-excellence/thinking-about-testing.html
https://moreagiletestingmanifesto.wordpress.com/2015/08/02/agile-testing-manifesto/
http://www.jamesshore.com/Agile-Book/root_cause_analysis.html
Neueste Kommentare