Estimer la charge de test ? Oui, selon l’ISTQB. Mais… – Imen Naguez

L’ISTQB, que ce soit au niveau Fondation ou Avancé, propose plusieurs méthodes bien cadrées pour estimer la charge des tests :

• L’estimation par l’expertise (jugement d’expert, méthode Delphi),
• L’estimation à partir de métriques issues de projets passés,
• Et même des modèles plus mathématiques basés sur l’effort.

Ces facteurs prennent en compte des critères comme la complexité des exigences, la stabilité des spécifications, ou encore la disponibilité des environnements.

Bref, tout ça est logique, structuré, bien pensé… sur le papier.

Mais dans la vraie vie du testeur manuel, ces méthodes laissent un grand angle mort.

Le projet démarre. Le cadrage commence. Et forcément… la question tombe :

« Dis, tu peux nous estimer la charge QA pour ce projet ? »

Et là, je souffle un coup ! Parce que je n’ai jamais su répondre à cette question avec précision.

Et je ne parle pas ici de la charge de rédaction des cas de test, ni de la durée de la phase d’exécution planifiée dans un joli tableau.

Non.

Je parle de la vraie vie du testeur manuel, celle qu’on ne met jamais dans l’estimation.

Alors ce que je réponds souvent, c’est un truc un peu bizarre, mais que je pense sincèrement comme ce que j’ai toujours vu sur les projets que ce soit complexe ou simple :

« Démarrons. Pour 3 devs, prévoyons 1 QA. On adaptera selon la réalité. »

Et cette réponse, même si elle semble floue, est plus honnête que n’importe quelle estimation figée. Parce qu’on va être clairs : la charge d’un QA manuel, c’est un océan de variables et des facteurs imprévisibles. Voici pourquoi.

Les facteurs imprévisibles de l’estimation de la charge

1)    Les environnements instables, le cauchemar du testeur

Le testeur est constamment dépendant des environnements. La moindre instabilité technique provoque :

• Des faux positifs,
• Des investigations inutiles,
• Des blocages à faire remonter,
• Et un moral plombé par des heures perdues.

Tout cela génère une charge invisible, aléatoire, et pourtant bien réelle.

2)    L’anomalie, ce n’est pas juste un clic sur “Créer un bug”

Quand on trouve une anomalie, il faut :

• La prouver (reproductions, captures, logs),
• La décrire avec rigueur (parfois avec l’effort d’un Victor Hugo pour que ce soit clair),
• La défendre auprès de l’équipe,
• Parfois même organiser un atelier informel pour en réexpliquer l’impact.

Pendant ce temps-là, on pense à d’autres cas à tester, mais on n’a pas le temps de les écrire. Encore de la charge contournée.

3)    La galère des jeux de données (JDD)

Créer ou trouver un JDD valide, dans un projet complexe, c’est un test en soi. Et ce n’est pas que pour soi : le testeur devient souvent celui qui débloque les autres intervenants pour leur propre JDD.

Temps imprévisible, charge collective assumée en silence.

4)    La charge mentale, ce facteur qu’on n’estime jamais

On jongle entre plusieurs cas en cours, les retours d’anomalies, les interruptions diverses, tout en gardant le contexte métier en tête.

Ce n’est pas visible sur un planning, mais ça pèse lourd sur la productivité et la précision

5)    Réaligner, clarifier, re-questionner

Les exigences sont souvent floues, mouvantes, ou interprétées différemment. Le testeur doit :

• Interroger le métier ou le PO,
• Reformuler ce qu’il a compris,
• Ajuster ses tests en conséquence.

Cette boucle de clarification est essentielle… mais rarement prise en compte.

6)    Gardien de la connaissance projet

Avec le temps, le testeur devient une référence : il forme les nouveaux, réexplique des règles oubliées, soutient les analystes ou développeurs sur des cas métier précis.

Il transmet, il vulgarise, il stabilise… mais ce n’est écrit dans aucun planning.

7)    Les priorités qui changent en continu

Le testeur vit au rythme des urgences :

• Un déploiement avancé,
• Une anomalie bloquante,
• Un environnement indisponible,
• Une régression imprévue…

Il doit s’adapter, replanifier, revoir sa stratégie. Et l’estimation initiale ? Elle vole en éclats.

8)    Le projet simple qui se transforme en complexe

Au lancement, on part souvent avec une vision macro : une description générale, quelques objectifs business… mais sans visibilité réelle sur les dépendances, les prérequis techniques, l’architecture cible ou les règles métier précises.
Très vite, ce qui semblait simple se révèle bien plus complexe :

• Multiplicité des cas métier,
• Enchaînements conditionnels,
• Intégrations multi-systèmes,
• Données croisées difficiles à valider.

Et là, le périmètre QA explose, tout comme la charge, sans que cela ait été anticipé dans l’estimation initiale.

Les points qui suivent m’ont été soufflés par Karine St-Onge analyste QA senior, avec qui j’ai eu l’opportunité d’un échange sur ces sujets. Son regard lucide et terrain complète parfaitement cette liste.

9)    La maturité de l’équipe

La charge QA dépend aussi de ceux qui l’entourent. Une équipe qui communique bien, qui comprend l’importance du test, qui livre des versions stables et qui rédige des specs claires, facilite énormément le travail QA.
Mais quand l’équipe est peu expérimentée, désorganisée ou peu impliquée côté qualité, le testeur doit compenser :

• Aller chercher les infos manquantes,
• Reformuler les règles métier,
• Vérifier ce qui aurait dû l’être en amont,
• Suivre les retours non tracés.

La charge explose, non pas à cause des tests eux-mêmes, mais à cause du contexte dans lequel ils sont réalisés.

10)  La qualité du processus QA en place

La charge ne dépend pas uniquement de ce qu’on teste, mais aussi de comment on teste. Quand il existe une vraie culture QA dans le projet — stratégie définie, outils adaptés, priorités claires, gestion structurée des anomalies — le testeur peut se concentrer sur l’essentiel.
Mais sans processus solide, tout devient lourd :

• Des critères d’acceptation flous,
• Des priorisations changeantes,
• Des anomalies non suivies,
• Des efforts dispersés et mal exploités.

Et dans ce flou, la charge de test devient ingérable, car chaque action est à inventer, à justifier, à reprendre.

En résumé

La charge QA n’est pas juste une estimation en heures. C’est un mix de rigueur, d’intuition, de débrouillardise, et surtout de résilience face à l’imprévu.

C’est être capable de planifier, oui ! mais aussi de s’adapter, d’improviser, de gérer l’inattendu avec calme, sang-froid et méthode.
Et c’est peut-être ça le plus dur à expliquer à ceux qui demandent un chiffre clair.

Parce que “Estimer la charge des tests manuels comme une tâche fixe, c’est comme vouloir prédire la météo d’un microclimat : tu peux avoir une tendance, mais jamais une garantie.”

Alors oui, on fait de notre mieux. On donne une estimation.
Mais la vérité, c’est que tout dépend du contexte, des personnes, des outils, de la qualité des livrables, de l’écoute, de la collaboration, et même parfois… de la chance.

Et c’est pour ça que le plus important dans un projet, ce n’est pas juste combien de jours de QA on a prévu, c’est comment on s’adapte ensemble quand les choses ne se passent pas comme prévu. Parce qu’elles ne se passent jamais exactement comme prévu.

A propos de l’auteure Imen Naguez: Experte en qualité logicielle (QA) et ingénierie qualité (QE), je possède une solide expérience en gestion des tests, automatisation et amélioration continue. Diplômée en ingénierie et certifiée ISTQB Test Manager, je conçois et mets en œuvre des stratégies de test adaptées aux projets complexes, en optimisant l’efficacité des équipes et l’efficience des processus.