La taverne du testeur

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 *

Agilité

PO et testeur… C’est possible?

La réponse peut paraître simple… Surtout lorsque l’on regarde ma mission actuelle chez Orange ! Néanmoins cumuler ces 2 casquettes soulève au moins 1 problème majeur . Problématique : Le PO représente le métier et est responsable des tests d’acceptance (Niveau 4) alors que le testeur s’occupe (et généralement exécute) les tests systèmes

Lire la suite »
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 »
Interview

Rajae Aouchi: Ingénieur test et validation

Bonjour, qui êtes-vous, quel est votre métier et quelles sont vos activités professionnelles ? Je suis Rajae AOUCHI, Ingénieur Test et Validation depuis 3 ans, membre de la CMTL. J’ai découvert le métier du test lors de ma toute première expérience professionnelle durant mon stage de Projet de Fin d’Etudes chez SQLI, cette

Lire la suite »