Test IO s'engage à soutenir la croissance des testeurs. Afin d'assurer que ta carrière de testeur emprunte la voie du succès, nous avons décidé de partager avec toi les erreurs les plus courantes commises par nos testeurs au début de leur parcours. Même les testeurs expérimentés font parfois des erreurs, mais ils en tirent des leçons.

Il est très tentant d'essayer de tout lors de tes tests, y compris des étapes inhabituelles qu'un utilisateur normal ne ferait jamais. Lorsque cette envie te prend, arrête-toi avant de soumettre un rapport de bogue. Réfléchis si tes étapes correspondent au comportement d'un utilisateur normal ou si le bogue que tu as trouvé intéressera nos clients. Pense toujours à l'impact que ton bogue pourrait avoir sur le flux de l'utilisateur moyen.

Voyons maintenant quelques exemples des erreurs les plus courantes que nous avons rassemblées pour toi.

Il arrive souvent que nos testeurs veuillent démontrer que le processus d'abonnement par e-mail ou d'inscription accepte des adresses e-mail invalides. Vérifier si le serveur accepte des adresses e-mail invalides est tout à fait acceptable et constitue une action utile pour nos clients. Avant de procéder à une telle pratique, assure-toi de comprendre la différence entre les adresses e-mail invalides et inexistantes. On pourrait penser que c'est la même chose, mais ce n'est pas le cas. Pour mieux comprendre ce qu'est une adresse e-mail invalide, veuillez lire cet article.

"D'un autre côté, les adresses e-mail inexistantes sont celles qui n'ont pas été créées par toi (ou par quelqu'un d'autre) et qui, par conséquent, n'existent pas dans le système. Une tentative de validation d'une adresse e-mail inexistante ne produira très probablement aucune réaction du serveur, car elle sera considérée comme valide si elle suit le modèle de structure d'e-mail. Ce comportement est attendu et ne doit pas être considéré comme un bogue.

La solution:

La validation du navigateur représente la validation de l'entrée HTML effectuée par le navigateur en fonction des attributs dans l'élément d'entrée.

Voici un exemple de validation du navigateur HTML5 pour une entrée d'e-mail:

Si tu observes quelque chose de similaire, cela signifie qu'une validation du navigateur est mise en place, et que cette validation n'est pas effectuée par JavaScript.

L'un des exemples les plus courants de validation du navigateur est l'affichage de la ligne rouge en zigzag sous le mot mal orthographié que tu saisis dans le champ de formulaire.

Signaler de tels bogues n'entre pas dans le cadre du cycle de test effectué par Test IO, et de tels bogues seront rejetés.

La solution :

Parfois, nos testeurs ne lisent pas attentivement les instructions de test, ce qui peut conduire au rejet de leurs rapports de bogues, voire, dans le pire des cas, à un avertissement de notre équipe de conformité. L'une des erreurs les plus courantes survient lorsque les testeurs n'utilisent pas de proxy alors que cela est requis. Nous avons effectué quelques investigations et voici ce qui posait problème aux testeurs:

Dans le cadre de tests récurrents, les testeurs lisent les instructions une fois. Lorsque le test suivant du même client, pour le même produit, arrive, les testeurs pensent que la stratégie de test devrait être la même et que la lecture des instructions serait une perte de leur temps précieux. C'est là qu'ils commettent une erreur. Le fait d'avoir le même titre de test ne garantit pas que l'accès à l'environnement de test suivra le même chemin.

Souvent, nos clients souhaitent séparer le trafic généré par nos testeurs du trafic des utilisateurs réels. Dans ces cas, nous utilisons un proxy. Une autre situation concerne l'accès à un environnement de mise en scène verrouillé pour quiconque n'a pas le mot de passe approprié : le proxy doit être activé. Si le testeur oublie d'activer le proxy, l'environnement de mise en scène renverra des erreurs 403 ou 1020. Signaler de tels problèmes entraînera le rejet des rapports en raison du non-respect des instructions de test.

La solution:

Il arrive parfois que nos testeurs, sans aucune intention, reclassent tous les bogues de Contenu et de Visualisation en bogues Fonctionnels parce qu'ils n'ont pas l'expérience nécessaire pour déterminer quels bogues devraient être reclassés en bogues fonctionnels. En conséquence, leurs rapports sont rejetés. Souvent, ces rejets sont dus à des raisons hors champ, ce qui signifie que la qualité et le classement du testeur en souffriront considérablement.

La solution:

Cette habitude est bien connue non seulement de nos débutants, mais aussi de nos testeurs expérimentés. Le plus souvent, cela n'est pas intentionnel. Nos testeurs participent à de nombreux tests chaque semaine, si bien qu'ils oublient parfois de mettre à jour les versions bêta du système d'exploitation.

La solution:

Parfois, les testeurs veulent être les plus rapides à signaler des bogues. Lorsqu'ils le font, il peut arriver qu'ils choisissent par erreur le mauvais appareil. S'ils ne passent pas à l'environnement correct avant que le chef d'équipe ne vérifie leur rapport de bogue, de bons bogues risquent d'être rejetés.

La solution:

Dans la phase initiale des tests, nos testeurs reçoivent de multiples demandes d'informations pour améliorer leurs rapports de bogue. Pendant cette période, les testeurs peuvent être impatients de voir le résultat de leur soumission. C'est à ce moment-là que les testeurs tombent généralement dans le piège d'envoyer plusieurs commentaires dans le Rapport de Bogue ou même des messages dans le chat du cycle de test pour informer le TL des modifications apportées. Cela te semble familier, n'est-ce pas ? Nous y sommes tous passés, et nous avons appris de nos erreurs. Mais nous voulons que tu sois plus malin que ça et que tu apprennes de nous.

La solution:

L'un des avantages de la technologie moderne est que tu n'as pas besoin de parler toutes les langues du monde pour tester le produit dans une langue étrangère. L'utilisation d'un outil de traduction tiers, comme Google Translate, est autorisée pendant les tests, mais assure-toi que le bogue que tu as trouvé n'est pas causé par l'utilisation de Google Translate. Parfois, Google Translate perturbe l'environnement et nos testeurs finissent par signaler des bogues qui n'existent pas. Dans d'autres cas, nos testeurs signalent un bogue qui existe, et qui n'est pas causé par Google Translate, mais ils oublient de désactiver Google Translate lors de l'enregistrement du bogue. Lorsque cela se produit, le bogue sera rejeté par le TL car il ne respecte pas nos normes.

La solution:

Ce comportement est observé dans les tests où nos testeurs sont invités à soumettre un seul bogue fonctionnel intitulé "PASS" pour prouver que le flux de travail décrit dans les instructions de test est réussi. La soumission de reproductions de tels bogues n'est pas autorisée, et de telles soumissions seront rejetées.

La solution:

Généralement, le filtrage et le tri sont présentés ensemble car ils aident les utilisateurs à gérer de grands ensembles d'articles (produits, films, billets, etc.); cependant, leur implémentation diffère grandement. Une fonctionnalité de filtrage réduit une collection d'articles en fonction de critères spécifiques tels que la taille, la couleur, la marque, et autres. Une fonctionnalité de tri ordonne un ensemble de données selon différents critères tels que du plus bas au plus élevé ou du plus récent au plus ancien.

Comprendre ces différences est crucial, car les bogues trouvés sur ces fonctionnalités appartiennent à des types différents. Par exemple, les problèmes liés à la fonction de tri sont des bogues fonctionnels, tandis que la plupart des problèmes de filtrage sont des bogues de contenu.

La solution:

La liste des bogues les plus courants ne se limite pas aux cas mentionnés. Pour plus de bogues courants et d'excellents conseils, nous vous suggérons d'écouter notre épisode de podcast: