Motivation

Testlio folgt einem strukturierten Testprozess, der mit Arbeitsbereichen verknüpft ist. Tester werden bestimmten Arbeitsbereichen zugewiesen, um eine Vielzahl von Tests durchzuführen, wie explorative Tests, Zahlungstests, funktionale Regressionstests, Lokalisierungstests, Barrierefreiheitstests, Usability-Tests, Livestream-Tests und Tests der Instrumentierung von SDKs, bei denen sie Testfälle von Anfang bis Ende durchführen.

Wenn ein Schritt im Testfall fehlschlägt, müssen die Tester Bugs melden; wenn der Bug bereits gemeldet wurde, sollten sie eine Reproduktion durchführen.

Tester können duplizierte Bugs finden, indem sie sich die Reports anderer Tester ansehen oder im "Bug-Browser" suchen. Wenn der Titel mindestens 30 Zeichen enthält, erhalten Tester automatisch Vorschläge für ähnliche bereits gemeldete Bugs.

Das Testteam wählt Tester anhand ihrer Profile und Geräteinformationen aus, um die Anforderungen des Arbeitsbereichs zu erfüllen und lädt sie in zwei Stufen per E-Mail ein. Zuerst erfolgt die Einladung zum Arbeitsbereich; die zweite Stufe ist ein Testdurchlauf, bei dem Zeit, Gerät und Zeitplan für den Test angegeben werden.

Je nach Arbeitsbereich können Tester Einladungen zu einem Testlauf erhalten oder auch nicht; alles hängt von den Anforderungen des Arbeitsbereichs ab.

Tester müssen auf die Einladung zum Testlauf antworten, um zur Teilnahme eingeladen zu werden. Das Verstreichenlassen von Einladungen wird als schwerwiegender Fehler angesehen.

Nach Abschluss der zugewiesenen Testzeit müssen die Tester eine Feedback-Umfrage beantworten.

Nachdem ein Bug gemeldet wurde, kann der TL ihn genehmigen, zusätzliche Informationen anfordern oder schließen. Das Schließen eines Bugs entspricht einer Ablehnung und wirkt sich negativ auf die Bewertungen des Testers aus.

Deshalb warten Tester darauf, dass andere Tester Bugs melden und erstellen dann eine Reproduktion, da das Melden eines Bugs die Bewertung des Testers verschlechtern kann, wenn der Bug geschlossen (abgelehnt) wird. Im Gegensatz dazu bringt die Annahme eines Bugs keine Vorteile.

Test IO verwendet einen agilen Testprozess, der Testplanung, Durchführung und kontinuierliches Feedback umfasst. Tester nehmen an Testläufen teil, die ihre Sprache, Geräte und ihren Standort berücksichtigen. Wir legen Wert auf Echtzeit- und manuelles exploratives Testen, um Testern zu ermöglichen, Bugs sofort zu entdecken und zu melden.

Um aktiv an einem Testlauf teilzunehmen, müssen Tester im Voraus eine Test-Session starten und bestätigen, dass sie die Anweisungen für die betreffenden Features gelesen und verstanden haben.

Um Duplikate zu identifizieren, werden dir beim Einreichen eines Bugs in der Liste "Ähnliche Bugs" auf der rechten Seite des Bug-Reports die bereits eingereichten Bugs im aktuellen Testlauf angezeigt. Du kannst auch die Bugs durchsuchen und filtern sowie die Liste der bekannten Bugs dazu verwenden.

Wenn ein Bug-Report abgelehnt wird, wirkt sich dies negativ auf die Punktzahl des Testers aus, abhängig von der Art der Ablehnung.

Tester können abgelehnte Bugs von Teamleitern beanstanden. Sobald ein Report beanstandet wird, wird er zur Überprüfung durch das Bug-Dispute-Team gesperrt.

Platzhalter-Reports sind strengstens verboten.

Basierend auf den in deinem Tester-Profil registrierten Geräten und anderen Informationen wählt das System eines der Geräte aus und lädt dich zur Teilnahme am Test ein. Je nach den verfügbaren Plätzen für jeden Testlauf kannst du möglicherweise kein anderes Gerät auswählen als das, das das System ausgewählt hat. Sobald für ein bestimmtes Gerät eingeladen wurdest, kannst du nicht zu einem anderen Gerät wechseln. Daher kannst du nur Bugs melden, die auf diesem Gerät gefunden wurden.

Falls erforderlich, hat das Testlio-Bug-Formular folgende Struktur:

Der Schweregrad, das Feature und die Labels können as Dropdown-Listen ausgewählt werden; die anderen Abschnitte, abgesehen vom Anhang, sind Vorlagen, die Tester manuell ausfüllen müssen. Dies gilt für jeden fehlgeschlagenen Schritt, gemeldeten Bug oder durchgeführte Reproduktion.

In jedem Bug-Titel muss zu Beginn ein Präfix des Abschnitts angegeben werden, in welchem das Problem auftritt, bevor der eigentliche Titel formuliert wird, sofern nicht anders angegeben.

Das Bug-Formular von Test IO hingegen vereinfacht die Dokumentation der Tester mit der folgenden Struktur:

Du musst keinen spezifischen Formatvorgaben folgen, um einen Titel zu erstellen. Du musst jedoch angeben, was passiert ist, wo der Bug aufgetreten ist und wann er ausgelöst wurde.

Auf unserem Bug-Formular musst du keine Schrittnummern hinzufügen; unser Formular erzeugt sie automatisch. Du kannst die Schritte nach Belieben verschieben und neu anordnen.

Mit Ausnahme des Browsers bei Website-Tests werden die Geräteinformationen aus dem von dir ausgewählten Gerät abgerufen, wenn du an einem Testlauf teilnimmst und können danach nicht geändert werden.

Testlio klassifiziert Bugs in der Regel wie folgt:

Für funktionale Bugs sind zwei Anhänge zur Dokumentation erforderlich.

Lokalisierungstests erfordern die Überprüfung des UI-Problems und des Inhalts selbst.

Test IO kategorisiert Bugs als:

Wir führen keine Sicherheitstests durch.

​

Hier sind weitere Spezifikationen: Content-Bugs sind mit jeder Art von Informationen verbunden, nicht nur Text (z. B. Übersetzungen; Rechtschreibfehler werden nicht gemeldet), daher handelt es sich bei fehlenden Bildern und Schaltflächen um Content-Bugs und nicht um visuelle Bugs.

Funktionale Bugs, die als Performance-Probleme angesehen werden, wie endloses Laden, können als funktionale Bugs betrachtet werden, wenn sie sich direkt auf Endbenutzer auswirken, beispielsweise beim Zugriff auf Inhalte oder dem Fortschritt bei einer Aufgabe.
​

Jedoch handelt es sich in spezifischen Performance-Testläufen, die bei Bedarf durchgeführt werden, beim endlosen Laden um ein Performance-Problem und sie werden entsprechend gemeldet. Daher sind die Messung der Internetgeschwindigkeit und die .har-Dateien Teil der Anhänge, die jedem Report beigefügt werden müssen.

Die Schweregrade für funktionale Bugs bei Testlio sind:

Die Tester entscheiden, welcher Schweregrad am besten auf das Problem zutrifft, basierend auf einer kurzen Erklärung für jeden Schweregrad.

Bei Test IO bieten wir spezifische Szenarien an, um dich bei der korrekten Auswahl des Schweregrades zu unterstützen. Dabei handelt es sich um die folgenden drei:

Die von uns bereitgestellten Szenarien helfen dabei, das Problem auf unterschiedliche Weisen zu analysieren, beispielsweise indem du die beeinträchtigte Funktionalität und das potenzielle Auswirkungen des Bugs auf die Endbenutzer berücksichtigst. Beispielsweise sind Showstopper-Bugs kritisch, während bei einem einfachen und intuitiven Workaround, wie dem erneuten Laden der Seite, der richtige Schweregrad Low sein wird.

Testlio ermöglicht Testern, relevante Dateien an ihre Bug-Reports anzuhängen, wie Screenshots, Screencasts und Protokolldateien (Crash-, Konsolen- und manchmal Charles-Log-Dateien).

Log-Dateien sind obligatorisch und funktionale Bugs müssen zwei verschiedene Anhänge bereitstellen.

Diese Anhänge müssen einen aussagekräftigen Namen haben, um dem Entwickler, der sie herunterlädt, bei der Diagnose des Problems zu helfen.

Während ein Screenshot oder ein Screencast visuelle Bugs leicht dokumentieren kann, erfordern funktionale Bugs zwei Anhänge pro gemeldetem Problem.

Screencast:

Alle Bugs müssen über einen Screenshot der Seite verfügen (auch wenn der Tester einen Screencast angehängt hat), und eine Textdatei mit dem HTML-Codeausschnitt des Problems muss hinzugefügt werden. Manchmal reicht die Information im Abschnitt 'Anhänge im Bug-Report' aus.

Test IO-Tester können Anhänge hinzufügen, wie Screenshots, Screencasts und Absturzprotokolle.

Screenshot:

Screencast:

Testlio fördert die Kommunikation zwischen Testern und Testleitern über den Chat der Plattform oder den RocketChat-Kanal für den jeweiligen Arbeitsbereich. Tester werden jedoch nur zu diesem Chat hinzugefügt, wenn sie eine Zertifizierungsprüfung bestanden haben oder dies für den Arbeitsbereich erforderlich ist.

E-Mails werden verwendet, um Verbesserungswünsche an Tester zu senden.

Test IO legt Wert auf Echtzeitkommunikation.

Tester haben die Möglichkeit, miteinander zu kommunizieren und über Bugs und Probleme zu diskutieren - sowohl im Test-Chat, in Kommentaren zu Bug-Reports, über den Discord-Server und E-Mail-Plattformen zwischen Testern, Teamleitern (TL), Customer Success Managern (CSMs) und Kunden. Tester können Fragen stellen, Klarstellungen suchen und sofortiges Feedback von den oben genannten Interessengruppen erhalten, da diese mehr Informationen über die Bug-Reports der Tester anfordern können.

Testlio zahlt Tester pro Stunde aus und nicht pro Bug.

Die Auszahlung bei Test IO hängt von der Art der durchgeführten Aufgabe ab. Einige Aufgaben sind direkt mit Testläufen verbunden. Andere, wie Reproduktionen, Bug-Fix-Confirmations und Bug-Report-Confimations, können jedoch auch ohne Teilnahme am entsprechenden Testlauf durchgeführt werden.

In einem Testlauf hängt die Auszahlung jedoch von der Art und dem Schweregrad des Bugs sowie den Gerätespezifikationen ab.

Bei Testlio werden freiberufliche Tester nach den Stunden bezahlt, die ihnen zugewiesen wurden, um spezifische Aufgaben innerhalb eines Testlaufs in einem bestimmten Projekt auszuführen.

Bei Test IO können freiberufliche Tester diese bezahlten Aufgaben durchführen und die folgenden Boni erhalten:​

Anstelle darauf zu warten, dass der Kunde deine Arbeit bei Test IO akzeptiert oder ablehnt, wirst du bezahlt, sobald der Teamleiter deinen Bug oder deine Ausführung annimmt.