Test de non-régression (TNR) - le guide complet

            By
            5 Minutes Read

            Lorsqu'on vise à garantir la qualité de son application web ou mobile, un éventail de tests est disponible, parmi lesquels le test de non-régression (TNR), également connu sous le nom de test de régression, joue un rôle essentiel.

            Poursuivez votre lecture pour découvrir ce qu'est le test de non-régression, ses avantages, les questions fréquemment posées sur le sujet, ainsi que les meilleures pratiques pour l’exécuter.

             

            Qu’est-ce qu’un test de non-régression (TNR) ?

            Dans le monde de développement Web, une régression a lieu dès lors qu’un changement de code a un impact sur le code existant.

            Par exemple, cela peut être dû à la correction d’un bug, une mise à jour logicielle, ou encore l'ajout d’une nouvelle fonctionnalité.

            Un test de non-régression (TNR) vérifie que les modifications apportées au logiciel, au site ou à l’application mobile, telles que l’ajout d’une nouvelle fonctionnalité ou une mise à jour, n’ont pas eu d'impact sur les fonctionnalités existantes.

            Les différents types de tests de non-régression

            Les tests de non-régression peuvent être effectués de plusieurs manières, en fonction du besoin visé ou des ressources de l’entreprise :

            Test de non-régression correctif : utilise les tests existants, à condition qu’aucun changement important n'ait été apporté au produit.

            Test de non-régression complet : consiste à tester à nouveau tous les éléments du produit, ce qui permet de vérifier toutes les modifications qui ont été apportées depuis le début.

            Test de non-régression sélectif : permet de choisir certains tests dans un ensemble afin de n’inspecter que les parties du code qui ont été impactées.

            Test de non-régression progressif : consiste à créer de nouveaux tests quand les tests établis ne sont plus utiles, par exemple lorsque les caractéristiques du produit sont modifiées.

            Test de non-régression partiel : effectué lorsque différents modules sont en cours de développement et sur le point d’être fusionnés avec la version principale du code.

            Test de non-régression unitaire : sert quant à eux à tester le code de façon individuelle, sans tenir compte des autres éléments.

             

            tests-tnr-types

             

            Test de non-régression (TNR) FAQ

            Pourquoi faire des tests de non-régression ?

            La première raison pour laquelle il faut faire des tests de non-régression, et qui devrait être la principale de tous les autres types de tests, est que cela permet de garantir la qualité du logiciel.

            En assurant un produit de qualité supérieure, on améliore simultanément l'expérience utilisateur et l'image de l'entreprise.

            De plus, le test de non-régression prévient les bugs pouvant entraver certaines fonctionnalités, impactant ainsi le chiffre d'affaires et la réputation de l'entreprise, tout en évitant les failles de sécurité potentielles.

            En exécutant régulièrement des tests de non-régression, on réalise des économies de temps et d'argent, car il est bien plus complexe et coûteux de rectifier un bug une fois en production.

            Dans le contexte du développement d'applications mobiles, de sites Web, ou de logiciels SaaS, sujets à des mises à jour fréquentes pour répondre aux exigences des clients, les tests de non-régression deviennent encore plus indispensables.

             

            pourquoi-faire-tests-TNR

             

            Quand faire des tests de non-régression ?

            Les tests de non-régression peuvent être exécutés à tous les niveaux du plan de test, et nous conseillons de les faire le plus régulièrement possible, dès qu’une modification ou mise à jour est apportée, au plus tôt de la conception du produit.

            Généralement, les tests de non-régression sont réalisés dès lors qu’il y a :

            • Une correction qui est apportée au code pour résoudre des anomalies
            • Une nouvelle fonctionnalité qui est ajoutée
            • Une modification d’une fonctionnalité existante
            • Une mise à jour effectuée dans l’environnement (ex : données)
            • Une optimisation du code source

            Quelles différences entre les tests fonctionnels de validation et de non-régression ?

            Les tests fonctionnels de validation sont un type de test effectué pour vérifier que chaque fonction ou fonctionnalité de l'application logicielle fonctionne conformément aux spécifications des exigences.

            Ils sont réalisés à l'aide de cas de test qui recréent tous les scénarios possibles, tant négatifs que positifs. Idéalement, les tests fonctionnels de validation commencent au stade initial du développement du produit et vérifient :

            • Les fonctionnalités manquantes
            • Les spécifications incorrectes
            • Si des erreurs d'interface persistent
            • Les lacunes qui existent pendant la phase des exigences

            Des tests fonctionnels de validation bien exécutés permettent de livrer un produit haut de gamme, ils aident à produire un produit ou un logiciel sans bug pour assurer la satisfaction de l'utilisateur final.

            Les différences entre ces deux types de tests

            Objectifs : le but des tests fonctionnels de validation est de déterminer dans quelle mesure l'application développée correspond aux exigences souhaitées.

            Le but des tests de non-régression est de vérifier que tout changement dans l'application ou les systèmes n'a pas entraîné de rupture de code et que le système fonctionne correctement.

            Cas de test exécuté : les tests fonctionnels de validation permettent de comprendre l’ensemble des cas et fonctionnalités, qui n'ont jamais été testés et exécutés auparavant.

            Les cas de test sont exécutés lorsque le défaut est relevé par rapport à une exigence. Par la suite, il est corrigé et assigné pour un nouveau test. Lors du nouveau test, si le défaut est résolu, les cas de test liés qui ont échoué plus tôt sont réussis.

            La suite de non-régression contient des cas qui ont été précédemment testés et résolus.

            Fondamentalement, dans les tests de non-régression, les cas de test sont exécutés pour s'assurer que les modifications n'ont pas eu d'impact sur les fonctionnalités précédemment testées.

            Processus utilisé : le processus de test fonctionnel commence par la lecture et la compréhension des exigences par les testeurs, ce qui soulève un écart en cas de divergence dans l'exigence, suivi de l'identification de l'entrée de test.

            Transmettre les valeurs d'entrée aux systèmes et comparer la sortie avec les résultats attendus.

            Si le résultat ne correspond pas, le défaut est signalé et le cas de test est marqué comme ayant échoué.

            Au contraire, le processus de type test de non-régression est entièrement différent car cette activité n'a lieu que lorsque l'application existante est modifiée ou que de nouvelles fonctionnalités y sont ajoutées.

            Faisabilité de l'automatisation : les tests fonctionnels de validation sont d'abord effectués manuellement. Une fois qu'une fonctionnalité est stable, les cas de test sont automatisés.

            Dans les tests de non-régression, les cas de test peuvent être exécutés manuellement ou automatiquement. Comme les cas de test sont déjà stables par défaut (puisqu'ils ont déjà passé leur test fonctionnel) dans les tests de non-régression, ils peuvent être automatisés.

            Les cas de test fonctionnels ne nécessitent pas beaucoup de modifications car ils sont moins nombreux et axés sur une fonctionnalité spécifique.

            Alors que dans les tests de non-régression, les scripts de test nécessitent une maintenance plus importante et peuvent contenir des cas de test plus anciens.

            Les cas de test peuvent contenir des fonctionnalités qui ont changé, de nouvelles fonctionnalités qui ont été ajoutées ou certaines fonctionnalités qui ont été supprimées, c'est pourquoi la suite de régression doit être mise à jour après chaque version.

             

            test-non-régression

             

            Qu’est-ce qu’un test de non-régression graphique ?

            Les tests de non-régression graphique, aussi connus sous le nom de tests de comparaison graphique, sont essentiels pour vérifier la qualité visuelle d’un site ou application.

            Fondamentalement, ces tests assurent que chaque élément d'une même page, tels que les boutons, les textes, les photos et les images, s'affiche correctement en termes d'emplacement, de taille, de couleur et de forme, quel que soit l'appareil ou le navigateur utilisé par les utilisateurs.

            Il s’agit de non-régression car ces tests sont utilisés pour contrôler que le site ou l’application mobile ressemble à sa version précédente au pixel près (pixel perfect) et sa conformité légale/juridique.

            De plus, ces tests graphiques permettent de vérifier la présence des affichages légaux obligatoires dans certains pays pour assurer une conformité réglementaire.

            Comment exécuter les tests de non-régression ? 

            Les tests de régression sont des tests très chronophages et répétitifs. Par conséquent, même si certains cas de tests doivent être effectués manuellement, la plupart sont automatisés à l’aide d’un outil de test automatisé permettant de détecter les bugs potentiels qui apparaissent suite à une modification, et de les résoudre avant qu’ils n'impactent les utilisateurs.

            Les tests de non-régression automatisés réduisent également les coûts en économisant des clients potentiellement perdus en raison d'une expérience utilisateur sous-optimale, ainsi qu’en accélérant le processus de test et de débogage.

            Enfin, l'automatisation permet un test continu et fiable tout au long du cycle de développement, garantissant que les régressions sont identifiées et résolues rapidement, réduisant ainsi le risque que des défauts n'atteignent la production.

            Quelles sont les limites des tests de non-régression ?

            Malgré l'automatisation, la création de scénarios reste nécessaire, notamment pour les fonctionnalités complexes, ce qui peut retarder l'exécution et donc la livraison. 

            Sous contraintes de temps et de budget, les équipes QA doivent prioriser les tests les plus essentiels, car tous les scénarios de régression ne peuvent pas être exécutés.

             

            Mr Suricate - Leader français des tests automatisés no-code

            Chez Mr Suricate, notre mission est de protéger l’image de marque du client et augmenter son chiffre d’affaires tout en garantissant le bon fonctionnement du parcours utilisateurs en détectant les bugs avant et après mise en production.

             

            Demander une démo

             

             

            Picture of Mr Suricate

            Mr Suricate

            Author