Tester sans spécifications : méthode, réflexes, et pièges à éviter

L'histoire se répète (trop souvent)

Tu rejoins un sprint en cours. Le développeur te dit : "C'est prêt, tu peux tester." Tu demandes la spec. Il répond : "Il y en a pas vraiment… on a fait au feeling, c'était urgent."

Bienvenue dans la réalité de 80 % des équipes agiles.

Pas de user story formalisée. Pas de critères d'acceptation. Parfois même pas de maquette validée. Juste du code livré, une deadline qui presse, et toi, le QA, censé valider quelque chose dont personne ne s'est mis d'accord sur ce que ça doit faire.

La mauvaise nouvelle : ça ne va pas changer de sitôt.

La bonne : tester sans spec, ça s'apprend. Et ça peut même rendre ton rôle plus stratégique que jamais.

Pourquoi tester sans spec est plus courant qu'on ne le croit

Avant de parler méthode, posons le contexte. L'absence de spécifications n'est pas toujours un signe d'amateurisme. C'est parfois :

• une équipe en mode exploration (MVP, proto, spike technique)
• une feature construite itérativement, sans jamais formaliser l'état final
• un héritage de dette documentaire : le code existe, la spec n'a jamais été écrite
• une organisation où le QA est appelé très (trop) tard dans le cycle

Dans tous ces cas, la question n'est pas "pourquoi je n'ai pas de spec ?" mais "comment je travaille quand je n'en ai pas ?"

La méthode

1. Reconstituer l'intention avant de tester quoi que ce soit

Ton premier réflexe ne doit pas être d'ouvrir l'application. Il doit être de comprendre ce que la feature est censée accomplir pour l'utilisateur.

Pose ces trois questions, à l'oral ou par écrit :

• Quel problème utilisateur cette feature résout-elle ?
• Qui l'utilise et dans quel contexte ?
• C'est quoi le "ça marche" pour le PO/PM ?

Même une réponse imprécise te donne une direction. Et si personne ne peut répondre… tu as déjà trouvé ton premier bug : une feature sans intention claire.

2. Utiliser l'heuristique SFDIPOT

C'est l'un des outils les plus puissants du testing exploratoire. Développée par James Bach, cette heuristique te force à examiner le produit sous 7 angles :

• Structure : qu'est-ce qui compose le système ?
• Fonctions : que fait-il ?
• Données : quelles entrées/sorties traite-t-il ?
• Interfaces : comment interagit-il avec l'extérieur ?
• Plateformes : dans quel environnement tourne-t-il ?
• Opérations : comment est-il utilisé en pratique ?
• Temps : que se passe-t-il dans la durée, sous charge, en séquence ?

Pas besoin de spec pour parcourir cette grille. Elle te guide là où les bugs se cachent.

3. Construire ta "spec minimale" en temps réel

Quand tu testes, tu documentes. Pas pour faire de la bureaucratie mais pour externaliser ce que tu comprends du comportement attendu.

Format simple :

Observation : quand je fais X, il se passe Y. Question : est-ce que Y est le comportement voulu ? Hypothèse : je m'attends à Z.

Ce document devient la base de la conversation avec le PO ou le dev. Il transforme ton test en dialogue, et le dialogue en décision.

4. Tester par risque, pas par couverture exhaustive

Sans spec, l'exhaustivité est une illusion. Tu ne peux pas tout tester. Alors tu dois prioriser par impact.

Pose-toi ces questions :

• Si ça casse ici, qui est impacté ? Combien d'utilisateurs ? Quel niveau de criticité business ?
• Quelle partie du code a changé récemment (risque d'introduction de régression) ?
• Où est-ce que les utilisateurs passent le plus de temps ?

Ce n'est pas du testing au hasard. C'est du risk-based testing sans grille formalisée et c'est une compétence à part entière.

5. Clôturer par une déclaration de couverture

À la fin de ta session de test, rends visible ce que tu as fait ET ce que tu n'as pas fait.

Exemple :

"J'ai couvert les parcours principaux (happy path + 3 cas d'erreur sur le formulaire). Je n'ai pas testé le comportement hors connexion ni les cas multi-langue. Ces zones restent non validées."

C'est ce qu'on appelle une déclaration de risque résiduel. Elle te protège, elle protège l'équipe, et elle force une décision explicite sur ce qu'on accepte de ne pas tester.

Les pièges à éviter absolument

Piège n°1 : Valider parce que "ça fonctionne"

Sans spec, "ça fonctionne" ne veut rien dire. Ça peut signifier que le code s'exécute sans crash et pas que le comportement est correct. La conformité sans référentiel, c'est du testing cosmétique.

Piège n°2 : Remplacer la spec par des suppositions implicites

On teste souvent ce qu'on croit que le système doit faire, influencé par ce qu'on a vu en réunion ou entendu dans le couloir. Ces suppositions ne sont jamais validées explicitement. Résultat : des bugs passent, et des non-bugs sont reportés comme bugs.

La règle d'or : toute hypothèse doit être verbalisée et confirmée.

Piège n°3 : Accepter l'absence de spec comme une fatalité

"On n'a pas le temps d'écrire des specs" est une dette qualité déguisée en pragmatisme. Ton rôle de QA, ou de Test Lead, n'est pas d'accepter cette dette en silence. C'est de la rendre visible et de proposer le minimum viable pour avancer proprement : une user story de 10 lignes, 3 critères d'acceptation, même rédigés après-coup.

Piège n°4 : Tester seul dans son coin

Sans spec, la collaboration n'est pas optionnelle. Elle est le substrat du test. Un QA isolé qui teste sans référentiel et sans interaction produira des rapports de bug qui ne seront ni compris ni prioritisés.

Organise des sessions de test collaboratives (avec le dev, le PO, ou le designer) même courtes. 20 minutes de partage collaboratif valent mieux que 2 heures de test solitaire.

Piège n°5 : Confondre vitesse et qualité

L'absence de spec est souvent justifiée par l'urgence. Et sous pression, le QA peut être tenté de valider vite pour "débloquer". Mais valider sans comprendre, c'est créer une fausse sécurité. Un "approuvé" mal fondé est plus dangereux qu'un "à tester" honnête.

Ce que cette compétence révèle sur ton rôle

Tester sans spec n'est pas un sous-mode dégradé du testing. C'est une compétence de haut niveau qui mobilise :

• le sens critique (questionner, ne pas accepter l'ambigu)
• la pensée systémique (voir le produit dans son ensemble, pas feature par feature)
• la communication (transformer l'incertitude en dialogue structuré)
• le leadership qualité (être celui qui rend visible ce que personne ne voit)

C'est exactement ce que font les QA Leader qui ont de l'impact dans leurs organisations. Pas des testeurs en attente de specs. Des QAs capables de travailler dans l'ambiguïté et d'en sortir quelque chose de solide.

Tu veux aller plus loin ?

Si tu reconnais ces situations dans ton quotidien, le sprint sans spec, la feature floue, les décisions prises dans le couloir, et que tu veux construire une vraie posture de QA Leader, rejoins la liste d'attente du Bootcamp Leader QA.

👉 Rejoindre la liste d'attente

C'est un programme de 6 semaines pensé pour les QA qui veulent passer d'un rôle d'exécutant à un rôle de référent qualité dans leur équipe. Méthode, outils, pratique terrain et une communauté francophone pour ne pas avancer seul.

FAQ

Q : Si je n'ai pas de spec, est-ce que je suis responsable des bugs qui passent en production ?

Non. La responsabilité est partagée. Ton rôle est de rendre visible ce que tu as couvert et ce que tu n'as pas couvert. Si tu as documenté les zones non testées et que la décision d'aller en production a été prise malgré tout, la responsabilité est collective. C'est précisément pour ça que la déclaration de couverture est critique.

Q : Comment convaincre l'équipe de prendre 30 minutes pour écrire des critères d'acceptation minimaux ?

Parle ROI, pas process. Montre concrètement le temps perdu en allers-retours sur des bugs qui n'en sont pas, ou en retravail parce que "ce n'est pas ce qu'on voulait". 30 minutes en début de sprint évitent souvent 3 heures de discussion post-livraison. Un seul exemple concret vaut mieux qu'un discours sur les bonnes pratiques.

Q : Le testing exploratoire, c'est vraiment du testing "sérieux" ou c'est juste du clic aléatoire ?

C'est du testing sérieux et probablement l'une des compétences les plus exigeantes du métier. Le testing exploratoire structuré repose sur des heuristiques, des charters de session, une prise de notes rigoureuse, et une capacité à raisonner sur le risque en temps réel. Ce n'est ni du scripted testing, ni du clic aléatoire. C'est une pensée critique appliquée au produit, en temps réel.

Q : Est-ce qu'il existe un outil pour documenter rapidement ce qu'on teste sans spec ?

Plusieurs approches fonctionnent : les Session-Based Test Management avec un simple Google Doc ou Notion, les mind maps pour cartographier les zones couvertes, ou encore un tableau Kanban de couverture (à tester / en cours / couvert / exclu). L'outil importe moins que l'habitude de documenter, même brièvement, à chaque session.

Q : Quelle est la différence entre tester sans spec et faire du test de régression ?

La régression suppose qu'il existe un comportement de référence connu (la version précédente). Tester sans spec, c'est opérer sans référence du tout où tu dois construire ta propre ligne de base. C'est plus complexe, parce que tu dois à la fois explorer ET définir ce que "correct" signifie. C'est pour ça que la collaboration avec le PO ou le dev est indispensable.

Q : Je suis junior, est-ce que cette méthode est accessible pour moi ?

Oui, à condition d'accepter l'inconfort de l'ambiguïté. Les réflexes décrits dans cet article sont accessibles dès le début de carrière. Ce qui demande de la maturité, c'est la confiance pour affirmer "je ne sais pas ce que ce système est censé faire, et c'est un problème". Les juniors qui développent cette posture tôt prennent beaucoup d'avance.

Plus d’articles comme celui-ci