Menu

L'art du rapport de bogues: comment commercialiser et corriger vos bogues?

art bug reporting

Essayez Notre Instrument Pour Éliminer Les Problèmes

Pourquoi le marketing d'un bug est-il nécessaire?

Les premières choses qui me viennent à l'esprit lorsque je commence à écrire cet article sont les mots de Cem Kaner - «Le meilleur testeur n’est pas celui qui trouve le plus de bogues ou qui embarrasse la plupart des programmeurs. Le meilleur testeur est celui qui corrige le plus de bogues. »

Maintenant - Quelle est la différence entre trouver la plupart des bogues et correction de la plupart des bogues ?

N'est-il pas évident qu'un bogue enregistré dans un système de gestion des bogues doit être corrigé par le développeur? La réponse est non. Des facteurs tels que le délai de commercialisation du produit, le temps nécessaire pour terminer le projet dans les délais et les développeurs travaillant en des calendriers serrés peu pratiques, etc. obligent les entreprises à publier le produit avec peu de bogues qui n'affecteront pas largement les utilisateurs.

Art de rapport de bogue

(image la source )

Qui donne la confiance à la direction en déclarant que les bogues présents dans le produit n’auront pas d’incidence sur la confiance du client, la fiabilité et l’intérêt des parties prenantes? - L'ingénieur de test ou l'équipe de test - il est du devoir de chaque ingénieur de test de corriger les bogues qui pourraient avoir un impact négatif sur la qualité du produit.

La priorité du bug , à mon avis, dépend en grande partie de la façon dont un problème est présenté par le testeur aux équipes de développement et de gestion.

Pensez-y comme à la publicité ou au marketing du problème - cela implique 2 étapes:

  1. Écrire ou signaler correctement les bogues
  2. Tout savoir sur le bogue, afin que tous les détails supplémentaires puissent être mieux expliqués

Ce que vous apprendrez:

L'art de signaler les bogues

Oui, le signalement de bogues est un art . La manière dont un bogue est écrit montre la compétence technique, l'expertise du domaine et les capacités de communication d'un ingénieur de test.

En règle générale, un bogue doit contenir les informations suivantes:

  • Résumé du bogue
  • Étapes à suivre pour reproduire
  • Pièces jointes (instantané, fichiers journaux, etc.)
  • Reproductibilité des bogues
  • Gravité du bogue
  • Version du logiciel, informations sur l'environnement
  • Autres informations basées sur les exigences organisationnelles.

Une note importante: Creusez toujours plus profondément pour trouver la cause profonde du problème et le signaler. Par exemple, un simple échec de connexion avec la bonne combinaison de nom d'utilisateur et de mot de passe peut être lié à diverses raisons telles que:

  1. Identifiants de connexion non validés du tout
  2. Problèmes de délai d'expiration du réseau en cas de connexion à distance
  3. Le système peut considérer tous les CAPS comme non-CAPS.

Ainsi, en tant que testeur, vous devriez être capable de déchiffrer les différences tout en suivant les instructions de résumé des bogues:

  • 'Impossible de se connecter avec le nom d'utilisateur et le mot de passe corrects'
  • 'Impossible de se connecter avec le nom d'utilisateur et le mot de passe corrects, lorsque le nom d'utilisateur ou le mot de passe contient un mélange d'alphabets CAPS et non CAPS.'

Ce dernier est une description très claire du problème et est sans ambiguïté. Avec cela, vous augmentez non seulement votre crédibilité en tant que testeur, mais vous signalez également le problème réel au lieu d'un symptôme.

Voyons maintenant chaque champ impliqué dans un rapport de bogue et discutons des aspects importants de chacun:

#1. Résumé du bogue

Un résumé de bogue devrait fournir un aperçu rapide de la nature exacte du problème. Il doit être précis et bien dirigé.

Exemple :

En dehors de la théorie, je vais essayer d’expliquer avec des exemples.

Supposons un simple module de connexion. Supposons le problème car un nouvel utilisateur visitant un site Web ne peut pas se connecter avec son mot de passe par défaut. Quand j'ai présenté le même scénario à de nombreux étudiants que j'ai formés lors de la phase initiale de formation, il y a eu plusieurs réponses sous forme de résumé de bogue. Vous trouverez ci-dessous quelques exemples de l'apparence du résumé:

comment ajouter un élément au tableau java

' Le nouvel utilisateur ne parvient pas à se connecter »

'La connexion de l'utilisateur ne fonctionne pas comme prévu'

'L'utilisateur ne peut pas se connecter avec le mot de passe correct'

résumé de bogue faux et correct

Parmi les exemples ci-dessus, pouvez-vous choisir une déclaration qui décrit réellement le problème? Je ne pense pas. Le résumé doit toujours donner une information complète sur le scénario défaillant.

Considérez la déclaration suivante:

'Le nouvel utilisateur ne peut pas se connecter avec le mot de passe par défaut fourni par e-mail ou par SMS'

Comme vous pouvez le voir, à partir de la déclaration ci-dessus, un développeur peut clairement comprendre quel est le problème et où se trouve le problème.

Alors, essayez de trouver les bons mots pour décrire le résumé qui donnerait directement l'information. Les déclarations génériques telles que «ne fonctionne pas correctement», «ne fonctionne pas comme prévu», etc., doivent être évitées.

# 2. Procédure de reproduction et pièces jointes

Les insectes non reproductibles passent toujours au second plan même s'ils peuvent être importants. Par conséquent, prenez bien soin d'écrire les étapes correctement et de manière descriptive.

Les étapes doivent être précises et exactement les mêmes que celles qui ont conduit au problème. Pour les bogues liés aux fonctionnalités, l'exemple suivant est le meilleur exemple.

Exemple :

Considérez le même problème mentionné dans la section précédente.

  1. Créez un nouvel utilisateur à l'aide de l'option Inscription sur la page d'accueil. (Exemple de nom d'utilisateur: HelloUser)
  2. Un e-mail et un SMS seront reçus avec un mot de passe par défaut. L'identifiant de messagerie et le numéro de téléphone mobile pour les SMS sont fournis lors de la création de l'utilisateur à l'étape 1. (Exemple d'e-mail: HelloUser@hello.com , Exemple de numéro de mobile: 444-222-1123)
  3. Sélectionnez l'option de connexion sur la page d'accueil.
  4. Dans le champ de texte du nom d'utilisateur, indiquez l'exemple de nom d'utilisateur fourni à l'étape 1.
  5. Dans le champ mot de passe, indiquez le mot de passe par défaut reçu par e-mail ou SMS.
  6. Cliquez sur le bouton Connexion
  7. Résultat attendu: L'utilisateur doit pouvoir se connecter avec le nom d'utilisateur et le mot de passe fournis et accéder à la page du compte d'utilisateur.
  8. Résultat actuel: Le message «Nom d'utilisateur / mot de passe invalide» s'affiche.

étapes du rapport de défaut

Si l'une des informations n'est pas fournie dans l'exemple ci-dessus, elle entraîner des lacunes de communication et le développeur ne pourra pas reproduire le problème. Les étapes doivent être spécifiques et détaillées avec les exemples de données que vous utilisez pendant les tests.

Si possible ou le cas échéant, fournissez un instantané de ce que vous voyez exactement à l’écran. De cette façon, il fournira non seulement une bonne vue du problème aux développeurs, mais également une preuve du résultat de votre test.

Le non fonctionnel des cas de test tels que des cas de test de stress, de stabilité ou de performance en plus des détails ci-dessus, les informations sur le scénario qui cause la contrainte au système peuvent être rapportées telles quelles. De plus, il existe peu de systèmes qui rapportent des journaux pour chaque opération effectuée. Les journaux sont généralement des instructions d'impression fournies par les développeurs dans leur code. Chaque fois qu'un module est exécuté, les journaux correspondants seront imprimés ou affichés. Lorsque les journaux sont disponibles, cela aiderait les développeurs dans une large mesure à reproduire le problème.

# 3. Reproductibilité des bogues

Un problème, grand ou petit, sera priorisé en fonction de la reproductibilité. Il peut être vu toujours, parfois, rarement ou même une seule fois. Un problème qui est reproduit comme «toujours» aura une priorité plus élevée que le reste.

impossible de reproduire un défaut

Il est donc du devoir d'un ingénieur de test de suivre le scénario exactement pour le problème qui est toujours reproduit. Parfois, il peut y avoir quelques problèmes hors de contrôle d'un ingénieur de test, ce qui entraînerait la reproduction d'un problème seulement quelques fois, mais dans plusieurs essais. Dans de tels cas, mentionnez toujours le nombre d'essais, un scénario particulier est exécuté ainsi que le nombre de fois où le problème est vu pendant ces essais.

Ceci, à son tour, ajouterait de la crédibilité au rapport de bogue que vous avez mentionné. Encore une fois, cela améliorerait votre réputation en tant que testeur. Je vous expliquerai plus tard les raisons d’avoir une bonne réputation.

# 4. Gravité du bogue

La gravité est sans aucun doute l'un des plus grands influenceurs pour prioriser le bug.

Voici les différentes catégories de gravité. Veuillez noter que ce ne sont que des échantillons généraux et que cela varie d'une entreprise à l'autre.

  1. Gravité 1 - Show Stopper - pour les bogues catastrophiques, sans être corrigés, l'utilisateur ne pourra pas continuer à utiliser le logiciel et il n'y a pas de solution de contournement possible
  2. Gravité 2 - Élevée - pour les bogues similaires à la gravité 1, mais il existe une solution de contournement
  3. Gravité 3 - Moyenne
  4. Gravité 4 - Faible
  5. Gravité 5 - Trivial.

Par exemple, comparons deux problèmes similaires.

Dans nos décodeurs, peu de fournisseurs de services fournissent les informations de fréquence du service tel qu'il est actuellement réglé. Supposons que la fréquence soit affichée comme 100 MHz au lieu de 100,20 MHz. Cela peut ne pas affecter la visualisation des services par l'utilisateur, mais peut avoir un impact en termes de surveillance des diagnostics des décodeurs. Cela peut donc être présenté comme un problème de gravité 3.

En supposant un problème similaire dans le domaine bancaire: si le solde de votre compte s'affiche à 100 USD au lieu de 100,20 USD, imaginez l'impact du problème. Il doit s'agir d'un défaut de gravité -1. Comme vous pouvez le voir dans les deux cas, le problème est très similaire: l'interface utilisateur n'affiche pas les chiffres après la virgule décimale. Mais, l'impact varie selon le domaine concerné.

Participation efficace aux réunions de contrôle de version logicielle

Habituellement, chaque organisation a son propre processus pour enquêter et hiérarchiser les bogues. En général, une réunion aurait lieu à des intervalles spécifiques au cours du projet pour discuter des bogues et les hiérarchiser.

Le processus lors de ces réunions est le suivant:

  1. Recherchez la liste des bogues du système de gestion des bogues en fonction de leur gravité.
  2. Consultez le résumé et discutez de l’impact du bogue sur l’expérience de l’utilisateur lors de l’utilisation d’un logiciel.
  3. Sur la base de l'évaluation des risques et de l'impact, définissez la priorité et attribuez le bogue à un développeur approprié pour le corriger.

Au cours de l'étape 2, il est impératif que chaque ingénieur de test préconise l'impact du bogue sur l'expérience utilisateur si le bogue ne reçoit pas la priorité qu'il mérite. Après tout, ce sont nous les ingénieurs de test qui considèrent le point de vue d'un utilisateur pour écrire des cas de test et tester le produit.

Considérez l'exemple ci-dessus de ne pas afficher les chiffres après la virgule décimale dans un domaine bancaire. Pour un développeur, cela peut sembler un problème moins grave. Il pourrait argumenter qu'au lieu de déclarer la variable comme un entier, il la déclarerait comme une virgule flottante pour résoudre le problème et donc moins grave.

Mais en tant que testeur, votre rôle consiste à expliquer la situation du client. Votre point devrait être de savoir comment l'utilisateur se plaindrait dans ce scénario. Le testeur devrait dire que cela provoquera la panique parmi les utilisateurs car le client perd son argent en centimes.

Impact de ne pas commercialiser correctement un bogue

Si un bogue n'est pas commercialisé correctement, il créera des problèmes tels que:

  • Priorité de défaut incorrecte
  • Retard dans la résolution des problèmes importants
  • Sortie de produit avec de graves défauts
  • Commentaires négatifs des clients
  • Dévaluer la valeur de la marque

Impact de ne pas commercialiser correctement un bogue

Hormis toutes les raisons mentionnées ci-dessus, il est très important de construire votre réputation d'ingénieur de test . C'est plus comme développer une valeur de marque pour vous-même.

Dans la phase initiale de votre carrière, si vous pouvez garder votre nombre de «Cannot Reproduce» ou «Need More Info» ou «Not a Valid Bug» ou des changements de gravité aussi bas que possible, à un moment donné vos bogues ne seront pas examinés du tout et ils seraient directement attribués au développeur approprié pour être corrigés.

Pour développer une telle valeur de marque et gagner la confiance de votre équipe et des équipes de développement / ou de gestion, vous devez développer des compétences techniques en termes de test des connaissances, du domaine et des compétences en communication.

Conclusion

Tout produit ou service, grand ou petit, est toujours voué à l'échec sans publicité appropriée. Une fois qu'une marque est établie, tout petit produit peut être un succès auprès du public.

Cela dit, la sur-publicité d'un produit peut également nuire à la réputation.

Ainsi, un bogue doit toujours être écrit de manière claire, concise et précise afin de donner un emplacement exact du bogue dans la carte logicielle étendue / exhaustive. Je répète que cela améliore non seulement la qualité du logiciel, mais réduit également le coût des tests et du développement du logiciel dans une large mesure.

Il n’est pas trop tard maintenant! Allons-y et corrigeons les bogues tout de suite!

java interview question et réponses pour les nouveaux

lecture recommandée

^