Avec une variété de termes décrivant les méthodologies de test qui tentent d'être explicites mais qui échouent souvent, le vocabulaire des tests peut parfois être déroutant.
Dans cet article, nous allons clarifier les différences entre les tests fonctionnels de validation et les tests de non-régression (TNR), mais nous devons d'abord établir que la façon dont la catégorie « tests de régression » est désignée peut être interchangée.
En d'autres termes : test de régression = test de non-régression
L'ISTQB préfère le terme de test de régression, mais beaucoup de personnes du milieu utilisent également le terme de test de non-régression (en France en tout cas).
Cependant, avant d'aborder les différences entre les tests fonctionnels de validation et les tests de non-régression, examinons d'abord ce qu'ils sont.
Qu'est-ce que les tests fonctionnels de validation ?
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 à la spécification des exigences.
Le testeur n'est pas concerné par le code sous-jacent. Les tests fonctionnels de validation portent sur la fluidité mécanique ou sur la vérification du bon fonctionnement de chaque module.
Il est réalisé à 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.
Exemples de tests fonctionnels de validation :
- Vérifier que le bouton de retour sur la page navigue vers la bonne page
- Vérifier que les liens redirigent vers les bonnes pages.
- Les fonctionnalités déroulantes doivent répertorier les valeurs correctes au clic
- Vérifier que le bouton suivant passe à la page suivante
- Vérifier qu'un utilisateur est capable de saisir des caractères dans les champs de texte comme défini dans la feuille d'éléments de données.
*Contrairement aux tests de régression, les termes «tests fonctionnels de validation» et « tests non fonctionnels » ne peuvent pas être interchangés. Les tests non fonctionnels consistent à tester l'application à partir d'aspects non fonctionnels tels que les performances, la convivialité, la sécurité, la fiabilité, la charge, le stress, etc. Ils sont effectués en se fondant sur des scénarios réels pour vérifier les performances du système lorsqu'il est conservé dans de telles circonstances.
Qu'est-ce qu'un test de régression/non régression (TNR) ?
Régression : une évolution qui ramène à un stade antérieur.
Les tests de régression sont effectués dans le but de détecter toute régression dans une fonctionnalité déjà testée.
Ces régressions dans le code peuvent survenir à la suite de "corrections de bugs", de "nouvelles fonctionnalités ajoutées au code" ou de "changements d'exigences".
L'objectif est de tester tout le code qui pourrait être impacté par les changements récents pour s'assurer qu'aucun nouveau bug n'est introduit.
En résumé, un test de régression sert à vérifier que les modifications avancées sur le logiciel, le site ou l'application mobile, telles que l'ajout d'une nouvelle fonctionnalité ou une mise à jour, n'ont pas impacté les fonctionnalités antérieures existantes.
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 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 ré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 régression contient des cas qui ont été précédemment testés et résolus. Fondamentalement, dans les tests de 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.
Des tests fonctionnels de validation sont requis :
- Lorsqu'un nouveau système est testé.
- Lorsqu'une application est vérifiée par rapport à ses spécifications et aux exigences souhaitées.
- Pour vérifier que l'intégration du système et du module fonctionne correctement.
- Lorsque la fonctionnalité d'un système dans son ensemble doit être examinée.
- Pour déterminer le flux de travail d'un système et ses fonctions.
- Pour s'assurer que le flux produit le résultat attendu.
Alors que les tests de régression sont effectués lorsque :
- Une demande de modification est émise par le client, ce qui entraîne une modification de la base du code.
- Le code back-end est migré vers une autre plate-forme.
- Une nouvelle fonctionnalité est ajoutée à l'application existante.
- Des corrections sont ajoutées.
- Il y a un changement dans l'environnement de test.
- Les bugs critiques trouvés par le testeur pendant la phase de test sont corrigés par le développeur.
- Les principales préoccupations concernant les problèmes de performances et les plantages sont résolues par les développeurs.
- L'interface utilisateur de l'application est modifiée pour une meilleure expérience utilisateur.
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é.
L'ensemble du processus de test fonctionnel comprend :
- L’identification des fonctionnalités à tester
- L’augmentation de la demande de données
- L’exécution de cas de test
- La comparaison d’un résultat avec un résultat attendu.
- L’échec du cas de test qui ne correspondait pas à l'exigence.
- La création de scénarios de test en fonction de l'exigence
- La conversion de scénarios de test en cas de test
- Soulever les défauts et les attribuer au développeur, si des écarts sont trouvés dans l'application.
- Ré exécution du cas d'échec une fois que le défaut signalé est corrigé
Au contraire, le processus de type test de 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.
Les activités impliquées dans ce type de test sont les suivantes :
- Identification des pièces modifiées
- Priorisation des cas de test en fonction du risque encouru.
- Sélection de cas de test en fonction des domaines impactés par la modification.
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 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 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 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.
Mr Suricate | Automatisez vos tests avec une solution codeless
Chez Mr Suricate, nous protégeons l’image de marque du client et augmentons son chiffre d’affaires tout en garantissant le bon fonctionnement du parcours utilisateurs et en détectant les bugs avant et après mise en production.
