Quand devriez-vous automatiser vos tests logiciels ?

Quelles sont les réponses habituelles lorsqu'il s'agit de mettre en œuvre l'automatisation des tests ? 

Quand faut-il automatiser ses tests ? Cette question revient régulièrement lorsqu'on travaille dans le développement de logiciels. La récurrence de cette question n'est pas surprenante car les réponses sont souvent différentes. Voici une liste de réponses courantes à cette question :

Les tests automatiques doivent être mis en place dès que les fonctionnalités (ou US) qu'ils couvrent sont validées. 

Cette déclaration peut généralement être réduite à "pendant le sprint" lorsqu'on travaille avec les cycles de développement Scrum.

Les tests doivent être automatisés avant même d'être exécutés pour la première fois.

Vous devez automatiser lorsque le logiciel ou le bloc testé est stable.

Cette vision de l'automatisation est assez traditionnelle (souvent liée au cycle en V) car l'automatisation arrive assez tard.

L'automatisation des tests doit être réalisée lorsque vous avez du temps.

Dans ce contexte, l'équipe doit faire des choix. Ce choix peut être de reporter l'automatisation à plus tard.

Automatiser lorsque le bon outil d'automatisation a été trouvé.

Dans ce cas, l'intérêt d'automatiser ses tests est clair, mais l'outil qui répond au besoin n'a pas encore été identifié.

L'automatisation doit être réalisée lorsque les ressources humaines sont disponibles.

Le problème ici peut être lié à une question de temps. Mais aussi, plus simplement, à l'absence d'une personne capable d'offrir cette automatisation.

Ne pas automatiser.

Il s'agit d'une réponse de plus en plus rare, qui peut être liée à des développements très courts ou à des expériences d'automatisation ratées.

A vrai dire, aucune de ces réponses n'est fausse car chacune peut être totalement valable en fonction de son contexte. J'ai évidemment une préférence, de par mon expérience Agile, pour l'automatisation pendant le sprint ou même en amont ! Néanmoins, j'ai été amené à reporter l'automatisation des tests en fonction de contextes spécifiques. En fait, si je devais donner une réponse générique à la question " quand faut-il automatiser ses tests ? ", ce serait :

Dès que possible !

Cette réponse suppose que l'automatisation est un investissement et que plus tôt elle est faite, meilleur sera le retour sur cet investissement. De même, l'utilisation du mot "possible" implique que le moment où elle devient intéressante ne dépend pas uniquement de la volonté de chacun, mais du contexte !

Une autre question se pose donc : 

En fonction de mon contexte, quand et comment dois-je automatiser les tests ?

Maintenant, définissons des contextes qui sont favorables aux réponses précédentes tout en décrivant comment cela est possible ! 

Les tests doivent être automatisés dès que les fonctionnalités (ou US) sont validées et couvertes. 

Pour pouvoir automatiser les tests pendant le développement de fonctionnalités, il est généralement très important d'être dans un contexte de développement Agile. De même, les compétences en automatisation doivent être présentes dans l'équipe à plein temps.

Afin d'obtenir une automatisation régulière de chaque fonctionnalité avant sa validation finale, il est préférable d'ajouter ce critère dans le Definition of Done. Mais aussi et surtout, il faut identifier le plus tôt possible les tests à automatiser et identifier leurs exigences en matière d'environnement et de données. Il est également essentiel d'intégrer ces tests dans des campagnes de tests automatisés dès que la fonctionnalité est validée, tout en veillant à maintenir les tests de régression existants.

Automatiser les tests avant qu'ils ne soient exécutés pour la première fois.

Pour apporter cette réponse, il est généralement nécessaire d'avoir une forte approche collaborative, ce qui est généralement présent dans certaines équipes Agile appliquant la méthodologie BDD. Grâce au BDD, l'équipe est amenée à décrire des scénarios d'acceptation qui illustrent le comportement de la fonctionnalité à développer. 

Avec un haut degré de rigueur, il est alors possible d'utiliser ces tests BDD pour disposer de tests automatisés avant même le début du développement. Ces tests sont alors conçus en BDD et, comme pour le TDD, échouent avant même que la fonctionnalité ne soit livrée. Il est alors possible d'exécuter directement ces tests automatisés pour participer à la validation de la User Story.

Vous devez automatiser lorsque le logiciel ou le bloc testé est stable.

Dans un contexte très changeant ou avec beaucoup d'incertitude, l'automatisation des tests peut rapidement finir par être abandonnée ou réécrite après 1 ou 2 exécutions. Cet effet peut être réduit avec une architecture modulaire des automates. Néanmoins, il peut être préférable, dans ce contexte, d'attendre que le logiciel (ou une partie du logiciel) soit stabilisé avant de commencer à automatiser. 

Ceci est particulièrement vrai dans un cycle en V. Mais il peut également être approprié en Agile lorsque de nombreux problèmes doivent être résolus.

L'automatisation devrait alors être réalisée dès qu'une solution permanente émerge.

Vous devez automatiser quand vous avez le temps.

L'automatisation reste un investissement. Elle permet de gagner beaucoup de temps, mais à moyen terme. Il y a des contextes où un produit doit être livré à une date très proche. L'équipe doit alors faire des choix pour répondre à ce contexte. Ce choix n'est pas fait gratuitement et il crée une dette qui ne fera qu'augmenter avec le temps. L'idéal est donc de trouver le temps d'automatiser le plus rapidement possible.

J'ai personnellement déjà dû faire ce choix avec la décision de ne pas automatiser les 3 premiers mois car un MVP devait être prêt pour cette échéance et nous n'avions pas le temps d'automatiser les tests (d'autres concessions temporaires avaient également été faites).

Vous devez automatiser lorsque le bon outil d'automatisation a été trouvé.

Le problème ici est lié à un outil qui ne répond pas au besoin. Cela peut être pour des raisons techniques (l'outil ne peut pas effectuer certaines actions sur le logiciel) ou pour des raisons humaines, avec un rejet de l'outil par les personnes ou, plus simplement, parce qu'il est trop long à utiliser (ou maintenir).

Dans ce cas, il est préférable de réaliser une étude de marché suivie d'un POC afin de déterminer quel outil sera le plus adapté à notre contexte technique, humain et budgétaire. L'outil (et son choix) ne doit pas être un frein et ne doit pas faire perdre de temps à l'équipe.

Nous devons automatiser avec les bonnes personnes.

Ce contexte est en partie similaire au précédent. Le problème ici est le temps et les personnes. La plupart du temps, l'équipe dispose d'un ou plusieurs bons testeurs fonctionnels qui ne sont pas très techniques. L'automatisation des tests, qui est considérée comme une tâche du testeur, devient alors trop complexe à mettre en œuvre. Cela peut expliquer une "attente" avant la mise en œuvre de l'automatisation.

Ces problèmes sont fréquents, et c'est pourquoi un outil comme Agilitest a été développé. En effet, Agilitest rend l'automatisation des tests accessible aux profils non techniques, laissant les professionnels des tests s'occuper de l'automatisation de l'exécution des tests.

Vous n'avez pas besoin d'automatiser.

Nous sommes ici dans un contexte très particulier. On peut penser à un développement très court ou à des tests particulièrement complexes à automatiser, comme la reconnaissance dynamique d'images ou les tests liés à l'ergonomie.

Dans ce cas, il est nécessaire de consacrer beaucoup de temps aux tests manuels.

Enfin, pourquoi pensez-vous tant à l'automatisation des tests ? Quel est l'avantage de l'automatisation des tests et pourquoi automatiser "dès que possible" ?

Pourquoi automatiser les tests dès que possible ?

L'automatisation des tests est un investissement qui s'amortit au fur et à mesure de son exécution. Plus vous automatisez vos tests tôt, plus le nombre d'exécutions est élevé et plus le retour sur investissement est important.

Au-delà du simple aspect financier, automatiser les tests le plus tôt possible permet d'intégrer des tests de régression, de les exécuter plus souvent et donc de tester plus tôt et plus fréquemment ! La détection précoce des anomalies les plus significatives permet de gagner beaucoup de temps et améliore également le moral des équipes de développement logiciel.

Enfin, dans le cas où les tests sont automatisés avant le début du développement, les tests sont partagés avec le développeur avant même que ce dernier ne commence à construire la fonctionnalité. Cela aide le développeur à mieux comprendre le besoin, mais aussi à s'assurer au préalable de la validité de son travail. On bénéficie alors de tous les avantages de l'automatisation mais aussi du BDD avec une réelle collaboration.

Conclusion

Il n'y a pas de "meilleur moment" théorique pour automatiser les tests. Selon le contexte, cette automatisation viendra plus ou moins tard. Cependant, il est important de garder à l'esprit que, quel que soit le contexte, il est bon de commencer à automatiser ses tests dès que possible, car l'automatisation des tests a beaucoup à offrir et ses répercussions sont d'autant plus visibles que l'on commence tôt.

‍