3 worst defect reporting habits
Les défauts sont des affaires sérieuses et les petites erreurs peuvent coûter cher.
Vous savez quoi faire lorsque vous trouvez un défaut. Vous le signalez; soit dans un Suivi des défauts / Outil de gestion des défauts ou dans une feuille Excel. Les principes sous-jacents sont les mêmes pour les deux méthodes.
Les outils de gestion des défauts ne garantissent pas de meilleurs rapports. Ce sont les bonnes pratiques qui sauvent la mise.
Pour apprécier le bien, nous devons reconnaître ce qui ne l’est pas.
Ce que vous apprendrez:
- 3 pires habitudes de signalement des défauts et comment les briser
- # 1) Paresse
- # 2) Se précipiter
- # 3) Manque de créativité
- lecture recommandée
3 pires habitudes de signalement des défauts et comment les briser
Voici:
# 1) Paresse
Ne pas prendre le temps de faire de son mieux.
C'est le processus de suivi des défauts suivi dans la plupart des équipes:
(Remarque- cliquez sur n'importe quelle image pour une vue agrandie)
Comme vous pouvez le voir, Test lead examine les défauts avant de les envoyer hors des équipes QA.
Cet examen comprend la confirmation:
- Validité - Est-ce un bug?
- Complétude - Titre, étapes, données, capture d'écran, etc.
- Doublons
- Reproductible ou non… etc.
Je sais de première main qu'il est impossible pour un responsable QA d'être exhaustif à 100%.
Donc, l'attitude: «Je vais rapporter le problème comme je le souhaite. Le responsable QA peut revérifier. Il peut décider si le défaut est valide / complet ou non »est la fin de votre équipe QA et de votre crédibilité.
Saviez-vous que certains clients ont un SLA pour le nombre de défauts invalides acceptables? Une fois que le nombre dépasse, ils commencent à pénaliser les entrepreneurs pour chaque défaut invalide signalé?
Remède: Faites votre diligence raisonnable et soyez responsable de votre livrable. Un défaut est revenu pour pas assez d'informations ou que ce n'est pas un bug? Ce n’est pas toujours la faute de l’équipe de développement. Ce n’est pas qu’ils ne veulent pas être propriétaires des problèmes de l’application. Cela pourrait être un véritable gâchis de l'équipe d'assurance qualité. Ne laissez pas cela arriver.
# 2) Se précipiter
Faisons cela avec unExemple.
Ci-dessous, une capture d'écran de OpenEMR écran create-patient. C'est un système de gestion hospitalière open source.
Cet écran permet à l’utilisateur de saisir la date de naissance du patient via une fonction de calendrier. Ce qu'il ne fait pas, c'est restreindre l'entrée au choix dans le calendrier. Ce que je veux dire, c'est que vous pouvez choisir la date de naissance comme disons «31 mars 1983» dans le calendrier. Modifiez-le plus tard en «31-fév-1983».
Pourquoi le 31 février? Implémenter erreur de deviner et essayez une donnée négative sur le terrain; quel est le but des tests, n'est-ce pas?
Une fois terminé, je clique sur «Créer un patient». Comme la date n'est pas valide, je m'attends à ce que le système affiche une erreur et ne crée pas le patient. Mais cela ne se produit pas. Il crée le patient comme ci-dessous.
Notez les champs Âge et Date de naissance dans l'écran ci-dessous:
Lors du test, vous pouvez essayer ceci plusieurs fois et décider que:
- C'est un bug.
- C'est reproductible.
- Ce n'est pas un doublon (vérifiez auprès de votre équipe pour confirmer)
- Vous connaissez la description exacte du problème
- En outre, vous connaissez les étapes exactes qui y parviennent.
Maintenant que vous avez la matière première, vous êtes prêt à partir.
Vous commencez à le signaler. L'attribution de la gravité du défaut est une étape obligatoire et votre équipe peut utiliser quelque chose de similaire à tableau suivant pour référence:
Gravité | Impact |
---|---|
1 (critique) | • Ce bogue est suffisamment critique pour planter le système, endommager les fichiers ou provoquer une perte de données potentielle • Cela provoque un retour anormal au système d'exploitation (un message d'erreur ou de panne système apparaît). • Cela provoque le blocage de l'application et nécessite le redémarrage du système. |
2 (élevé) | ? Cela provoque un manque de fonctionnalités vitales du programme avec une solution de contournement. |
3 (moyen) | • Ce bogue dégradera la qualité du système. Cependant, il existe une solution de contournement intelligente pour obtenir la fonctionnalité souhaitée - par exemple via un autre écran. • Ce bogue empêche les autres zones du produit d'être testées. Cependant, d'autres domaines peuvent être testés indépendamment. |
4 (faible) | • Il y a un message d'erreur insuffisant ou peu clair, ce qui a un impact minimal sur l'utilisation du produit. |
5 (cosmétique) | • Il y a un message d'erreur insuffisant ou peu clair qui n'a aucun impact sur l'utilisation du produit. |
Étant donné que ce défaut ne plante pas le système, ne bloque pas une fonctionnalité vitale ou n'empêche pas les autres zones de l'application d'être testées, nous pourrions opter pour «Faible».
Ça a l'air juste?
MAL. D'après les données du patient, toutes les vaccinations et autres rappels sont en retard. Cela peut être correct ou non. De plus, pour un patient, son âge détermine s'il consulte un pédiatre ou un médecin généraliste, etc.
Il affecte les dosages des médicaments et de nombreux autres domaines de traitement que nous ne connaissons peut-être même pas.
Donc, je vais aller avec «High». Je conviens qu'il est peu probable que le personnel de l'hôpital entre la date de naissance d'un patient de manière erronée. Mais que ce soit un facteur qui influe sur la priorité du moment pour résoudre le problème.
Mon travail en tant que testeur est de m'assurer que je communique le mieux possible la gravité du problème.
Remède: Ne soyez pas pressé de signaler. Soyez sûr à 100% que vous comprenez l'impact des problèmes sous plusieurs angles. C'est la meilleure valeur ajoutée que les testeurs peuvent offrir. Nous ne disons pas simplement: «Quelque chose ne fonctionne pas». Nous disons également: «Voici ce qui se passera si cela continue de ne pas fonctionner.» Des tonnes de différence, n'est-ce pas?
# 3) Manque de créativité
Les testeurs ont une merveilleuse occasion de faire des suggestions pour améliorer le logiciel.
Dans votre Outil de gestion des défauts vous pouvez également soumettre une erreur de type 'Suggestion d'amélioration'. C'est là que vous pouvez faire preuve de créativité.
Remède: Sortez des sentiers battus. Si vous pensez qu'une certaine fonctionnalité manque un facteur «Wow» et que vous savez comment l'intégrer, proposez l'idée. Au pire, il pourrait être rejeté et c'est normal. L'essentiel est d'essayer.
Aussi, utilisez ce super pouvoir avec prudence. Essayez de ne pas faire de commentaires tels que 'Je déteste la couleur de la bannière, veuillez la changer.'
Voici un bonExempled'une suggestion d'amélioration que j'ai rencontrée: Remplacer «E-mail au concessionnaire» par l'option «Discuter avec le concessionnaire» sur le site d'un concessionnaire automobile. Il est prévu de convertir plus de trafic en ventes.
J'aurais aimé être aussi créatif! Mais peut-être pouvons-nous tous y travailler.
Voici un bonus. Une check-list pour se libérer de ces mauvaises habitudes:
1. Mon titre exprime-t-il le problème de manière claire et concise?
Par exemple:«Créer un patient ne fonctionne pas» n'est pas un bon titre. «Créer un patient échoue même lorsque tous les champs de saisie contiennent des valeurs correctes» est.
2. Quel est le taux de reproductibilité?
En d'autres termes, cela arrive-t-il toujours? Est-ce que je connais la séquence exacte des étapes qui répéteront le problème?
3. Ce problème est-il spécifique à la plate-forme, au navigateur ou à l'utilisateur?
Quatre. Les étapes sont-elles terminées et vous amènent à votre problème?
5 . Ai-je une capture d'écran incluse?
6. Dois-je annoter ma capture d'écran pour mettre en évidence des zones particulières?
7. Le nom du fichier image joint est-il descriptif?
N'utilisez pas quelque chose comme 'Untitled.jpg'. Donnez-lui un nom descriptif.
8. Ai-je inclus les données de test?
Par exemple:Pour un défaut dans un module d'administration nécessitant des informations d'identification d'autorisation, incluez-les. L'équipe de développement peut ou non avoir accès à l'environnement QA. Vous ne voulez pas de retard et de suivi sur quelque chose d'aussi basique que cela.
9. Puis-je donner d'autres détails pour renforcer mon défaut?
(Exemple:une référence au FRD ou une conversation avec le client, etc.)
dix. Est-ce que je comprends la gravité du problème sous différents angles?
Onze. Est-ce que je connais la cause première du problème? Si oui, ai-je des preuves (peut-être des fichiers journaux) et puis-je les inclure? Veuillez noter que vous ne le savez peut-être pas toujours ou n'avez pas besoin de le savoir. Mais si vous le faites, cela ne fait pas de mal de l’inclure.
12. Le rapport de défauts est-il exempt de problèmes de grammaire, de format, d'orthographe et de ponctuation?
la meilleure application de téléchargement de musique mp3
13. Est-ce que je connais un moyen d'améliorer le produit?
Pensez-vous que cela prend du temps? Eh bien, une fois que cela deviendra une habitude, ce ne sera plus le cas.
Enraciner pour mieux rapport de défauts routines!
A propos de l'auteur: Cet article est écrit par Swati, membre de l'équipe STH.
N'hésitez pas à poster vos questions / commentaires ci-dessous.
lecture recommandée
- Pourquoi le rapport de bogues est un art qui devrait être appris par chaque testeur?
- Qu'est-ce que le cycle de vie des défauts / bogues dans les tests logiciels? Tutoriel sur le cycle de vie des défauts
- Exemples de rapports de bogues pour les applications Web et produit
- Qu'est-ce que la technique de test basée sur les défauts?
- Processus de gestion des défauts: comment gérer efficacement un défaut
- Processus de triage des anomalies et moyens de gérer la réunion de triage des anomalies
- Comment rédiger un bon rapport de bogue? Trucs et astuces
- 3 stratégies pour traiter un défaut de bloqueur