Les Tests de Non-Régression (TNR)

Qu'est-ce que les TNR ? 

D’après la définition de l’ISTQB, un test de non-régression est un ensemble de tests d’un programme après une modification, pour s’assurer que des défauts n’ont pas été introduits ou découverts dans des parties non modifiées du logiciel.

C’est donc par le biais de ces tests que l’on s’assure que les ajouts de nouvelles fonctionnalités ou les modifications de l’application n’ont pas apportés de régression ou eu un impact négatif sur le reste du code qui fonctionnait jusqu’à présent.

Pourquoi des TNR ? 

L’intérêt des tests de non-régression est de garantir que les modifications apportées au code actuel n’ont pas de répercussions négatives sur les fonctionnalités existantes et la qualité du logiciel.

C’est un complément aux tests unitaires et aux tests d’intégration qui sont effectués en amont des tests de recette.

Quand effectuer des TNR ? 

Nous effectuons des TNR dans les cas suivants :

• De nouvelles fonctionnalités mises en place.
• Modification d’une fonctionnalité déjà en place.
• Des corrections d’anomalies.
• Modification de la structure de données.
• Optimisation du code source et amélioration des performances.

Les process TNR chez ORKESTER  ? 

a - Écriture des cas de tests : 

L’écriture des cas de test se fait au début du projet à partir d’US ou de document de spécification. Chez Orkester, nous utilisons l’outil de référentiel « Squash TM » pour écrire tous nos tests dont ceux de la TNR.

L’écriture d’un cas de test se décompose en différentes actions à effectuer et pour chacune d'elles un résultat est attendu.

b - Déroulement des campagnes de TNR : 

À chaque fin de sprint, nous créons et déroulons une campagne de TNR avec tous les cas de tests créés. Pour ce faire, nous utilisons Squash TM pour exécuter et assurer le suivi.

c - Écriture des cas d'anomalies : 

Si des erreurs sont observées lors des TNR, nous écrivons des tickets d’anomalie afin de remonter les problèmes rencontrés lors des tests.

Toute erreur remontée doit être au maximum documentée (scénario, capture d’écran, log, …) dans le ticket afin que le développeur puisse au mieux faire une correction. Plus il y a de détails dans la description du bug, plus ce sera facile d’identifier l’erreur à corriger et d’y apporter des réponses.

d - Partage des résultats des tests avec le client : 

Une fois la campagne terminée, nous partageons le résultat de nos tests avec le client, afin de le tenir au courant par le biais de mails de compte rendu.

Nos résultats sont joints avec des graphiques générés par l’outil de référentiel de test. Nous accompagnons ces données par des explications sur tous les blocages qui ont pu être rencontrés (tests en erreurs et tests bloqués).

e - MAJ des cas de tests : 

Au cours du projet, certaines fonctionnalités peuvent évoluer ou d'autres peuvent être mises en place. Quand cette évolution affecte nos tests nous effectuons une mise à jour des cas de tests.

Celle-ci se fait en cas de modification de design ou de fonctionnement de l’application ou du site Web ; pour les nouvelles fonctionnalités, l’idéal est d’écrire de nouveaux cas de tests. C’est ce que nous faisons. 

TNR automatisés / manuels 

 1 - Définition des tests automatisés :

Les tests automatisés sont ceux exécutés par un robot avec l’aide de scripts simulant les actions faites par un utilisateur.

Il existe différents outils permettant d’automatiser ses tests comme: Selenium, Cypress, Robot Framework …

 2 - Définition des tests manuels :

Les tests manuels sont tous ceux effectués en menant chaque action des cas de test enregistrés dans notre logiciel de référentiel, de manière manuelle.

 3 - Limites des TNR manuels :

Les TNR manuels sont très chronophages et répétitifs. Ils sont exécutés avant chaque déploiement sur les différents environnements, ce qui fait que le rythme de livraison est directement impacté par ces tests.

Plus on a des tests à effectuer lors de des TNR, plus le temps pris pour sera long et toutes anomalie rencontrée impactera directement la livraison.

 4 - Pourquoi automatiser des TNR ?

Comme dit précédemment des TNR manuels sont chronophages et répétitifs. L’intérêt de pouvoir automatiser les TNR est le gain de temps car ils sont plus rapidement exécutés.

Mais avant d’automatiser les tests, il est bon de se demander s’il est utile de le faire. 

S’ils sont faits une fois dans l’année, il n’y a techniquement pas d’utilité à automatiser ses tests. Cependant si les tests ont une récurrence certaine, l’automatisation prend tout son sens.

 
5 - Limite des tests automatisés :

L'impossibilité d’automatiser tous les tests constitue une limite. Il faut donc étudier correctement ce qui peuvent l’être ou non