how create requirements traceability matrix
Qu'est-ce que la matrice de traçabilité des exigences (RTM) dans les tests logiciels: guide étape par étape pour créer une matrice de traçabilité avec des exemples et un modèle d'échantillon
Le didacticiel d’aujourd’hui porte sur un outil de contrôle qualité important, qui est soit trop simplifié (lu négligé), soit surestimé, c’est-à-dire Matrice de traçabilité (TM).
Le plus souvent, la création, la révision ou le partage d'une matrice de traçabilité n'est pas l'un des principaux livrables du processus d'AQ - il n'est donc pas principalement concentré sur, ce qui entraîne une sous-importance. Au contraire, certains clients s'attendent à ce qu'un TM révèle des facettes bouleversantes de leur produit (en cours de test) et sont déçus.
«Lorsqu'elle est utilisée correctement, une matrice de traçabilité peut être votre GPS pour votre parcours d'assurance qualité».
Comme c'est une pratique générale à STH , nous verrons les aspects «Quoi» et «Comment» d'une MT dans cet article.
Ce que vous apprendrez:
- Quelle est la matrice de traçabilité des exigences?
- Couverture des tests et traçabilité des exigences
- Comment créer une matrice de traçabilité des exigences
Quelle est la matrice de traçabilité des exigences?
Dans la matrice de traçabilité des exigences ou RTM, nous mettons en place un processus de documentation des liens entre les besoins utilisateurs proposés par le client et le système en construction. En bref, il s'agit d'un document de haut niveau pour cartographier et suivre les exigences des utilisateurs avec des cas de test afin de garantir que pour chaque exigence, un niveau de test adéquat est atteint.
Le processus d'examen de tous les cas de test définis pour toute exigence est appelé traçabilité. La traçabilité nous permet de déterminer quelles exigences ont engendré le plus grand nombre de défauts au cours du processus de test.
L'objectif de toute mission de test est et doit être une couverture de test maximale. Par couverture, cela signifie simplement que nous devons tester tout ce qui doit être testé. L'objectif de tout projet de test doit être une couverture de test à 100%.
La matrice de traçabilité des exigences établit un moyen de s'assurer que nous vérifions l'aspect de la couverture. Il aide à créer un instantané pour identifier les lacunes de couverture. En bref, il peut également être appelé métrique qui détermine le nombre de cas de test exécutés, réussis, échoués ou bloqués, etc. pour chaque exigence.
Pourquoi la traçabilité des exigences est-elle requise?
La matrice de traçabilité des exigences permet de relier les exigences, Cas de test , et les défauts avec précision. L'ensemble de l'application est testé en ayant la Traçabilité des Exigences ( Test de bout en bout d'une application est réalisée).
questions et réponses d'entrevue de base java pour les novices
Exigence La traçabilité garantit une bonne «qualité» de l'application car toutes les fonctionnalités sont testées. Contrôle de qualité peut être réalisé lorsque le logiciel est testé pour des scénarios imprévus avec un minimum de défauts et toutes les exigences fonctionnelles et non fonctionnelles étant satisfaites.
La matrice de traçabilité des exigences aide les applications logicielles à être testées dans la durée stipulée, la portée du projet est bien déterminée et sa mise en œuvre est réalisée selon les exigences et les besoins du client et le coût du projet est bien contrôlé.
Défaut Les fuites sont évitées dans l'ensemble de l'application est testée pour ses exigences.
Types de matrice de traçabilité
Traçabilité avant
Dans «Transférer les exigences de traçabilité» aux cas de test. Il garantit que le projet progresse selon la direction souhaitée et que chaque exigence est testée à fond.
Traçabilité en amont
Les cas de test sont mappés avec les exigences de «traçabilité descendante». Son objectif principal est de s'assurer que le produit en cours de développement est sur la bonne voie. Cela aide également à déterminer qu'aucune fonctionnalité supplémentaire non spécifiée n'est ajoutée et que la portée du projet est donc affectée.
Traçabilité bidirectionnelle
(Avant + Arrière): Une matrice de bonne traçabilité contient des références allant des cas de test aux exigences et vice versa (des exigences aux cas de test). C'est ce que l'on appelle la traçabilité «bidirectionnelle». Il garantit que tous les cas de test peuvent être tracés aux exigences et que chaque exigence spécifiée a des cas de test précis et valides pour eux.
Exemples de RTM
# 1) Exigence commerciale
BR1 : L'option d'écriture d'e-mails doit être disponible.
Scénario de test (spécification technique) pour BR1
TS1 : L'option de rédaction de courrier est fournie.
Cas de test:
Cas de test 1 (TS1.TC1) : L'option de rédaction de courrier est activée et fonctionne correctement.
Cas de test 2 (TS1.TC2) : L'option de rédaction de courrier est désactivée.
# 2) Défauts
Après avoir exécuté les cas de test, si des défauts sont détectés, ils peuvent également être répertoriés et mappés avec les exigences commerciales, les scénarios de test et les cas de test.
Par exemple, Si TS1.TC1 échoue, c'est-à-dire que l'option Composer le courrier bien qu'activée ne fonctionne pas correctement, un défaut peut être enregistré. Supposons que l'ID de défaut généré automatiquement ou que le numéro attribué manuellement soit D01, cela peut être mappé avec les numéros BR1, TS1 et TS1.TC1.
Ainsi, toutes les exigences peuvent être représentées sous forme de tableau.
| Exigence commerciale # | Scénario de test # | Cas de test # | Défauts # |
|---|---|---|---|
| BR1 | TS1 | TS1.TC1 TS1.TC2 | D01 |
| BR2 | TS2 | TS2.TC1 TS2, TC2 TS2.TC3 | D02 D03 |
| BR3 | TS3 | TS1.TC1 TS2.TC1 TS3.TC1 TS3.TC2 | NÉANT |
Couverture des tests et traçabilité des exigences
Qu'est-ce que la couverture des tests?
La couverture de test indique quelles exigences des clients doivent être vérifiées lorsque la phase de test commence. La couverture de test est un terme qui détermine si les cas de test sont écrits et exécutés pour garantir le test complet de l'application logicielle, de manière à ce que des défauts minimes ou NUL soient signalés.
Comment obtenir une couverture de test?
La couverture maximale du test peut être obtenue en établissant une bonne «traçabilité des exigences».
- Mappage de tous les défauts internes aux cas de test conçus
- Mappage de tous les défauts signalés par le client (CRD) à des cas de test individuels pour la future suite de tests de régression
Types d'exigences Spécifications
# 1) Exigences commerciales
Les besoins réels des clients sont répertoriés dans un document appelé Document sur les exigences opérationnelles (BRS) . Cette BRS est une liste d'exigences de haut niveau dérivée minutieusement, après une brève interaction avec le client.
Il est généralement préparé par les «analystes commerciaux» ou «l’architecte» du projet (selon l’organisation ou la structure du projet). Le document «Software Requirement Specifications» (SRS) est dérivé de BRS.
# 2) Document de spécification des exigences logicielles (SRS)
C'est un document détaillé qui contient tous les détails méticuleux de toutes les exigences fonctionnelles et non fonctionnelles. Ce SRS est la base de la conception et du développement d'applications logicielles.
# 3) Documents sur les exigences du projet (PRD)
Le PRD est un document de référence pour tous les membres de l'équipe d'un projet pour leur dire exactement ce qu'un produit doit faire. Il peut être divisé en sections telles que l'objectif du produit, les caractéristiques du produit, les critères de publication et la budgétisation et le calendrier du projet.
# 4) Document de cas d'utilisation
C'est le document qui aide à concevoir et à mettre en œuvre le logiciel selon les besoins de l'entreprise. Il cartographie les interactions entre un acteur et un événement avec un rôle qui doit être joué pour atteindre un objectif. Il s'agit d'une description détaillée étape par étape de la manière dont une tâche doit être effectuée.
Par exemple,
Acteur: Client
Rôle: Télécharger le jeu
Le téléchargement du jeu a réussi.
Les cas d'utilisation peuvent également faire partie du document SRS conformément au processus de travail de l'organisation.
# 5) Document de vérification des défauts
Il est documenté contenant tous les détails relatifs aux défauts. L’équipe peut conserver un document de «vérification des défauts» pour la correction et le nouveau test des défauts. Les testeurs peuvent se référer au document «Vérification des défauts», lorsqu'ils veulent vérifier si les défauts sont corrigés ou non, retester les défauts sur différents OS, appareils, différentes configurations de système, etc.
Le document «Vérification des défauts» est pratique et important lorsqu'il existe une phase dédiée de correction et de vérification des défauts.
# 6) Histoires d'utilisateurs
La user story est principalement utilisée dans le développement «Agile» pour décrire une fonctionnalité logicielle du point de vue de l'utilisateur final. Les user stories définissent les types d'utilisateurs et de quelle manière et pourquoi ils veulent une certaine fonctionnalité. L'exigence est simplifiée par la création de user stories.
Actuellement, toutes les industries du logiciel s'orientent vers l'utilisation des User Stories et du Développement Agile et des outils logiciels correspondants pour enregistrer les exigences.
Défis pour la collecte des exigences
#1) Les exigences collectées doivent être détaillées, sans ambiguïté, exactes et bien spécifiées. Mais il y a NE PAS mesure appropriée pour calculer ces détails, sans ambiguïté, exactitude et spécifications bien définies qui sont nécessaires pour la collecte des exigences.
#deux) L’interprétation de l ’« analyste commercial »ou du« propriétaire de produit »qui fournit les informations sur les exigences est essentielle. De même, l'équipe qui reçoit les informations doit apporter les clarifications appropriées afin de comprendre les attentes des parties prenantes.
La compréhension doit être en phase avec les besoins de l'entreprise et les efforts réels requis pour la mise en œuvre de l'application.
# 3) Les informations doivent également être tirées du point de vue de l'utilisateur final.
# 4) Les parties prenantes déclarent des exigences contradictoires ou contradictoires à différents moments.
# 5) Le point de vue de l'utilisateur final n'est pas pris en compte pour de multiples raisons et d'autres parties prenantes pensent qu'elles comprennent «complètement» ce qui est requis pour un produit, ce qui n'est généralement pas le cas.
# 6) Ressources manque de compétences pour l'application développée.
# 7) Changements fréquents de «champ d'application» ou changement de priorité pour les modules.
# 8) Exigences manquées, implicites ou non documentées.
# 9) Exigences incohérentes ou vagues déterminées par les clients.
# dix) La conclusion de tous les facteurs énoncés ci-dessus est que le «succès» ou «l’échec» d’un projet dépend considérablement d’une exigence.
Comment la traçabilité des exigences peut aider
# 1) Où une exigence est-elle mise en œuvre?
Par exemple,
Exigence: Implémentez la fonctionnalité «Composer un courrier» dans une application de messagerie
Mise en œuvre: Où, sur la page principale, le bouton «Rédiger un e-mail» doit être placé et accessible.
# 2) Une exigence est-elle nécessaire?
Par exemple,
Exigence: Implémentez la fonctionnalité «Rédiger un e-mail» dans une application de messagerie pour certains utilisateurs uniquement.
Mise en œuvre: Selon les droits d'accès de l'utilisateur, si la boîte de réception de l'e-mail est en 'lecture seule', dans ce cas, le bouton 'Rédiger un e-mail' n'est pas nécessaire.
# 3) Comment interpréter une exigence?
Par exemple,
Exigence: Fonctionnalité «Rédiger un e-mail» dans une application de messagerie avec polices et pièces jointes.
Mise en œuvre: Lorsque vous cliquez sur 'Rédiger un e-mail', quelles fonctionnalités doivent être fournies?
- Corps de texte pour rédiger des e-mails et les éditer dans différents types de polices et également en gras, en italique, pour les souligner
- Types de pièces jointes (images, documents, autres e-mails, etc.)
- Taille des pièces jointes (taille maximale autorisée)
Ainsi, les exigences sont décomposées en sous-exigences.
# 4) Quelles décisions de conception affectent la mise en œuvre d'une exigence?
Par exemple,
Exigence: Tous les éléments 'Boîte de réception', 'Messages envoyés', 'Brouillons', 'Spam', 'Corbeille', etc. doivent être clairement visibles.
Mise en œuvre: Les éléments à voir doivent être affichés au format «Tree» ou «Tab».
# 5) Toutes les exigences sont-elles attribuées?
Par exemple,
Exigence: L'option de messagerie 'Corbeille' est fournie.
Mise en œuvre: Si l'option 'Corbeille' a été fournie, l'option 'Supprimer' les e-mails (exigence) doit être implémentée au départ et doit fonctionner correctement. Si l'option 'Supprimer' des e-mails fonctionne correctement, seuls les e-mails supprimés seront collectés dans la 'Corbeille' et la mise en œuvre de l'option de messagerie 'Corbeille' (exigence) aura du sens (sera utile).
Avantages du RTM et de la couverture des tests
#1) La version développée et testée possède la fonctionnalité requise qui répond aux besoins et attentes des «clients» / «utilisateurs». Le client doit obtenir ce qu'il veut. Surprendre le client avec une application qui ne fait pas ce qu’il est censé faire n’est une expérience satisfaisante pour personne.
#deux) Le produit final (application logicielle) développé et livré au client ne doit comprendre que les fonctionnalités nécessaires et attendues. Les fonctionnalités supplémentaires fournies dans l'application logicielle peuvent sembler intéressantes au départ jusqu'à ce qu'il y ait une surcharge de temps, d'argent et d'efforts pour la développer.
etl testing entretien questions et réponses pdf
La fonctionnalité supplémentaire peut également devenir une source de défauts, ce qui peut causer des problèmes pour un client après l'installation.
# 3) La tâche initiale du développeur est clairement définie au fur et à mesure qu'il travaille d'abord sur la mise en œuvre des exigences, qui sont de haute priorité, conformément aux exigences du client. Si les exigences hautement prioritaires du client sont clairement spécifiées, alors ces composants de code peuvent être développés et mis en œuvre en priorité.
Ainsi, il est garanti que les chances que le produit final soit expédié au client soient conformes aux exigences les plus élevées et soient dans les délais.
# 4) Les testeurs vérifient d'abord les fonctionnalités les plus importantes mises en œuvre par les développeurs. Comme la vérification (test) du composant logiciel prioritaire est effectuée en premier, cela aide à déterminer quand et si les premières versions du système sont prêtes à être publiées.
# 5) Des plans de test précis, des cas de test sont écrits et exécutés qui vérifient que toutes les exigences de l'application sont correctement implémentées. La cartographie des cas de test avec les exigences permet de garantir qu'aucun défaut majeur n'est oublié. Il aide en outre à mettre en œuvre un produit de qualité selon les attentes des clients.
# 6) En cas de «demande de changement» du client, tous les composants d’application affectés par la demande de changement sont modifiés et rien n’est oublié. Cela améliore encore l'évaluation de l'impact d'une demande de changement sur l'application logicielle.
# 7) Une demande de modification apparemment simple peut impliquer des modifications qui doivent être apportées à plusieurs parties de l'application. Il est préférable de tirer une conclusion sur l’effort nécessaire avant d’accepter de procéder au changement.
Défis de la couverture des tests
# 1) Bon canal de communication
S'il y a des changements suggérés par le Les parties prenantes , la même chose doit être communiquée aux équipes de développement et de test dans les premières phases de développement. Sans cela à temps Le développement, le test de l'application et la capture / correction des défauts ne peuvent être assurés.
# 2) Il est important de hiérarchiser les scénarios de test
Identifier les scénarios de test hautement prioritaires, complexes et importants est une tâche difficile. Essayer de tester tous les Scénarios de test est presque une tâche irréalisable. L'objectif de tester les scénarios doit être très clair du point de vue de l'entreprise et de l'utilisateur final.
# 3) Mise en œuvre du processus
Le processus de test doit être clairement défini en tenant compte de facteurs tels que l'infrastructure technique et les implémentations, les compétences de l'équipe, les expériences passées, les structures organisationnelles et les processus suivis, les estimations de projet liées au coût, au temps et aux ressources et à l'emplacement de l'équipe selon les fuseaux horaires.
Une mise en œuvre uniforme du processus tenant compte des facteurs mentionnés garantit que chaque personne concernée par le projet est sur la même longueur d'onde. Cela aide à un flux fluide de tous les processus liés au développement d'applications.
# 4) Disponibilité des ressources
Les ressources sont de deux types, les testeurs spécifiques au domaine spécialisé et les outils de test utilisés par les testeurs. Si les testeurs ont une bonne connaissance du domaine, ils peuvent écrire et mettre en œuvre des scénarios et des scripts de test efficaces. Pour mettre en œuvre ces scénarios et scripts, les testeurs doivent être bien équipés avec des «outils de test» appropriés.
Une bonne mise en œuvre et une livraison ponctuelle de l'application au client peuvent être assurées par le seul testeur qualifié et les outils de test appropriés.
# 5) Mise en œuvre efficace de la stratégie de test
' La stratégie de test »en soi est un grand sujet de discussion distinct. Mais ici, pour la «couverture de test», une mise en œuvre efficace de la stratégie de test garantit que le Qualité' de l'application est bon et c'est entretenu sur la période de temps partout.
Une «stratégie de test» efficace joue un rôle majeur dans la planification à l’avance de toutes sortes de défis critiques, ce qui contribue en outre au développement d’une meilleure application.
Comment créer une matrice de traçabilité des exigences
Pour être avec nous, nous devons savoir exactement ce qui doit être suivi ou retracé.
Les testeurs commencent à écrire leurs scénarios / objectifs de test et éventuellement les cas de test basés sur certains documents d'entrée - Document sur les exigences commerciales, Document de spécifications fonctionnelles et document de conception technique (facultatif).
Supposons que ce qui suit est notre Business Requirements Document (BRD): ( Téléchargez cet exemple de BRD au format Excel )
(Cliquez sur l'image pour l'agrandir)
Vous trouverez ci-dessous notre Document de Spécifications Fonctionnelles (FSD) basé sur l'interprétation du Business Requirements Document (BRD) et l'adaptation de celui-ci aux applications informatiques. Idéalement, tous les aspects de la FSD doivent être traités dans la BRD. Mais pour simplifier, je n’ai utilisé que les points 1 et 2.
Exemple de FSD ci-dessus BRD: ( Téléchargez cet exemple de FSD au format Excel )
Noter : Le BRD et le FSD ne sont pas documentés par les équipes QA. Nous ne sommes que les consommateurs des documents avec les autres équipes de projet.
Sur la base des deux documents d'entrée ci-dessus, en tant qu'équipe d'assurance qualité, nous avons élaboré la liste ci-dessous de scénarios de haut niveau à tester.
Exemples de scénarios de test des BRD et FSD ci-dessus: ( Téléchargez cet exemple de fichier de scénarios de test )
Une fois que nous sommes arrivés ici, ce serait le bon moment pour commencer à créer la matrice de traçabilité des exigences.
Personnellement, je préfère une feuille Excel très simple avec des colonnes pour chaque document que nous souhaitons suivre. Étant donné que les exigences commerciales et les exigences fonctionnelles ne sont pas numérotées de manière unique, nous allons utiliser les numéros de section dans le document pour effectuer le suivi.
(Vous pouvez choisir de suivre en fonction des numéros de ligne ou des numéros à puces, etc. en fonction de ce qui est le plus logique pour votre cas en particulier.)
Voici à quoi ressemblerait une simple matrice de traçabilité pour notre exemple:
Le document ci-dessus établit une trace entre le BRD et le FSD et éventuellement les scénarios de test. En créant un document comme celui-ci, nous pouvons nous assurer que chaque aspect des exigences initiales a été pris en compte par l'équipe de test pour créer ses suites de tests.
Vous pouvez le laisser de cette façon. Cependant, afin de le rendre plus lisible, je préfère inclure les noms de section. Cela améliorera la compréhension lorsque ce document est partagé avec le client ou toute autre équipe.
Le résultat est comme ci-dessous:
Encore une fois, le choix d'utiliser l'ancien format ou le plus récent vous appartient.
Ceci est la version préliminaire de votre TM mais généralement, ne remplit pas son but lorsque vous vous arrêtez ici. On peut en tirer un maximum d'avantages lorsque vous l'extrapolez jusqu'aux défauts.
Voyons comment.
Pour chaque scénario de test que vous avez proposé, vous allez avoir au moins 1 ou plusieurs cas de test. Alors, incluez une autre colonne lorsque vous y arrivez et écrivez les ID de cas de test comme indiqué ci-dessous:
À ce stade, la matrice de traçabilité peut être utilisée pour trouver des lacunes. Par exemple, dans la matrice de traçabilité ci-dessus, vous voyez qu'il n'y a pas de cas de test écrits pour la section 1.2 de la FSD.
exemples d'application client-serveur et d'application Web
En règle générale, tous les espaces vides dans la matrice de traçabilité sont des domaines potentiels à étudier. Donc, un écart comme celui-ci peut signifier l'une des deux choses:
- L'équipe de test a en quelque sorte manqué la fonctionnalité «Utilisateur existant».
- La fonctionnalité 'Utilisateur existant' a été reportée ultérieurement ou supprimée des exigences de fonctionnalité de l'application. Dans ce cas, le TM montre une incohérence dans le FSD ou BRD - ce qui signifie qu'une mise à jour des documents FSD et / ou BRD doit être effectuée.
S'il s'agit du scénario 1, il indiquera les endroits où l'équipe de test doit travailler davantage pour assurer une couverture à 100%.
Dans les scénarios 2, TM ne montre pas seulement des lacunes, mais indique une documentation incorrecte qui nécessite une correction immédiate.
Développons maintenant la TM pour inclure l'état d'exécution et les défauts du scénario de test.
La version ci-dessous de la matrice de traçabilité est généralement préparée pendant ou après l'exécution du test:
Télécharger le modèle de matrice de traçabilité des exigences:
=> Modèle de matrice de traçabilité au format Excel
Points importants à noter
Voici les points importants à noter à propos de cette version de la matrice de traçabilité:
#1) L'état d'exécution est également affiché. Pendant l'exécution, il donne un aperçu consolidé de la progression du travail.
# 2) Défauts: Lorsque cette colonne est utilisée pour établir la traçabilité vers l'arrière, nous pouvons dire que la fonctionnalité «Nouvel utilisateur» est la plus défectueuse. Au lieu de signaler que tel ou tel cas de test a échoué, TM fournit de la transparence à l'exigence commerciale qui présente le plus de défauts, présentant ainsi la qualité en fonction de ce que le client désire.
# 3) Comme étape supplémentaire, vous pouvez coder en couleur l'ID de défaut pour représenter leurs états. Par exemple, L'ID de défaut en rouge peut signifier qu'il est toujours ouvert, en vert peut signifier qu'il est fermé. Lorsque cela est fait, le TM fonctionne comme un rapport de contrôle de santé affichant l'état des défauts correspondant à une certaine fonctionnalité BRD ou FSD est en cours d'ouverture ou de fermeture.
# 4) S'il existe un document de conception technique, des cas d'utilisation ou tout autre artefact que vous souhaitez suivre, vous pouvez toujours développer le document créé ci-dessus en fonction de vos besoins en ajoutant des colonnes supplémentaires.
Pour résumer, RTM aide à:
- Assurer une couverture de test à 100%
- Affichage des incohérences entre les exigences et les documents
- Affichage du statut global de défaut / exécution en mettant l'accent sur les exigences métier.
- Si une certaine exigence métier et / ou fonctionnelle venait à changer, une MT permet d’estimer ou d’analyser l’impact sur le travail de l’équipe QA en termes de révision / retouche des cas de test.
Aditionellement,
- Une matrice de traçabilité n'est pas un outil spécifique aux tests manuels, elle peut également être utilisée pour les projets d'automatisation. Pour un projet d'automatisation, l'ID de scénario de test peut indiquer le nom du script de test d'automatisation.
- Ce n'est pas non plus un outil qui peut être utilisé uniquement par les AQ. L'équipe de développement peut utiliser la même chose pour mapper les exigences BRD / FSD aux blocs / unités / conditions de code créés pour s'assurer que toutes les exigences sont développées.
- Outils de gestion des tests comme HP ALM sont livrés avec la fonction de traçabilité intégrée.
Un point important à noter est quela façon dont vous maintenez et mettez à jour votre matrice de traçabilité détermine l'efficacité de son utilisation. S'il n'est pas mis à jour souvent ou mis à jour de manière incorrecte, l'outil est un fardeau au lieu d'être une aide et donne l'impression que l'outil en lui-même n'est pas digne d'être utilisé.
Conclusion
La matrice de traçabilité des exigences est le moyen carte et trace toutes les exigences du client avec les cas de test et les défauts découverts. C'est un document unique qui sert le but principal qu'aucun cas de test n'est manqué et ainsi chaque fonctionnalité de l'application est couverte et testée.
Une bonne «couverture de test» qui est planifiée à l'avance empêche les tâches répétitives dans les phases de test et les fuites de défauts. Un nombre élevé de défauts indique que les tests sont bien effectués et que la «qualité» de l’application augmente. De même, un nombre de défauts très faible indique que le test n’est pas effectué à la hauteur de la marque et que cela nuit à la «qualité» de l’application de manière négative.
Si la couverture du test est effectuée à fond, un faible nombre de défauts peut être justifié et ce nombre de défauts peut être considéré comme des statistiques à l'appui et non comme une statistique principale. La qualité d'une application est qualifiée de «bonne» ou «satisfaisante» lorsque la couverture de test est maximisée et le nombre de défauts minimisé.
A propos de l'auteur: Urmila P., membre de l'équipe STH, est une professionnelle de l'assurance qualité expérimentée avec haute qualité compétences de test et de suivi des problèmes.
Avez-vous créé une matrice de traçabilité des exigences dans vos projets? Dans quelle mesure est-il similaire ou différent de ce que nous avons créé dans cet article? Veuillez partager vos expériences, commentaires, pensées et commentaires sur cet article à travers vos commentaires.
lecture recommandée
- Exemple de modèle de plan de test logiciel avec format et contenu
- Comment rédiger un rapport de synthèse de test efficace (Exemple de téléchargement de rapport)
- Exemple de modèle de scénario de test avec des exemples de scénario de test (Télécharger)
- Exemple de modèle de rapport de test d'acceptation avec des exemples
- Comment rédiger un document de stratégie de test (avec un exemple de modèle de stratégie de test)
- Comment tester la spécification des exigences logicielles (SRS)?
- Top 20+ meilleurs outils de gestion des exigences (la liste complète)
- Les listes de contrôle de test de logiciel d'assurance qualité (exemples de listes de contrôle inclus)