L’automatisation, le nouvel Eldorado !
Il faut automatiser tous les tests et une fois que ça sera fait, exécuter les cas de tests sera gratuit et parfaitement fiable, tout sera merveilleux !
Vraiment ?
Dire cela montre juste un manque de connaissance du métier du test. Les tests ce n’est pas que l’exécution.
L’automatisation a de nombreuses qualités (surtout avec des méthodes incrémentales, pour plus d’info lire mon post sur le testeur dans la méthode Scrum) indéniables et il serait dommage de s’en priver. Néanmoins les cas de tests manuels ont également de nombreux points forts non négligeables et souvent complémentaires avec les tests automatisés.
Commençons donc par la vie d’un cas de test (automatisé ou manuel) :
La vie d’un cas de test comporte de nombreuses étapes qui sont :
- Designer le cas de test (souvent à partir des spécifications, on appelle cela le BDD) avec son scénario et ce qu’on attend du cas.
- Ecrire le cas de test
- Exécuter le cas de test
- Analyser le cas en cas d’échec
- Maintenir le cas de test
- Archiver le cas de test
Nous pouvons donc commencer à décortiquer les avantages et contraintes des cas de tests automatiques et des cas de tests manuels.
Les tests manuels :
La partie design du cas de test n’est pas la partie la plus coûteuse mais elle reste néanmoins très importante particulièrement afin d’atteindre la qualité souhaitée pour le logiciel ou l’application.
L’écriture du cas est très importante, il faut un cas clair en plusieurs étapes avec à chaque étape :
- Une action (précise, ex : cliquer sur le bouton nouveau mail)
- Un résultat attendu (le composeur s’affiche, il contient…)
Exécuter le cas de test, dans le cas d’un test manuel, le cas est exécuté par le testeur directement qui effectue les actions demandées et vérifie que le résultat obtenu est bien celui attendu. La répétition de l’exécution de cas de test, n’est pas très enrichissante, c’est d’ailleurs pour cela que les tests automatisés semblent si attractifs.
L’analyse du cas en cas d’échec est ici beaucoup de récupération d’informations et ce fait au moment où le bug se produit.
Maintenir le cas, en cas d’évolution de la fonctionnalité ou changement dans le résultat souhaité le cas peut être rapidement mis à jour.
L’archivage du cas intervient quand on décide de ne plus utiliser le cas, soit car il est devenu obsolète ou qu’il était un cas de validation, soit car l’application n’est plus en production.
Les cas de tests automatiques :
La partie design du cas de test ne dépend quasiment pas du fait que le test soit automatique ou manuel. En effet il n’est pas rare qu’un test à l’origine manuel soit automatisé.
Pour la partie Ecriture du cas, les tests automatisés sont très chers. Il faut en effet en plus de faire le travail d’un cas de test manuel « coder » ce cas dans le langage voulu avec les outils à dispositions (outils qui ne sont pas forcément parfaitement stables). Si on ne veut pas coder, il existe également le KDT (Keyword Driven Testing) qui est une couche intermédiaire entre le « code » et le cas de test manuel. Il est plus facile de lire un cas de test écrit en KDT que directement codé mais cela ajoute un nouvelle couche sujette à des instabilités et pouvant également être source de restrictions.
La vraie plus-value des cas de tests automatiques est l’exécution des cas de tests. Pas besoins de tourner à la main 50 fois un cas de tests, on peut le tourner n’importe quand et autant de fois que l’on veut. Il ne reste au testeur qu’à faire la partie avec le plus de valeur ajoutée. Car oui, je ne vous le cache pas, l’exécution des cas n’est pas la partie la plus palpitante du métier de testeur !
La partie analyse est sensiblement la même qu’en test manuel à l’exception que l’on n’est pas forcément présent lorsque l’échec survient. Pour pallier à cela il faut avoir de bons logs afin que la recherche de la raison de cet échec soit facilitée.
Le maintien des cas de tests coûte pour les tests automatisés beaucoup plus cher que pour les tests manuels. En reprenant mon exemple d’ouverture du composeur. Admettons qu’avec notre nouvelle version le composeur soit refait totalement (cela arrive régulièrement, pas plus tard que la semaine dernière pour le webmail d’outlook). Dans le cas d’un test manuel on ne change pas grand-chose si les fonctionnalités reste les mêmes, par contre dans le cas d’un test automatisé, selon les vérifications faîtes, il faut potentiellement toutes les changer (changer les IDs par exemple est très pénalisant pour les tests automatisés), cela prend donc beaucoup plus de temps.
L’archivage du cas est identique qu’il soit manuel ou automatique.
Conclusion :
Les cas de tests automatiques sont particulièrement intéressants dès lors qu’il faut exécuter régulièrement ces cas (automatiser un cas qui ne devra être exécuté qu’une ou deux fois est une perte de temps et d’argent !) et que ces cas ne sont pas voués à évoluer souvent. Il faut toujours voir, ici le retour sur investissement.
C’est pour ces raisons que l’on préconise généralement l’automatisation dans les méthodes comme la méthode Scrum (méthodes incrémentales) et pour les cas de tests de régressions (qui par définition ne sont pas voués à évoluer souvent).
Enfin, les cas de tests manuels ont également d’autres avantages. Le fait qu’ils soient exécutés par un humain et non une machine permet d’apercevoir certains détails non vérifiés mais qui peuvent potentiellement être gênant (exemple : mauvaise ergonomie) ou des régressions non vérifiées par un cas de test automatisé. Enfin il existe aussi les tests « exploratoires », qui pour le moment ne peuvent être automatisés.
Encore une fois on est ici devant des choix et des compromis à faire. Automatiser oui ! Mais seulement ce qui est intéressant à automatiser. Les tests manuels sont toujours présents et nécessaire, et cela encore pour un certain temps.
BDD : Business Driven Development
Plus d’informations sur les tests exploratoires : http://referentiel.institut-agile.fr/exploratory.html
Pensez à rejoindre le groupe Le métier du test si le test 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
