Peut-on vraiment tester un logiciel à 100 % ? Comprendre la couverture de test
Résumer cet article avec :
Un tableau de bord, une matrice de traçabilité ou un rapport de test affiche un résultat rassurant : 100 % de couverture. On a vite envie de comprendre : « tout a été testé ».
Le chiffre peut être juste. Mais il peut seulement signifier que tous les tests prévus ont été exécutés. Ou que toutes les lignes de code ont été parcourues. Ou encore que chaque exigence possède au moins un test. Dans les trois cas, des scénarios importants peuvent manquer.
Avant de faire confiance au score, il faut donc savoir ce qu'il mesure. Une fois ce point clair, le 100 % devient beaucoup plus facile à lire.
Que signifie réellement « 100 % de couverture de test » ?
Tout pourcentage compare un résultat à un total. Si 100 tests étaient prévus et que les 100 ont été exécutés, la couverture d'exécution atteint 100 %. Si chaque exigence possède un test, un tableau de bord de traçabilité peut lui aussi afficher 100 %. Les deux calculs sont justes. Mais ils ne parlent pas de la même chose.
Face à un score parfait, je veux connaître trois choses. Que compte-t-on ? Quand un élément est-il considéré comme couvert ? Qu'est-ce qui reste hors du calcul ?
Une métrique ne peut répondre qu'à la question posée par son calcul. Ce n'est pas un défaut. Il faut seulement connaître la question avant d'utiliser la réponse.
Les différentes métriques de couverture ne répondent pas aux mêmes questions
Les équipes emploient le mot couverture pour plusieurs mesures. Chacune répond à une question différente.
- La couverture de code indique quelles parties de l'implémentation ont été exercées : instructions, branches ou conditions, par exemple.
- La couverture des exigences indique quelles exigences sont reliées à des tests ou à d'autres preuves de vérification.
- La couverture d'exécution indique quelle part du plan de test a été exécutée, et parfois quelle part a réussi.
- La couverture des scénarios ou des comportements s'intéresse aux chemins, conditions et résultats attendus qui ont réellement été contrôlés.
Ces mesures se complètent, mais ne se remplacent pas. Exécuter tous les tests prévus ne prouve pas que le plan contient tous les tests nécessaires. Parcourir toutes les lignes ne prouve pas que le test a contrôlé le bon résultat. Relier un test à chaque exigence ne prouve pas que toute l'exigence a été vérifiée.
Le pourcentage devient plus utile lorsque le tableau de bord indique clairement le type de couverture affiché.
Comment une couverture de 100 % peut encore masquer des lacunes
Prenons une exigence simple de connexion. Après trois mots de passe incorrects, le système doit verrouiller le compte pendant 15 minutes. Il doit enregistrer l'événement. Après 15 minutes, l'utilisateur doit pouvoir se connecter de nouveau.
Un test saisit trois mauvais mots de passe et vérifie le verrouillage. Il est bien relié à l'exigence. Il contrôle un comportement important. Si un seul test suffit pour marquer une exigence comme couverte, celle-ci reçoit le statut Couvert.
Mais le test ne contrôle pas le journal de sécurité. Il ne vérifie pas que le blocage dure 15 minutes. Il ne vérifie pas non plus que la connexion fonctionne ensuite. Le tableau de bord peut tout de même afficher « 100 % des exigences reliées à des tests ». Le chiffre est juste, alors que plusieurs comportements n'ont pas été testés.
La métrique a fait son travail : elle a trouvé un lien. Le problème commence lorsque nous lisons ce lien comme la preuve que toute l'exigence a été testée.
C'est la différence à garder en tête. « Chaque exigence possède un test » ne veut pas toujours dire « chaque comportement attendu a été testé ».
Couvert ne signifie pas toujours entièrement vérifié
Une vue binaire Couvert / Non couvert reste utile. Elle repère vite les exigences sans test. Sur une longue spécification, c'est un bon premier contrôle.
Mais elle masque des détails dans notre exemple. Nous avons testé le verrouillage. Nous n'avons pas testé le journal, les 15 minutes ni le retour à la normale. Qualifier toute l'exigence de Couverte rend ces absences difficiles à voir.
Une lecture plus utile peut distinguer trois statuts : Entièrement couvert, Partiellement couvert et Non couvert. Le premier indique que les comportements attendus sont testés. Le deuxième signale qu'il reste un manque. Le dernier indique qu'aucun test adapté n'a été trouvé.
Ces statuts ne décident pas à la place de l'ingénieur. Ils lui montrent où regarder.
Ce qu'une couverture utile devrait vous apprendre
Une couverture utile n'est pas un nouveau chiffre magique. Elle doit montrer ce qui a été testé et ce qui demande encore du travail.
- Quelles exigences disposent de tests de vérification ?
- Que contrôlent réellement ces tests ?
- Quelles exigences ne sont que partiellement couvertes ?
- Quels scénarios ou résultats attendus restent absents ?
- Lorsqu'une exigence évolue, sa vérification reste-t-elle cohérente ?
Une bonne traçabilité des exigences donne une première partie de la réponse. On voit quel test est relié à quelle exigence. Il reste ensuite à lire le test pour comprendre ce qu'il prouve vraiment.
Cette deuxième étape compte dans les activités de vérification et validation. Un relecteur voudra voir les preuves derrière le score, pas seulement le score.
Un score élevé est une bonne nouvelle. Savoir ce qu'il contient est encore mieux. Le problème n'est pas d'atteindre 100 %. C'est de voir 100 % et d'en conclure qu'il ne reste plus rien à vérifier.
Aller au-delà du pourcentage avec KomAInu
Une exigence peut avoir un test et demander encore du travail. C'est précisément le problème que nous cherchons à résoudre avec KomAInu.
C'est pour cette raison que nous avons choisi de ne pas limiter KomAInu à un simple statut Couvert / Non couvert. KomAInu lit les exigences et les tests, relie les deux et affiche trois statuts : Entièrement couvert, Partiellement couvert et Non couvert. Un test incomplet reste visible, même si un lien existe déjà.
Revenons à notre exemple. Le test de verrouillage est utile. Il faut le garder. Mais l'exigence reste Partiellement couverte tant que les tests ne contrôlent pas aussi le journal, les 15 minutes et le retour à la normale.
En pratique, l'exigence et ses tests peuvent être examinés ensemble. Le comportement manquant se voit plus facilement. L'équipe peut le revoir ou générer les tests nécessaires. Vous pouvez en savoir plus sur cette analyse des lacunes de couverture.
Alors, peut-on vraiment tester un logiciel à 100 % ?
Oui, un logiciel peut atteindre 100 % pour une métrique précise. Tous les tests prévus peuvent être exécutés. Toutes les lignes peuvent être parcourues. Chaque exigence peut avoir un test. Ces résultats sont utiles.
Mais « testé à 100 % » ne veut pas dire grand-chose tant que l'on n'a pas défini ce 100 %. Un score parfait ne suffit pas à prouver que tous les comportements ont été contrôlés.
Les métriques de couverture nous aident à suivre l'avancement et à trouver les manques. La question n'est pas seulement « Quel est notre pourcentage de couverture ? ». Il faut aussi demander : « Que peut-il encore manquer ? »
Questions fréquentes
Peut-on atteindre 100 % de couverture de test ?
Oui, pour une métrique et un périmètre clairement définis. Ce résultat montre seulement que la règle de couverture choisie est satisfaite ; il ne signifie pas automatiquement que tous les comportements pertinents ont été vérifiés.
Une couverture de code de 100 % signifie-t-elle que le logiciel est entièrement testé ?
Non. La couverture de code montre quelles structures de l'implémentation ont été exercées. Elle ne prouve pas que tous les comportements attendus, combinaisons d'entrées ou résultats ont été contrôlés.
Quelle différence entre couverture de test et couverture des exigences ?
La couverture de test désigne largement la part d'une cible choisie qui a été exercée. La couverture des exigences examine spécifiquement si les exigences sont reliées à des tests et, dans une analyse plus fine, si ces tests vérifient suffisamment les comportements attendus.