La finalité des tests de non régression est de déterminer, si lors de la livraison d'une application, le contenu des nouvelles fonctionnalités n'impacte pas le bon fonctionnement de l'ensemble des modules (inclus ceux qui ne sont pas concernés par les évolutions du code). Toutefois, malgré l'importance reconnue par tous de ce type de test, cette activité est souvent négligée ou inexistante dans de nombreuses entreprise. L'absence de référentiel ou encore le manque de temps ou de ressources peuvent expliquer cette situation. Cette fiche est destinée à ceux qui voudraient mettre en place ou améliorer ce processus.
Pour réaliser une campagne de tests de non régression correctement planifiée et efficace, on doit répondre aux questions suivantes.
Quand les tests de non régression doivent ils être exécutés ?
On exécute des tests de non régression à chaque fois qu'une modification susceptible d'impacter les fonctions existantes est apportée à l'application. On mène également des tests de non régression lorsqu'une version défectueuse de l'application a été corrigée par l'équipe de développement.
Que doit on inclure dans les tests de non régression ?
Au début, les tests de non régression doivent se concentrer sur les fonctionnalités à haut risque et celles qui sont le plus fréquemment exécutées. Après que ces éléments aient été testés, on peut alors examiner les différentes composantes de l'application plus en détail.
Comment peut on optimiser les tests de non régression ?
On peut améliorer les tests de non régression en suivant les étapes ci dessous :
- Exécuter la campagne de tests de non régression,
- Si ensuite on rencontre de nouvelles anomalies dans des cas non traités en non régression, il faut les inclure au référentiel denon régression
- Répéter continuellement ce process.
Il faut garder à l'esprit que, fréquemment, on rencontre des anomalies là où on s'y attendait le moins. Si les tests de non régression ne couvrent que les parties directement modifiées, on omet alors de nombreux cas de régressions potentielles.
Les tests de non régression ne doivent pas être figés. Il est fréquent que l'on ait besoin de rajouter des tests ou de supprimer certains tests de non régression au fur et à mesure que l'application évolue. Il faut donc les faire vivre.
Pourquoi automatiser les tests de non régression ?
Quand on travaille sur un système complexe gérant un volume de données important, il est possible que l'on arrive à la fin à plusieurs milliers de tests de non régression, étant donné que l'on a cumulé tous les tests de non régression au fur et à mesure que l'application évolue. Il est par conséquent nécessaire que l'on exécute ces tests de manière automatique mais aussi dans un environnement stable qui permette d'exécuter l'ensemble des tests sans nécessiter beaucoup de ressources. Si ces tests n'étaient pas automatisés, ils mobiliseraient alors de nombreuses ressources pour un travail fastidieux, long et rébarbatif. Pire, on pourrait faire l'impasse sur plusieurs tests, faute de temps, ce qui contribuerait alors à réduire la couverture de tests.
C'est dans le domaine des tests de non régression que les outils de tests automatisés génèrent le plus de retour sur investissement. Les scripts qui ont été développés précédemment peuvent être exécutés successivement pour vérifier que de nouvelles erreurs n'apparaissent pas suite à des corrections de l'application. Comme ils ne nécessitent pas d'intervention humaine, on peut les répéter autant de fois que c'est nécessaire. Les tests automatisés permettent ainsi de répéter simplement les mêmes tests.
Comment analyser les résultats d'une campagne de tests de non régression ?
Quand on constate des anomalies relatives à une fonctionnalité spécifique de l'application qui marchait correctement précédemment, les testeurs doivent identifier les autres parties de l'application qui ont pu affecter la fonction pour laquelle on a découvert les anomalies. Une fois que l'on a les résultats de cette analyse, on accorde alors plus d'importance aux tests de non régression liés aux parties affectées. Une fois que les corrections ont été implémentées, on réalise alors à nouveau une campagne de non régression sur la partie concernée, afin de vérifier que l'anomalie a bien été corrigée et que de nouvelles anomalies n'ont pas été introduites.
L'équipe de test doit aussi identifier les parties de l'application pour lesquelles on a détecté le plus d'anomalies. Une fois l'analyse effectuée, il peut s'avérer nécessaire d'assigner à ces composants des procédures de tests additionnels. On peut aussi analyser les résultats des tests afin de déterminer quels sont les tests qui ne semblent pas être pertinents pour détecter de nouvelles anomalies. Si nécessaire, on supprimera ces tests de l'ensemble des tests de non régression.
