defect severity priority testing with examples
Dans ce didacticiel, vous apprendrez ce que sont la gravité et la priorité des défauts dans les tests, comment définir la priorité et les niveaux de gravité des défauts avec des exemples pour comprendre clairement le concept.
Nous aborderons également en détail comment classer les défauts sous différents seaux et leur pertinence dans le cycle de vie des défauts. Nous aborderons également le rôle crucial de la classification avec un ensemble d'exemples en direct.
Le dépôt des défauts est un élément très partie du cycle de vie des tests logiciels . Il existe plusieurs bonnes pratiques définies pour Rapports de défauts efficaces sur Internet ou dans des organisations.
logiciel d'extraction de DVD gratuit pour Windows 10
Ce que vous apprendrez:
- Présentation du suivi des défauts
Présentation du suivi des défauts
L'un des aspects importants du cycle de vie des défauts au niveau générique comprend le suivi des défauts. Ceci est important car les équipes de test découvrent plusieurs défauts lors du test d'un logiciel qui ne se multiplie que si le système particulier testé est complexe. Dans un tel scénario, gérer ces défauts et analyser ces défauts pour entraîner la fermeture peut être une tâche ardue.
Conformément aux processus de maintenance des défauts, lorsqu'un testeur dépose un défaut - en dehors de la méthode / description pour reproduire le problème observé, il doit également fournir des informations catégoriques qui faciliteraient la classification inexacte du défaut. Ceci, à son tour, contribuerait à des processus efficaces de suivi / maintenance des défauts et constituerait également la base d'un délai de traitement des défauts plus rapide.
Les deux principaux paramètres qui constituent la base d'un suivi et d'une résolution efficaces des défauts sont:
- Priorité des défauts dans les tests
- Gravité des défauts lors des tests
Ces concepts sont souvent déroutants et sont presque utilisés de manière interchangeable non seulement par les équipes de test, mais également par les équipes de développement. Il y a une ligne fine entre les deux et il est important de comprendre qu’il existe effectivement des différences entre les deux.
Comprenons brièvement les définitions théoriques des deux paramètres dans la section suivante.
Qu'est-ce que la gravité et la priorité des défauts?
La priorité par la définition anglaise est utilisée dans la comparaison de deux choses ou conditions, où l'une doit avoir plus d'importance que l'autre (s) et doit être abordée avec / résolue d'abord avant de passer au (x) suivant (s). Par conséquent, dans le contexte des défauts, la priorité d'un défaut indiquerait l'urgence avec laquelle il devrait être corrigé.
La gravité selon la définition anglaise est utilisée pour décrire la gravité d'un événement indésirable. Par conséquent, en ce qui concerne les bogues, la gravité d'un bogue indiquerait l'effet qu'il a sur le système en termes d'impact.
Qui les définit?
L'AQ classe le défaut selon la gravité appropriée en fonction de la complexité et de la criticité des défauts.
Toutes les parties prenantes de l'entreprise, y compris les chefs de projet, les analystes commerciaux, le chef de produit définissent la priorité des défauts.
La figure ci-dessous illustre le rôle à qui appartient et classe la criticité et la gravité des défauts.
Comment choisir ces niveaux?
Comme nous l'avons déjà mentionné, le paramètre de gravité est évalué par le testeur, tandis que le paramètre de priorité est principalement évalué par le chef de produit ou essentiellement par l'équipe de triage. Même si c'est le cas, la gravité d'un défaut est certainement l'un des facteurs déterminants et déterminants pour hiérarchiser le défaut. Par conséquent, il est important en tant que testeur de sélectionner la bonne gravité pour éviter toute confusion avec les équipes de développement.
Différence entre gravité et priorité
La priorité est associée à la planification et la «gravité» est associée aux normes.
«Priorité» signifie que quelque chose est accordé ou mérite une attention préalable; préséance établie par ordre d'importance (ou urgence).
La «gravité» est l'état ou la qualité d'être sévère; sévère implique le respect de normes rigoureuses ou de principes élevés et suggère souvent de la dureté; sévère est marqué par ou exige le strict respect de normes rigoureuses ou de principes élevés, Par exemple, un code de conduite sévère.
Les mots priorité et gravité apparaissent dans le suivi des bogues.
Une variété d'outils logiciels commerciaux de suivi / gestion des problèmes est disponible. Ces outils, avec la contribution détaillée des ingénieurs de test logiciel, donnent à l'équipe des informations complètes afin que les développeurs puissent comprendre le bogue, se faire une idée de sa «gravité», le reproduire et le corriger.
Les correctifs sont basés sur les «priorités» du projet et la «gravité» des bogues.
La «gravité» d’un problème est définie conformément à l’évaluation des risques du client et enregistrée dans l’outil de suivi sélectionné.
Les logiciels bogués peuvent «gravement» affecter les horaires, ce qui, à son tour, peut conduire à une réévaluation et à une renégociation des «priorités».
Qu'est-ce que la priorité?
La priorité, comme son nom l'indique, consiste à prioriser un défaut en fonction des besoins de l'entreprise et de la gravité du défaut. La priorité signifie l'importance ou l'urgence de corriger un défaut.
Lors de l'ouverture d'un défaut, le testeur attribue généralement la priorité au départ en considérant le produit du point de vue de l'utilisateur final. Conformément à ceux-ci, il existe différents niveaux:
De manière générale, la priorité des défauts peut être classée comme suit:
Priorité n ° 1) Immédiate / Critique (P1)
Cela doit être résolu immédiatement dans les 24 heures. Cela se produit généralement dans les cas où une fonctionnalité entière est bloquée et qu'aucun test ne peut être effectué en conséquence. Ou dans certains autres cas, s'il y a des fuites de mémoire importantes, le défaut est généralement classé en priorité -1, ce qui signifie que le programme / la fonctionnalité est inutilisable dans l'état actuel.
Tout défaut nécessitant une attention immédiate et ayant un impact sur le processus de test sera classé dans la catégorie immédiate
Tous les Gravité critique les défauts entrent dans cette catégorie (à moins que les entreprises / parties prenantes ne redéfinissent leur priorité)
Priorité n ° 2) Élevée (P2)
Une fois que les défauts critiques ont été corrigés, un défaut ayant cette priorité est le prochain candidat qui doit être corrigé pour que toute activité de test corresponde aux critères de «sortie». Normalement, lorsqu'une fonctionnalité n'est pas utilisable comme elle est censée l'être, en raison d'un défaut de programme, ou qu'un nouveau code doit être écrit ou parfois même parce qu'un problème environnemental doit être traité par le biais du code, un défaut peut être qualifié pour une priorité 2 .
Il s'agit du défaut ou du problème qui doit être résolu avant la publication. Ces défauts doivent être résolus une fois que les problèmes critiques sont résolus.
Tous les Majeur gravité les défauts entrent dans cette catégorie.
Priorité n ° 3) Moyenne (P3)
Un défaut avec cette priorité doit être en conflit pour être corrigé car il pourrait également traiter des problèmes de fonctionnalité qui ne sont pas conformes aux attentes. Parfois, même des erreurs cosmétiques telles que l'attente du bon message d'erreur lors de l'échec peuvent être qualifiées de défaut de priorité 3.
Ce défaut devrait être résolu une fois que tous les bogues sérieux ont été corrigés.
Une fois les bogues critiques et prioritaires terminés, nous pouvons opter pour les bogues de priorité moyenne.
Tous les Mineur gravité les défauts entrent dans cette catégorie.
Priorité n ° 4) Faible (P4)
Un défaut de faible priorité indique qu'il y a certainement un problème, mais il n'a pas besoin d'être corrigé pour correspondre aux critères de «sortie». Cependant, cela doit être corrigé avant la fin de l'AG. En règle générale, certaines erreurs de frappe ou même des erreurs esthétiques, comme indiqué précédemment, peuvent être classées ici.
Parfois, des défauts de priorité faible sont également ouverts pour suggérer des améliorations dans la conception existante ou une demande d'implémentation d'une petite fonctionnalité pour améliorer l'expérience utilisateur.
Ce défaut peut être résolu à l'avenir et ne nécessite aucune attention immédiate et le Faible gravité les défauts entrent dans cette catégorie.
Comme déjà discuté, la priorité détermine la rapidité avec laquelle le délai de traitement des défauts doit être. S'il y a plusieurs défauts, la priorité décide quel défaut doit être corrigé et vérifié immédiatement par rapport à quel défaut peut être corrigé un peu plus tard.
Qu'est-ce que la gravité?
La gravité définit la mesure dans laquelle un défaut particulier peut avoir un impact sur l'application ou le système.
La gravité est un paramètre qui indique l’implication d’un défaut sur le système - quelle est la gravité du défaut et quel est l’impact du défaut sur la fonctionnalité du système dans son ensemble? La gravité est un paramètre défini par le testeur pendant qu'il ouvre un défaut et est principalement sous le contrôle du testeur. Encore une fois, différentes organisations ont différents outils à utiliser pour les défauts, mais à un niveau générique, il s'agit des niveaux de gravité suivants:
Par exemple, Considérez les scénarios suivants
- Si l'utilisateur tente de faire des achats en ligne et que l'application ne se charge pas ou que le serveur n'est pas disponible, un message s'affiche.
- L'utilisateur effectue l'ajout d'un article au panier, le nombre de quantités ajoutées est incorrect / un produit incorrect est ajouté.
- L'utilisateur effectue le paiement et après le paiement, la commande reste dans le panier comme réservée à la place confirmée.
- Le système accepte la commande mais finalement, annule la commande après une demi-heure en raison de problèmes.
- Le système accepte le «Ajouter au panier» sur double clic uniquement au lieu d'un seul clic.
- Le bouton Ajouter au panier est orthographié comme Ajouter au panier.
Quelle serait l'expérience utilisateur si l'un des scénarios ci-dessus pouvait se produire?
En gros, les défauts peuvent être classés comme suit:
# 1) Critique (S1)
Un défaut qui gêne ou bloque complètement le test du produit / de la fonctionnalité est un défaut critique. Un exemple serait dans le cas des tests d'interface utilisateur où, après avoir parcouru un assistant, l'interface utilisateur se bloque dans un volet ou ne va pas plus loin pour déclencher la fonction. Ou dans certains autres cas, lorsque la fonctionnalité développée elle-même est absente de la construction.
Pour une raison quelconque, si l'application tombe en panne ou devient inutilisable / incapable de continuer, le défaut peut être classé dans la gravité critique.
Toute défaillance catastrophique du système pourrait conduire l'utilisateur à la non-utilisabilité des applications pourrait être classée sous la gravité critique
Par exemple, Dans le fournisseur de services de messagerie comme Yahoo ou Gmail, après avoir tapé le nom d'utilisateur et le mot de passe corrects, au lieu de se connecter, le système plante ou envoie le message d'erreur, ce défaut est classé comme critique car ce défaut rend toute l'application inutilisable.
Le scénario sur le point 1 discuté ci-dessus pourrait être classé comme défaut critique, car l'application en ligne devient complètement inutilisable.
# 2) Majeur (S2)
Toute fonctionnalité majeure implémentée qui ne répond pas à ses exigences / cas d'utilisation et se comporte différemment que prévu, elle peut être classée sous gravité majeure.
Un défaut majeur se produit lorsque la fonctionnalité fonctionne de manière très éloignée des attentes ou ne fait pas ce qu'elle devrait faire. Un exemple pourrait être: Supposons qu'un VLAN doit être déployé sur le commutateur et que vous utilisez un modèle d'interface utilisateur qui déclenche cette fonction. Lorsque ce modèle pour configurer le VLAN échoue sur le commutateur, il est classé comme un grave inconvénient de fonctionnalité.
Par exemple, Dans le fournisseur de services de messagerie comme Yahoo ou Gmail, lorsque vous n'êtes pas autorisé à ajouter plus d'un destinataire dans la section CC, ce défaut est classé comme défaut majeur car la fonctionnalité principale de l'application ne fonctionne pas correctement.
qu'est-ce qu'un bogue dans un logiciel
Ce qui est attendu du comportement de la section CC dans le mail, il doit permettre à l'utilisateur d'ajouter plusieurs utilisateurs. Ainsi, lorsque la fonctionnalité majeure de l'application ne fonctionne pas correctement ou lorsqu'elle se comporte différemment des attentes, il s'agit d'un défaut majeur.
Les scénarios sur les points 2 et 3 discutés ci-dessus pourraient être classés comme défaut majeur, car la commande devrait passer en douceur à la phase suivante du cycle de vie de la commande, mais en réalité, son comportement varie.
Tout défaut susceptible d'entraîner une persistance incorrecte des données, des problèmes de données ou des comportements d'application incorrects pourrait être globalement classé sous la gravité majeure.
# 3) Mineur / Modéré (S3)
Toute fonctionnalité mise en œuvre qui ne répond pas à ses exigences / cas d'utilisation et qui se comporte différemment que prévu, mais dont l'impact est négligeable dans une certaine mesure ou qui n'a pas d'impact majeur sur l'application, peut être classée sous Gravité mineure.
Un défaut modéré se produit lorsque le produit ou l'application ne répond pas à certains critères ou présente toujours un comportement non naturel, mais la fonctionnalité dans son ensemble n'est pas affectée. Par exemple, dans le déploiement du modèle VLAN ci-dessus, un défaut modéré ou normal se produirait lorsque le modèle est déployé avec succès sur le commutateur, cependant, aucune indication n'est envoyée à l'utilisateur.
Par exemple, Dans le fournisseur de services de messagerie comme Yahoo ou Gmail, il existe une option appelée «Conditions générales» et dans cette option, il y aura plusieurs liens concernant les termes et conditions du site Web, lorsqu'un des multiples liens ne fonctionne pas correctement, il est appelé gravité mineure car il n'affecte que les fonctionnalités mineures de l'application et n'a pas un impact important sur l'utilisabilité de l'application.
Le scénario du point 5 discuté ci-dessus pourrait être classé comme un défaut mineur, car il n'y a pas de perte de données ou de panne dans l'ordre de flux du système, mais un léger inconvénient en ce qui concerne l'expérience utilisateur.
Ces types de défauts entraînent une perte minimale de fonctionnalités ou d'expérience utilisateur.
# 4) Faible (S4)
Tout défaut esthétique, y compris les fautes d'orthographe, les problèmes d'alignement ou la casse de la police, peut être classé sous Faible gravité.
Un bogue mineur de faible gravité se produit lorsqu'il n'y a pratiquement aucun impact sur la fonctionnalité mais qu'il s'agit toujours d'un défaut valide qui doit être corrigé. Des exemples de ceci peuvent inclure des fautes d'orthographe dans les messages d'erreur imprimés aux utilisateurs ou des défauts pour améliorer l'aspect et la convivialité d'une fonction.
Par exemple, Dans le fournisseur de services de messagerie comme Yahoo ou Gmail, vous auriez remarqué la «page de licence», s'il y a des fautes d'orthographe ou un mauvais alignement dans la page, ce défaut est classé comme faible.
Le scénario sur le point 6 discuté ci-dessus pourrait être classé comme défaut faible, car le bouton Ajouter est affiché dans le mauvais boîtier. Ce type de défaut n'aura aucun impact sur le comportement du système ou la présentation des données ou la perte de données ou le flux de données ou même l'expérience utilisateur mais sera très cosmétique.
Pour résumer, la figure suivante illustre la classification générale des défauts basée sur la gravité et la priorité:
Exemples
Comme déjà mentionné, étant donné que différentes organisations utilisent différents types d'outils pour le suivi des défauts et ses processus associés, cela devient un système de suivi commun entre les différents niveaux de gestion et le personnel technique.
Étant donné que la gravité du défaut relève davantage de la fonctionnalité, l'ingénieur de test définit la gravité du défaut. Parfois, les développeurs participent à influencer la gravité du défaut, mais cela dépend principalement du testeur car il évalue dans quelle mesure une fonctionnalité particulière peut avoir un impact sur le fonctionnement global.
D'autre part, lorsqu'il s'agit de définir la priorité des défauts, bien qu'au départ, l'auteur du défaut fixe la priorité, celle-ci est en fait définie par le chef de produit car il a une vue d'ensemble du produit et la rapidité avec laquelle un défaut particulier doit être résolu . Un testeur n'est pas la personne idéale pour définir la priorité des défauts.
Aussi choquant que cela puisse paraître, il existe deux exemples distincts expliquant pourquoi:
Exemple 1) Considérez qu'il existe une situation où l'utilisateur trouve une erreur dans la dénomination du produit lui-même ou un problème avec la documentation de l'interface utilisateur. Un testeur ouvrirait normalement un défaut mineur / esthétique et pourrait être très simple à réparer, mais en ce qui concerne l'aspect et la sensation du produit / l'expérience utilisateur, cela pourrait avoir un impact sérieux.
Exemple # 2) Il peut y avoir certaines conditions dans lesquelles un défaut particulier se produit, ce qui peut être une possibilité extrêmement rare ou inexistante de se produire dans l'environnement du client. Même si, du point de vue de la fonctionnalité, cela peut sembler être un défaut hautement prioritaire pour un testeur, compte tenu de sa rareté et du coût élevé de sa réparation, cela serait classé comme un défaut de faible priorité.
Ainsi, en effet, la priorité des défauts est généralement fixée par le chef de produit lors d'une réunion «triage des défauts».
Différents niveaux
La priorité et la gravité ont des classifications parmi elles qui aident à déterminer comment le défaut doit être traité. De nombreuses organisations ont différents outils de journalisation des défauts , donc les niveaux peuvent varier.
Jetons un coup d'œil aux différents niveaux de priorité et de gravité.
- Priorité élevée, gravité élevée
- Priorité élevée, faible gravité
- Haute gravité, faible priorité
- Faible gravité, faible priorité
La figure suivante illustre la classification des catégories dans un seul extrait de code.
# 1) Gravité élevée et priorité élevée
Tout échec critique / majeur de l'analyse de rentabilisation est automatiquement promu dans cette catégorie.
Tout défaut en raison duquel les tests ne peuvent pas se poursuivre à tout prix ou entraîne une défaillance grave du système dans cette catégorie. Par exemple, cliquer sur un bouton particulier ne charge pas la fonction elle-même. Ou l'exécution d'une fonction particulière entraîne une panne constante du serveur et entraîne une perte de données. Les lignes rouges de la figure ci-dessus indiquent ces types de défauts.
Par exemple,
Le système plante après que vous ayez effectué le paiement ou lorsque vous ne pouvez pas ajouter les articles au panier, ce défaut est marqué comme défaut de gravité élevée et de défaut de priorité élevée.
Un autre exemple serait une fonction de devise de distribution ATM dans laquelle après avoir entré le nom d'utilisateur et le mot de passe corrects, la machine ne distribue pas d'argent mais déduit le transfert de votre compte.
# 2) Priorité élevée et faible gravité
Tout défaut de gravité mineur pouvant avoir un impact direct sur l'expérience utilisateur est automatiquement promu dans cette catégorie.
Les défauts qui doivent être corrigés mais n'affectent pas l'application entrent dans cette catégorie.
Par exemple, on s'attend à ce que la fonction affiche une erreur particulière à l'utilisateur en ce qui concerne son code de retour. Dans ce cas, fonctionnellement le code générera une erreur, mais le message devra être plus pertinent par rapport au code de retour généré. Les lignes bleues de la figure indiquent ces types de défauts.
Par exemple,
Le logo de l'entreprise sur la page d'accueil est erroné, il est considéré comme Priorité élevée et faible gravité défaut .
Exemple 1) Dans le site Web d'achat en ligne, lorsque le logo FrontPage est mal orthographié, par exemple, au lieu de Flipkart, il est orthographié Flipkart.
Exemple 2) Dans le logo de la banque, au lieu d'ICICI, il est écrit ICCCI.
En termes de fonctionnalité, cela n'affecte rien, nous pouvons donc marquer comme faible gravité, mais cela a un impact sur l'expérience utilisateur. Ce type de défaut doit être résolu en haute priorité même s'il a très moins d'impact du côté de l'application.
# 3) Haute gravité et faible priorité
Tout défaut qui ne répond pas aux exigences fonctionnellement ou qui a des implications fonctionnelles sur le système mais qui est écarté par les parties prenantes en ce qui concerne la criticité de l'entreprise est automatiquement promu dans cette catégorie.
nom d'utilisateur et mot de passe par défaut pour le routeur
Des défauts qui doivent être corrigés mais pas immédiatement. Cela peut se produire spécifiquement lors de tests ad hoc. Cela signifie que la fonctionnalité est affectée dans une large mesure, mais n'est observée que lorsque certains paramètres d'entrée inhabituels sont utilisés.
Par exemple, une fonctionnalité particulière ne peut être utilisée que sur une version ultérieure du micrologiciel, donc pour vérifier cela, le testeur rétrograde en fait son système et effectue le test et observe un problème de fonctionnalité sérieux qui est valide. Dans un tel cas, les défauts seront classés dans cette catégorie indiquée par des lignes roses, car normalement les utilisateurs finaux devront avoir une version supérieure du micrologiciel.
Par exemple,
Dans un site de réseau social, si une version bêta d'une nouvelle fonctionnalité est publiée avec peu d'utilisateurs actifs utilisant cette fonctionnalité à ce jour. Tout défaut détecté sur cette fonctionnalité peut être classé comme une priorité faible car la fonctionnalité passe au second plan en raison de la classification commerciale comme non importante.
Bien que cette fonctionnalité présente un défaut fonctionnel, car elle n'affecte pas directement les clients finaux, une partie prenante de l'entreprise peut classer le défaut sous une faible priorité bien qu'elle ait un impact fonctionnel grave sur l'application.
Il s'agit d'un défaut de gravité élevée mais peut être priorisé sur une priorité faible car il peut être corrigé avec la prochaine version en tant que demande de modification. Les parties prenantes de l'entreprise accordent également la priorité à cette fonctionnalité en tant que fonctionnalité rarement utilisée et n'affectent aucune autre fonctionnalité ayant un impact direct sur l'expérience utilisateur. Ce type de défaut peut être classé sous le Haute gravité mais faible priorité Catégorie.
# 4) Faible gravité et faible priorité
Toute faute d'orthographe / casse de police / défaut d'alignement dans le paragraphe du 3rdou 4epage de l'application et non dans la page principale ou la première page / titre.
Ces défauts sont classés dans les lignes vertes comme indiqué sur la figure et se produisent lorsqu'il n'y a pas d'impact sur la fonctionnalité, mais ne respectent toujours pas les normes dans une faible mesure. Généralement, les erreurs esthétiques ou les dimensions d'une cellule dans un tableau sur l'interface utilisateur sont classées ici.
Par exemple,
Si la politique de confidentialité du site Web comporte une faute d'orthographe, ce défaut est défini comme Faible gravité et faible priorité.
Des lignes directrices
Vous trouverez ci-dessous certaines directives que chaque testeur doit essayer de suivre:
- Tout d'abord, comprenez bien les concepts de priorité et de gravité. Évitez de confondre l'un avec l'autre et de les utiliser de manière interchangeable. Conformément à cela, suivez les consignes de gravité publiées par votre organisation / équipe afin que tout le monde soit sur la même page.
- Choisissez toujours le niveau de gravité en fonction du type de problème car cela affectera sa priorité. Quelques exemples sont:
- Pour un problème critique, tel que le système entier tombe en panne et que rien ne peut être fait, cette gravité ne doit pas être utilisée pour corriger les défauts du programme.
- Pour un problème majeur, comme dans les cas où la fonction ne fonctionne pas comme prévu, cette gravité pourrait être utilisée pour traiter de nouvelles fonctions ou une amélioration du fonctionnement actuel.
N'oubliez pas que choisir le bon niveau de gravité donnera à son tour le défaut, c'est la priorité qui s'impose.
- En tant que testeur - comprendre comment une fonctionnalité particulière, plutôt que de pousser plus loin - comprendre comment un scénario ou un cas de test particulier affecterait l'utilisateur final. Cela implique beaucoup de collaboration et d'interaction avec l'équipe de développement, les analystes commerciaux, les architectes, le responsable des tests, le responsable du développement. Dans vos discussions, vous devez également prendre en compte le temps qu'il faudrait pour corriger le défaut en fonction de sa complexité et du temps nécessaire pour vérifier ce défaut.
- Pour terminer , c’est toujours le propriétaire du produit qui possède le droit de veto de la libération, le défaut doit être corrigé. Cependant, comme les sessions de triage des défauts contiennent des membres variés pour présenter leur point de vue sur le défaut au cas par cas, à un moment où les développeurs et les testeurs sont synchronisés, cela aide sûrement à influencer la décision.
Conclusion
Lors de l’ouverture des défauts, il incombe au testeur d’attribuer la gravité appropriée aux défauts. Une gravité incorrecte et donc un mappage de priorité peuvent avoir des implications très drastiques sur le processus STLC global et le produit dans son ensemble. Dans plusieurs entretiens d'embauche - plusieurs questions sont posées sur la priorité et la gravité pour vous assurer qu'en tant que testeur, vous avez ces concepts parfaitement clairs dans votre esprit.
En outre, nous avons vu des exemples en direct de la façon de classer le défaut sous divers compartiments de gravité / priorité. À présent, j'aimerais que vous ayez suffisamment de précisions sur la classification des défauts à la fois au niveau des groupes de gravité / priorité.
J'espère que cet article est un guide complet pour comprendre la priorité et les niveaux de gravité des défauts. Faites-nous part de vos réflexions / questions dans les commentaires ci-dessous.
lecture recommandée
- Qu'est-ce que la technique de test basée sur les défauts?
- 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
- Processus de gestion des défauts: comment gérer efficacement un défaut
- Comment reproduire un défaut non reproductible et faire en sorte que votre effort de test en vaille la peine
- 7 Principes des tests logiciels: clustering de défauts et principe de Pareto
- Méthodes et techniques de prévention des défauts
- Différence exacte entre la vérification et la validation avec des exemples
- 3 stratégies pour traiter un défaut de bloqueur