Quelques rappels

1. Principe du test #1 - Les tests montrent la présence de défauts, et non l’absence de défauts

Ce principe vient d’une citation d’Edsger Dijkstra lors d’une conférence faite à Rome en octobre 1969 au Comité des Sciences de l’OTAN [Meerts 2012] :

« Les tests montrent la présence de défauts, pas leur absence » - [Dijkstra 1969]

L’activité de test montre seulement la présence de défauts, ce qui veut dire qu’elle n’en démontre pas l’absence, mais son déroulement permet de réduire la probabilité de leur présence.

Bien qu’un proverbe danois dit que « tant qu’on ne sait pas que son lit est dur, on dort bien », appliquer la politique de l’autruche en ignorant les problèmes qui pourraient survenir aboutira tôt ou tard à une plainte d’un client. Pour éviter que cette situation ne se produise, ce principe est une invitation à chercher, car tester est le seul moyen qui pourrait montrer l’anomalie.

Dans certains cas comme la Méthode B (voir chapitre Versant technique du test), le code est démontré, ce qui est bien plus fort que toute une batterie de tests en boîte blanche. Cependant, la preuve n’est pas pour autant exempte d’erreurs. Ainsi, trouver des situations qui viennent alors démontrer que la preuve est fausse ou refaire la démonstration est une démarche indispensable au test.

2. Principe du test #2 - Le test exhaustif est impossible

De nos jours, les systèmes conçus sont d’une complexité telle qu’il est impossible de vérifier toutes les combinaisons qui permettraient de contôler une éventuelle absence de défaut.

1. Partitionnement de classes d’équivalences et valeurs limites

Lorsqu’une variable influence le comportement de l’application par palier, cette technique peut être utilisée pour identifier tous les tests qui seraient à réaliser.

Figure I-7 : Exemple de partitionnement d’une variable

Le partitionnement de la variable x choisie pour exemple en figure I-7 donne les classes suivantes :

Chaque classe sera ainsi vérifiée par un test (ce sont les flèches du dessous sur la figure I-8).

En complément à ces vérifications, il faudra ajouter les tests de chaque valeur pivot (Ai). Pour assurer cette partie, vous disposez de deux tactiques en fonction de la criticité du test :

Le choix du nombre de tests autour des valeurs pivots dépendra de la criticité ou du niveau de confiance.

La figure I-8 montre les tests de valeurs pivots, les flèches du dessus. Sur notre exemple, il faudra 6 tests pour les différentes classes d’équivalences et 3*5 tests pour les 5 valeurs pivots, ce qui nous fait...

1. Projet à l’échelle d’une seule équipe Scrum

Pour Scrum, il n’y a pas d’équipe dans l’équipe. Scrum ne reconnaît donc pas la présence d’une équipe de test dans l’équipe de réalisation ; en d’autres termes, le test est idéalement confié à tous, chacun à son niveau de compétence, au même titre que d’autres activités telles que l’architecture.