Organisation des tests : Cycle en V

Après un premier article sur les tests unitaires, je me suis dit que, pour le coup, j'avais mis la charrue avant les boeufs. En effet, avant de se lancer dans les différentes phases de tests à mettre en place, il est probablement plus judicieux de détailler un peu ce que l'on entend des tests, et de voir comment ils s'intègrent dans un projet.

Les tests ont pour buts premiers de valider le travail effectué, de déterminer la qualité du travail produit, et de permettre ainsi de mettre en oeuvre des actions correctives, pour qu'au final, on obtienne un résultat le plus fiable possible, mais aussi le plus proche de ce que l'on attendait initialement.

On le voit bien ici, la notion de tests ne s'applique pas exclusivement aux programmeurs, mais bien à tous les membres travaillant sur un projet : je ne referai pas le monde et je vous présente donc directement la conclusion de la réflexion de nombreuses personnes sur le sujet : le cycle en V.



Sans entrer trop dans le détail, on voit clairement qu'à chaque étape de la production correspond une catégorie de tests. Chacune se basera sur la documentation réalisée dans le cadre de la conception pour déterminer les tests à effectuer.

On voit aussi que la progression dans les tests va à l'inverses de la progression de la conception : d'un côté on part d'une observation "générale", la rédaction du cahier des charges, vers le détail, à savoir la production du code, tandis que l'on commencera par tester le code, pour finir par s'assurer de la bonne cohérence da la production par rapport à ce qui était initialement recherché.

Programmation -> Tests unitaires : on contrôle la qualité du source produit, du bon fonctionnement des fonctions indépendemment de leur environement.
Conception architecturale -> Tests d'intégration : on contrôle que l'ensemble des fonctions associées entre elles fonctionnent correctement.
Analyse -> Tests de validation : on contrôle que le logiciel répond bien au critères techniques fixés.
Rédactions du cahier des charges -> Tests fonctionnels : on contrôle que le logiciel fini répond bien aux besoins exprimés dans le cahier des charges.

Le principal avantage de cette hiérarchisation des tests est que les erreurs remontées à chaque niveau trouvent leur solution au même niveau côté conception, cela permet de limiter considérablement le champ de recherches de solutions. Par contre, plus le niveau de conception remis en cause est élevé, plus il y aura de travail à fournir dans les niveaux inférieurs : d'où l'importance de bien travailler chaque phase de la production avant de passer à la suivante.

Pour aller plus loin :
- Comment construire les tests d'un logiciel