Testlio suit un processus de test bien organisé lié aux espaces de travail. Les testeurs sont affectés à des espaces de travail spécifiques pour réaliser une grande variété de tests, comme des tests exploratoires, des tests de paiement, des tests de régression fonctionnelle, des tests de localisation, des tests d'accessibilité, des tests d'utilisabilité, des sessions de tests en direct, et des tests d'instrumentation SDK, où ils exécutent des cas de test de haut en bas.

Si une étape du cas de test échoue, les testeurs doivent signaler des bogues ou des problèmes. S'il s'avère que le bogue a déjà été signalé, ils doivent effectuer une reproduction.

Les testeurs peuvent repérer des bogues en double lorsqu'ils signalent un problème en consultant les rapports d'autres testeurs ou en faisant des recherches dans le ❝Navigateur de problèmes❞. Si le titre comporte au moins 30 caractères, les testeurs recevront automatiquement des suggestions de problèmes similaires déjà signalés.

L'équipe de test choisit les testeurs en fonction de leur profil et des informations sur leurs appareils pour répondre aux exigences de l'espace de travail. Ensuite, elle les invite par e-mail en deux étapes. La première invitation concerne l'espace de travail, et la deuxième étape concerne un lot où l'heure, l'appareil et l'horaire de test sont précisés.

En fonction de l'espace de travail, les testeurs peuvent ou non être invités à rejoindre un lot; cela dépend des besoins spécifiques de l'espace de travail.

Les testeurs doivent répondre à l'invitation pour être inclus dans le lot. Laisser expirer les invitations est considéré comme un problème sérieux.

Une fois qu'ils ont terminé le temps qui leur a été alloué pour le test, les testeurs doivent remplir une enquête de feedback.

Après avoir signalé un problème, le responsable des tests peut l'approuver, demander des informations supplémentaires ou le clore. La clôture d'un problème équivaut à un rejet et aura un impact négatif sur la note du testeur.

Par conséquent, les testeurs attendent souvent que d'autres signalent des problèmes avant de créer une reproduction, car soumettre un problème pourrait affecter négativement la note du testeur s'il est clos (rejeté). En revanche, si le bogue est accepté, cela ne procure aucun avantage.

Test IO adopte un processus de test agile qui englobe la planification des tests, leur exécution, ainsi que des retours continus. Les testeurs participent à des cycles de test correspondant à leur langue, leurs appareils et leur emplacement. Nous mettons l'accent sur les tests exploratoires en temps réel et manuels, permettant aux testeurs de découvrir et de signaler des bogues à la volée.

Pour commencer à contribuer à un cycle de test, les testeurs doivent lancer les sessions de test à l'avance et reconnaître avoir lu et compris les instructions des fonctionnalités incluses.

Afin d'identifier les doublons, lors de la soumission d'un bogue, la liste des ❝Bogues similaires❞ sur le côté droit du formulaire de bogue affichera les bogues déjà soumis dans le test actuel. Vous pouvez également rechercher et filtrer les bogues ainsi que consulter la liste des Bogues connus.

En cas de rejet d'un rapport de bogue, cela aura un impact négatif sur les scores du testeur, en fonction du type de rejet reçu.

Les testeurs ont la possibilité de contester les bogues rejetés par les chefs d'équipe. Une fois qu'un rapport est contesté, il est verrouillé en attente de révision par l'équipe chargée de la contestation des bogues.

Les rapports contenant des espaces réservés sont formellement interdits.

Le système choisit l'un de tes appareils enregistrés dans ton profil et t'invite à rejoindre le test. En fonction des places disponibles pour chaque cycle, te pourrais ne pas pouvoir le choix de prendre un autre appareil que celui désigné par le système. Une fois que t'as été invité sur un appareil, tu peux pas switcher vers un autre. Du coup, tu peux soumettre tes bogues trouvés que sur cet appareil.

Quand nécessaire, le formulaire de bogue ou de problème de Testlio suit la structure suivante:

La gravité, la fonctionnalité et les étiquettes sont présentées sous forme de listes déroulantes pour choisir parmi différentes options. Les autres sections, à l'exception de la pièce jointe, sont des modèles que les testeurs doivent remplir manuellement. Ceci est applicable à chaque étape échouée, bogue signalé ou reproduction effectuée.

Chaque problème doit avoir un préfixe indiquant la section où le problème se produit avant le titre, sauf indication contraire.

Le formulaire de rapport de bogue de Test IO, en revanche, simplifie la documentation des testeurs avec la structure suivante:

Tu n'as pas besoin de suivre un format spécifique pour construire un titre. Cependant, tu dois décrire ce qui s'est passé, où le bogue s'est produit, et quand il s'est déclenché.

Sur notre formulaire de bogue, pas besoin d'ajouter le numéro d'étape; notre formulaire le fournit déjà. Tu peux les faire glisser et les réorganiser comme tu veux.

Sauf pour le navigateur lors des tests de site Web, les infos sur l'appareil sont prises de celui que t'as choisi en participant à un cycle de test, et ça peut pas être changé après.

En règle générale, Testlio classe les problèmes de la manière suivante:

Les problèmes fonctionnels exigent deux pièces jointes à des fins de documentation.

Les tests de localisation demandent la vérification tant de l'interface utilisateur (UI) que du contenu proprement dit.

Test IO classe les bogues de la manière suivante:

Nous ne réalisons pas de tests de sécurité.

Quelques spécifications supplémentaires: les bogues de contenu sont liés à tous les types d'informations, pas seulement au texte (par exemple, les traductions ; les fautes de frappe ne sont pas signalées). Ainsi, les images manquantes et les boutons manquants relèvent des bogues de contenu plutôt que des bogues visuels.

Les bogues fonctionnels incluent les problèmes de performance, comme le chargement infini, s'ils affectent directement les utilisateurs finaux. Par exemple, l'accès au contenu ou la progression dans une tâche.

D'autre part, lors des cycles de test de performance, qui sont effectués sur demande, le chargement infini est considéré comme un problème de performance et est signalé en tant que tel. Par conséquent, la mesure de la vitesse Internet et les fichiers .har font partie des pièces jointes nécessaires à inclure dans le rapport.

La gravité des bogues pour les bogues fonctionnels chez Testlio est catégorisée comme suit:

Les testeurs décident de la gravité qui convient le mieux au problème en se basant sur une brève explication de chaque niveau de gravité.

Chez Test IO, on propose des scénarios spécifiques pour t'aider dans la sélection correcte de la sévérité ; il y en a seulement trois:

Les scénarios qu'on fournit vont t'aider à analyser le problème de différentes manières, en tenant compte de la fonctionnalité compromise et de l'impact potentiel du bogue sur les utilisateurs finaux. Par exemple, les bogues bloquants sont considérés comme critiques, tandis que si une solution facile et intuitive, comme le rechargement de la page, existe, la sévérité correcte sera faible.

Testlio autorise les testeurs à inclure des fichiers pertinents dans leurs rapports de bogue, tels que des captures d'écran, des enregistrements vidéo de l'écran (screencast) et divers fichiers journaux (crash, console, et parfois des fichiers de log Charles).

Les fichiers journaux sont requis, et pour les bogues fonctionnels, deux pièces jointes distinctes sont nécessaires.

Ces pièces jointes doivent porter un nom significatif afin d'aider le développeur qui les télécharge à diagnostiquer le problème.

Alors qu'une capture d'écran ou un enregistrement vidéo de l'écran peut documenter facilement les bogues visuels, les bogues fonctionnels exigent deux pièces jointes par problème signalé.

Enregistrement vidéo de l'écran:

Tous les problèmes doivent avoir une capture d'écran de la page (même si le testeur a joint un enregistrement vidéo de l'écran), et un fichier texte contenant un extrait du code HTML du problème doit être ajouté. Parfois, les informations dans la section ❝Pièces jointes dans le rapport de bogue❞ suffisent.

Les testeurs de Test IO peuvent inclure des pièces jointes, comme des captures d'écran, des enregistrements d'écran et des journaux de plantage.

Captures d'écran:

Enregistrements d'écran:

Pour les tests de performance, les fichiers .har sont requis.

Testlio encourage la communication entre les testeurs et les responsables de test via la plateforme de chat ou le canal RocketChat spécifique à l'espace de travail. Cependant, les testeurs ne sont intégrés à ce chat que s'ils ont réussi un test de certification ou si leur présence est nécessaire pour l'espace de travail.

L'e-mail est employé pour adresser aux testeurs des demandes d'amélioration.

Test IO met l'accent sur la communication en temps réel, permettant aux testeurs de collaborer et de discuter des problèmes via le chat de test, les commentaires des rapports de bogue, le serveur Discord et les plateformes de messagerie entre les testeurs, les chefs d'équipe (TL), les gestionnaires de la réussite des clients (CSM) et les clients. Les testeurs peuvent poser des questions, demander des éclaircissements et recevoir des retours instantanés de ces parties prenantes, car celles-ci peuvent demander des informations sur les tâches des testeurs.

Testlio rémunère les testeurs à l'heure, et non en fonction du nombre de bogues signalés.

Chez Test IO, le paiement dépend du type de tâche effectuée. Certaines tâches sont directement liées aux cycles de test. En revanche, d'autres, comme les reproductions, la confirmation de la correction de bogue et la confirmation de rapport de bogue, peuvent être effectuées sans rejoindre le cycle de test auquel le rapport appartient.

Cependant, dans le cadre d'un cycle de test, le paiement dépend du type et de la gravité du bogue, ainsi que des spécifications de l'appareil.

Chez Testlio, les testeurs indépendants sont rémunérés en fonction du nombre d'heures qui leur sont attribuées pour exécuter des tâches spécifiques au sein d'un projet donné.

Chez Test IO, les testeurs indépendants peuvent faire les missions rémunérées suivantes et recevoir les bonus correspondants:

Au lieu d'attendre que le client accepte ou rejette ton travail chez Test IO, tu reçois ton paiement dès que le chef d'équipe prend en compte ton bogue ou ton exécution.