Quand une équipe de test rejoint votre projet, elle réclame d’abord vos exigences. Cette demande paraît vague lorsque vous ne disposez que de vieilles spécifications, de quelques tickets et de connaissances qui vivent dans la tête des gens. Les exigences de test logiciel sont les descriptions écrites de ce que votre produit doit faire, assez claires pour que quelqu’un d’extérieur à votre équipe puisse en vérifier le résultat.
Elles couvrent les fonctionnalités que vous construisez, les règles métier qui les sous-tendent et les conditions qui décident si cela marche. Les testeurs les lisent pour apprendre ce qui compte comme correct.
Cependant, « avoir des exigences » et « avoir des exigences contre lesquelles quelqu’un peut tester » sont deux choses différentes. Beaucoup d’équipes possèdent des documents qui décrivent fidèlement le produit et laissent malgré tout un testeur sans moyen de prouver qu’une fonctionnalité marche. C’est de cette différence que parle ce guide, car elle détermine la vitesse à laquelle vos tests démarrent et la part qui repose sur des suppositions.
Vous verrez quels documents les testeurs utilisent réellement, ce qui rend une exigence testable, comment une équipe QA relit ceux que vous envoyez et par où commencer quand rien de tout cela n’existe encore. Si ce dernier cas vous parle, nos services de rédaction technique couvrent exactement cet écart.
Quelles Exigences de Test Logiciel une Équipe QA Attend-elle ?
La plupart des équipes transmettent les spécifications et les tickets qu’elles ont déjà en espérant que cela suffise. En général cela ne suffit pas, et le manque se situe rarement là où on l’attend. Quatre documents portent l’information dont les testeurs ont besoin, et vous en avez probablement déjà deux :
- SRS, la spécification des exigences logicielles. C’est le document détaillé, qui énumère chaque fonctionnalité et décrit le comportement attendu.
- BRD, le document des exigences métier. Il se place au-dessus du SRS et explique pourquoi le produit existe et à qui il s’adresse.
- Récits utilisateur et cas d’utilisation. Ils abordent la même question du côté de la personne, en montrant ce que quelqu’un cherche à accomplir.
- Critères d’acceptation. Ce sont les plus courts et souvent les plus utiles, une poignée de conditions qui tranchent la question de savoir si une fonctionnalité est terminée.
SRS
Comment chaque fonctionnalité doit se comporter
Analyste métier ou product owner
Les testeurs devinent le comportement voulu, puis signalent comme bugs des fonctionnalités correctes
BRD
Pourquoi le produit existe et à qui il s’adresse
Décideurs métier
L’effort se répartit uniformément au lieu de protéger ce qui rapporte de l’argent
Récits utilisateur et cas d’utilisation
Ce qu’une personne cherche à accomplir
Product owner, avec l’équipe
La couverture suit les écrans plutôt que les parcours réels, donc les chemins cassés survivent
Critères d’acceptation
Les conditions qui tranchent si une fonctionnalité est terminée
Product owner, affiné avec la QA
Chaque livraison finit en débat sur le fait de savoir si le travail est achevé
Vous n’avez pas besoin des quatre pour commencer. Un jeu clair de critères d’acceptation apporte plus à un testeur qu’une spécification de cent pages que personne n’a ouverte depuis l’an dernier. Ce qui compte, c’est que quelqu’un d’extérieur à la conversation puisse lire vos exigences de test logiciel et savoir quoi vérifier.
Il existe aussi une norme officielle derrière tout cela. ISO/IEC/IEEE 29148, actuellement dans son édition de 2018, traite de la manière d’écrire les exigences et de ce qu’une spécification devrait contenir. Vous n’avez presque certainement pas besoin de la lire, et la plupart des équipes ne le font jamais. Il vaut la peine de savoir qu’elle existe, car un auditeur, un régulateur ou un grand client d’entreprise peut vous demander quelle norme suivent vos exigences.
Qu'est-ce qui Rend une Exigence Testable ?
Une exigence est testable quand une personne qui ne l’a pas rédigée peut la lire, vérifier le produit et aboutir à la même conclusion que tout le monde. Cela semble évident, mais on le perd de vue parce que celui qui l’a écrite sait déjà ce qu’il voulait dire, si bien que les trous lui restent invisibles.
Voici la différence en pratique.
L’application devrait charger rapidement.
La liste de produits apparaît en moins de 3 secondes sur une connexion mobile normale.
Les utilisateurs devraient pouvoir réinitialiser leur mot de passe.
Un e-mail de réinitialisation arrive en moins de 2 minutes, et le lien cesse de fonctionner au bout de 24 heures.
Le paiement devrait gérer les erreurs avec élégance.
Si une carte est refusée, le panier conserve ses articles, aucun argent ne bouge, et l’acheteur voit la raison.
Remarquez ce qui a changé : chaque version testable nomme quelque chose qu’une personne peut observer et sur quoi elle peut s’accorder. Aucune n’avait besoin de plus de détail technique, seulement d’une décision que quelqu’un devait prendre tôt ou tard.
Trois questions vous diront si une exigence est prête :
- Pouvez-vous décrire à quoi ressemble « ça marche » sans les mots bon, rapide ou facile ?
- Deux personnes qui la liraient attendraient-elles le même résultat ?
- Quelqu’un peut-il la vérifier sans demander à l’auteur ce qu’il voulait dire ?
Répondez oui aux trois et l’exigence se transforme presque directement en cas de test, et c’est généralement là que commence notre travail de test fonctionnel.
Comment une Équipe QA Relit-elle vos Exigences ?
Avant que quiconque n’exécute le moindre test, une bonne équipe QA lit ce que vous avez envoyé et revient avec des questions. Cette relecture est rapide, et elle évite beaucoup de travail gâché plus tard.
Un relecteur cherche un ensemble précis de problèmes :
- Ce qui doit se passer quand quelque chose échoue, puisque la plupart des documents ne décrivent que le succès
- Des situations que personne n’a mentionnées, comme un compte vide, un visiteur de première fois ou une carte expirée
- Deux documents qui disent des choses différentes sur la même fonctionnalité
- Des règles sans aucun chiffre associé, du type rapide, sécurisé ou convivial
- Qui a le droit de faire quoi, quand personne ne l’a écrit
Chaque point de cette liste devient une question pour votre équipe. Y répondre pendant que les documents s’écrivent encore est rapide. La même question après la mise en production signifie modifier du code, relancer les tests et expliquer le retard à celui qui a signalé le problème.
Il est utile de distinguer quelques termes voisins. Les exigences sont le point de départ des tests. Les objectifs du test logiciel sont ce à quoi les tests servent. Vérifier votre produit par rapport à ces documents s’appelle la vérification, et confirmer qu’il résout le bon problème est la validation. Nous expliquons la différence dans vérification vs validation dans les tests logiciels.
Pourquoi ne pas Attendre la Documentation Finale
Les équipes retiennent souvent la QA jusqu’à ce que la paperasse soit terminée. Or, sur un produit encore en construction, elle ne l’est jamais tout à fait.
Attendre vous coûte deux fois :
- Les contradictions survivent. Un conflit entre deux documents passe inaperçu jusqu’à ce que quelqu’un écrive du code dessus, et le corriger signifie alors reconstruire plutôt que retoucher.
- Vous perdez votre meilleur lecteur. Un ingénieur QA qui parcourt une spécification à moitié écrite repérera les pièces manquantes par pure habitude.
Alors transmettez ce qui existe aujourd’hui, si partiel soit-il. Les testeurs peuvent commencer à bâtir des vérifications à partir des parties déjà arrêtées pendant que le reste rattrape son retard, et leurs questions nourrissent directement les documents que vous êtes encore en train d’écrire.
C’est pourquoi nous rejoignons les projets au stade qu’ils ont atteint au lieu d’attendre une passation finalisée. Notre guide du test agile montre comment cela se déroule sprint après sprint, et notre parcours des phases du test logiciel couvre les étapes que traverse le travail lui-même.
Que Faire Quand vos Exigences Sont Incomplètes
Beaucoup de produits nous parviennent avec presque rien d’écrit. C’est normal, surtout une fois que l’équipe qui a bâti la première version est partie. Vous avez davantage de matière première que vous ne le pensez.
- Écrivez ce que le produit fait aujourd’hui. Sur un produit en service, le comportement actuel est une source légitime, et le confirmer vaut mieux que l’inventer de toutes pièces.
- Commencez par les parcours qui rapportent de l’argent. L’inscription, le paiement et le renouvellement méritent des conditions écrites bien avant un écran de réglages.
- Transformez au fil de l’eau ce que les gens savent en critères d’acceptation. Chaque réponse donnée en réunion est une exigence qui attend d’être consignée.
- Rangez ces décisions dans un endroit trouvable. Une page partagée vaut mieux qu’un fil de discussion, qui vaut mieux que la mémoire d’une seule personne.
Ce travail relève de la rédaction plutôt que du test, si bien que la plupart des prestataires QA vous le renverront tel quel et attendront. Nous, à l’inverse, écrivons nous-mêmes les documents manquants puis testons contre eux, ce qui vous évite de payer deux sociétés pour qu’elles se mettent d’accord entre elles.
C’est ainsi que s’est déroulé le projet Logo Maker Shop. Sa version Android nous est parvenue sans aucune documentation de test, et les règles qui existaient étaient éparpillées en commentaires sur des écrans Figma. Nous avons reconstitué le reste à partir du comportement déjà en place de l’application iOS, demandé ce qui manquait au fur et à mesure, et rédigé 270 cas de test depuis zéro.
Comment QAwerk Comble l'Écart d'Exigences
Des exigences de test logiciel claires rapportent pour une raison purement commerciale. Elles réduisent les heures que votre équipe passe à expliquer le produit, elles diminuent les défauts qui se révèlent être des malentendus, et elles mettent fin au débat sur le fait de savoir si une fonctionnalité est terminée. Ce sont les exigences testables qui rendent ces trois choses possibles.
Quand vos documents restent en deçà, nous comblons l’écart en trois étapes. D’abord nous lisons ce que vous avez et revenons avec les questions que cela soulève. Ensuite nous mettons par écrit les pièces manquantes, pour que vos cas de test naissent d’un document et non d’une supposition. Pendant ce temps, les tests démarrent sur ce qui est déjà acté, et grandissent à partir de là. Nous avons fait cela sur plus de 300 projets, avec plus de 30 ingénieurs QA seniors dans l’équipe, chacun totalisant 9 ans d’expérience en moyenne.
Si vous n’êtes pas sûr que ce dont vous disposez suffise pour tester, réservez un appel avec notre équipe QA et nous passerons vos documents en revue avant que vous ne vous engagiez à quoi que ce soit.
FAQ
Que sont les exigences de test logiciel ?
Les exigences de test logiciel sont ce à partir de quoi une équipe QA travaille, en général une spécification, un document métier, des récits utilisateur, des critères d’acceptation, ou un mélange de tout cela. Leur rôle est d’énoncer ce que le produit doit faire en des termes assez précis pour qu’un testeur puisse décider, sans demander à personne, si un résultat donné est correct ou constitue un défaut.
Qu'est-ce qu'un SRS dans les tests ?
Un SRS, ou spécification des exigences logicielles, est le document long qui expose chaque fonctionnalité en détail. Utiliser un SRS pour tester signifie que chaque résultat attendu remonte à une ligne écrite, si bien qu’un testeur peut distinguer un vrai défaut de quelque chose construit ainsi à dessein. Les équipes en sprints courts le sautent souvent et s’appuient plutôt sur des récits utilisateur et des critères d’acceptation.
Qu'est-ce qui rend une exigence testable ?
Surveillez les adjectifs. Rapide, sécurisé, intuitif et convivial décrivent une opinion plutôt qu’un résultat, donc deux personnes les jugeront différemment. Une version testable met à leur place quelque chose de mesurable : un temps de chargement, une règle de permission, ou les étapes exactes qu’une personne accomplit. Réécrire une exigence prend en général une phrase, et cela supprime un débat que vous auriez sinon au moment de la livraison.
Peut-on commencer les tests sans exigences complètes ?
Oui, et patienter jusqu’à disposer de documents complets coûte généralement plus cher que de démarrer tôt. Une équipe QA peut travailler à partir de spécifications partielles, du comportement actuel du produit et de conversations avec ceux qui le connaissent le mieux. La relecture fait remonter les trous pour vous, ce qui va plus vite que de tout écrire d’abord et de découvrir les contradictions ensuite.
Qui rédige les critères d'acceptation ?
Le product owner les rédige normalement, puis les affine avec les développeurs et les testeurs qui vont les appliquer. Les écrire seul est l’erreur courante, car les conditions ne couvrent alors que le cas où tout fonctionne. Une courte relecture avec la QA ajoute celles que ce premier jet manque, et c’est là que commencent vraiment la plupart des désaccords sur ce qui est terminé.
Gratuit pour Vous : Modèle de Cas de Test
