STLC - Classification des défauts
Les défauts sont classés du point de vue de l'équipe d'assurance qualité comme Priority et du point de vue du développement comme Severity(complexité du code pour y remédier). Ce sont deux classifications majeures qui jouent un rôle important dans le calendrier et la quantité de travail nécessaire pour corriger les défauts.
Qu'est-ce que la priorité?
La priorité est définie comme l'ordre dans lequel les défauts doivent être résolus. Le statut de priorité est généralement défini par l'équipe QA tout en signalant le défaut à l'équipe de développement en mentionnant le délai pour corriger le défaut. Le statut de priorité est défini en fonction des besoins des utilisateurs finaux.
Par exemple, si le logo de l'entreprise est mal placé dans la page Web de l'entreprise, la priorité est élevée mais elle est de faible gravité.
Liste prioritaire
Une priorité peut être classée des manières suivantes -
Low - Ce défaut peut être corrigé après la correction des problèmes critiques.
Medium - Le défaut doit être résolu dans les versions suivantes.
High - Le défaut doit être résolu immédiatement car le défaut affecte considérablement l'application et les modules concernés ne peuvent pas être utilisés tant qu'il n'est pas corrigé.
Urgent - Le défaut doit être résolu immédiatement car le défaut affecte gravement l'application ou le produit et le produit ne peut pas être utilisé tant qu'il n'a pas été corrigé.
Qu'est-ce que la gravité?
La gravité est définie comme l'espièglerie d'un défaut sur l'application et la complexité du code pour y remédier du point de vue du développement. Itest lié à l'aspect développement du produit. La gravité peut être décidée en fonction de la gravité / importance du défaut du système. L'état de gravité peut donner une idée de l'écart de fonctionnalité dû au défaut.
Example - Pour le site Web d'exploitation de vols, le défaut de génération du numéro de billet contre réservation est de haute gravité et également de haute priorité.
Liste de gravité
La gravité peut être classée des manières suivantes -
Critical /Severity 1- Un défaut affecte les fonctionnalités les plus cruciales de l'application et l'équipe d'assurance qualité ne peut pas continuer avec la validation de l'application testée sans la corriger. Par exemple, l'application / produit plante fréquemment.
Major / Severity 2- Un défaut impacte un module fonctionnel; l'équipe QA ne peut pas tester ce module particulier mais continue avec la validation d'autres modules. Par exemple, la réservation de vol ne fonctionne pas.
Medium / Severity 3- Le défaut a un problème avec un seul écran ou lié à une seule fonction, mais le système fonctionne toujours. Le défaut ici ne bloque aucune fonctionnalité. Par exemple, Ticket # est une représentation qui ne suit pas les caractères alphanumériques appropriés comme les cinq premiers caractères et les cinq derniers comme numériques.
Low / Severity 4- Cela n'a aucun impact sur la fonctionnalité. Il peut s'agir d'un défaut esthétique, d'une incohérence de l'interface utilisateur pour un champ ou d'une suggestion pour améliorer l'expérience de l'utilisateur final du côté de l'interface utilisateur. Par exemple, la couleur d'arrière-plan du bouton Soumettre ne correspond pas à celle du bouton Enregistrer.