De manière cyclique on voit venir et revenir des besoins d’automatisation de test. Ce sujet vient notamment de charges de maintenances sous-évaluées qui rend les automates rapidement obsolètes. Les organisations oublient et quelques années plus tard on redémarre. Nous n’aborderons pas ce point en soi, mais l’amont qui est de savoir si on doit avoir des tests manuels ou des test automatiques ?

Certaines personnes considèrent qu’il faut tout automatiser, mais ils sont souvent proches du développement et parlent en conséquence des tests unitaires, qui par définition sont automatisés (du code qui teste du code)… Confondent-ils couverture des tests unitaires et automatisation des tests ?

D’un autre côté on a des testeurs fonctionnels, qui sûrement défendent leur activité.

Entre les deux on a beaucoup d’autres profils qui ont autant de visions différentes. Qui a raison, quel est le bon ratio d’automatisation des tests ?

Comparatifs

La première chose à faire quand on parle d’automatisation c’est de savoir de quel niveau de test on parle.

Pour les tests de bas niveau tel que les tests unitaires, les tests d’API… on doit bien entendu être à 100% d’automatisation, mais c’est même une tautologie pour les tests unitaires. En ce qui concerne les tests API, il ne faut pas confondre l’appel API qui est quasi forcement outillé, avec la vérification des résultats attendus qui ne l’est pas forcément. L’automatisation des test API veut dire qu’on a automatisé la vérification des résultats attendus.

Pour les tests fonctionnels, système, …, souvent sur un écran, il faut utiliser des technologies différentes. Ces technologies vont interagir avec les technologies sous test pour pouvoir cliquer sur un bouton, remplir un champ à l’écran … C’est donc plus long à automatiser, voire complexe pour certaines technologies. Il faut maintenir les scripts dès qu’on modifie l’aspect de l’écran.

On sous-estime souvent le ROI de ce type d’automatisation. D’expérience on se situe entre 10 et 15 exécutions manuelles pour rentabiliser un automate d’écran. Tout dépend de la technologie, du framework, de la manière dont cela a été codé, on peut même aller au-delà des 15.

Il est rare que l’ensemble d’un référentiel de test nécessite autant d’exécution, et souvent asymptomatique d’une stratégie de test non optimisée.

On constate assez fréquemment des taux d’automatisation écran aux alentours de 50%. Il est alors important d’avoir une stratégie d’automatisation complémentaire entre les niveaux pour éviter les redondances de périmètre. A quoi bon automatiser les bas niveaux à 100%, si les hauts niveaux, plus proche de la réalité, font des uses cases équivalents.

Une bonne stratégie serait plutôt d’avoir une couverture de non régression bas niveau de 50%, complémentaire d’une automatisation écran de 50%, sans oublier les test manuels…

Ce combat était plus compliqué que ce qu’il paraissait, et c’est avant tout la complémentarité des acteurs qui gagne, comme souvent dans le test.