👴🏻 🛀🏻 🧒🏻 Matrice de traçabilité 👋🏾 🥦 👨🏻‍🎤

Lorsque les exigences d'un projet changent «à la volée» et que vous n'avez pas les moyens de suivre la mise en œuvre de chaque exigence individuelle par fonctionnalité ou module, la question se pose: comment analyser la couverture? L'un des outils que notre équipe AQ utilise sur de tels projets est la matrice de traçabilité.

Pour le moment, nous utilisons des matrices depuis plus de 2,5 ans. Pendant ce temps, nous avons pu évaluer les avantages de cet outil, ainsi que l'adapter à notre projet.

Qu'est-ce qu'une matrice de traçabilité?

Par définition, la matrice de traçabilité est un tableau bidimensionnel contenant la correspondance des exigences fonctionnelles du produit (exigences fonctionnelles) et des cas de test préparés (cas de test).

À l'intersection de la ligne et de la colonne correspondantes, une marque est placée indiquant que cette exigence est couverte par ce scénario de test.

Ainsi, le tableau donne un affichage visuel de deux paramètres:

la présence dans le système d'exigences qui ne sont pas encore couvertes (si l'exigence n'a pas d'intersection unique avec des cas de test (condition suffisante);
Y a-t-il des tests excessifs dans le système - si les exigences ont plusieurs intersections (une condition nécessaire).

Dans notre projet, nous utilisons des matrices de traçabilité non seulement pour évaluer la couverture, mais aussi pour déterminer la relation entre les tâches de développement, les exigences et les artefacts de test.

Par conséquent, la matrice a la forme d'un tableau, dont chaque ligne contient:

numéro et description de la tâche de développement à partir de la tâche de suivi;
bloc logique auquel appartient la tâche (facultatif);
exigence atomique ou critères d'acceptation;
priorité;
numéro et description de l'artefact de test correspondant.

Puisque nous utilisons le traqueur de tâches Jira, Zephyr by Jira pour la documentation des tests et le système de gestion des exigences Confluence, toutes les entités sont synchronisées et cette traçabilité nous permet de:

visualiser l'état actuel de la mise en œuvre;
décomposer les besoins en plus atomiques et les structurer;
contrôler s'il existe des besoins pour lesquels le développement n'est pas encore planifié (passe de mise en œuvre);
surveiller si l'exigence est actuellement mise en œuvre;
surveiller si l'exigence est couverte par un scénario de test (sauter les tests);
Visualisez la hiérarchisation des exigences.

Options de relation dans la matrice de traçabilité

Les exigences de liaison et les cas de test peuvent être:

1 à 1 (exigence atomique, qui est couverte par un cas de test, ce cas de test ne couvre que cette exigence);
1 à n (une exigence couverte par plusieurs cas de test, ces cas de test ne couvrent que cette exigence);
n à n (une exigence qui est couverte par plusieurs cas de test, ces cas de test couvrent cette exigence et d'autres).

Concernant le dernier point, je tiens à noter que

lorsqu'une exigence de la matrice de traçabilité est couverte par plusieurs tests, cela peut indiquer une redondance des tests. Dans ce cas, il est nécessaire d'analyser le degré d'atomicité de l'exigence.
si, en effectuant tous les cas de test, nous garantissons l'exhaustivité de la couverture et que les cas de test eux-mêmes ne se dupliquent pas, ce ne sera pas un test excessif.

Nous avons des cas sur le projet où une exigence est couverte par plusieurs tests et un test peut couvrir plusieurs exigences (connexions «1 à n» et «n à n»).

Spécificité de l'estimation de la couverture à l'aide de matrices de traçabilité

Si nous utilisons le métrique «rapport du nombre d'exigences au nombre d'artefacts de test» pour évaluer la couverture, alors les relations dans la matrice doivent être «1 pour 1» et les exigences doivent être décomposées au maximum.

Un exemple. Nous avons une exigence non atomique: "L'utilisateur doit pouvoir modifier et formater la lettre dans un éditeur de texte." Un cas de test ne sera évidemment pas suffisant, mais si un seul artefact est lié dans la matrice, visuellement, il y aura une idée que l'exigence est couverte.

Il vaut donc mieux:

diviser cette exigence dans la matrice en fonctions atomiques distinctes d'un éditeur de texte;
rédiger un critère d'acceptation pour chaque fonction;
créer un artefact de test pour chaque critère;
si plusieurs exigences atomiques peuvent être couvertes par une seule liste de contrôle, vous ne pouvez pas effectuer une fragmentation excessive, économiser des ressources.

Avec un manque de ressources pour une décomposition maximale, vous pouvez utiliser des exigences non atomiques, mais pour couvrir chacune d'entre elles, vous devez créer plusieurs artefacts de test.

Dans ce cas, les cas de test et les listes de contrôle pour chaque exigence non atomique sont compilés à la fois, c'est-à-dire que chaque exigence de la matrice est entièrement couverte par des artefacts ou pas du tout couverte.

Lors de la compilation des matrices, il est conseillé de respecter la recommandation selon laquelle la décomposition de chaque exigence dans une seule matrice doit être approximativement égale, c'est-à-dire qu'un tableau ne doit pas contenir d'exigences, dont certaines nécessitent 5 cas de test et une partie - un cas de test.

Le score de couverture dans ce cas est calculé séparément pour chaque matrice.
Étant donné que la documentation de notre projet peut avoir un aspect différent pour chaque fonctionnalité et même une description d'une fonctionnalité peut contenir UML, des diagrammes, des diagrammes de cas d'utilisation et de transitions, et le projet contient plus de 40 fonctionnalités de volume, nous avons décidé de développer une matrice distincte pour chaque module ou fonctionnalité afin que Ne perdez aucun des avantages de cet outil.

Le score de couverture est également calculé séparément pour chaque module ou fonctionnalité.

Avec cette approche, nous pouvons utiliser la métrique décrite ci-dessus: «le nombre d'exigences pour le nombre d'artefacts de test». Même si nous avons 1 à n, n à n connexions, nous avons plusieurs composants, chacun pouvant être utilisé dans plusieurs modules. Les exigences et les critères d'acceptation sont décrits dans chaque matrice et un artefact de test est utilisé.

Nos matrices sont également stockées dans le système de gestion des exigences de Confluence - chaque matrice est située avec la structure en tant que page enfant de la fonctionnalité pour laquelle elle a été développée. De plus, toutes les matrices sont rassemblées sur une seule page pour faciliter l'évaluation de la couverture de la demande entière.

Création et maintenance d'une matrice

La création d'une matrice est incluse dans notre flux de travail sur les tâches d'analyse.

Lorsque nous recevons des informations sur une nouvelle fonctionnalité, l'analyste de notre équipe crée une tâche dans le traqueur de tâches et, avec le responsable du produit, travaille dans le cadre de cette tâche de la part du client. Dans le processus de collecte et de structuration des exigences, toute l'équipe procède à une revue et pose des questions supplémentaires. Lorsque les exigences sont formulées, documentées et confirmées par le client, le chef de l'équipe de développement crée des tâches pour le développement de cette fonctionnalité, et l'équipe de test peut commencer à créer une matrice de trace.

Et ici, nous pouvons distinguer les étapes suivantes de la compilation de la matrice de traçabilité:

Au début, les exigences sont décomposées et hiérarchisées par la commande QA et / ou Product Owner. Le résultat de cette étape est une liste structurée et hiérarchisée de toutes les exigences pour cette fonctionnalité.
La deuxième étape sera la communication avec l'équipe de développement et l'attribution des tâches des tâches du tracker au développement dans la matrice aux exigences pertinentes. En conséquence, nous pouvons suivre la traçabilité des exigences et des tâches de développement.
La troisième étape est l'élaboration de cas de test et de listes de contrôle.
Cette étape est effectuée soit avant le test, soit pendant le test d'une tâche spécifique.
Si la fonctionnalité est nouvelle et que l'interface change, il peut y avoir des cas dans lesquels les étapes sont mieux décrites immédiatement avant de tester la tâche.
Si la fonctionnalité d'implémentation est similaire à l'une des fonctionnalités existantes, nous pouvons commencer à décrire les cas de test avec des étapes immédiatement après l'examen et la décomposition des exigences.
Étape 4 - remplir la matrice de cas de test.
Sur la base des résultats de l'ensemble du processus, nous obtenons des tâches de développement, des cas de test pour les tests et une matrice de traçabilité qui les combine et les exigences.
L'élaboration des exigences est en cours de clôture.
Étape 5 - maintien de la matrice dans l'état actuel. Des modifications doivent être apportées à toute modification des exigences. Vous devez également prendre en compte les relations d'intégration entre deux matrices qui décrivent des fonctionnalités ou des modules différents, et lorsque vous en changez une, assurez-vous de vérifier s'il est nécessaire de modifier la seconde.

Difficultés à travailler avec la matrice de traçabilité

Actualisation
La matrice ne sera utile qu'à la condition d'être toujours à jour. Sur notre projet avec des exigences qui changent fréquemment, la mise à jour a pris beaucoup de temps, mais si la matrice n'est pas mise à jour, elle devient non seulement inutile, mais aussi confuse.

Comment décider :

Résolution partielle du problème avec un changement fréquent des exigences et transfert de l'étape de création de la matrice au moment où les exigences ont déjà été revues par l'équipe et confirmées par le client.
L'équipe a décidé que l'analyste mettrait à jour les exigences non seulement sur la page avec la description des fonctionnalités, mais les trouverait également et les mettrait à jour dans la matrice, en les surlignant dans une couleur différente. Cela a aidé toute l'équipe à ne pas perdre les modifications, et l'équipe QA en particulier - pour voir quels cas de test nécessitaient une mise à jour.
Ressources temporaires
Le projet peut avoir une version urgente et fonctionner avec de nouvelles exigences en même temps, et toutes les ressources d'assurance qualité sont envoyées pour les tests et ne fonctionnent pas avec les exigences. Ainsi, la dette augmente selon la documentation de test.

Comment décider :

Si tous les spécialistes de l'assurance qualité sont occupés à tester des tâches prioritaires, nous transférons la création d'une matrice pour une fonctionnalité spécifique. Dans la mesure du possible, elle est transférée au moment de tester la première tâche pour cette fonctionnalité, et dans ce cas, la matrice est remplie de cas de test lorsque vous testez les tâches dans lesquelles la fonctionnalité est implémentée.

Le spécialiste de l'assurance qualité fixe le temps d'évaluation non seulement pour la rédaction des cas de test eux-mêmes, mais aussi pour le développement de la matrice.
Efficacité

Si le projet est petit et que toutes les exigences sont encadrées sous la forme d'un mandat structuré, et que des cas de test sont créés pour chaque exigence à la fois, la matrice de traçabilité de notre formulaire ne fera que dupliquer les informations et sera un gaspillage de ressources.

Par conséquent, vous devez utiliser la matrice standard décrite dans la définition pour évaluer la couverture.

Commodités

La matrice vous permet de surveiller la mise en œuvre des exigences, de vérifier que toutes les exigences sont développées et testées et que rien ne manque.
La matrice aide l'équipe AQ à vérifier s'il existe des dettes sur la documentation de test et quelles exigences spécifiques ne sont pas encore couvertes par les cas de test.
L'outil est utilisé par l'analyste et l'équipe AQ pour surveiller les exigences modifiées.
Sur le projet, des matrices de traçabilité ont été utilisées non seulement par nous, mais aussi par le propriétaire du produit de la part du client. Ils se sont donc assurés que toutes les exigences sont là et qu'elles sont correctes, et suivies à l'aide de la matrice, qui a déjà été mise en œuvre. Les matrices nous ont permis de rendre le processus de développement et de test quelque peu transparent.