Certains en font beaucoup, d’autres pas du tout. Pourquoi cette différence de traitement en ce qui concerne la non régression. Quel est son objectif ? Pourquoi certains en font, quand d’autres non ?
Le principe même d’une anomalie est de ne pas savoir où elle va advenir, ou sinon il n’y en aurait pas. La non régression n’échappe pas à ce principe, par conséquent certains par prudence retestent tout et d’autres trouvant cela trop cher, n’en font finalement pas.
D’autre part, la plupart des acteurs projet se focalisant sur la « nouveauté », la non régression est souvent « invisible ». Sans oublier que les approches agiles étant des processus relativement cadencés, la non régression ni trouve tout simplement pas toujours sa place.
Mais aussi, la non régression est un capital qui augmente à chaque version applicative et qui nécessite un processus particulier. De plus ce capital pouvant devenir conséquent, on doit y adjoindre un autre processus pour le choix du périmètre pour une version, engendrant une certaine complexité…
Comparatifs
Certaines personnes m’ont dit qu’il était inadmissible d’avoir une régression en production. Pour les utilisateurs, il ne faut pas de dégradation de service, alors qu’on peut toujours attendre une évolution, ou être plus conciliant si elle ne fonctionne pas correctement. De ce point de vue, la non régression est obligatoire.
Donc pour moi, la question n’est donc pas de savoir si on doit en faire, mais finalement de savoir la part de non régression à exécuter.
Exécuter toute la non régression à chaque fois coûte cher et n’est donc pas une solution.
Exécuter tout le temps le même sous périmètre n’est pas ciblé et n’est donc pas une solution.
La meilleure solution est d’avoir un petit noyau de cas critique à exécuter à chaque fois et une enveloppe de test qui dépendent du périmètre de la version.
Le sujet étant toujours de comparer le coût de la qualité au coût de la non qualité. Cette étude pouvant être compliqué ou non réalisable, en tout cas pour une version, le plus simple peut être de définir un budget de non régression acceptable pour chaque version. Ce budget pouvant être légèrement adapté en fonction des risques particuliers de la version.
Pour donner des ordres d’idée, de manière générale, on est souvent autour de 20% du budget prévu pour les tests évolutifs. Rarement en dessous, mais pour des applications anciennes et complexes on peut monter jusqu’à 50%. Au final, il s’agit d’un sujet de budget et de risque.
Afin de toucher du doigt la complexité du processus permettant de réaliser la non régression, je vous propose un petit exercice calculatoire. Une application qui en est à sa dixième version ou sprint, avec un périmètre de test évolutif constant de 100 tests, amène à choisir pour une version un périmètre de non régression de 20 tests parmi les 1000 existants…
Même si on ne capitalise pas les 1000 pour différentes raisons de coût et pertinence, cela nécessite néanmoins une certaine organisation pour les gérer… De plus, dans tous les cas il faut choisir les 20 parmi un périmètre bien plus conséquent…
Tout le monde a perdu dans ce combat, et c’est malheureusement difficile de gagner avec la non régression, entre le risque de sur qualité et le risque de sous qualité. On touche ici du doigt la complexité du métier de testeur, à plus d’un titre.
3 réponses
Quel est l’intérêt de tester ?
On peut comparer le test avec une assurance :
– tant que je n’ai pas d’incident je pense que je paie une police d’assurance « pour rien ». En réalité j’achète une sérénité (voire une conformité suivant les assurances)
– mais le jour où j’ai un accident alors je suis bien content d’être assuré, car je peux réagir et rapidement avoir une solution
Le coût du bug en prod (l’incident pour l’assurance) n’est pas toujours facile à mesurer/anticiper alors que le coût du test (police d’assurance) peut facilement être suivi.
Faisons appel aux 7 principes pour nous guider :
Pourquoi y a t’il des régressions : combo [l’absence d’erreur est illusion] + [le test montre la présence de défauts et pas l’absence] + [tester tout est impossible]
Que doit on tester : [le regroupement de défauts] + [le test dépend du contexte] pour identifier un périmètre & [l’usure des tests] car il faut faire vivre son patrimoine pour que le test reste efficace
Enfin j’ajouterais [tester tôt] : un défaut lors de la fabrication coûte moins cher qu’en prod
Quelle stratégie adopter : régression ou pas ?
Je partage votre avis : tout dépend du contexte. Ne pas vérifier une page consultée 1 fois par an est peut être envisageable dans certains contextes : tout dépend de ce qu’elle contient et du risque qu’on accepte.
Pour chaque risque on peut décider de le diminuer (ce que fais le test), transférer (solliciter une autre équipe) ou accepter (on ne fait rien et on fera face quand il sera avéré).
C’est pourquoi il n’y a pas de gagnant, pas de stratégie « prête à l’emploi ». On décide de tester (un périmètre/tout/rien) selon le budget et le contexte… idéalement en ayant une gestion des risques.
Clairement il n’y a pas de stratégie de test « prête à l’emploi » comme certains peuvent le penser.
Et oui tout est question de risque.
Le test n’est que de la gestion de risque, à tous les niveaux…
La problématique des tests de non-régression (ou tests de régression) met en lumière l’importance, lors de la conception et de l’implémentation des cas de test, de leur qualification en termes d’importance (a.k.a. « criticité », même si ce terme devrait être spécifique aux conditions de test) et de la gestion de la traçabilité bijective entre conditions de test et cas de test.
Le niveau d’importance des CT n’est pas « gravé dans le marbre ! Il doit être revu en fonction des risques, de l’objectif de test et de la stratégie de test définie.
J’ai toujours trouvé utile, pour les outils qui le permettent, la possibilité de tracer les différentes versions des CT, permettant ainsi de tracer l’évolution des différents critères de leur qualification.