Kennst Du das? Du kommst als neuer Tester in ein Projekt hinein und sollst anfangen, die vorhandenen Bugs nach zu testen. Dann öffnest Du den ersten Bug und die Beschreibung ist genau einen Satz lang. Ganz genau – einen Satz. Das war es. Keine Schritte zum Nachvollziehen. Kein Screenshot. Nichts. Wenn Du nun denkst, das ist nur ein schlechter Traum gewesen, dann muss ich Dich nun leider enttäuschen. Das ist in vielen Projekten die Realität. Da spreche ich aus meiner selbst gemachten Erfahrung als Test Consultant bei der SwissQ.
So und nun? Jetzt stehst Du da mit Deiner Ein-Satz-Beschreibung eines Fehlverhaltens. Die Applikation kennst Du auch noch nicht wirklich. Sie wurde Dir zwar mal grob erklärt, aber wo jetzt genau überall dieses Fehlverhalten auftritt, bleibt Dir zunächst schleierhaft. Was bleibt Dir dann übrig? Genau, Du gehst explorativ durch die Applikation durch. Immer mit dem unguten Gefühl, dass Du etwas übersehen könntest. Vielleicht versteckt sich hinter irgendeinem Button oder Link doch noch der ein oder andere Workflow, den Du eigentlich testen müsstest.
Was kannst Du dann tun? Nun, Dir bleibt nichts anderes übrig, als die Zähne zusammen zu beissen und so schnell wie möglich die Applikation kennen zu lernen. Das kannst Du folgendermassen tun:
- Du gehst explorativ vor, das heisst, Du hast keine Testfälle, an denen Du Dich entlang hangeln kannst, sondern Du klickst Dich frei in der Applikation durch. Ich empfehle immer oben links zu starten und sich dann nach unten rechts durch zu klicken. Dabei solltest Du alles auszuprobieren, was auf einer Seite angeboten wird. Danach gehst Du mit der nächsten Seite genau so vor.
- Dann hast Du natürlich noch die Möglichkeit, Dir die vorhandene Dokumentation geben zu lassen. Es ist zwar nicht unbedingt Verlass darauf, dass diese vollständig ist, aber Du kannst schon einmal einen Eindruck der Komplexität dadurch bekommen.
- Des Weiteren hast Du die Möglichkeit, Deine Kollegen zu fragen, ob sie Zeit hätten, Dir noch die Funktionalität zu zeigen. Du kannst dabei explizit fragen, ob sie Dir die Workflows zeigen können, die etwas schwieriger zu entdecken sind.
- Oder Du testest direkt, mit einem erfahrenen Tester, im Rahmen eines Pairtestings zusammen. So lernst Du nicht nur die Applikation kennen, Du bringst gleichzeitig auch noch einen frischen Blickwinkel mit hinein. Da Du noch unvoreingenommen der Applikation gegenüber bist und dadurch vielleicht noch Bugs entdeckt, die die anderen vor lauter Betriebsblindheit nicht mehr sehen.
Das wäre zumindest meine Vorgehensweise in einem neuen Projekt. Aber worauf ich eigentlich hinaus möchte, ist folgendes:
Du solltest immer mit einem guten Beispiel voran gehen und Dir Zeit nehmen, eine qualitativ hochwertige Bugbeschreibung zu erstellen.
Wie sieht nun eine ideale Bugbeschreibung aus?
Zumindest ist dieser Blogbeitrag mein Plädoyer für leicht verständliche und nachvollziehbare Bugbeschreibungen! Daher möchte ich mit gutem Beispiel voran gehen und Dir vorstellen, was ich von einer sehr guten Bugbeschreibung erwarte.
- Fangen wir mit der Beschreibung an: Hier solltest Du hineinschreiben, welches Fehlverhalten genau aufgetreten ist. Es ist also die Beschreibung der aktuellen Situation, das “Ist-Verhalten”. Hierbei brauchst Du noch nicht beschreiben, wie Du genau zu diesem Verhalten gekommen bist, das kommt gleich noch.
- Als nächstes würde ich an Deiner Stelle das erwartete Verhalten beschreiben: Also hier schreibst Du hinein, was aus Deiner Sicht eigentlich passieren sollte. Falls Du Dir nicht sicher bist, kannst Du auch hinein schreiben, was Du vorschlägst. Dies muss aber noch abgeklärt werden.
- Dann kommen die Schritte, um den Bug zu reproduzieren: Hier schreibst Du wirklich Schritt-für-Schritt hinein, was Du getan hast, um den Bug zu reproduzieren. Dabei kannst Du zum Beispiel die URL von der Seite angeben, auf der der Bug aufgetreten ist. Eine andere Möglichkeit ist, dass Du den ganzen Weg vom Login über die einzelnen Schritte hin zu deinem Bug beschreibst. Dabei ist es wichtig, dass Du einen guten Grad an Detaillierung hinbekommst und nur das wirklich essentiell Wichtige an Schritten aufschreibst. Wenn Du zum Beispiel 5 Minuten gewartet hast, um diesen Bug zu reproduzieren, kannst Du das aufschreiben. Du musst aber nicht beschreiben, was Du in den 5 Minuten alles getan hast. Du darfst trotzdem natürlich auch keinen wichtigen Schritt auslassen!
- Als nächsten Schritt fasse ich dann alle weiten Infos zusammen, die bis jetzt nirgends hin gepasst haben: Das wäre zum Beispiel auf welchem Betriebssystem und welcher Browservariante ich getestet habe. Also zum Beispiel Windows 7 Internet Explorer 9. Diese Infos sind für die Entwickler meist entscheidend, um den Bug auf der richtigen Umgebung nachzutesten! Ansonsten verwende ich diesen Punkt, um alle Infos hineinzupacken, die sonst nirgends hin passen.
- Als letzten Schritt hänge ich an die Bugbeschreibung entweder einen Screenshot oder ein kleinesVideo an. Das mache ich, damit ich zum Einen einen Beweis habe, dass der Bug wirklich aufgetreten ist und zum Anderen, dass für alle Projektbeteiligten der Bug einfach nachvollziehbar ist.
Das wäre aus meiner Sicht eine perfekte Bug-Beschreibung. Natürlich ist dieses Vorgehen ein klein wenig aufwendiger, aber der Aufwand lohnt sich sowohl für dich, als auch für die Entwickler!
Denn stell Dir mal folgendes vor: Es kommt – so wie Du – ein neues Team Mitglied, dass Deine Bug-Beschreibung testen soll. Du kannst so sicher sein, dass Dein Bug auf jeden Fall verstanden wird. Oder Du sollst diesen Bug in ein paar Wochen, wenn die Entwicklung diesen gefixt hat, erneut nachtesten. Vielleicht würdest Du gar nicht mehr wissen, wie genau Du diesen Bug reproduziert hast, weil Du mittlerweile viele andere erstellt hast.
Dann noch ein weiterer wichtiger Punkt:
Ich würde stets vorschlagen, die Bugs auf Englisch zu erfassen, auch wenn dein Team nur aus deutschsprachigen Mitarbeitern besteht. Du kannst schliesslich nie wissen, ob irgendwann mal ein neues Team Mitglied hinzu kommt, dass der deutschen Sprache nicht mächtig ist. Schließlich arbeiten wir global und ich hatte schon z.B. mit Entwicklern in den verschiedensten Ländern zu tun und ausserdem ist die Schweiz 4-sprachig, da kann es schnell passieren, dass jemand nicht Deutsch spricht.
Das war es. Mein Plädoyer für ausführliche Bug-Beschreibungen. Ich hoffe, Du kannst meine angegebenen Punkte nachvollziehen und entscheidest Dich zukünftig für diese Variante. Es hilft allen Projektbeteiligten. Wirklich!
Wie siehst Du das Ganze? Würdest Du zukünftig auch lieber die etwas ausführlichere Methode wählen, oder siehst Du das Ganze aus einem anderen Blickwinkel? Schreibe mir dazu gerne einen Kommentar!
## Foto by https://unsplash.com/florianklauer