Quels tests automatiser en priorité ?

Partir des risques, pas des outils

Le choix d'un outil vient après. La première question est : quelles anomalies coûteraient le plus cher si elles arrivaient en production ? Les parcours qui génèrent du chiffre d'affaires, manipulent des données sensibles ou sont soumis à des obligations réglementaires sont souvent les premiers candidats.

Quatre critères pour prioriser

• Fréquence : un test exécuté à chaque version rapporte plus qu'un test lancé une fois par an.
• Criticité : un parcours de paiement ou de connexion passe avant une page d'information.
• Stabilité : une fonctionnalité qui change chaque semaine coûtera cher à maintenir en automatique.
• Effort : un test simple à écrire et à fiabiliser permet de montrer rapidement l'intérêt de la démarche.

Exemple illustratif

Imaginons une application de souscription en ligne. La connexion, le calcul d'un tarif et la validation d'un dossier sont exécutés à chaque version et ont un impact direct sur les clients : ce sont de bons candidats. Le nouvel écran de personnalisation, encore en cours de conception, peut rester en test manuel tant qu'il évolue.

Penser à la pyramide des tests

Beaucoup de vérifications peuvent être faites plus bas que l'interface : tests unitaires côté développement, puis tests d'API. Ils sont plus rapides et plus stables. Les tests de bout en bout par l'interface sont réservés aux parcours qui doivent être vus comme un utilisateur.

Erreurs fréquentes

• Vouloir automatiser 100 % des cas de test manuels existants.
• Automatiser avant d'avoir stabilisé les données et les environnements de test.
• Accepter des tests instables : l'équipe finit par ignorer tous les résultats.
• Ne pas prévoir qui maintiendra les tests après leur création.

Par où commencer

Listez une dizaine de parcours, notez-les selon les quatre critères ci-dessus, puis automatisez les trois ou quatre premiers. Mesurez leur stabilité avant d'élargir.