Des tests de non-régression, par définition, ne permettent pas de trouver des défauts (sous entendu "nouveaux") mais de s'assurer qu'ils ne reviennent pas.
C'est ce qu'oublient souvent les gens quand ils critiquent les tests (unitaires, de non-régression, etc.). Dans l'expression assurance qualité, le terme assurance est important : grâce aux tests, on sait que certains bugs n'existent pas. Sans les tests, on peut croiser les doigts et compter sur la méticulosité des développeurs, mais en réalité on ne sait jamais à coup sûr ce qui marche et ce qui ne marche pas. Surtout que sauf exception on a très peu de testeurs des versions alpha et béta, donc la plupart des bugs sont rapportés après une sortie officielle.
en conclusion, je me demande si l'efficacité de ces méthodes n'est pas plutôt dépendante du moment où elle sont effectuées plutôt que de la méthode elle-même
Je dirais plutôt que c'est le soin avec lequel elles sont appliquées. Par exemple, des tests peuvent aller du trivial (tester un cas nominal et basta) jusqu'au très poussé (lancer des tas de threads et pousser une API dans ses derniers retranchements, simuler des erreurs d'allocation mémoire, etc.).
[^] # Re: efficacité des différentes méthodes de tests
Posté par Antoine . En réponse à la dépêche [code] Trouver les erreurs. Évalué à 4.
Des tests de non-régression, par définition, ne permettent pas de trouver des défauts (sous entendu "nouveaux") mais de s'assurer qu'ils ne reviennent pas.
C'est ce qu'oublient souvent les gens quand ils critiquent les tests (unitaires, de non-régression, etc.). Dans l'expression assurance qualité, le terme assurance est important : grâce aux tests, on sait que certains bugs n'existent pas. Sans les tests, on peut croiser les doigts et compter sur la méticulosité des développeurs, mais en réalité on ne sait jamais à coup sûr ce qui marche et ce qui ne marche pas. Surtout que sauf exception on a très peu de testeurs des versions alpha et béta, donc la plupart des bugs sont rapportés après une sortie officielle.
Je dirais plutôt que c'est le soin avec lequel elles sont appliquées. Par exemple, des tests peuvent aller du trivial (tester un cas nominal et basta) jusqu'au très poussé (lancer des tas de threads et pousser une API dans ses derniers retranchements, simuler des erreurs d'allocation mémoire, etc.).