En informatique la régression est un bug induit lors de la modification d’un logiciel ou et/ou du système qui permet de l’exécuter. Cela peut être lors de l’ajout ou de modification de fonctionnalités voire d’une migration technique. Le bug va entrainer un dysfonctionnement qui n’était pas présent à la version précédente ce qui impliquera déception et énervement de la part des utilisateurs et ternira l’image du produit et de la société qui le commercialise. Pour éviter cela, on procède à des campagnes de tests de non-régression. Voyons plus en détail en quoi cela consiste et comment cela fonctionne.

Qu’est-ce que le test de non-régression ?

Le test de non-régression ou TNR est un test informatique qui a pour but de vérifier que les changements ou évolution apportés à un système (un site ou une application) n’ont pas induit des bugs dans celui-ci. En gros, on s’assure que la modification n’a touché que la partie (le code) désiré et aucun défaut ne s’est immiscé dans la partie non modifiée, dans ce cas on parlera « d’effets de bords ».

Le but est de limiter les anomalies lors de l’exécution du système, car si un site est ouvert ou une application déployée, cela aura un impact financier conséquent de mettre le système en maintenance pour régler le problème. Le test de non-régression vient s’ajouter à d’autres tests comme

  • le test unitaire ;
  • le test d’intégration ;
  • le test de recette.

Comment fonctionne le test de non-régression ?

Un test de non régression peut être effectué à différents niveaux, il rentre aussi bien dans la catégorie des tests structurels, fonctionnels ou non fonctionnels.

Le test de non-régression est automatisable permettant ainsi de minimiser le temps à y consacrer pallient son principal défaut : le temps homme à y consacrer. Même si la modification apportée au système reste minime, le test s’effectue sur les cas les plus critiques, regroupés au sein d’un panel de tests appelés : tests critiques ou tests socles. Les scénarios peuvent alors être très variés en y injectant des jeux de données, de la variabilisation et ultime luxe de la qualité : en les exécutant sur divers types de navigateurs ou devices.

L’automatisation permet de faire ce qu’on appelle des robots tests, il rejoue des scénarios prédéfinis selon l’utilisation des consommateurs. Suivant les cas ils peuvent utiliser des sessions réelles déjà enregistrées afin d’être le plus proche possible de l’utilisation du site ou de l’application

Le fonctionnement n’est pas si compliqué ni différent des autres jeux de tests, il demande de la rigueur dans l’exécution, l’analyse des résultats et surtout dans le maintien en condition opérationnelles autant du patrimoine de scénarios que de l’infrastructure qui permettra d’exécuter les tests. Il faudra tout d’abord s’assurer que les environnements soient disponibles, que les jeux de données soient compatibles, etc.

Cela nécessite méthode, organisation et surtout compétence dans le domaine de la qualité logicielle. Les réunions d’équipe permettent de couvrir un large spectre des besoins de réponses pour que votre projet de tests automatisés soit une réussite. Cela peut aller de la définition de la stratégie des tests en passant par le panel de terminaux les plus importants utilisés par vos clients.

C’est aussi les codes (programmes) qui sont les plus susceptibles d’être touchés. Le test peut commencer en exécutant chaque code (programme) pour éventuellement repérer les anomalies. Enfin un test de confirmation est effectué en exécutant le programme, c’est une exécution « tests de sécurisation » avant la mise en production. Ainsi, la campagne du site ou de l’application peut commencer et se déployer.

Il ne faut pas oublier que malgré les différents tests, comme les tests de non-régression, on ne peut pas être complètement sûr que le programme ne comporte aucune anomalie. Comme l’a dit Edsger W. Dijkstra « Le test peut détecter les anomalies, mais ne peut pas établir leur absence. »