Quelques rappels

1. Les tests montrent la présence de défauts

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.

Cette évidence indique aussi que si on ne teste pas, on ne trouvera pas de défauts : « qui cherche trouve », mais il faut commencer par chercher et être capable de trouver, car les tests dépendent d’un oracle (https://en.wikipedia.org/wiki/Test_oracle), mécanisme qui permet d’évaluer la réponse indiquée par l’application testée avec ce qu’elle est censée répondre ; si l’oracle est faux, le test le sera lui aussi et on n’aura rien trouvé !

L’expérience de chacun montre que généralement, ces recherches se situent dans le domaine de l’exactitude fonctionnelle, car par manque de culture et poussée par l’urgence, la facilité poussera l’équipe à conserver le focus sur les seuls tests fonctionnels.

2. Les tests exhaustifs sont impossibles

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 vérifier 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 6 : Exemple de partitionnement d’une variable

Le partitionnement de la variable x choisie pour exemple en Figure 6 donne les classes suivantes :

Chaque classe sera ainsi vérifiée par un test (voir flèches du dessous sur la Figure 7).

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

Le choix du nombre de valeurs pivots dépendra de la criticité (ou du niveau de confiance).

La Figure 7 montre les tests de valeurs pivots avec les flèches du dessus.

Sur notre exemple, on constate qu’il faudra 21 (6 + 5x3) tests sur l’hypothèse de l’approche 3 valeurs sur les pivots.

Figure 7 : Cas de tests avec les classes d’équivalences (flèches du dessous) et valeurs limites (flèches du dessus)

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, au même titre que d’autres activités telles que l’architecture.

Par ailleurs, l’équipe de développement étant dans son ensemble responsable de la qualité du produit livré, chacun doit participer à la qualité du produit, et aider au test autant que nécessaire !