Der beste Tester...

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.

Zur Objektivität: Natürlich sind für einen Tester Abweichungen, die immer und immer wieder als gelöst rückgemeldet werden und daher auch immer wieder und wieder re- testet werden müssen, ein Ärgernis. Gleiches gilt natürlich, wenn die Grundqualität der Software-Einlieferung mangelhaft ist. Zeitaufwand für die Vorbereitung und Durchführung, oft immenser Erfolgsdruck für den Tester (alle wollen ja, dass das Testergebnis ein „closed“ der Abweichung ist), der Mangel an Abwechslung (immer und immer wieder das gleiche...) und die damit einhergehende Frustration verleiten einen Menschen leicht zum Überkochen. „Verd<biep< Sch<biiieeeep>, so kann man nicht arbeiten!!! Macht das endlich richtig, oder...!“. Würde man nun dies in die Abweichungsbeschreibung aufnehmen, dann ist klarerweise die Freundschaft mit der Entwicklung nicht wahrscheinlich.

Auch muss man sich fragen, wo die Ursache für die Abweichung liegt. Wir bezeichnen ja bereits richtigerweise einen „defect“ lieber als „Abweichung“ oder „finding“ – es kann ja sein, dass die Ursache nicht beim Entwickler liegt:

• Stimmt eigentlich mein Testfall – oder fordere ich Funktionalität, die so nie vereinbart wurde?
• Liegt die Ursache tatsächlich im Code – oder habe ich ggf. ein Problem in der Testumgebung oder am Client? Gerade wir Tester haben ja oft Clients, die weit mehr können und dürfen, als der Standard-PC...
• Habe ich das Problem ausreichend und gut beschrieben – „... kann keinen Kunden anlegen“ ist ja keine Abweichungsbeschreibung, sondern mehr eine Vorhaltung...

Der Klarheit dienlich ist eine ausreichende Beschreibung des Problems – kein langwieriges Prosagequatsche („Ich weiß nicht ob Sie das wissen, aber wie ich gestern ins Büro gekommen bin...“), sondern hard facts helfen hier der Entwicklung, der Ursache rasch und fundiert auf den Weg zu gehen. Aus meiner Wahrnehmung sind die Gruppen der hilfreichen Informationen zu einer Abweichung wie folgt:

• eine global-eindeutige Abweichungsnummer
• eine Kurzbezeichnung für das Problem
• Detaillierte Beschreibung des Problems („was geht nicht“) inkl. Schaffung der Nachvollziehbarkeit
• Testfall (inkl. Daten, ggf. verbundene Testfälle,...) und Beschreibung was wie gemacht wurde, als das Problem aufgetreten ist (inkl. Datum und Uhrzeit)
• Verweis auf die Anforderung, Spezifikation etc. mit möglichst genauer Beschreibung der Abweichung zwischen Soll- und Ist-Verhalten
• Dokumentation des Testobjekts (Version und Build/Releasehinweis)
• Relevante Informationen zum verwendeten Client, wie Betriebssystem, Browserversion und Co.
• Daten zum Zeitpunkt der Abweichungsmeldung, Namen des Melders (für Rückfragen)
• Einschätzung der Fehlerquelle (in der Spezifikation, im Design - oder was sonst hilfreich ist)
• Ggf. Verweis auf andere Abweichungen, die damit in Verbindung stehen könnten
• Einschätzung von Kritierien wie
• Auswirkung der Abweichung (Trivial, Optimierung, kleines Problem – bis hin zum Blocker)
• Priorität (niedrig bis hoch – also wie rasch muss aus Testsicht das Problem beseitigt werden)
• Klassifikation
• Tritt sporadisch oder immer auf
• ... ist ein Änderungswunsch oder ein Problem Schaffen der Nachvollziehbarkeit
• Zuordnung des Defects an einen Entwickler oder ein Entscheiderteam (wie geht’s mit der Abweichung weiter...)
• Sinnvolle Ergänzungen durch Attachments, Screenshots, Links und Co.
• Problem-Workflow Status („neu“, „zugeordnet an“, „reopen“,...)

Projektspezifisch gibt’s natürlich auch noch Potential für wichtige Erweiterungen, aber damit ist sicher ein guter Grundstock an Informationen vorhanden. Wenn Sie unsicher sind: Fragen Sie einfach die Entwicklung, was diese noch gerne wissen will – damit schaffen Sie auch leichter den Schritt zur Partner- und Freundschaft mit den Entwicklern.

Natürlich braucht’s auch ein „bisserl G’fühl für die Sache“ – pochen Sie nicht unbedingt nur auf abgestimmte Problem-Workflows, nehmen Sie auch mal das Telefon in die Hand und sprechen Sie mit den Kollegen, wenn das Problem nicht und nicht gelöst wird und das Ergebnis Ihres Tests immer wieder „failed“ ist. Verstecken Sie sich nicht hinter Definitionen und Vereinbarungen, sondern sorgen Sie aktiv dafür, dass das Problem gelöst werden kann.

Dann haben Sie das Zeug zum besten Tester und Sie werden sehen, alles ist lösbar.

Viel Erfolg,

weixi