uTest suit un processus de test structuré, comprenant généralement l'intégration au projet, l'exécution des cas de test, le signalement des bogues, et la clôture du cycle de test. Les testeurs se voient attribuer des cas de test spécifiques qu'ils exécutent dans l'environnement de test désigné. Après l'exécution, les testeurs soumettent des rapports de bogue détaillés à la plateforme.

Si un rapport de bogue est rejeté, cela impacte négativement 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 clients.

Les espaces réservés ne sont pas autorisés.

Les testeurs peuvent utiliser n'importe quel appareil enregistré s'il répond aux exigences du cycle de test.

L'ingénieur de test sélectionne les testeurs qui participeront à un test.

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.

Le formulaire de rapport de bogue sur uTest est structuré de la manière suivante:

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.

uTest classe les bogues de la manière suivante:

Les testeurs doivent identifier et signaler ces bogues avec précision.

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 sévérité des bogues dans uTest est classée comme suit:

Le testeur décide quelle sévérité correspond le mieux au problème.

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.

uTest permet aux testeurs de joindre des fichiers pertinents, tels que des captures d'écran, des enregistrements d'écran et des fichiers journaux, à leurs rapports de bogue.

Captures d'écran:

Enregistrements d'écran (screencasts):

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.

uTest encourage la communication entre les testeurs, les chefs de projet et les développeurs grâce à un système de messagerie dédié. Les testeurs peuvent poser des questions sur les exigences et interagir avec les parties prenantes tout au long du cycle de test.

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.

Chez uTest, le paiement dépend de la valeur du bogue de la manière suivante:

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 uTest, les testeurs peuvent effectuer les tâches suivantes:

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.