— Une nouvelle carte ! Avec cette fois des “acteurs” comme tu dis. Ils chassent les bugs ?
— Disons qu’ils recherchent activement des problèmes possibles avec l’application.
— À voir le nombre de triangles, ils ne vont pas rentrer bredouille…
— Oui, c’est un bon terrain de jeu. défense vs exploration (1) — On voit qu’ils sont surtout concentrés sur le périmètre initial de la conception.
— Exact. Ils le parcourent en s’aidant de la doc fonctionnelle, qu’ils transforment en “plans de tests”. Ensuite ils exercent le code de l’application en suivant ce plan.
— Ils explorent aussi la zone extérieure, on dirait ?
— Dès qu’ils le peuvent, oui. Mais il ne le peuvent pas souvent: le périmètre “connu” de la conception présente déjà assez de problèmes pour remplir leurs journées.
— Au moins ici le scénario dont tu parlais hier ne risque pas de se produire.
— Tu veux parler du cas où la liste des comptes dont le solde dépasse un certain seuil n’est pas correcte ?
— Oui. Ici, un testeur peut essayer la “feature” dans tous les sens possibles, et finir par trouver le bug !
— En y passant le temps qu’il faut, bien sûr.
— Bah ! C’est mieux que rien.
— Supposons que l’application autorise une opération seulement si le portefeuille ne contient aucun compte en “dépassement”. Comment tu t’y prendrais pour vérifier cette partie de son comportement ?
— Eh bien je testerais plusieurs cas :

∙ un portefeuille ne contenant aucun compte en dépassement, et l’opération est effectuée
∙ un portefeuille contenant un seul compte en dépassement, et l’opération est refusée
∙ un portefeuille contenant plusieurs comptes en dépassement, même résultat
∙ un portefeuille vide…

— Pas sûr qu’avec cette liste de cas tu aurais détecté le défaut dont on parlait hier.
— Je ne vois comment je l’aurais raté ! On a tous les cas de figure.
— Je ne sais pas si tu as recensé tous les cas de figure, mais je sais une chose : effectuer tous ces tests prend un certain temps.
— Hélas. Mais avec une IA…
— En attendant qu’une IA soit capable de raisonner jusqu’au point où elle peut élaborer une suite de cas pertinente, les testeurs prennent leur courage à deux mains, leurs journées de 8 heures, leur maigre budget de test, et essaient tant bien que mal de “couvrir” le périmètre de l’application.
— Je présume que pour cette application, tu militerais pour qu’on recrute plus de testeurs ?
— Ce ne n’est pas dit que le remède “plus de testeurs” viendrait à bout de tous les problèmes. Mais ce serait déjà mieux que rien.
— Évidemment, dans ce cas, le projet coûterait plus cher.
— Oui. Je doute que le client de cette application accepterait de payer plus cher pour ce travail de vérification assez élémentaire…
— Je suppose qu’il demanderait plutôt qu’on recrute de meilleurs développeurs !
— “Des meilleurs développeurs” c’est aussi plus cher.
— Il n’y a pas de solution, donc.
— Tant qu’on passe plus de temps à corriger les problèmes qu’à essayer de prévenir leur apparition, non.

(à suivre)

publié sur Linked In le 26/09/2023 #testing #tdd