Motivation
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.
Tester l'abonnement par e-mail en utilisant une adresse e-mail à laquelle tu n'as pas accès
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:
Si tu testes avec des adresses e-mail commerciales, utilise une boîte de réception existante. De cette manière, nous n'enverrons pas de demandes non valides à Gmail, Outlook, ou tout autre fournisseur de messagerie.
Si tu souhaites tester la validation, tu dois utiliser les adresses e-mail de l'équipe QA. Étant donné que tous les noms d'utilisateur valides de l'équipe QA existent, les testeurs n'enverront jamais de demande à une boîte de réception inexistante. Ainsi, ils testeront uniquement la validation elle-même.
Pour les environnements de mise en scène, les adresses e-mail de l'équipe QA doivent toujours être utilisées pour l'inscription régulière (sauf indication contraire du client).
Pour les validations d'adresses e-mail invalides, utilisez les exemples partagés dans l'article crée ta propre combinaison qui suit le même chemin.
Signalement des bogues liés à la validation du navigateur
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:
<input type="email" id="email"
pattern=".+@test\.io" size="30" required>
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 :
Lorsque tu te demandes quel type de validation d'entrée est mise en place par le client pour l'environnement particulier (site web), fais un clic droit sur la page, puis clique sur Afficher la source de la page. Si tu remarques le code
<input type="email"...>, cela signifie que le champ d'e-mail est validé par le navigateur, et tu ne dois pas signaler le bogue dans le test."
Tester sans activer le proxy lorsque cela est demandé dans les instructions de test
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:
Lorsque tu acceptes le cycle de test dans lequel l'utilisation d'un proxy pour accéder à l'environnement de test est requise, il est impératif de suivre précisément les instructions de test. Sinon, les bogues que tu découvres ne seront pas considérés comme légitimes.
Reclassifier les bogues de contenu et de visualisation en bogues fonctionnels pour les inclure dans le cadre du test
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:
Concentre-toi sur l'apprentissage de la distinction entre les bogues de contenu, de visualisation et fonctionnels. Comprends que si les bogues de contenu et de visualisation n'impactent pas la fonctionnalité du produit ou s'il existe une solution intuitive, tu ne devrais pas soumettre un bogues fonctionnel.
Ne pas mettre à jour le système d'exploitation de l'appareil avant d'accepter le cycle de test bêta
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:
Il est humain de commettre des erreurs, mais assure-toi toujours de lire les instructions de test, car elles contiennent des informations importantes sur l'appareil demandé et le système d'exploitation bêta requis.
Dans les cas où la version bêta du système d'exploitation est requise, tu ne dois pas tester le produit avec la version officielle, mais avec la version bêta.
Sélectionner le mauvais appareil dans le rapport de bogues
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:
Avant de cliquer sur ❝Soumettre le bogue❞, assure-toi de sélectionner les bonnes informations sur le bogue, telles que le type de bogue, la gravité, l'appareil et le navigateur. Si tu as accidentellement choisi le mauvais appareil ou le mauvais navigateur, tu peux le corriger tant que personne d'autre ne l'a signalé correctement, et ce, avant que le chef d'équipe ne vérifie ton rapport de bogue.
Envoyer un message dans le chat du cycle de test pour informer le TL que tu as apporté les modifications demandées dans le rapport de bogue
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:
Lorsque tu réponds à la demande d'informations avec toutes les informations nécessaires demandées par ton TL, retiens-toi d'envoyer plusieurs commentaires dans le rapport de bogue et des messages dans le chat du cycle de test. Les TL reçoivent des notifications concernant les demandes d'informations complétées, et il n'est pas nécessaire de se sentir nerveux ou impatient. Tous les bogues seront examinés à temps, car notre système n'autorise pas la clôture d'un test tant que les rapports de bogue ne sont pas examinés.
Utiliser Google Translate pour traduire l'environnement de test pendant l'enregistrement du bogue
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:
Chaque fois que tu testes un environnement dans une langue que tu ne parles pas, utilise l'outil de traduction tiers pour une meilleure compréhension du produit, mais désactive-le juste avant de commencer l'enregistrement d'une capture d'écran.
Reproduire un bogue "PASS" dans le test
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:
Lorsque tu vois le terme "PASS" dans le titre du rapport de bogue, veuillez ne pas soumettre de reproduction.
Penser à tort que le filtrage et le tri sont des fonctionnalités similaires
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.
Filtrage et tri sur les appareils mobiles et de bureau
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 manière la plus simple de différencier ces deux fonctionnalités est de regarder le type et le nombre d'options pour la fonctionnalité. La fonctionnalité sera un filtrage lorsqu'elle offre de nombreuses options qui décrivent les caractéristiques des articles physiques. La fonctionnalité sera un tri lorsque les options fournies sont peu nombreuses et destinées à afficher les articles d'une manière particulière.
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: