Qu'est-ce qu'un plan de test ? La page qui dit ce que vous ne testez pas

Un plan de test est un document court qui dit ce qui sera testé, ce qui ne le sera pas, par qui, dans quels environnements, et ce qui doit être vrai avant que quiconque commence ou s’arrête. Il s’écrit avant les tests, et l’essentiel de sa valeur tient au deuxième élément de cette liste.

N’importe qui sait énumérer ce qu’il compte vérifier. Écrire ce que l’on laisse délibérément de côté est la partie qui évite la conversation de trois semaines plus tard, celle où quelqu’un avait supposé qu’un point était couvert parce que personne n’avait dit le contraire.

Ce qu’il contient

Six sections portent presque toute la valeur, et chacune peut tenir en quelques lignes.

• Périmètre. Ce que couvre cette campagne de tests : quelles fonctionnalités, quelles versions, quelles plateformes.
• Hors périmètre. Ce qu’elle ne couvre délibérément pas, et pourquoi. La section la plus utile et celle qui manque le plus souvent.
• Approche. Manuelle, automatisée, ou la répartition entre les deux, et à quel niveau.
• Environnements et données. Où cela s’exécute et contre quoi, ce qui décide de ce qui peut être trouvé. Un plan qui dit “recette” sans dire quelle build et quelles données ne dit pas grand-chose.
• Critères d’entrée et de sortie. Ce qui doit être vrai avant que les tests commencent, et ce qui doit être vrai avant de les déclarer terminés.
• Risques. Ce qui pourrait empêcher ce plan de fonctionner, nommé tant que le dire ne coûte rien.

Certains plans ajoutent des rôles, un calendrier et un processus de traitement des anomalies. Cela compte d’autant plus qu’il y a de personnes impliquées, et très peu quand vous êtes deux.

Les critères de sortie sont là où les disputes ont lieu

“Terminé” n’a rien d’évident, et un plan qui ne le définit pas produit une livraison que l’on discute le jour même au lieu de l’avoir tranchée à l’avance.

Faible

Tous les bogues majeurs corrigés et les tests terminés

Mieux

Chaque cas de la suite de commande passe, aucune anomalie ouverte en sévérité 1 ou 2, et les trois anomalies connues en sévérité 3 sont consignées avec leurs contournements dans les notes de version

Le second peut être vérifié par quelqu’un qui n’était pas dans la pièce. Le premier est une humeur.

Il en va de même des critères d’entrée : convenir que les tests commencent quand la build passe son test de fumée épargne à un testeur un après-midi passé à prouver de quarante façons qu’une build cassée est cassée.

Quelle longueur lui donner

Plus court que vous ne le pensez, et proportionné au nombre de personnes qui doivent être d’accord.

Deux personnes qui testent une fonctionnalité qu’elles comprennent toutes les deux ont besoin d’un paragraphe, et en écrire davantage relève du théâtre. Une livraison réglementée avec un auditeur externe demande le document formel, parce que quelqu’un d’extérieur à l’équipe doit pouvoir lire ce qui a été décidé. La plupart des situations se trouvent entre les deux, et une page est en général la bonne taille.

Le test à appliquer : le comportement de quelqu’un changerait-il si cette section n’existait pas ? Sinon, supprimez-la. Un plan que personne ne lit est pire que pas de plan du tout, parce qu’il installe la croyance que les tests avaient été planifiés.

Où il se situe parmi les autres documents

Un plan se situe un cran au-dessus des vérifications elles-mêmes.

• Le plan dit que le tunnel de commande sera testé manuellement sur Chrome et Safari, et que le mobile est hors périmètre pour cette campagne.
• Les cas de test disent exactement quoi faire et ce qui doit se produire.
• La suite de régression dit ce qui est revérifié parce que cela fonctionnait auparavant.
• Les critères d’acceptation disent ce que la fonctionnalité devait faire au départ, et ils ont été écrits avant tout le reste.

Confondre le plan et les cas est l’erreur courante : un document qui énumère deux cents étapes n’est pas un plan, c’est une suite avec une page de garde.

Le processus de traitement des anomalies en fait partie

Une ligne que la plupart des plans sautent, et elle coûte plus cher qu’il n’y paraît. Dites comment une anomalie est remontée, où elle va, et qui décide si elle bloque la livraison.

Sans cela, les constats arrivent dans trois fils de discussion et un tableur, la personne qui les rassemble passe le dernier jour de la campagne à courir après les détails, et quelque chose de réel se perd dans le bruit. Nommez la destination et la forme de ce qui y entre, et faites un lien vers le mode d’emploi plutôt que de le réécrire : notre guide du rapport de bogue existe pour être la chose que vous liez.

Si ceux qui testent sont des gens dont le métier n’est pas le logiciel, la forme compte davantage, et non l’inverse. Demandez-leur ce qui s’est passé et ce qu’ils attendaient, et laissez l’outillage porter la partie technique.

En bref

Une page : ce qui est couvert, ce qui ne l’est pas, comment, où, ce qui doit être vrai pour commencer et pour s’arrêter, et ce qui pourrait mal tourner. Écrit avant les tests, validé par les personnes qu’il concerne, et assez court pour qu’elles le lisent. La section que tout le monde saute, celle du hors périmètre, est celle qui évite la dispute.