On passe vraiment des tests manuels aux tests automatisés ?

La théorie dit qu'il est possible d'automatiser ses tests très vite voire même avant la toute première exécution de ses tests grâce à BDD.

Cette même théorie arrive avec de nombreuses bonnes pratiques, comme une automatisation au plus tôt et, en Agile, au sein de sprint où les user storys sont developpées

La théorie est très jolie, mais elle est souvent très différente de ce que l'on observe dans la pratique ! Une des raisons est évidemment le contexte.

Automatiser dès le début, c'est bien... mais que faire lorsque l'on est sur des  logiciels existants qui n'ont pas de tests automatisés ?

De même, l'automatisation d'une fonctionnalité peut ne pas être pertinente dans le cas où il y a des changements majeurs prévus pour cette même fonctionnalité.

En pratique, on observe régulièrement une automatisation des tests assez tardive. Cette automatisation se fait sur un répertoire de tests servant de régression.

Lorsque l'on est dans ce cas, une pratique usuelle consiste à automatiser les tests de régression existants, car ceux-ci ont déjà fait preuve de leur efficacité.

A noter : il existe des contextes sans campagne de régression scriptée ou définie. Dans ce cas, l'automatisation des tests peut être l'occasion de travailler sur cette dernière en définissant un répertoire de test pour cette campagne.

‍

Automatiser ses tests de régression manuels

Maintenant que l'on sait pourquoi les équipes se retrouvent à automatiser les tests manuels, il est important de savoir comment !

L'automatisation est une affaire d'investissement. Comme pour tout investissement, on attend un retour sur investissement le plus rapidement possible.

‍

Déterminer le couple valeur/effort des tests à automatiser pour prioriser l'automatisation des tests.

De même, l'automatisation des tests manuels peut aussi se voir comme un développement Agile, où les tests à automatiser représentent les US et la campagne à automatiser produit. En voyant les choses comme cela, il devient clair qu'il va falloir prioriser les tests à automatiser afin de maximiser la livraison de valeur.

Cette priorisation se fait de manière assez "classique", avec une combinaison faite entre un effort d'automatisation des tests et la valeur que cette automatisation devrait apporter.

Il ne reste plus qu'à définir comment évaluer cette "valeur".

Le calcul de la valeur peut s'avérer complexe, car en fonction des raisons de l'automatisation (gain de temps, gain d'argent, mise en œuvre de tests continus...), elle peut varier fortement. Elle dépend de nombreux éléments comme :

• Le temps passé à exécuter les tests
• La fréquence d'exécution du test
• La valeur métier du test
• La complexité de l'exécution des tests...

‍

Cependant, il est essentiel de bien estimer la valeur, comme en Agile, à décider de ne pas automatiser certains tests si la valeur n'est pas suffisante par rapport à l'effort demandé pour son automatisation.

Il est donc essentiel de définir l'effort nécessaire pour automatiser les tests... Cet effort est d'ailleurs plus conséquent sur les premiers tests où tout une architecture est à mettre en place. En effet, il est plus que recommandé de découper ses tests en sous-scripts réutilisables, afin de limiter la maintenance et mais aussi de simplifier l'automatisation des tests à venir. L'effort d'automatisation d'un test dépendra alors de :

• La qualité du test manuel : est-il bien écrit, clair, avec des étapes et des résultats attendus ?
• La complexité des actions à automatiser
• La complexité du parcours : est-il modal ? Plus ou moins long ?
• Les potentielles dépendances
• La sensibilité aux données
• Le potentiel impact sur d'autres tests...

‍

Cette combinaison effort /  valeur permet alors de prioriser son backlog de tests à automatiser. Comme pour un backlog "produit", ce dernier sera sûrement amené à évoluer tout comme lapriorisation des éléments qui le constituent.

A noter : la complexité dépend de l'outil d'automatisation et des compétences de l'équipe.

‍

Automatisation des tests

Maintenant que la priorisation est faite il est nécessaire de commencer à automatiser ses tests… Acondition que l’outil d’automatisation ait été sélectionné et que l’équipe ait les compétencesnécessaires (si besoin avec des formations).

Il peut être intéressant de continuer à travailler comme en « Scrum » avec des jalons de dates et desobjectifs de tests à automatiser. Tout comme en « Scrum » il pourra être nécessaire de travailler surdes tâches « techniques » afin de faciliter l’automatisation et la maintenance future.

Les premiers tests seront donc vraisemblablement plus longs à automatiser que les suivants… surtoutdans le cas où l’on souhaite suivre des bonnes pratiques de développement des tests automatisés quilimitent la maintenance avec l’utilisation de sous-scripts qui deviennent alors l’équivalent de motsclés et permettent de faire de l’automatisation par mot clés aussi appelée « Keyword DrivenTesting ».

Il peut aussi être intéressant de variabiliser ces mots clés et de coupler cette automatisation KDTavec tests pilotés par des données pour des éléments comme l’authentification ou le remplissage deformulaires.

Vous l’aurez compris, 1 test à automatiser ne se traduira pas forcément par 1 test automatisé.

Au final, 1 test à automatiser pourra se traduire par :

• Plusieurs sous-scripts
• Plusieurs sous-scripts et une partie unique
• Plusieurs tests afin de mieux cibler les objectifs et faciliter l'analyse
• Un jeu de données pour un test piloté par les données (par exemple, sur du login)
• Plusieurs jeux de données afin de proposer une meilleure couverture ou s'adapter à certains événements

‍

Le suivi des tests automatisés

La véritable valeur apportée par l’automatisation doit pouvoir se voir dès la mise à disposition despremiers tests automatisés.

Il est alors essentiel de définir des indicateurs qui permettront de voir l’apport de ces tests et ainsid’évaluer et/ou de suivre l’éventuel retour sur investissement. C’est grâce à ce suivi que l’on pourraprendre des décisions comme :

• La poursuite de l'automatisation
• L'arrêt de l'automatisation (cela peut être pour de nombreuses raisons comme l'atteinte des objectifs fixés ou un retour sur investissement jugé insuffisant)
• Le changement de stratégie afin de s'améliorer
• Le changement d'outil pour mieux répondre au besoin...

‍

Ce suivi est essentiel. Il doit se faire du point de vue opérationnel avec l’équipe qui se penche sur lesaspects techniques mais aussi d’un point de vue "projet" avec une évaluation des apports concretsde l’automatisation.

C’est uniquement à ce prix que l’on peut savoir et démontrer que l’automatisation de sa campagnede test manuel a un vrai intérêt et qu’elle est un succès. C’est également uniquement à ce prix quel’on peut savoir s’il est préférable d’arrêter ou de s’orienter différemment afin d’atteindre lesobjectifs que doivent remplir l’automatisation des tests.

‍

En conclusion

L’automatisation des campagnes de régressions manuelles est un sujet très fréquent auquel il estessentiel de pouvoir répondre. Cette automatisation qui ne se fait pas "au plus tôt" engendre unecertaine complexité notamment vis-à-vis de la priorisation des tests à automatiser.

Un moyen de réussir cette automatisation, en plus des bonnes pratiques usuelles, est de bien gérerla construction de son "produit" campagne de test automatisée. Cela passe par un vrai travail depriorisation avec une évaluation de la valeur et de l’effort nécessaire mais aussi par un suivi régulier àtravers un ajustement constant de la stratégie et des indicateurs de suivi.

‍