Fréquence et automatisation des tests, quelle est la parfaite symphonie ?

Vous avez un déficit de qualité sur vos versions en production et vous cherchez une solution pour les résoudre ? Autant commencer par-là : l’automatisation de vos tests de non régression peut vous aider, mais ne résoudra pas tout. L’industrialisation de vos tests de non régression va vous permettre d’identifier vos régressions mais n’en traitera pas la cause.

Vous allez améliorer la qualité de vos livrables c’est évident, mais il vous faudra également travailler l’organisation et les processus de vos équipes. L’automatisation des tests s’intègre en fonction : des organisations d’équipes, de votre contexte, pour des fréquences de mises en production cadencées.

Avant de poursuivre, un rappel pour beaucoup mais peut être une révélation pour d’autres ;-) Trop souvent nous avons comme argument déclencheur d’un projet d’automatisation de tests de non régression : « Je verrai si cela est rentable au nombre de bugs des nouvelles fonctions détectées !! ». Nous devons alors nous contorsionner pour expliquer à notre interlocuteur que les tests de non régression ne sont pas fait pour cela et, nous vous l’assurons, ce n’est pas simple …

La définition d’un test de non régression, norme ISTQB 2018  :

« Tests d’un programme préalablement testé, 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, comme suites des modifications effectuées. » Copyright Notice © ISTQB / CFTL 2018

Alors, fréquence et automatisation, quelle est la parfaite symphonie ?

Cas n° 1 : Mises en production 2 à 3 fois par semaine.

Dans une carrière nous sommes tous confrontés, à un moment ou à un autre, à des mises en production à la file indienne. Et dans la majeure partie des cas, ces MEP n’apportent pas une nouvelle fonctionnalité mais corrigent des bugs présents en production. Et là l’automatisation n’a pas sa place. Cette situation est liée à une mauvaise organisation ou à une défaillance lors de la conduite du projet et la priorité doit être à la réorganisation de la méthodologie de travail avant de penser à l’automatisation de vos tests.

Cas n°2 : Mises en production toutes les 3 à 4 semaines à quelques mois.

L’industrialisation de l’automatisation des tests de non régression est incontournable pour soutenir ce rythme de mise en production de nouvelles fonctionnalités. Pour les entreprises qui fonctionnent avec la méthodologie Agile l’automatisation est une des clés de la réussite. Cela permet de se concentrer sur l’adéquation avec le besoin et le bon fonctionnement de la nouvelle option demandée par le marketing et/ou vos clients. La stabilité de l’existant, la détection des effets de bords.. étant assuré par des campagnes de tests de non régression.

Si les mises en production sont très fréquentes (quelques semaines) il y a fort à parier que le patrimoine de test n’est pas complètement remis en question à chaque MEP ! Il peut arriver, en fonction des secteurs d’activité, que lorsque les mises en production ont lieu tous les deux à trois mois, que le patrimoine de tests soit à actualiser. Dans ce cas, il convient de poser le ROI de l’automatisation des tests Vs mobiliser une équipe dédiée le temps d’effectuer les tests « manuellement ». En fonction du résultat de l’analyse vous serez fixés.

Le mois dernier nous avons rencontré un Directeur de Production qui avait pour objectif de réduire ses délais de mise en production pour passer de 3 mois à 1 mois. Mais au fur et à mesure du développement des nouvelles fonctionnalités ses équipes n’avaient pas le temps d’élaborer des scénarios fonctionnels et de les intégrer au patrimoine de tests de non régression. Les recettes manuelles venaient donc ralentir les mises en production et dans ce cas précis, l’automatisation des tests est LA solution pour gagner du temps. À noter que l’effort pour industrialiser l’automatisation des tests de non régression est significatif (intégration des scénarios, mise en place de l’infrastructure …) et il ne faut pas le négliger.

Cas n°3 : Trois mois et +

À cette fréquence, pas de secret, il faut calculer le ROI et analyser la pertinence en fonction du besoin. Dans la majorité des cas, l’effort nécessaire et le coût lié à l’automatisation des tests ne sera pas pertinent. Mais, par exemple dans le cas d’un ERP, qui dépend des mises à jour de l’éditeur, de l’intégrateur, ou encore d’une application tierce, l’automatisation des tests prend là aussi tout son sens car elle va permettre d’identifier rapidement les régressions car le patrimoine de test aura probablement peu évolué et les scénarios pour tester les fonctionnalités critiques resteront fonctionnels.

Pour conclure.

Comme pour la majorité des projets c’est souvent la même rengaine : au regard du besoin qu’est-ce que cela coûte ? Mais pour schématiser il y a 4 grandes lignes :

1. Fréquence élevée (2 à 3 MEP par semaine) : pas d’automatisation
2. Méthodologie Agile : automatisation incontournable
3. Fréquence moyenne (2 à 3 mois) :
   1. Patrimoine des tests stable : automatisation pertinente
   2. Patrimoine des tests qui évolue fortement : pas d’automatisation
4. Fréquence rare (3 mois et +) : calcul du ROI en tenant compte du temps nécessaire à l’actualisation du patrimoine des tests.