„Nicht reproduzierbare Defects sind reproduzierbar!“ – Serie: „Aus der Praxis – für die Praxis― weixis Beitrag für bessere Software

Nicht reproduzierbare Defects können die teuersten Probleme sein, mit denen sich Tester beschäftigen sollten.

Worum geht‘s?

Manchmal (?) verhält sich ein Testobjekt so, dass ein erkannter (?) Defect nicht mehr (einfach) nachgestellt werden kann. Hoffentlich tauchen zu diesem Zeitpunkt viele Fragen auf: War die Beobachtung korrekt? Hat mein Test das Ergebnis verändert? Was waren die Bedingungen für die Abweichungen? Hab ich was übersehen? Was soll ich machen – einfach ignorieren oder trotzdem als Defect melden?

Gehen wir davon aus, dass Sie sich auf andere Punkte konzentrieren wollen und Sie ignorieren das Problem als einmaligen „SW-Ausrutscher, der nur viel Aufwand kostet“. Die möglichen Konsequenzen? Die Software wird an den Endkunden geliefert und dann taucht dieses Problem dort auf. Die Auswirkung des Problems korreliert im Regelfall mit dem entstandenen Schaden: Von einer Kleinigkeit, die nicht mehr kommt, bis hin zum Problem, dass die SW nicht eingesetzt werden kann („Blocker“). Spätestens jetzt tritt das Supportteam auf den Plan, will Zugriff zur Kunden IT und Betriebsführung, Datenabzügen usw. – viele Dinge, um das Problem vor Ort nachzustellen, aber eben auch viele Dinge, die den Kunden weiter beanspruchen und damit verärgern. Es ist klar: Hier ist dem Problem bereits im Test kreativ nachzusetzen!

Was tun?

Mehr von diesem Beitrag lesen

10 things I wished they’d told me – Softwaretestdokumentation

Für alle die bei der Präsentation (1) nicht dabei sein konnten möchten wir hier die Gelegenheit nutzen Ihnen auch einen kompakten inhaltlichen Rückblick zu dem Vortrag und insbesondere eine schriftliche Übersicht der 10 Tipps zu geben.

Gerade mit dem Begriff Testdokumentation werden viele Begriffe und Standards in Verbindung gebracht. Was davon brauchen wir aber wirklich, also was ist der Kern einer guten Testdokumentation? Wie kann ich diesen bei Bedarf weiter ausbauen und optimieren?

Tag Cloud Test Documentation

Tag Cloud der Testdokumentation

Dokumentieren Sie immer die Testdurchführung

Ein Ansatz ist es einfach und schlicht nichts zu dokumentieren. Man bekommt das Testobjekt testet drauf los, schickt die Findings, welcher Art auch immer, direkt an die Entwicklung und diese erledigt eben diese so gut sie kann. Solang das Testobjekt überschaubar ist und die Entwicklung eng mit dem Test zusammen arbeitet, funktioniert dieses Vorgehen zur Beurteilung der Qualität auf Basis der Aussagen eines Testers. Dies ist aber auch implizit der Nachteil, in Wirklichkeit kann keiner außer diesem einen Tester die Qualität beurteilen.  Auch wenn er viel und gut getestet hat, gibt es dafür keinen Nachweis und seine Arbeit ist weder nachvollziehbar noch reproduzierbar. Dies gilt nicht nur für das Management, sondern auch für den Tester selbst. Er kann seine Regressionstests nicht mehr auf dem bereits einmal ausgearbeiteten und durchgeführten Tests aufbauen und hat keine Chance seine eigenen Aktivitäten zu verfolgen.  Aus diesen Gründen sollte man immer zumindest die Testdurchführung, die konkreten Ergebnisse der Durchführung (Test OK, Test Nicht-OK) und die Findings dokumentieren. Die Form der Dokumentation ist in dieser Ausprägung irrelevant, es kann ein Video-Capture der Tests sein oder Dokumentation im Notepad oder bereits in einem Testtool. Die Auswahl der geeigneten Methode ist schon eine Maßnahme der Optimierung, aber oft auch intuitiv gewählt.

Mehr von diesem Beitrag lesen

%d Bloggern gefällt das: