Nicht reproduzierbare Defects sind reproduzierbar!

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?

Tipp 1: Oft stellt sich zu diesem Zeitpunkt bereits die Frage, ob dieses Problem überhaupt in die Defectdatenbank aufgenommen werden soll. Eindeutige Antwort: Ja! Denken Sie daran, dass das Entwicklungsteam im Regelfall mehr Möglichkeiten hat, dem Problem auf den Grund zu gehen. Wenn Sie die Symptome klar beschreiben, kann der Programmierer durch Codeanalyse und weiteren Rückfragen („Was war sonst noch zu sehen, wie Sie das Control bedient haben?―) das Problem weiter einschränken. Wir gehen davon aus, dass in der Praxis mindestens rund 20% der „nicht reproduzierbaren Defects" bereits in erster Instanz durch die Programmierer korrigiert werden können.

Tipp 2: Auch wenn Ihre Entwicklungsmannschaft mantra-mäßig „nicht reproduzierbare Probleme nicht analysiert" – loggen Sie das Problem auf alle Fälle in der Defectdatenbank. Vielleicht ergeben sich durch andere Einträge in der Defectdatenbank Querverbindungen, die bei der Fehleranalyse doch noch helfen. Suchen Sie aber auch selbst aktiv nach diesen Querverbindungen – diese Hints findet man nur, wenn man sie sucht...

Tipp 3: Kennzeichnen Sie das Problem klar als „nicht reproduzierbar“ (NR), am besten als eigenes Attribut in der Datenbank und taggen Sie „NR" in der Zusammenfassung. Damit stellen Sie sicher, dass die Analyse von NRs unterstützt wird.

Tipp 4: Verwenden Sie unbedingt PrintScreen oder einen Screenrecorder (wie z.B. www.viewletcam.org) bei der Problembeschreibung – ein Bild sagt ja bekannterweise mehr wie 1000 Worte...

Tipp 5: Die binäre Welt ist vordergründig einfach: Wenn Sie ein Problem nicht nachstellen können, muss ein Unterschied vorliegen, den Sie übersehen. Machen Sie sich also auf die Suche nach den Unterschieden und analysieren Sie die Bedingungen, unter denen das Problem aufgetaucht ist. Wenn Sie die Rahmenbedingungen nicht kennen, können Sie das Problem nicht nachstellen. Ein paar Aspekte, die Sie bei der Suche unterstützen könnten:

• Das Problem tritt gegebenenfalls nur bei der Erstinstallation oder Erstverwendung einer spezifischen Funktion auf. Nutzen Sie Tools, die einen sauberen Client (einen PC, der Ihr Testobjekt noch niemals gesehen hat) wiederherstellen können.

• Das Problem tritt nur in speziellen Zuständen oder bei bestimmten Bedingungen auf
• mit spezifischen Daten oder Datenkonstellationen (z.B. eine corrupted database),
•  zu spezifischen Zeitpunkten (Wochenende, nach Büroschluss etc.)
• in spezifischen Betriebssituationen (batch vs online mode, Monats-, Quartals- oder Jahresabschlüsse oder laufen einfach nur irgendwelche Betriebsüberwachungs/Monitoringprozesse, die doch nicht nur schauen?)
• Auswirkungen paralleler Aktivitäten auf den Servern (z.B. Ressourcen, die durch andere Prozess gerade blockiert sind) oder am Client (berücksichtigen Sie auch die Background Prozesse)

• Das Problem tritt nur in einer speziellen Ablaufsituation auf → Was haben Sie vorher gemacht? Vielleicht hängt das Problem auch noch an Auswirkungen vorher identifizierter Probleme → Clientrestart

Es gibt noch eine Unzahl spezifischer Aspekte, die den Rahmen dieses Artikels sprengen würden. Einen Tipp (Tipp 6) hab ich noch, den ich Ihnen besonders ans Herz lege: Machen Sie diese Probleme im Projektteam bekannt und stellen Sie die Diskussion auf eine breitere Basis (Architekt, Designer, Entwickler, Betriebsführung usw.). Nicht reproduzierbare Defects gehören nicht Ihnen allein! Im Gespräch haben Sie eindeutig bessere Aussichten auf Lösung Ihrer Frage.

Viel Erfolg, weixi