Introduction :
Passer des tests de validation aux tests de régression, oui, mais c’est quoi les tests de validation et les tests de régression. Et surtout pourquoi ce passage ? En quoi cela est-il utile ? Pour quelles méthodes de travail ? J’espère qu’après avoir lu cet article vous aurez une réponse à toutes ces questions. Commençons par des définitions.
Les tests de validation :
Les tests de validations sont l’ensemble des tests servant à « valider » une nouvelle fonctionnalité. Pour être plus concret c’est tous les tests conçus et exécutés afin de s’assurer que cette fonctionnalité réagit comme elle le doit. Comme déjà dit lors de mon post sur les couvertures de tests, ici une couverture des chemins d’exécution est intéressante. Prenons la fonctionnalité « transfert » pour une application mail. Ici nous devront tester toutes les possibilités offertes par cette fonction (avec/sans pièce(s) jointe(s), depuis le mail affiché, depuis la liste des mails, avec/sans historique, depuis différent dossier, les cas d’erreurs documentés…)
Les tests de régression :
Les tests de régression sont des tests effectués sur l’ensemble des fonctionnalités déjà existantes d’une application visant à s’assurer que ces fonctionnalités fonctionnent toujours après la livraison de nouvelles fonctionnalités (ou de modifications de fonctionnalités déjà existantes). Leur but est donc différent de celui des tests de validation. Généralement une couverture des instructions est plus pertinente qu’une couverture des chemins d’exécution.
Le passage des tests de validation aux tests de régression :
Ce passage peut être pensé au moment du design des tests de validation tout comme après l’implémentation de la fonctionnalité. Je suis personnellement plus favorable à une analyse en amont cela permet de faire des tests plus propres, stable et facile à maintenir sur les tests de validations qui sont candidats à devenir tests de régression que sur les autres tests de validation qui seront des tests « jetables » (que l’on n’exécutera plus après la validation et qui serviront d’archives après l’implémentation de la fonctionnalité). Dans tous les cas ce passage doit être pensé et se faire.
Pourquoi ne prendre comme tests de régression qu’une partie des tests de validation ?
Il y a plusieurs réponses à cela, en voici les deux principales : La première est la plus simple, le coût ! En effet, on pourrait penser que passer plus de tests devrait être plus intéressant néanmoins plus on a de tests plus cela coûte cher à exécuter, maintenir et plus le temps d’analyse est important (95% de tests en succès sur 100 tests c’est 5 tests à analyser, 95% de tests en succès sur 1000 tests, c’est 50 !). Il faut à tout prix éviter d’avoir des cas de régression qui sont en échec car ils ne sont pas à jour. La seconde est la plus pertinente, le but des tests de régression et de validation est différent. Dans un le cas des tests de validation on teste une fonctionnalité nouvelle, qui n’a jamais fonctionnée, dans le cas des tests de régression la fonctionnalité fonctionne déjà et on vérifie que l’implémentation des nouvelles fonctionnalités, qui « à priori » n’ont pas d’impact sur les anciennes fonctionnalités, n’engendre pas de bugs sur les fonctionnalités déjà existantes. Le nombre de cas de régression doit donc être inférieur au nombre de cas de tests de validation. On ne peut pas se permettre d’avoir plusieurs milliers de cas de tests de régression sur une application mail.
Quelles sont les méthodes de travail ayant besoin de ce passage ?
Ce passage ne dépend pas des méthodes de travail. Ce passage semble évident en mode SCRUM et toutes les méthodes incrémentales, car on a de nouvelles fonctionnalités régulièrement à travers la livraison des User Story. Mais cela est tout aussi important en cycle en V où une application continue de vivre et d’évoluer, généralement avec de grosses mises à jour/ versions après sa mise en production.
Conclusion :
Les tests de validations et les tests de régressions sont deux outils au but bien différent mais néanmoins nécessaire au cycle de vie d’un projet. Leur but n’est pas le même c’est pourquoi l’ensemble des cas de tests de validations ne peut être transformé en cas de tests de régression. Pour assurer une bonne transition il faut penser à cette phase du projet. Le choix des cas de régression est très important, il ne faut pas le négliger ou le faire à la va vite. Trop de cas de régression et ils sont impossibles à maintenir (donc inutiles), pas assez et c’est la qualité de l’application qui peut faire défaut.
Pensez à rejoindre le groupe Le métier du test si le test vous intéresse !
N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances
Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles
