Neue vs. erfahrene Tester

Hier bei test IO nennen wir unsere neuen Tester “Greenhorns” und wenn du dich anmeldest, fällst du in diese Kategorie, bis du 50 Bugs reported hast.
Sobald du mehr als 50 Bugs eingereicht hast, denken wir, das du erfahren genug bist und die Grundlagen des Bug-Report-Schreibens kennen solltest und du verlierst den Status des Neulings (Greenhorns) und alle damit verbundenen Vorteile.
Greenhorn Tester bekommen von unseren Teamleadern mehr Unterstützung als erfahrene Tester.
Wenn du kein Greenhorn mehr bist, ändern sich die Spielregeln – deine Bugs können dann direkt abgelehnt werden, wenn sie bestimmten Ansprüchen nicht gerecht werden.

Direkt abgelehnt werden kann:

  • Schlechte Grammatik (Nicht bei einzelnen Schreibfehlern)
  • Unverständliche Beschreibung und Ergebnisse
  • Wenn wichtige Schritte in der Beschreibung fehlen
  • Wenn ein Tester die gleichen Fehler, trotz Hinweis, immer wieder macht.
  • Unklarer Bug-Titel
  • Klares Nicht-verstehen/-lesen der Testbeschreibung
  • Ungenügende Anhänge
    z.B.: Anhang zeigt zwar einige Steps, aber nicht das Wesentliche
    z.B.: fehlende Crash Logs

Als Tester solltest du also sicherstellen, dass du deine Bugs immer nach unseren Standards und komplett einreichst.

test IO Tester ms_frodo teilt seine top 5 Tipps zum erfolgreichen Crowd-Testing!

Tipp #1: Lese die Test-Instruktionen gründlich
Es gibt oft tester die testen ohne die (gesamte) Beschreibung gelesen zu haben. Als Resultat werden viele ihr Bugs aus oft den folgenden Gründen abgelehnt:

„Bug ist nicht im Scope des Tests“, „Das ist kein Bug“ oder „Dieser Bug ist bereits bekannt“

Wenn du diesen Tipp befolgst und die die gesamte Beschreibung gründlich durchliest, können solche abgelehnten Bugs und verschwendete Zeit vermieden werden. Und das beste ist, dein Ranking wird auch nicht darunter leiden.

Tipp #2: Verbessere die Qualität deiner Bugreports
Wenn du Bugreports schreibst, reiche gleich alle wichtigen Informationen mit ein, achte auf sprachliche Qualität und Grammatik. So das deine Reports vom Teamleader und Kunden gleich und richtig verstanden werden. Halte dich an die „3 W Regel“ (Was, Wo, Wann) in deinem Bugtitel. Qualitative Bugs können gleich angenommen werden und vermindern deine abgelehnten Bugs. Und als Bonus, Teamleader und Kunden werden deine Reports lieben.

Tipp #3: Stelle sicher das dein Bug kein Duplikat ist
Bevor du einen Bug einreichst, checke die Known- und Bugliste und stelle sicher das dein Bug kein Duplikate ist. Ab und zu reiche ich einen Bug auch erst ein und gehe danach durch die Listen im zu sehen das es kein Duplikat ist. Die meisten Bugs werden abgelehnt das es sich um Duplikate handelt. Dieser Tipp ist sehr einfach, trotzdem vergessen viele Tester es und bekommen dadurch viele ihrer Bugs abgelehnt.

Tipp #4: Prüfe den vollen funktionalen Umfang der App wenn du testest
Wenn du eine App testest, prüfe alle Funktionen und Features der App. Es ab und zu „high“ oder „critical“ Bugs die man gleich offensichtlich findet, wie z.B. das ein Upload-Button nicht funktioniert, oder man sich nicht via Facebook einloggen kann. Aber um die versteckten Bugs zu finden, musst du gründlich und tief in die App.

Tipp #5: Arbeite Hand in Hand mit der Test-Plattform
Was meine ich damit? Ich meine das du immer die neusten Updates lesen und verinnerlichen solltest. Normalerweise werden die Regeln auf solchen Plattformen regelmäßig geupdatet. Wenn dir diese Updates nicht bekannt sind, dann kannst du die neuen oder geupdateteten Regeln auch nicht befolgen und einige deiner Bugs werden abgelehnt werden. Und es hilft auch immer die Artikel der Seite zu lesen, denn hier kannst du sicher einiges lernen was dir beim Testen hilft.

Behalte diese Regeln im Kopf und sie werden dir sicher helfen deine Arbeit zu verbessern.

Relevante Bugs sind wertvolle Bugs

Versetz dich in die Position von einem Entwickler oder Product Owner: Du hast einen Crowd Test laufen lassen und jetzt hast du eine Menge Bugs zu bearbeiten. Du guckst dir also die Bugs an und realisierst, dass einige der Bugs einfach nicht relevant sind. Das mag an verschiedenen Dingen liegen wie beispielsweise das Device / Browser Setup oder dass der Bug „herbeigeführt“ ist. Das Resultat ist einfach: Du lehnst die irrelevanten Bugs ab, da es in der Regel genug relevante Bugs gibt und selbst wenn nicht, hast du sicher noch genug relevante Bugs aus alten Tests zu bearbeiten.

Was kannst du also tun um sicherzustellen, dass du relevante Bugs einreichst?

  1. Versuche die Sichtweise des Kunden zu verstehen um zu sehen, was für den Kunden relevant ist. Hier hilft es die Testbeschreibung and App Sections gründlich zu lesen.
  2. Bedenke die Zielgruppe für die App / Website. Wenn eine App z.B. für den russischen Markt ist, wird ein Crash durch das Umstellen der Telefonsprache auf Italienisch wohl kaum relevant sein.
  3. Wenn du für einen Bug Schritte gehen musst die kein normaler User machen würde (typical user behaviour), wird der Bug sehr wahrscheinlich als „Edge Case“ gesehen. Edge Cases werden sehr oft abgelehnt. Wenn ein Bug keine Auswirkungen auf die „User“ eines Kunden hat, interessiert er den Kunden auch sehr wahrscheinlich nicht.

Fünf goldenen Regeln für mehr angenommene Bugs

Wir werden oft gefragt, was man tun muss, damit mehr Bugs angenommen werden. Zum Glück können wir, aus Erfahrung aus fast einer halben Million Bugs, recht genau sagen, was nötig ist, damit ein Bug „akzeptiert“ wird.
Da jeder angenommene Bug euch wie uns einen Mehrwert bietet, möchten wir diese fünf goldenen Regeln mit euch teilen.

Regel #1: TEST-ANWEISUNGEN LESEN!

Es sollte eigentlich klar sein, dass man ohne das aufmerksame Lesen der Anweisungen (Instructions und Chat) und der App-Sections nicht genau weiß, was der Kunde erwartet. Und selbst wenn ein Bug gefunden wird, der wirklich ein Bug ist, kann es sein, dass der Kunde genau diese Art von Bugs gerade nicht sucht und der Bug abgelehnt werden muss.

Regel #2: REPRODUZIERE DEINEN BUG

Wenn du deinen Bug nicht reproduzieren kannst, ist es unwahrscheinlich, dass der Kunde es kann und eigentlich ist niemand an Fehlern interessiert, die nur einmal auftreten.

Regel #3: POSTE NUR RELEVANTE BUGS

Etwas, dass wir relativ häufig sehen, sind Bug-Reports, die zwar einen Fehler zeigen, dieser aber aber bei „Benutzer-untypischem Verhalten“ auftritt oder provoziert wurde. Versuch es mal aus Kundensicht zu sehen: Würde es dich interessieren, dass man einen Fehler herbeiführen kann, indem man etwas tut, was kein normaler Benutzer tun würde? Nein, denn dein Ziel als Anbieter ist es, für die Nutzer deines Produktes eine gute Erfahrung zu schaffen. Es ist also relativ wahrscheinlich, dass ein solcher Bug als nicht relevant abgelehnt wird.

Regel #4: POSTE KEINE DUPLIKATE

In vielen Tests findest du eine „Known-Bug Liste“, mit Fehlern die dem Kunden schon bekannt sind. Allerdings ist es auch ein Duplikat, wenn du einen Bug postest, den ein anderer Tester schon vor dir eingereicht hat.
Wichtig ist es hier zu bedenken, es geht um den Fehler, nicht um den Weg zum Fehler. Ein Fehler auf der Produktdetailseite bleibt z. B. der gleiche Fehler, egal auf welchem Weg man auf die Seite gekommen ist.
Um schon eingereichte Fehler so schnell wie möglich zu finden, ist es wichtig, immer aussagekräftige Bug-Titel zu verwenden.

Regel #5: REICHE BUG-REPORTS IN HOHER QUALITÄT EIN

Diese Regel ist wieder sehr offensichtlich, aber gerade deswegen auch sehr wichtig. Wenn der Anhang oder die Beschreibung nicht klar ist, versteht der Kunde den Bug evtl. falsch und lehnt diesen ab.
Mehr zur Bug-Qualität findest du hier.

Folge diesen fünf Regeln und du wirst deine Bug Acceptance Rate auf jeden Fall verbessern.

Der perfekte Bug-Title

Der Bug-Title ist viel mehr als eine „Notwendigkeit“ – er ist eine Kurzbeschreibung des Problems und mit einer guten Kurzbeschreibung hilft man sich selbst, anderen Testern und dem Kunden.

Also lasst uns doch mal angucken, was einen guten Bug-Title ausmacht. Er sollte kurz und prägnant sein. Er sollte aber auch die wichtigsten Informationen enthalten, damit er zugeordnet und wiedergefunden werden kann.
Also am besten fragt man sich, was der eigentliche Bug ist (oft ist dies nicht das Resultat des Bugs) und diese Information nimmt man dann als erstes.
Die nächste Frage ist „wo“, also die Location, damit andere User wissen, wo der soeben gefundene Bug auftritt. Jetzt können wir noch zusätzliche Informationen hinzufügen und.. Tada.. wir haben einen aussagekräftigen Bug-Title.

Wenn wir das anwenden, sieht der Bug-Title so aus:

[Fehler] Location / zusätzliche Information

Beispiele:

[Broken button] „Jetzt kaufen“ Button auf der Summer Savings Seite / Error #123 displayed

[Crash] Sortierungsmenü / App crashed wenn das Menü geöffnet wird

[Unendliches Laden] Video auf „know our product“ Seite / Beim Versuch das Video abzuspielen

Nun gehe fort und schreibet gute Bug-Title.

Neue Seite – Attachments

Informationen und Regeln zum Erstellen von Attachments findet ihr jetzt nicht mehr „versteckt“ in der Bug-Qualität, sondern separat auf einer Seite zum Thema Attachments.

Wir haben die Regeln etwas klarer definiert, um unseren Kunden ein hohes Maß an Qualität und einheitlichere Attachments liefern zu können.