Les tests et leurs stratégies

Près-requit: connaître le TDD et/ou le BDD, les méthodes agiles.

L'agilité met l'accent sur la qualité. C'est vrai :

• Des pratiques telles que l'intégration continue, les tests unitaires, les tests de recette, le pair programming, mais aussi une volonté évidente d'automatisation jouent indéniablement sur la qualité du produit logiciel...
• Le client sur site et de courtes itérations, pour plus de collaboration et de feedback permettent de s'assurer que le "bon produit" est développé...
• Avec l'ajout d'un regard Lean et d'une approche ergonomique, le compte est souvent bon...

Malheureusement souvent, cette qualité est mal maîtrisée. Pourquoi ? Les tests sont mal définis. Précisément: un test coûte cher. Pour deux jours de développement, il en faut autant si ce n'est plus pour le tester. De ce constat, il en convient qu'il faut que ces tests soient de la hauteur de la fonctionnalité en vigueur. Revenons sur les concepts agiles, où la base est sur la priorité du besoin. Il en vas de même pour les tests, d'où la naissance de stratégie de test.

La stratégie de test se doit d'abord d'être envisagée dans une dimension high level en Sprint 0 pour l'ensemble de la version (une version, c'est entre 3 et 6 mois). Ensuite, le challenge du testeur est de l'ajuster au contexte à chaque début de sprint, en fonction du contenu du sprint à venir et de ce qui a été qualifié de Done au sprint précédent. A ce niveau, on va à l'essentiel : la stratégie de test, niveau sprint à la particularité d'être à la fois synthétique et très précise !

Pour mener a bien cette stratégie de test, des outils très visuels existent pour combler au mieux cette défaillance.

Ce sujet m'est venu à l'esprit lors d'une de mes réunions CMMi d'OPPTIC-LR