Combler l'écart entre les exigences et la couverture des tests avec Jira and Thunders MCP in Claude

L'écart entre les exigences et la couverture des tests

Il existe une lacune que presque toutes les équipes d'assurance qualité vivent et dont elles parlent rarement directement.

Les exigences sont réunies dans un seul outil. Des cas de test existent dans un autre.

Et la question « Nos tests couvrent-ils réellement ce qui a été spécifié ? » reçoit souvent une réponse informelle, dans le cadre d'un stand up, d'une critique de publication ou simplement par intuition, plutôt que par des preuves.

Cet écart est particulièrement important lorsqu'il est trop tard : lorsqu'un bug est entré en production ou lorsqu'un auditeur de conformité demande la traçabilité entre vos spécifications et votre suite de tests.

Cet article montre comment combler cet écart en utilisant Jira MCP et Thunders MCP dans Claude, automatiquement, à la demande et avec une sortie auditable.

‍

Pourquoi les évaluations manuelles de la couverture ne sont pas fiables

Lorsqu'un ticket de fonctionnalité arrive dans QA, le processus standard est le suivant : lisez les critères d'acceptation dans Jira, ouvrez le scénario de test dans votre outil de gestion des tests et cochez mentalement quels critères semblent couverts.

Cela fonctionne lorsqu'un ticket comporte trois critères et deux étapes de test. Il se décompose lorsque vous avez défini six critères relatifs à la gestion des fichiers, au traitement, à la qualité de sortie, à l'expérience utilisateur et à la sécurité, ainsi qu'un scénario de test comportant huit étapes qui ne correspondent pas à une.

Vous vous retrouvez avec un appel subjectif, documenté nulle part, passé sous la pression du temps.

Le problème le plus profond est que les exigences et les cas de test sont créés indépendamment, souvent à l'aide d'outils différents, par différentes personnes et à différents moments du cycle de développement. Il n'y a aucun mécanisme intégré pour les maintenir alignés. Vous devez les aligner manuellement, à chaque fois.

‍

Ce qui change avec MCP

Le MCP (Model Context Protocol) permet aux assistants IA de se connecter directement à des outils externes et d'accéder à leurs données.

Une fois Jira MCP et Thunders MCP connectés, Claude peut récupérer un ticket Jira et un cas de test Thunders au cours de la même session et les examiner ensemble, sans exporter, copier-coller ou passer d'un outil à l'autre.

Claude peut lire les critères d'acceptation de Jira, revoir les étapes de test de Thunders et les comparer directement.

Au lieu de vérifier manuellement les systèmes et de mapper les exigences aux étapes de test, l'analyse peut être générée automatiquement à partir des données en temps réel des deux outils.

Alors que cette démo utilise Claude, le même flux de travail MCP fonctionne avec tous les clients compatibles MCP, y compris ChatGPT, Devin et autres.

Avant d'utiliser ce flux de travail, assurez-vous que Thunders MCP est connecté à Claude. Vous pouvez suivre ce guide de configuration rapide.

‍

Démo : vérification de la couverture des tests pour la fonctionnalité PDF-to-Word de Smallpdf

‍
Pour rendre cela concret, voici le flux exact que nous avons utilisé.

En Jira, nous avons créé un ticket de fonctionnalité (KAN-10) pour la fonction de conversion de PDF en Word sur Smallpdf. Le ticket contient une histoire utilisateur et six critères d'acceptation structurés couvrant le comportement de téléchargement des fichiers, le traitement des conversions, la qualité de sortie, les options de téléchargement et d'exportation, les exigences en matière d'expérience utilisateur et une exigence de sécurité concernant la suppression des fichiers.

Dans Thunders, nous avons utilisé Thunders Copilot pour générer un scénario de test intitulé « Conversion de PDF en Word à partir d'un scénario en langage naturel. Les étapes générées valider le chemin du bonheur : télécharger image-compressed.pdf, attendez la fin de la conversion, vérifiez qu'un bouton Télécharger apparaît, cliquez dessus et vérifiez qu'un .docx le lien de téléchargement est présenté.

Ensuite, nous avons lancé cette invite dans Claude :
‍

🧠 Rapide (copier/coller) :
‍
À l'aide du Jira MCP et du Thunders MCP, récupérez le ticket Jira KAN-10 et le scénario de test Thunders correspondant.
Comparez les critères d'acceptation avec les étapes du test.
Pour chaque critère, marquez-le comme étant couvert, partiellement couvert ou non couvert, et expliquez pourquoi.
Produisez un document Word contenant un résumé de la couverture, un tableau de couverture et des recommandations pour les éventuelles lacunes.

Claude appelle les deux serveurs MCP, récupère les données en temps réel et exécute l'analyse.

Le résultat est un document Word structuré avec une matrice de couverture, une analyse des lacunes et de nouvelles étapes de test écrites au format Thunders, prêtes à être ajoutées directement.

‍

Pourquoi c'est important au-delà du gain de temps

L'avantage évident est la rapidité. Un examen de couverture qui prenait auparavant 20 à 30 minutes de lecture et de recoupement ne prend désormais que quelques secondes.

Mais l'avantage le plus important est la cohérence et l'auditabilité. Le rapport est généré à partir de l'état réel des deux systèmes, à un moment précis, avec des références explicites aux données sources.

Si les exigences changent dans Jira, vous relancez l'invite et vous obtenez un nouveau rapport. Si des étapes de test sont ajoutées dans Thunders, même chose. La sortie est toujours actuelle, toujours traçable.

Pour les équipes travaillant dans des secteurs réglementés ou effectuant des examens de conformité internes, cette traçabilité fait la différence entre « nous pensons que nos tests couvrent cela » et « voici les preuves ».

‍

Invite réutilisable pour l'analyse de la couverture

Pour effectuer la même analyse de couverture sur vos propres billets, utilisez le modèle d'invite ci-dessous.
‍

🧠 Rapide (copier/coller)
‍
À l'aide du Jira MCP et du Thunders MCP, récupérez le ticket Jira [CLÉ DU BILLET] et son scénario de test Thunders correspondant.
Comparez les critères d'acceptation avec les étapes du test.
Pour chaque critère, marquez-le comme étant couvert, partiellement couvert ou non couvert, et expliquez pourquoi.
Produisez un document Word contenant un résumé de la couverture, un tableau de couverture et des recommandations pour les éventuelles lacunes.

‍

Remplacer [CLÉ DU BILLET] avec votre clé de Issue Jira et lancez l'invite.

Si vous souhaitez que les recommandations soient écrites sous forme d'étapes de test prêtes pour Thunder, ajoutez-les.

Si vous avez besoin d'une piste d'audit avec horodatages et identifiants source pour un rapport de conformité, ajoutez-la également.

L'invite de base fonctionne telle quelle pour une vérification quotidienne de la couverture.

‍

Où cela va-t-il se passer ensuite ?

Ce flux fonctionne pour tous les tickets de fonctionnalité dont les critères d'acceptation sont structurés, et pas uniquement pour les outils PDF. Le schéma est le même : exigences dans Jira, scénarios de test dans Thunders, Claude comme passerelle.

L'étape suivante consiste à l'exécuter dans le cadre du Définition de Done. Avant la publication d'un ticket, un rapport de couverture est généré et joint.

Pas comme une porte, mais comme un signal : un signal rapide et automatique qui vous indique exactement où se trouvent les lacunes pendant qu'il est encore temps de les combler.