Processus: Automatiser ses tests

L’automatisation des tests se solde souvent par un échec. Les raisons peuvent être multiples et variées comme :

  • Les problèmes de maintenance
  • L’absence de retour sur investissement
  • Les problèmes d’outils
  • Exécuter uniquement les tests sans les analyser
  • La non compréhension des résultats…

Ces échecs sont généralement explicables par un manque de préparation, de stratégie ou un mauvais processus de mise en place de l’automatisation… Et pour résoudre ces problèmes il faut accepter l’idée que l’automatisation des tests est un projet à part entière.

Dès lors il est normal de procéder par étapes, de connaitre les besoins et étudier l’intérêt d’automatiser et ses conséquences directes.

Par rapport aux processus, il en existe évidemment un grand nombre, je vous propose celui-ci :

Stratégie automatisation des tests

La première chose à identifier, c’est savoir pourquoi on veut automatiser. Les raisons peuvent être diverses, en voici des possibles :

  • Gain de temps sur l’exécution des tests
  • Multiplication des exécutions des tests de régression (ou vitaux)
  • Réduire le coût des tests
  • Implémenter une démarche d’intégration continue

Dans tous les cas la ou les raisons d’automatiser permettront de savoir s’il est intéressant d’automatiser. L’automatisation des tests fait gagner du temps (si implémenté correctement) sur l’exécution de ces derniers mais le retour sur investissement n’est garanti que dans des cas d’exécution fréquentes.

Il faut ensuite sélectionner les tests à automatiser et à automatiser en priorité

Pour cela il faut d’abord choisir quels sont les types de tests que l’on souhaite automatiser. Cela peut par exemple être des:

  • Tests d’interface graphique
  • Tests batchs, Webservices
  • Tests de régression/vitaux
  • Tests de « performances »
  • Tests de sécurité

On peut alors, et seulement alors, choisir l’outil de test afin de choisir le plus adapté :

  • En fonction des tests que l’on veut automatiser
  • En fonction du budget que l’on a
  • En fonction des connaissances de l’équipe
  • En fonction des technologies
  • Il est probable de devoir réduire son périmètre des tests à automatiser lors de cette phase

Vient alors le moment de concevoir l’automate de test. Ce dernier doit être conçu afin de :

  • Limiter la maintenance (la modularité est impérative)
  • Rester stable et fiable

On peut choisir à ce moment-là si l’on souhaite utiliser du KDT afin de faciliter l’automatisation des tests par des personnes peu techniques.

Vient alors le moment de prioriser les tests en fonction de :

  • Leur criticité
  • Leur complexité

Par priorisation il est évidemment possible de choisir de ne pas automatiser certains tests. De manière générale, le plus intéressant est d’automatiser en premier les tests avec le meilleur retour sur investissement, c’est-à-dire les tests qui ne sont pas sur IHM et les tests vitaux.

Enfin, il faut faire le bilan de cette mise en place de l’automatisation

  • Retour d’expérience
  • Résultats de l’automatisation

Il ne faut également pas oublier de continuer à exécuter, analyser, enrichir et maintenir les campagnes de tests automatisés.

Pensez à rejoindre le groupe Le métier du test si le sujet vous intéresse !

N’hésitez pas à me suivre et lire mes autres articles si vous voulez en apprendre plus sur le test ou venir partager vos connaissances

Merci à tous ceux qui mettent « j’aime », partagent ou commentent mes articles

2 réponses

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Les petits trucs de testeur
Bug

Petits trucs de testeur: reproduire une anomalie

Introduction Lorsque l’on fait nos tests, scriptés ou non, il n’est pas rare de rencontrer une anomalie (et heureusement car trouver des défauts fait partie des objectifs des tests selon l’ISTQB). Notre réflexe de testeur est alors de créer une fiche d’anomalie afin de donner de l’information. Nous voilà donc

Lire la suite »
Couvertures

« Les » couvertures de test

J’ai il y a longtemps écrit un article sur les couvertures de test. Honnêtement je trouve cet article trop incomplet pour pouvoir être le seul présentant les couvertures de test. Il a néanmoins l’avantage de montrer qu’une couverture de 100% ne veut rien dire, comme je l’ai écrit dans mon

Lire la suite »
Dérives à éviter en BDD: BDD = automatisation Scénarios conçus par une seule personne Absence de scénarios d’acceptation Scénarios non compréhensibles par tous BDD fait en cours de sprint Gherkin = BDD
BDD

Les dérives qui rendent le BDD inefficace

Le BDD peut beaucoup apporter Comme vous le savez en lisant mes divers articles, je suis convaincu que le BDD est particulièrement efficace dans des environnements agiles. Les gains potentiels (directs ou non) sont très nombreux. Je pense notamment à: Cela semble être une solution miracle! Ce n’est malheureusement pas

Lire la suite »