Les livrables du test

Le test, par définition n’est pas un métier de « création » comme peut l’être le métier de développeur. Néanmoins lorsque l’on exerce ce métier on crée de la valeur.

La valeur créée par un testeur est simplement différente (un testeur seul ne développera pas une application mobile). La valeur ajoutée du testeur est plus abstraite, elle se rapproche d’un indice de confiance ou même d’un indicateur aidant à la prise de décision pour des questions vitales aux projets telles que :

L’application (ou le logiciel) peut-il être mis sur le marché dans son état actuel?

C’est pour cela que la visibilité des tests, ainsi que la communication sur leurs résultats et analyses est primordiale dans ce métier.

Malgré le fait que la valeur du test soit abstraite, il existe de nombreux « livrables » créés par les testeurs pendant leur travail, en voici quelques-uns :

1.      Les plans de test

Les plans de tests sont des documents essentiels, partagés par l’ensemble des intervenants sur le projet. Ils définissent ce qui va être testé, ce qui ne va pas être testé, comment cela va être testé et les risques engendrés par ces décisions. Ils sont un élément essentiel dans la visibilité des tests.

Les plans de test permettent de savoir où on va et comment on y va. Il est dès lors plus simple de s’y rendre efficacement.

2.      Les tests

Les tests sont la base du travail de tous les testeurs. Ils doivent être designés, écrits, exécutés, analysés, maintenus et archivés. Ces tests peuvent être manuels ou automatisés. L’ensemble des tests sur un projet a beaucoup de valeurs… à conditions qu’ils soient:

  • bien designés (et donc qu’il y ait une bonne couverture): des tests mal designés laissent trop de « trous dans la raquette » et ont un mauvais retour sur investissement.
  • bien écrits (facile à exécuter, à analyser en cas de besoin et à maintenir): des tests mal écrits sont sources de nombreuses erreurs (bugs qui n’en sont pas, cas en échec car non stable…)
  • maintenus: des tests non maintenus sont des tests dangereux, car en plus de ne plus fournir l’information voulue, il en fournit une fausse et empêche d’avoir celle que l’on souhaite.

Vouloir tester avec de mauvais tests c’est comme vouloir nager avec les bras attachés dans le dos : c’est possible mais dans tous les cas plus compliqué et moins efficace.

3.      Des campagnes spécifiques

Il existe plusieurs types de campagne de tests en voici trois :

Il y a les campagnes de validation où l’on exécute des cas de test dans le but de vérifier le bon fonctionnement d’une nouvelle fonctionnalité. Cette campagne est ponctuelle et une majorité de ses tests ne seront plus exécutés à la fin de cette campagne.

Les campagnes de régression, servant à vérifier que l’implémentation d’une nouvelle fonctionnalité n’a pas cassé les anciennes. Les tests de ce type de campagnes doivent régulièrement être maintenus.

Les campagnes de tests vitaux dont le but est de s’assurer que les fonctions vitales de l’application sont en état de fonctionnement. Ces tests doivent être exécutés très régulièrement et toujours être à jour.

Savoir optimiser le temps passer sur les campagnes afin d’atteindre la juste qualité sur le projet permet, en plus d’atteindre cette qualité souhaitée, de ne pas dépenser trop d’argent pour l’atteindre (la maintenance des tests peut très vite coûter très cher).

4.      Les bilans des campagnes de test

Les bilans de campagnes permettent de donner les résultats de l’exécution des tests. Il peut avoir des bilans intermédiaires dans le cas de campagnes longues (plusieurs jours). Dans ces campagnes figurent des informations comme les tests exécutés, les bugs ouverts, les bugs corrigés, les difficultés rencontrées, une analyse des risques, divers indicateurs et toute autre information demandée par des membres du projet.

Ces bilans, essentiels pour la visibilité des tests, sont généralement les livrables les plus attendus pas les responsables métiers.

5.      Les bugs et leur gestion

Un bug détecté est une information précieuse, que celui-ci soit résolu ou non (non résolu peut être un signe qu’il n’est pas prioritaire à corriger, résolu veut dire qu’il a existé et que du travail a été fait afin de le clore), rejeté ou non (s’il est rejeté cela peut dire que le test n’est pas assez bien écrit ou que l’environnement de test n’est pas stable), mineur ou critique (cela permet de connaitre son impact).

Il faut donc savoir gérer cette information. Par gérer je veux dire 2 choses. La première est simple : avoir et respecter un parcours dans la résolution des bugs (détecter, analyser et catégoriser, corriger, vérifier la correction, clôturer) mais aussi avoir des bugs « standardisés » au moins au niveau des noms de bugs. Cela permet de retrouver beaucoup plus facilement si un bug est déjà ouvert ou s’il a déjà existé. Dès lors l’utilisation des informations des bugs est plus simple.

6.      Un environnement et des données de test

Cela n’est pas toujours un livrable de l’équipe de test mais dans tous les cas cela reste un outil essentiel qui doit être géré.

De nombreux tests ne sont pas stables à cause des environnements ou de données de tests non fiables. Ces instabilités sont régulièrement source de beaucoup de temps de perdus. Dans le cas où les environnements et les données ne dépendent pas de l’équipe de test une communication visant à donner les besoins de l’équipe à l’équipe responsable des environnements et des données peut s’avérer nécessaire.

Faire une couverture des données (qui peut aussi être un livrable) est un vrai plus afin de connaitre quels sont les réels besoins de l’équipe sur le projet.

Conclusion :

Même si le test n’a pas pour but de créer des livrables, ces derniers sont souvent indispensables afin d’atteindre le but premier de ce métier : Fournir assez d’informations pour savoir si un produit peut passer en production. Les livrables et leur qualité ne sont donc pas à négliger, la qualité du travail fournit en dépend grandement.

Avoir de mauvais livrables garantit des informations de mauvaises qualité et/ou très coûteuses par rapport à leur valeurs.

Pensez à rejoindre le groupe Le métier du test si le test vous intéresse !

N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Agilité

Fiche métier: Testeur Agile (réflexion)

Dans mon article sur les évolutions dans les métiers du test, je n’utilise que des fiches métiers CFTL à l’exception du métier « Testeur Agile ». Si j’ai mis ce métier à part c’est justement parce qu’il a certaine particularité. Je me suis donc essayé à l’exercice de construire une fiche métier

Lire la suite »
logo test
culture générale

Les valeurs de l’extrême droite ne sont pas compatibles avec le test

En ce moment on parle beaucoup, élections oblige, de politique et de la possibilité de l’accession au pouvoir en France d’un parti d’extrême droite. Je m’abstiens généralement de parler de politique mais j’ai décidé, pour cette fois, de faire une entorse à cette règle en raison du contexte mais aussi

Lire la suite »
processus

La phase de Retest

Le cycle de vie d’un bug  comporte plusieurs étapes décrites ci-dessous : Dans ce cycle, une étape est malheureusement souvent négligée : La phase de Retest (ou de vérification). A quoi correspond exactement cette phase ? La phase de retest d’un bug a plusieurs buts : ·        Vérifier que le bug est bien corrigé : un

Lire la suite »