pour donner ma vision :
la stratégie de tests, au sens large, doit se baser avant tout sur le bénéfice risque
- développer des tests unitaires automatisés n'a de sens que si on les réutilise souvent (donc il faut avoir souvent des évolutions mais il ne faut pas tout changer à chaque fois). En effet, si on ne doit tester qu'une fois une appli car si elle, et son environnement (données, connexions, ...), sont tellement stables qu'il n'y a aucune activité pendant des années, le coût sera bien trop important par rapport à des tests manuels (le temps de conception des tests est le même, qu'ils soient manuels ou automatisés, le temps de dev est bien plus élevé que le temps d'une passe de tests) A l'inverse, si l'application est tellement fluctuante que les tests doivent être fortement redéveloppés à chaque fois à quoi bon.
- développer des tests unitaires automatisés avec l'objectif de couvrir 100% des fonctionnalités et l'exhaustivité des cas est aussi une perte de temps
- accepter des trous dans la raquette des tests n'est pas une hérésie. On peut aussi s'appuyer sur l'apprentissage. Un bug est détecté (soit en phase de recette, soit en production) alors que les tests unitaires n'ont rien vu alors on apprend en rajoutant un test correspondant aux entrants du bug. Ex pour le cas de la multiplication :
je teste : 1 * 1 ca donne 1, 1 * 2 ca donne 2, 2 * 3 ca donne 6, ca a l'air correct, youpi. Mais voilà, suite à un bug identifié plus tard dans la chaine de validation, je m'aperçois que 8 * 4 ne donne pas 32 mais 3 (ce con ne renvoie que le premier chiffre de la multiplication et pas tout le résultat) qu'à cela ne tienne, je rajoute un cas test 8 * 4, j'ai appris, la prochaine phase de tests automatisé identifiera ce bug éventuel (en cas de régression)
bref les tests unitaires ou pas, automatisés ou pas, n'ont pas systématiquement pour vocation de garantir et d'apporter la preuve que 100% du développement répond correctement au besoin. Ils sont là pour améliorer la qualité en réduisant les coûts liés à l'anomalie éventuelle
(évidemment un logiciel de paie, surtout pour ma paie, mérite d'être extrêmement bien testé :p )
la stratégie de tests, au sens large, doit se baser avant tout sur le bénéfice risque
- développer des tests unitaires automatisés n'a de sens que si on les réutilise souvent (donc il faut avoir souvent des évolutions mais il ne faut pas tout changer à chaque fois). En effet, si on ne doit tester qu'une fois une appli car si elle, et son environnement (données, connexions, ...), sont tellement stables qu'il n'y a aucune activité pendant des années, le coût sera bien trop important par rapport à des tests manuels (le temps de conception des tests est le même, qu'ils soient manuels ou automatisés, le temps de dev est bien plus élevé que le temps d'une passe de tests) A l'inverse, si l'application est tellement fluctuante que les tests doivent être fortement redéveloppés à chaque fois à quoi bon.
- développer des tests unitaires automatisés avec l'objectif de couvrir 100% des fonctionnalités et l'exhaustivité des cas est aussi une perte de temps
- accepter des trous dans la raquette des tests n'est pas une hérésie. On peut aussi s'appuyer sur l'apprentissage. Un bug est détecté (soit en phase de recette, soit en production) alors que les tests unitaires n'ont rien vu alors on apprend en rajoutant un test correspondant aux entrants du bug. Ex pour le cas de la multiplication :
je teste : 1 * 1 ca donne 1, 1 * 2 ca donne 2, 2 * 3 ca donne 6, ca a l'air correct, youpi. Mais voilà, suite à un bug identifié plus tard dans la chaine de validation, je m'aperçois que 8 * 4 ne donne pas 32 mais 3 (ce con ne renvoie que le premier chiffre de la multiplication et pas tout le résultat) qu'à cela ne tienne, je rajoute un cas test 8 * 4, j'ai appris, la prochaine phase de tests automatisé identifiera ce bug éventuel (en cas de régression)
bref les tests unitaires ou pas, automatisés ou pas, n'ont pas systématiquement pour vocation de garantir et d'apporter la preuve que 100% du développement répond correctement au besoin. Ils sont là pour améliorer la qualité en réduisant les coûts liés à l'anomalie éventuelle
(évidemment un logiciel de paie, surtout pour ma paie, mérite d'être extrêmement bien testé :p )