Deux définitions du test

Comme tant de domaines, le test logiciel a souvent été défini. On trouvera une définition différente dans chaque livre, dans chaque glossaire. Avec un peu de chance, on constatera que ces définitions expriment globalement la même idée. Est-ce bien le cas ?

La définition classique : le test pour vérifier la conformité

Le glossaire du CFTL donne une définition large et conventionnelle du test logiciel :

Processus consistant en toutes les activités du cycle de vie, statiques et dynamiques, concernant la planification et l’évaluation de produits logiciels et produits liés pour déterminer s’ils satisfont aux exigences, pour démontrer qu’ils sont aptes au objectifs et détecter des anomalies.

Voilà une définition qui tache de ne rien oublier : les techniques statiques, si facilement évincées, l'application à tout le cycle de vie du logiciel et non aux activités qui précèdent la mise en production... Quant au but, il est clair : le test permet de vérifier que le logiciel livré et maintenu est le bon. Celui qui est conforme aux attentes des utilisateurs, aux besoins, aux exigences, aux standards... Oh, et s'il y a des défauts, ils sont détectés.

Cette description est assurément positive. Le test permet d'améliorer la qualité. Au fait, comment pourrait-il en être autrement ? Contrairement au développement, le test contribue pas directement au logiciel produit. En passant commande, le client achète du code (fut-il compilé) et de la documentation, pas des tests. Par conséquent, le test n'aurait pas sa place dans les projets s'il n'annonçait pas sa capacité à apporter de la valeur.

La définition destructive : le test qui casse le logiciel

Dans The Art of Software Testing, Glenford Myers donne une toute autre version :

Tester est le processus consistant à exécuter un programme dans le but d'y trouver des erreurs. *

L'approche est radicalement différente. Point de qualité ou de conformité, mais un but précis et résolument négatif. Trouver des bugs. Mettre en défaut le travail des développeurs.

Curieuse approche, voir carrément suicidaire. Entretien d'embauche : "Bonjour Monsieur l'Employeur. Vous devez savoir que j'aime les bugs. Je les collectionne.Si vous m'offrez ce poste, je m'évertuerai à démontrer que vos logiciels sont bourrés d'erreurs". D'accord, cette approche sarcastique ne dupe personne. On voit bien que la définition de Myers a du sens. Néanmoins la question se pose : comment deux définitions si différentes peuvent-elle coexister ?

Une question de buts et de taches

Dans le test comme dans la vie, on a des buts :

• Vérifier la conformité d'un logiciel
• Apprendre le chinois
• Partir en voyage

Cet buts permettent de savoir où l'on va. Cependant, ils ne sont pas réalisables tel quel. Ils ne sont pas actionables comme le décrit David Allen dans son best seller Getting Things Done. On en peut pas débuter la journée en se disant "Aujourd'hui, j'apprends le chinois", car l'apprentissage du chinois prend des années. Pour réaliser ces buts, il faut :

• Implémenter les cas de test spécifiés la veille, déclencher une réunion pour discuter de ces tests qui n'en finissent pas d'échouer, lancer les tests sur le dernier build...
• Chercher les cours de chinois qui se déroulent dans le quartier, apprendre 10 idéogrammes, regarder un film chinois en VO...
• Renouveler son passeport, rechercher le meilleur rapport qualité/prix sur Internet, faire la liste des choses à acheter avant le départ...

Autrement dit, on a besoin de décomposer les buts en sous-projets et finalement en taches qui sont concrètement réalisables. C'est ce que fait la définition de The Art of Software Testing par rapport à celle du CFTL. Un testeur ne peut pas poser les mains sur le clavier en pensant "Je vais vérifier que le logiciel satisfait aux exigences". Il devrait avoir cela en tête pour ne pas perdre le Nord, mais cela ne lui dira pas s'il doit lire un document, ouvrir un fichier ou lancer un test. En approfondissant, le testeur peut déterminer ses activités :

• Lire et comprendre les exigences, faire des retours s'il y détecte des incohérences
• Participer à une revue de code
• ...

L'une de ses activités lui est dictée par la définition de Myers : exercer le logiciel dans le but d'y trouver des erreurs. A nouveau, le testeur devra réfléchir aux taches concrètes qui découlent de ce sous-objectif : écrire un test, exécuter ce test, lire The Art of Software Testing...

* Testing is the process of executing a program with the intent of finding errors.