La taverne du testeur

Que devons nous tester avec la régression ?

La régression est un sujet majeur du test en Agile. Son importance est prépondérante car en Agile on construit son produit de manière itérative et il est essentiel de s’assurer que l’ajout d’une fonctionnalité n’a pas impacté négativement l’existant. Pour évaluer cet impact nous avons un outil: la régression.

Cette régression fréquente est d’ailleurs la source de nombreuses évolution dans les pratiques. Je pense notamment:

  • au besoin d’automatisation: pour gagner du temps sur l’exécution
  • aux tests exploratoires: pour tester plus en moins de temps des tests non réutilisés mais aussi lutter contre le paradoxe des pesticides
  • aux démarches DevOps et de test continu: pour fluidifier les processus de modification
  • au shift right: et le test en production pour compenser une couverture moins importante des tests manuels
  • au BDD: pour avoir des tests pouvant intégrer la régression avant même le développement de la fonctionnalité

Bref, il n’y a pas de produit Agile pérenne sans bonne campagne de régression. Mais comment s’assurer que notre campagne de régression est « bonne » ? Que doit contenir une campagne de régression ?

Pour répondre à cela je vous invite tout d’abord à revenir sur le rôle d’une campagne de régression ?

Pourquoi une campagne de régression ?

Une campagne de régression a de nombreux rôles. Son principal est avant tout de détecter des régressions majeures sur le produit en construction. Il est évidemment impossible de détecter toutes les régressions (l’exhaustivité des tests est impossible) ou même de tester tout autant en profondeur une nouvelle fonctionnalité qu’une fonctionnalité déjà implémentée pour des raisons de budget et de temps.

Tout tient donc dans le concept de « régression majeure » et je vous propose de revenir rapidement dessus:

  • Il faut d’abord détecter des « régressions », c’est à dire que le comportement doit être le même entre la version précédente et la nouvelle. Il n’y a, sur le papier, pas besoin de détecter des anomalies déjà présentes. En 2019, j’ai assisté à un tutoriel sur l’IA et le problème de l’Oracle pour ma première JFTL. Le présentateur considérait que la régression était simple à concevoir car on avait un oracle: la production! Et qu’au final une régression était un « contrôle de version ». J’aime beaucoup cette vision car elle limite le but de la régression et permet de se concentrer sur l’essentiel.
  • Il faut que cette régression soit « majeure », c’est à dire jugée suffisamment impactante pour occasionner une vraie gêne pour nos utilisateurs ou sur l’utilisation du produit… ce qui revient souvent à, de manière pratico-pratique, détecter des anomalies que nous souhaitons corriger plutôt que de les envoyer en production.

En partant de ces points il est plus simple d’imaginer ce à quoi doit ressembler une campagne de régression.

Le contenu d’une campagne de régression

Pour qu’une régression soit majeure (et ici ont dépend fortement du contexte) il faut qu’elle ait un impact conséquent ou qu’elle se produise suffisamment fréquemment pour occasionner une vraie gêne.

Il semble donc particulièrement important, d’après le 2ème point, que cette régression représente fidèlement les usages. Une régression sur un scénario jamais utilisé par les utilisateurs et n’ayant aucun impact non fonctionnel n’a potentiellement que peu d’intérêt. C’est d’ailleurs l’objet du bel article de Bruno Legeard sur le test des usages définis grâce à des logs d’utilisation.

Une régression doit donc proposer des parcours utilisateurs fréquents…Néanmoins ce n’est pas suffisant! Même si ces tests peuvent/doivent présenter la grande majorité des tests d’une campagne de régression il est primordial d’aller plus loin avec la régression… et c’est d’ailleurs pour cela que Bruno indique bien que l’outil gravity n’allège pas totalement la charge de travail sur la régression mais 80%.

Les 20% restant de l’effort sont dédiés à ce que l’on voit souvent sous le terme de cas « non-passants » ou de tests liés au non fonctionnel comme les performances et la sécurité. En effet, les tests de sécurité sont nécessaires afin d’éviter des intrusion, du vol de données ou des usurpations d’identité… mais les attaques ne sont pas aussi fréquentes que le flux des utilisateurs lambdas. De même une baisse de la performance et modifiera pas le résultat des tests d’usages mais détériorera très fortement l’expérience de nos utilisateurs.

Une campagne de régression doit donc proposer des tests complémentaires aux usages et ces tests doivent être en adéquation avec les différents risques identifiés… ces risques étant souvent liés à du non fonctionnel.

Conclusion

La campagne de régression est un élément majeure de la qualité lors des développement d’un produit en Agile. Il est donc nécessaire d’avoir une « bonne » campagne de régression pour avoir, sur la durée, un produit de qualité. Pour arriver à cela il faut évidemment avoir des tests proches des usages pour éviter l’illusion d’absence d’erreur mais ce n’est malheureusement pas suffisant, il faut aussi intégrer des tests plus spécifiques et souvent liés au non fonctionnel (sécurité, performances, robustesse…)

Cet article est disponible en anglais sur le blog de Gravity avec ce lien.

Pensez à rejoindre le groupe « Le métier du test » si vous souhaitez échanger sur le test

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles

N’hésitez pas à faire vos propres retours d’expérience en commentaire.

Une réponse

  1. Salutations, et bien que j’aie été satisfait de ce qui a été rapporté à propos de l’e-mail, je suis devenu un adepte fidèle de votre site, en plus de cela, l’ajout qualitatif que vous apportez dans le domaine du labo logiciel, et son leader rôle dans l’ajout qualitatif fourni par le laboratoire de logiciels à l’organisation dans laquelle il travaille et maintient sa position et son leadership de Grâce au travail diligent et distingué qu’il accomplit, merci pour le travail, que vous soyez bien et paix

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Automatisation

KDT: Keyword Driven Testing

On parle toujours de tests manuels et de tests automatisés mais rarement de Keyword Driven Testing (KDT). A quoi cela correspond exactement le KDT ? Repartons de la base. Les tests manuels Un test manuel bien écrit est une suite d’actions entraînant chacune un résultat à vérifier Prenons un exemple : lire

Lire la suite »
Agilité

Des tests en prod ?

Introduction On nous a toujours appris que les tests en production c’était mal, qu’il fallait un environnement dédié pour les tests capable de simuler la production afin de détecter les problèmes en amont et de tester tôt. Les environnements de test font d’ailleurs parti des critères nécessaires selon TMMI afin

Lire la suite »
Avenir

Pourquoi être testeur ?

Introduction : Le métier de testeur est devenu très vaste. Tout comme pour les développeurs (avec par exemple les développeurs : Web, php, java…), le métier est maintenant très diversifié et peu difficilement être réduit à un unique métier (testeur « manuel », testeur automaticien, test manager, test de performance…) ou tout du moins

Lire la suite »