Menu

Suivi des bogues de projet en direct, mesures de test et signature des tests - Formation gratuite au contrôle qualité, jour 6

live project bug tracking

Essayez Notre Instrument Pour Éliminer Les Problèmes

C'est la dernière partie de notre « Formation aux tests de logiciels sur un projet en direct ' séries.

Il s'agira de défauts et de quelques sujets restants qui marqueront l'achèvement de la phase d'exécution des tests du STLC.

Dans le article précédent , pendant l'exécution du test, nous avons rencontré une situation dans laquelle le résultat attendu du scénario de test n'était pas atteint. De plus, nous avons identifié un comportement inattendu lors des tests exploratoires.

Suivi des bogues du projet en direct, mesures de test et approbation des tests

Que se passe-t-il lorsque nous rencontrons ces écarts?

Nous devons évidemment les enregistrer et les suivre pour nous assurer que ces écarts sont traités et finalement corrigés sur l'AUT.

#1) Ces écarts sont appelés défauts / bogues / problèmes / incidents / erreurs / défauts.

#deux) Tous les cas suivants peuvent être enregistrés comme défauts

  • Exigences manquantes
  • Exigences de travail incorrectes
  • Exigences supplémentaires
  • Incohérences du document de référence
  • Problèmes liés à l'environnement
  • Suggestions d'amélioration

# 3) L'enregistrement des défauts est principalement effectué dans des feuilles Excel ou via l'utilisation d'un logiciel / outil de gestion des défauts. Pour plus d'informations sur la gestion des défauts via des outils, essayez d'utiliser les liens suivants:

Ce que vous apprendrez:

Comment enregistrer efficacement les défauts

Nous allons maintenant essayer de voir comment enregistrer les défauts rencontrés dans l'article précédent dans une feuille Excel. Comme toujours, il est important de choisir un format ou un modèle standard.

le trafic du réseau sans fil peut être capturé avec des renifleurs

En règle générale, les colonnes suivantes font partie du rapport d'anomalie:

  • ID de défaut: Pour une identification unique.
  • Description du défaut: C'est comme un titre pour décrire brièvement le problème.
  • Module / section de l'AUT: Ceci est facultatif, juste pour ajouter plus de clarté afin d'indiquer la zone de l'AUT où le problème a été rencontré.
  • Étapes à suivre pour reproduire: Quelle est la séquence exacte des opérations à effectuer sur l'AUT pour recréer le bogue doit être répertoriée ici. De plus, si des données d'entrée sont spécifiques au problème, ces informations doivent également être saisies.
  • Gravité: Pour indiquer l'intensité du problème et éventuellement l'impact que cela pourrait avoir sur le fonctionnement de l'AUT. Les instructions sur la façon d'attribuer et les valeurs à attribuer dans ce champ se trouvent dans le document du plan de test. Alors, veuillez vous référer au Document de plan de test de l'article 3 .
  • Statut: Sera discuté plus loin dans l'article.
  • Capture d'écran: Un instantané de l'application pour montrer l'erreur lorsqu'elle s'est produite.

Voici quelques-uns des champs «incontournables». Ce modèle peut être développé (par exemple pour inclure le nom du testeur qui a signalé le problème) ou sous contrat ( Par exemple, le nom du module supprimé) selon les besoins.

En suivant les instructions ci-dessus et en utilisant le modèle ci-dessus, un exemple de journal / rapport d'anomalies pourrait ressembler à ceci:

Exemple de rapport d'anomalie pour le projet OrangeHRM Live:

Rapport de défaut OrangeHRM

=> Cliquez ici pour télécharger le rapport d'anomalie du projet en direct

Vous trouverez ci-dessous un exemple de rapport d'anomalie créé dans l'outil de gestion des tests qTest: (Clique sur l'image pour l'agrandir)

Exemple de rapport de défaut

Les défauts ne sont pas bons lorsque nous les enregistrons et les gardons pour nous. Nous devrons les attribuer dans le bon ordre pour que les équipes concernées agissent en conséquence. Le processus - qui attribuer ou quel ordre suivre peut également être trouvé dans le document du plan de test. Il est principalement similaire à (Clique sur l'image pour l'agrandir)

Cycle de défaut:

Cycle de vie des défauts 1

À partir du processus ci-dessus, on peut noter que les bogues passent par différentes personnes et différentes décisions en cours d'identification pour être corrigées. Pour suivre et établir la transparence quant à l'état exact d'un certain bogue, un champ «Statut» est utilisé dans le rapport de bogue. L'ensemble du processus est appelé «cycle de vie des bogues». Pour plus d'informations sur tous les statuts et leur signification, veuillez vous référer à ceci Tutoriel sur le cycle de vie des bogues .

Quelques conseils lors du suivi des bogues

  • Lorsque nous sommes nouveaux dans une équipe créative / un projet / AUT, il est toujours préférable de discuter du problème rencontré avec un pair pour nous assurer que notre compréhension de ce qui constitue réellement un défaut est correcte ou non.
  • À fournir toutes les informations qui est nécessaire pour reproduire le problème. Un défaut qui revient à une équipe de test avec le statut défini comme «Pas assez d'informations» ne reflète pas très positivement sur nous. Consultez ce post - Comment résoudre tous les bogues sans aucune étiquette 'Bogue non valide' .
  • Vérifiez si un problème similaire a été soulevé avant d'en créer un nouveau. Problèmes de 'duplication' sont également de mauvaises nouvelles pour l'équipe QA.
  • S'il y a un problème, cela survient au hasard et nous ne connaissons pas les étapes / situations exactes dans lesquelles nous pouvons recréer le problème - soulevez le problème tout de même. Au risque de voir le problème 'IrReproductible / pas assez d'informations' - nous devons encore nous assurer que nous avons traité au mieux tous les dysfonctionnements possibles.
  • La pratique générale est que l’équipe QA crée les défauts de chacun dans une feuille Excel au cours d’une journée et la consolide à la fin de la journée.

Le cycle de vie complet des défauts

Pour notre projet en direct si nous devions suivre le cycle de vie du défaut pour le défaut 1,

reddit best VPN torrenting
  • Lorsque je (le testeur) le crée, son statut est 'Nouveau». Lorsque je l'attribue au responsable de l'équipe QA, le statut est toujours «Nouveau», mais le propriétaire est désormais le responsable du contrôle qualité.
  • Le responsable AQ examinera le problème et, lorsqu'il déterminera qu'il s'agit d'un problème valide, le problème est attribué au responsable du développement. À cette phase, le statut est 'Attribué' et le propriétaire est le responsable du développement.
  • Le responsable du développement attribuera ensuite ce problème à un développeur qui travaillera à la résolution de ce problème. Le statut sera désormais 'Travail en cours' (ou quelque chose de similaire à cet effet), le propriétaire est le développeur.
  • Pour le défaut 1, le développeur n'est pas en mesure de reproduire l'erreur, il l'attribue donc à l'équipe QA et définit le statut comme 'Incapable de se reproduire».
  • Sinon, si le développeur était en mesure de travailler dessus et de résoudre un problème, le statut serait défini sur 'résolu' et le problème serait renvoyé à l'équipe d'AQ.
  • L'équipe QA le récupérera, testera à nouveau le problème et, s'il est résolu, définira le statut sur 'Fermé' . Si le problème persiste, le statut est défini sur 'Rouvrir' et le processus se poursuit.
  • Selon les autres situations, le statut peut être défini comme 'Différé' , 'Pas suffisamment d'informations', 'Dupliquer' , 'Travailler comme prévue' , etc. par le développeur.
  • Cette méthode d'enregistrement des défauts, de rapport, de leur attribution, de leur gestion est l'une des activités majeures réalisées par les membres de l'équipe QA pendant la phase d'exécution des tests. Cela se fait quotidiennement jusqu'à ce qu'un cycle de test particulier soit terminé.
  • Une fois le cycle 1 terminé, l'équipe de développement prendra un jour ou deux pour consolider tous les correctifs et reconstruire le code dans la prochaine version qui sera utilisée pour le prochain cycle.
  • Le même processus se poursuit également pour le cycle 2. À la fin du cycle, il est possible qu'il y ait encore des problèmes «ouverts» ou non résolus dans l'application.
  • À ce stade, continuons-nous toujours avec le cycle 3? Si oui, quand arrêterons-nous les tests?

Critères de sortie pour le test de projet en direct OrangeHRM

C'est là que nous employons ce que nous appellerions les «critères de sortie». Ceci est prédéfini dans le document du plan de test. C'est simplement sous la forme de la liste de contrôle qui déterminera si nous terminons les tests après le cycle 2 ou si nous allons pour un cycle de plus. Il ressemble à ce qui suit une fois rempli en tenant compte de quelques réponses hypothétiques aux questions suivantes concernant le projet OrangeHRM:

Critères de sortie du test

Lorsque nous examinons attentivement la liste de contrôle ci-dessus, il y a des métriques et des signatures mentionnées ici dont nous n'avons pas discuté plus tôt. Parlons-en maintenant.

Mesures de test

Nous avons établi que pendant la phase d'exécution des tests, des rapports sont envoyés à tous les autres membres de l'équipe de projet pour donner une idée claire sur ce qui se passe dans la phase d'exécution du contrôle qualité . Ces informations sont importantes pour tout le monde afin d'obtenir une validation sur la qualité globale du produit final.

Imaginez que je rapporte que 10 cas de test réussis ou 100 cas de test ont été exécutés - ces chiffres ne sont que des données brutes et ne donnent pas une très bonne perspective sur la façon dont les choses se passent.

Les métriques jouent un rôle essentiel pour combler cette lacune. Les métriques sont en termes simples, numéros intelligents que l'équipe de test collecte et maintient . Par exemple, si je dis que 90% des cas de test ont réussi, cela a plus de sens que de dire que 150 cas de test ont réussi. N'est-ce pas?

Il existe différents types de métriques collectées pendant la phase d'exécution du test. Quelles mesures exactement doivent être collectées et maintenues pendant quelles périodes de temps - ces informations peuvent être trouvées dans le document du plan de test.

Voici les mesures de test les plus couramment collectées pour la plupart des projets:

  • Pourcentage de réussite des cas de test
  • Densité des défauts
  • Pourcentage de défauts critiques
  • Défauts, nombre sage de gravité

Vérifiez Rapport de situation joint à cet article pour voir comment ces métriques sont utilisées.

Test de validation / rapport d'achèvement

Comme nous devons informer toutes les parties prenantes que les tests ont commencé, il est également du devoir de l’équipe d’assurance qualité de faire savoir à tous que les tests sont terminés et de partager les résultats. Ainsi, en général, un e-mail est envoyé par l'équipe d'assurance qualité (généralement le chef d'équipe / gestionnaire d'assurance qualité) indiquant que l'équipe d'assurance qualité a approuvé le produit en joignant les résultats des tests et la liste des problèmes ouverts / connus.

Exemple d'e-mail de validation de test:

À: Client, PM, équipe de développement, équipe DB, BA, équipe QA, équipe environnement (et toute autre personne qui doit être incluse)
Email: Bonjour équipe,

L'équipe QA approuve le logiciel OrangeHRM version 3.0 après la réussite des 2 cycles de tests fonctionnels du site Web.

Les cas de test et leurs résultats d'exécution sont joints à l'e-mail. (Ou mentionnez l'emplacement où ils sont présents. Ou si vous utilisez un logiciel de gestion de test, fournissez des détails à ce sujet.)

La liste des problèmes connus est également jointe à l'e-mail. (Encore une fois, toute autre référence qui a du sens peut être ajoutée.)

Merci,
Chef d'équipe QA.

Pièces jointes: Rapport final d'exécution, rapport final sur les problèmes / défauts, liste des problèmes connus

Une fois que l'e-mail de validation de test est envoyé par l'équipe QA, nous avons officiellement terminé le processus STLC. Cela ne marque pas nécessairement l'achèvement de la phase «Test» du SDLC. Nous avons encore les tests UAT à terminer pour que cela se produise. Trouver plus de détails sur les tests UAT ici .

Une fois l'UAT terminé, le SDLC passe à la phase de déploiement où il est mis en ligne et est disponible pour ses clients / utilisateurs finaux pour être consommé.

C'est tout!

Cela a été notre effort pour apporter l'expérience la plus vivante du projet QA à nos lecteurs. Veuillez nous faire part de vos commentaires et questions sur cette série de formations en ligne gratuites sur le contrôle qualité des tests de logiciels.

lecture recommandée

^