Motivation
Test IO steht für die Unterstützung des Wachstums von Testern. Damit deine Testkarriere steil nach oben geht, wollen wir mit dir die häufigsten Fehler teilen, die unsere Tester in den ersten Tagen ihrer Testkarriere machen. Sogar erfahrene Tester machen manchmal Fehler und lernen daraus.
Beim Testen ist es sehr verlockend, alles Mögliche auszuprobieren, sogar einige ungewöhnliche Schritte, die ein normaler Benutzer nie unternehmen würde. Wenn du diesen Drang verspürst, warte bitte, bevor du einen Bug-Report einreichst. Denke erst darüber nach, ob deine Schritte einem normalen Benutzerverhalten entsprechen oder ob der von dir gefundene Bug interessant für unsere Kunden sein wird. Stelle dir immer die Frage, ob dein Bug die gewöhnliche Benutzererfahrung beeinflusst.
Lass uns einige Beispiele der häufigsten Fehler ansehen, die wir für dich gesammelt haben.
Testen des E-Mail-Abonnements mit einer E-Mail-Adresse, auf die du keinen Zugriff hast
Oft möchten unsere Tester beweisen, dass das E-Mail-Abonnement- oder der Registrierungsprozess ungültige E-Mail-Adressen akzeptieren. Natürlich kann getestet werden, ob der Server ungültige E-Mail-Adressen akzeptiert oder nicht, dies ist auch für unsere Kunden nützlich - aber mache dich erst mit dem Unterschied zwischen ungültigen und nicht vorhandenen E-Mail-Adressen vertraut. Man könnte meinen, dass es dasselbe ist, dies ist jedoch nicht der Fall. Bitte lies diesen Artikel, um zu verstehen, was ungültige E-Mail-Adressen sind.
Nicht vorhandene E-Mail-Adressen hingegen sind E-Mail-Adressen, die nicht von dir (oder sonst jemandem) erstellt wurden und daher nicht im System existieren. Ein Versuch, eine nicht existierende E-Mail-Adresse zu validieren, wird höchstwahrscheinlich keine Reaktion vom Server hervorrufen, da sie als gültig angesehen wird, wenn sie dem üblichen Format einer E-Mail-Adresse folgt. Ein solches Verhalten ist erwartet und wird nicht als Bug angesehen.
Die Lösung:
Wenn du mit kommerziellen E-Mail-Adressen testest, MUSST du ein vorhandenes Postfach verwenden. So vermeiden wir unnötige Anfragen an Gmail, Outlook oder andere E-Mail-Anbieter.
Wenn du die Validierung testen möchtest, musst du qa.team-E-Mail-Adressen verwenden. Da alle gültigen Benutzernamen von qa.team existieren, senden Tester niemals eine Anfrage an ein nicht vorhandenes Postfach und testen daher nur die Validierung selbst.
Für Testumgebungen sollten immer qa.team-E-Mail-Adressen für die reguläre Registrierung verwendet werden (sofern nicht anders vom Kunden angegeben).
Für die Validierung ungültiger E-Mail-Adressen verwende die Beispiele, die in diesem Artikel geteilt werden oder erstelle deine eigene Kombination, die der gleichen Struktur folgt.
Melden von Bugs in Bezug auf die Browservalidierung
Die Browservalidierung repräsentiert die HTML-Eingabevalidierung, die der Browser auf der Grundlage von Attributen innerhalb des Eingabefeldes durchführt.
Hier ist ein Beispiel für die HTML5-Browservalidierung der E-Mail-Eingabe:
<input type="email" id="email"
pattern=".+@test\.io" size="30" required>
Wenn du so etwas siehst, bedeutet das, dass eine Browservalidierung implementiert ist und dass diese Validierung nicht durch JavaScript durchgeführt wird.
Eines der häufigsten Beispiele für die Browservalidierung ist die Anzeige einer roten Zickzacklinie unter dem falsch geschriebenen Wort, das du im Formularfeld eingibst.
Das Melden solcher Bugs gehört nicht zum Testumfang von Test IO und wird abgelehnt.
Die Lösung:
Wenn du dich fragst, welche Art der Validierung für die jeweilige Umgebung (Website) durch den Kunden implementiert wurde, klicke mit der rechten Maustaste auf die Seite und dann auf "Zeige den Quelltext" ("View Page Source"). Wenn du den Code <input type="email"...> bemerkst, bedeutet das, dass das E-Mail-Feld vom Browser validiert wird und dass du den Bug nicht melden solltest.
Testen ohne aktivierten Proxy, obwohl dies in den Testanweisungen gefordert ist
Manchmal lesen unsere Tester die Testanweisungen nicht sorgfältig durch, was dazu führt, dass ihre Bugs abgelehnt werden oder sie sogar im schlimmsten Fall eine Warnung von unserem Compliance-Team erhalten. Einer der häufigsten Fehler ist, wenn Tester keinen Proxy verwenden, obwohl dies erforderlich ist. Wir haben eine kleine Untersuchung durchgeführt und hierin liegt das Problem der Tester:
In wiederkehrenden Tests lesen Tester die Testanweisungen oft nur einmal durch, vernachlässigen es aber in den folgenden Tests desselben Produktes und denken, dass die Teststrategie die gleiche ist, wie zuvor. Hier machen sie aber einen Fehler. Derselbe Testtitel bedeutet nicht zwangsläufig, dass der Zugang zur Testumgebung demselben Pfad wie in vorherigen Testläufen folgt.
Oftmals möchten unsere Kunden den Datenverkehr (Traffic), den unsere Tester verursachen, vom Traffic echter Benutzer trennen. In solchen Fällen verwenden wir einen Proxy. In einem anderen Fall ist ein Proxy nötig, um Zugriff auf eine Staging-Testumgebung zu erhalten, die für Personen ohne entsprechenden Zugang gesperrt ist. Wenn der Tester das Aktivieren des Proxys übersieht, gibt die Testumgebung 403- oder 1020-Fehler aus. Das Melden solcher Bugs wird aufgrund des Nichtbefolgens der Testanweisungen zur Ablehnung führen.
Die Lösung:
Wenn du den Testlauf akzeptierst, in dem das Aktivieren eines Proxys erforderlich ist, musst du die Testanweisungen genau befolgen oder die von dir gefundenen Bugs werden nicht als legitim angesehen.
Einstufung von Content- und visuellen Bugs als funktionale Bugs, um zum Testumfang zu gehören
Manchmal stufen unsere Tester ohne Absicht alle Content- und visuellen Bugs in funktionale Bugs ein, da sie nicht die Erfahrung haben, welche Bugs als funktional hochgestuft werden können. Als Resultat werden diese Bugs dann abgelehnt. Oftmals handelt es sich bei diesen Ablehnungsgründen um "Out of Scope" (außerhalb des Testumfangs), was bedeutet, dass die Qualität und der Rang des Testers erheblich leiden.
Die Lösung:
Konzentriere dich darauf, den Unterschied zwischen Content-, Visual- und funktionalen Bugs zu verstehen. Beachte, dass wenn Content- und Visual-Bugs die Funktionalität des Produkts nicht beeinträchtigen oder ein intuitiver Workaround existiert, du keinen funktionalen Bug melden solltest.
Keine Aktualisierung des Betriebssystems des Geräts vor der Annahme eines Beta-Testlaufs
Dieser Fehler unterläuft nicht nur unseren Neulingen, sondern manchmal auch unseren erfahrenen Testern. Meistens geschieht dies unbeabsichtigt. Unsere Tester nehmen in einer Woche an vielen Tests teil und manchmal vergessen sie, sich für den Test von Beta-Betriebssystemversionen anzumelden.
Die Lösung:
Fehler zu machen ist menschlich, beachte aber, dass du immer die Testanweisungen liest, da diese wichtige Informationen zum angeforderten Gerät und Beta-Betriebssystem enthalten.
In Fällen, in denen die Beta-Version des Betriebssystems erforderlich ist, solltest du das Produkt nicht mit der offiziellen Version, sondern mit der Beta-Version testen.
Auswählen des falschen Geräts im Bug-Report
Meistens möchten Tester die schnellsten beim Melden von Bugs sein. Dabei kann es vorkommen, dass sie aus Versehen das falsche Gerät auswählen. Wenn sie vor dem Überprüfen ihres Bug-Reports nicht zum richtigen Gerät wechseln, könnten gute Bugs abgelehnt werden.
Die Lösung:
Bevor du auf "Bug melden" klickst, vergewissere dich, dass du die richtigen Bug-Details wie Bug-Typ, Schweregrad, Gerät und Browser auswählst. Wenn du aus Versehen das falsche Gerät oder den falschen Browser auswählst, kannst du es ändern, solange kein anderer Tester den Bug bereits korrekt eingereicht hat und bevor der Teamleiter deinen Bug-Bericht überprüft.
Senden einer Nachricht im Chat des Testlaufs, um den TL über die vorgenommenen Änderungen in einem Bug-Report aufgrund einer Informationsanfrage zu informieren
In der Anfangsphase des Testens erhalten unsere Tester mehrere Informationsanfragen, um ihre Bug-Reports zu verbessern. Während dieser Zeit warten Tester oft ungeduldig auf eine Rückmledung vom TL. Oftmals senden die Tester dann mehrere Kommentare im Bug-Report oder sogar Nachrichten im Chat des Testlaufs, um den TL über die durchgeführten Änderungen zu informieren. Das kommt dir bekannt vor, oder? Wir haben das alle schonmal gemacht und haben aus unseren Fehlern gelernt. Aber wir möchten, dass du klüger bist und von uns lernst.
Die Lösung:
Wenn du auf die Informationsanfrage mit allen erforderlichen Informationen antwortest, die dein TL angefordert hat, unterlasse es bitte, mehrere Kommentare im Bug-Report und Nachrichten im Chat des Testlaufs zu senden. TLs erhalten Benachrichtigungen über abgeschlossene Informationsanfragen und es besteht keine Notwendigkeit, nervös oder unruhig zu werden. Alle Bugs werden rechtzeitig überprüft, da unser System das Abschließen eines Tests mit nicht überprüften Bug-Reports nicht zulässt.
Verwenden von Google Translate, um die Testumgebung zu übersetzen, während du den Bug aufzeichnest
Einer der Vorteile der modernen Technologie ist, dass du nicht alle Sprachen der Welt beherrschen musst, um das Produkt in einer Fremdsprache zu testen. Die Verwendung eines Übersetzungstools von Drittanbietern wie Google Translate ist beim Testen erlaubt, aber stelle sicher, dass der von dir gefundene Bug nicht durch die Verwendung von Google Translate verursacht wird. Manchmal führt die Verwendung von Google Translate zu einem ungewollten Verhalten in der Testumgebung und unsere Tester melden dann nicht existente Bugs. In anderen Fällen reichen unsere Tester Bugs ein, die zwar real existieren, aber sie vergessen, Google Translate zu deaktivieren, wenn sie den Bug aufzeichnen. In solchen Fällen wird der Bug vom TL abgelehnt, da er nicht unseren Standards entspricht.
Die Lösung:
Wenn du eine Umgebung in einer Sprache testest, die du nicht sprichst, kannst du ein Übersetzungstool von Drittanbietern verwenden, um das Produkt besser zu verstehen. Denke aber daran, die automatische Übersetzung wieder zu deaktivieren, bevor du mit der Aufnahme eines Screencasts beginnst.
Reproduzieren eines "PASS"-Bugs
In einigen Tests werden unsere Tester dazu aufgefordert, einen funktionalen Bug mit dem Titel "PASS" einzureichen, um nachzuweisen, dass der in den Testanweisungen beschriebene Arbeitsablauf erfolgreich ist. Das Hinzufügen von Reproduktionen bei solchen Bugs ist jedoch nicht zulässig und solche Einreichungen werden abgelehnt.
Die Lösung:
Reiche bitte keine Reproduktion ein, wenn du den Titel "PASS" im Bug-Report siehst.
Falsche Annahme, dass Filtern und Sortieren ähnliche Funktionen sind
In der Regel werden Filter- und Sortierfunktionen zusammen präsentiert, da sie Benutzern beim Umgang mit einer großen Mengen von Elementen (Produkte, Filme, Tickets usw.) helfen. Ihre Umsetzung unterscheidet sich jedoch erheblich. Eine Filterfunktion reduziert eine Sammlung von Elementen anhand bestimmter Kriterien wie Größe, Farbe, Marke und ähnlichem. Eine Sortierfunktion ordnet eine Datensammlung nach verschiedenen Kriterien, wie niedriger bis hoher Preis oder neueste bis älteste Einträge.
Das Filtern und Sortieren auf mobilen und Desktop-Geräten
Das Verständnis dieser Unterschiede ist entscheidend, da Fehler, die bei diesen Funktionen gefunden werden, verschiedenen Typen angehören. Beispielsweise sind Probleme mit der Sortierfunktion funktionale Bugs, die meisten Filterprobleme sind jedoch Content-Bugs.
Die Lösung:
Der einfachste Weg, diese beiden Funktionen zu unterscheiden, besteht darin, den Typ und die Anzahl der Optionen für die Funktionalität zu betrachten. Die Funktion ist ein Filter, wenn sie zahlreiche Optionen bietet, die die physischen Merkmale der Elemente beschreiben und die Ergebnisliste damit eingrenzbar ist. Bei der Funktion handelt es sich um eine Sortierung, wenn die gegebenen Optionen (meist in einem Dropdown-Menü) nur wenige Einträge umfassen und die dazu dienen, die Liste von Ergebnissen auf eine bestimmte Weise anzuordnen.
Die Liste der häufigsten Fehler endet nicht mit den oben genannten Fällen. Für weitere häufige Fehler und einige ausgezeichnete Tipps empfehlen wir dir, unsere Podcast-Episode anzuhören: