„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

Advertisements

„Der beste Tester…“ aus der Serie: „Aus der Praxis – für die Praxis“ – weixis Beitrag für bessere Software

Oder: „Abweichungen sind die Trüffeln der Software-Tester-Suche“

Für uns bei SEQIS steht diese Einstellung zu Abweichungen seit sicher 10 Jahren bereits fest: Der beste Tester ist nicht der, der die meisten Fehler findet (→ rein destruktiver Fokus). Der beste Tester ist jener, der die meisten Probleme gelöst bekommt (→ konstruktiver Ansatz)!

Doch was kann ein Tester tun, damit er „die Probleme gelöst bekommt?“ – Nun, hier haben sich in den letzten Jahren einige gute Standards etabliert, allen voran natürlich auch Normen wie die IEEE 1044-2009 (= IEEE Standard Classification for Software Anomalies). Kurz beschrieben definiert dieser Standard die Abweichungsklassifikation in vier Schritten (Erkennen, Analysieren, Beheben und Abschließen (i.S. von Lösen, Verwerfen oder Konservieren)). Soweit, so gut.

Doch was macht mich als Tester und „meine Abweichungsbeschreibung“ zum Freund der Entwicklung? Eigentlich auch einfach: Objektivität, Klarheit und ein bisserl G‘fühl für die Sache. Mehr von diesem Beitrag lesen

%d Bloggern gefällt das: