Le test de régression est un processus de test logiciel exécuté après avoir apporté des modifications ou des mises à niveau à une application logicielle et teste à nouveau les domaines d’application susceptibles d’avoir été affectés par le correctif. Il peut être effectué manuellement et automatiquement en exécutant un ensemble spécifique de cas de test.
Lorsqu’un produit logiciel subit des modifications dans les fonctionnalités existantes, des corrections de bogues et l’ajout de nouvelles fonctionnalités, les tests de régression visent à garantir qu’après ces modifications, le produit fonctionne comme prévu.
Le terme « régression » implique de re-tester les sections non modifiées du produit. Les testeurs de logiciels sont chargés de déterminer si les nouvelles modifications ont entraîné des bogues ou des défauts potentiels.
Qu’est-ce qu’un test de régression ?
Lorsque les développeurs corrigent un bogue, ajoutent de nouvelles fonctionnalités ou en modifient une existante, ils doivent modifier le code du programme. Même un changement mineur entraînera probablement plusieurs bogues. Dans de tels cas, des tests de régression sont utilisés pour révéler et identifier les effets secondaires indésirables. Pour cela, ils ré-exécutent les cas de test qui fonctionnaient parfaitement dans la version précédente du produit avec la dernière version pour s’assurer que les fonctionnalités du produit fonctionnent correctement.
Lorsqu’une nouvelle version doit être validée, les testeurs effectuent les tests fonctionnels pour vérifier les modifications apportées aux fonctionnalités existantes et nouvellement ajoutées. Une fois ces tests terminés, les testeurs procèdent à des tests de régression. Ils découvrent si les nouvelles améliorations ont causé un défaut de fonctionnalité dans le fonctionnement qui était satisfaisant avant les dernières modifications.
Pourquoi effectuer des tests de régression ?
Chaque fois que vous ajoutez un code qui active une nouvelle fonctionnalité ou corrige un bogue, vous lancez des tests de régression. Cette initiation est obligatoire car les fonctionnalités existantes et nouvellement ajoutées peuvent avoir de nombreuses dépendances. Ce contrôle qualité est incontournable car le nouveau code doit être conforme au code existant. Vous devez vous assurer que le code non modifié ne subit pas d’impact. Vous pouvez fréquemment être amené à vérifier les modifications du système effectuées à la dernière minute.
Au cours du cycle de développement, si une amélioration ou une modification continue existe dans le produit, la nouvelle fonctionnalité peut endommager le code existant qui a été testé et trouvé OK. L’altération du code peut donner lieu à des bugs. Si un tel code n’est pas testé, vous pouvez rencontrer des problèmes critiques dans l’environnement en direct. Pour cette raison, votre client pourrait avoir des ennuis.
Considérons un site Web en ligne. Vous signalez un problème selon lequel le coût d’un produit à vendre ne s’affiche pas correctement ; c’est-à-dire qu’un prix inférieur remplace le coût réel d’un produit. Vous concluez que ce problème doit être résolu dès que possible.
Maintenant, un développeur a résolu ce problème. À ce stade, il est possible que le prix sur la page signalée ait été modifié, mais la page de résumé a toujours le coût erroné, et l’e-mail envoyé au client a également le mauvais coût. Cela prouve qu’une fois la correction du bogue terminée, la page qui affichait un prix inférieur doit être vérifiée et les pages associées doivent être vérifiées. Cela montre pourquoi il est crucial d’exécuter des tests de régression.
Le graphique ci-dessous montre l’importance d’exécuter un test de régression.
Un exemple de test de régression
Supposons qu’il existe un produit logiciel XYZ. L’une des fonctions consiste à déclencher les e-mails d’envoi, d’acceptation et de confirmation lorsqu’un utilisateur clique sur les boutons Envoyer, Accepter et Confirmer. Au cours du développement, l’e-mail de confirmation développe quelques problèmes.
Pour résoudre ces problèmes, les développeurs apportent quelques modifications au code. Dans ce processus, il est évident que les e-mails de confirmation doivent être testés. De plus, les e-mails envoyés et d’acceptation doivent également être testés pour vérifier que les modifications de code ne les ont pas impactés.
Avantages et inconvénients des tests de régression
Les tests de régression présentent les avantages et les inconvénients suivants.
Avantages :
- La qualité du produit logiciel augmente.
- Il peut être garanti que les modifications logicielles et les corrections de bogues n’affectent pas négativement la fonctionnalité du produit.
- Il peut y avoir la mise en place d’outils de test d’automatisation.
- Il peut être vérifié que les problèmes résolus ne se reproduisent pas à l’avenir.
Désavantages:
- Si vous n’utilisez pas l’automatisation des tests et décidez d’effectuer des tests manuels, les tests de régression deviennent très lourds et chronophages car ils doivent être mis en œuvre à plusieurs reprises.
- Même une modification mineure du code génère des problèmes dans la fonctionnalité du produit. Par conséquent, cette modification mineure nécessite le processus de test de régression.
Quand effectuer un test de régression
Chaque scénario impliquant des modifications du code de production nécessite des tests de régression. Tous les scénarios suivants nécessitent ce test.
- Ajout de nouvelles fonctionnalités à l’application : Un site Web doté d’une fonctionnalité de connexion. Les utilisateurs peuvent utiliser cette fonctionnalité uniquement avec le courrier électronique. Une nouvelle fonctionnalité consiste à se connecter à l’aide des informations d’identification Facebook.
- Exigence de changement : Un exemple est la suppression de la fonctionnalité Mémoriser le mot de passe, qui était auparavant applicable.
- Correction d’un défaut : Une page de connexion sur laquelle le bouton Connexion ne fonctionne pas correctement. Un testeur fournit un rapport indiquant qu’il y a un bogue, c’est-à-dire que le bouton de connexion est cassé. Une fois que les développeurs ont corrigé ce bogue, un ingénieur QA effectue un test, s’assurant que le bouton de connexion fonctionne comme prévu. En même temps, le testeur teste d’autres fonctionnalités pertinentes pour le bouton de connexion.
- Correction du problème de performances : Un exemple est que la page d’accueil a besoin de cinq secondes pour se charger. Désormais, cette durée est réduite à deux secondes.
- Modification dans l’environnement : Un exemple est lorsque la base de données est modifiée de MySQL à Oracle.
Les points ci-dessus peuvent être résumés dans les circonstances suivantes :
- La configuration subit des modifications.
- Il y a un ajout de correctifs correctifs.
- Il y a une optimisation du code source pour améliorer les performances.
- Il y a une correction de la base de code pour la résolution des défauts.
- Il y a un ajout de nouvelles fonctionnalités ou fonctionnalités.
- Il y a un ajout d’une nouvelle exigence à une fonctionnalité existante.
Certains produits logiciels nécessitent plusieurs mois pour être achevés. Ainsi pour ces produits, des tests de régression sont recommandés quotidiennement. Certaines versions sont faites chaque semaine. Dans le cas de tels produits, les tests de régression commencent après la fin des tests fonctionnels.
Considérons le scénario lorsque vous testez une fonctionnalité spécifique et que les tests ne sont pas terminés à la fin de la journée. Maintenant, vous deviez arrêter le processus à mi-chemin. Le lendemain, vous revenez et recommencez les tests depuis le début. Cette action est appelée « Re-tester ». Vous testez à nouveau pour une raison particulière. Une des raisons peut être qu’un scénario de test spécifique a échoué lors de l’exécution finale et, par conséquent, le scénario de test doit être réexécuté. La deuxième raison peut être que le code source a un défaut qui a été corrigé.
Les tests de régression peuvent être considérés comme un léger changement par rapport au nouveau test. Les tests de régression ne sont planifiés que lorsqu’il y a un changement dans le produit ou le code. Ce changement peut concerner la conception, le code ou tout autre problème entraînant une modification du cadre général du produit. La raison la plus fréquente de cette modification est que des bogues ont été corrigés ou que de nouvelles versions du produit ont été créées.
Dans un cycle de vie de test logiciel (STLC) habituel, le processus le plus ancien est le nouveau test, qui peut être suivi de tests de régression. Dans, la concentration est uniquement sur les cas de test échoués. Dans les tests de régression, l’attention est portée sur les cas de test qui ont déjà été réussis, mais il existe une possibilité de bogues nouveaux et inattendus.
Que devez-vous faire dans les tests de régression ?
Le cycle de vie des tests logiciels (STLC) est un processus continu qui comprend de nombreuses étapes. Une fois les tests de fumée ou de santé mentale terminés ou dans la dernière phase de test fonctionnel, vous devez commencer les tests de régression.
Il existe principalement deux types d’actions que vous devez effectuer :
- Les tests effectués précédemment sont relancés.
- Les résultats actuels des cas de test sont comparés aux résultats de test précédemment exécutés.
La première étape pour des tests de régression efficaces consiste à définir un plan de test de régression. Ce plan doit détailler votre stratégie de test de régression et les critères de sortie. Vous pouvez également inclure des tests de performance dans ce plan. Cette inclusion vise à garantir que les altérations des composants du produit n’affectent pas les performances du produit.
Il est essentiel de respecter les meilleures pratiques en matière de tests de régression. Vous devez exécuter des scénarios de test automatisés vers la fin de la journée. De plus, si des effets secondaires de régression sont détectés, vous pouvez les partager avec les développeurs pour les corriger dans la version du jour suivant. Par cette pratique, vous couvrez la plupart des défauts de régression dans une phase précoce plutôt que vers la fin du cycle de publication. De cette manière, les risques de rejet sont minimisés.
Types de tests de régression
Vous pouvez implémenter divers tests de régression en fonction de la fonctionnalité ou de la mise à jour que vous souhaitez déployer. Cependant, il est crucial de comprendre les différents types de tests de régression pour choisir le bon.
Les tests de régression sont des types suivants.
- Régression complète ou complète
- Régression partielle
- Régression unitaire
- Régression corrective
- Régression sélective
- Re-tester la régression
Régression complète ou complète
Vous devez opter pour ce type lorsqu’il y a une altération du code sur de nombreux modules, et que l’impact de cette altération sur les autres modules est inconnu. Ainsi, la décision est de vérifier l’ensemble du produit pour détecter s’il existe d’autres modifications provenant du code modifié.
Pour la deuxième version du produit, le client propose d’ajouter quatre ou cinq nouvelles fonctionnalités, et certains défauts de la première version sont à corriger. L’équipe de test met en œuvre une analyse d’impact et conclut que l’ensemble du produit doit être testé pour ces modifications. En un mot, ce type implique de tester toutes les fonctionnalités modifiées et anciennes.
Considérons une application Java avec Java Virtual Machine (JVM) comme fichier racine. L’application Java doit être testée si un changement est indispensable pour le…