Souviron, tu as complètement raison. Si Miles tu enseignes en utilisant un vocabulaire douteux, tu donnes une très mauvaise base à tes étudiants. Les mots ont un poids important dans la compréhension d'un processus, ce qui explique les définitions normalisées par exemple.
Mais, par contre, mon cher Souviron, en appliquant ce principe, on ne vérifie pas plus « que ça marche » qu'on ne vérifie « que ça plante », car les tests ne vérifient pas qu'un programme marche mais uniquement qu'il n'y a pas de nouvelle faute introduite, et a fortiori, cela augmente donc la confiance qu'on a dans le logiciel. À la limite, peut être pratiques-tu du model-checking dans ta branche, mais ça reste exceptionnel dans l'industrie. Mais sinon le but des tests traditionnels n'est que d'augmenter le niveau de confiance. Autrement, il n'y aurait pas tant de bug après mise sur site.
Comme le disait Hoare : « si tu n'as pas de bugs dans ton logiciel, c'est soit qu'il est trop petit pour en avoir, soit que tu ne les as pas encore découvert. »
Au passage, pour ceux qui s'intéresse aux tests, un nouveau livre est sorti il y a peu :
Software Testing and Analysis
Process, principles, and techniques
Mauro Pezzè and Michal Young
Wiley 2007.
D'avis de plusieurs collègues, ce livre est excellent.
Pis solutionner est un anglicisme... on t'a pas dit ça icite ?
Partager