Assurance qualité : automatiser ou pas ?
Au cours des cinq dernières années, les tests automatisés ont considérablement évolué. Plusieurs entreprises d’automatisation ont vu le jour, développant des outils et des environnements qui rendent la technique plus accessible. Des outils et des frameworks à code source libre ont aussi vu le jour, soutenus par de vastes communautés qui offrent des réponses et des solutions aux problèmes récemment découverts.
Tout cela simplifie grandement la vie des ingénieurs de tests automatisés de nos jours. Mais cela signifie-t-il que nous pouvons automatiser tout ce que nous voulons ?
Oui et non : très souvent, l’automatisation est plus facile à dire qu’à faire. Les scénarios de tests qui étaient impossibles à automatiser il y a quelques années sont maintenant automatisables, mais ils peuvent requérir de considérables efforts, une certaine expertise et parfois même l’implication de l’équipe de développement. Ces facteurs peuvent rendre impraticable l’automatisation de tous les tests, d’où l’importance de déterminer dans quels cas les tests devraient être automatisés et si ça en vaut la peine. En effet, pour certains types de projets comme ceux à court terme, les tests automatisés n’ont tout simplement pas de sens. Cependant, ils sont le moteur de la livraison continue et des pratiques agiles.
Ce qui nous amène à la question suivante : quelle valeur ajoutée apporte tel ou tel scénario de test automatisé ? Est-ce que cela fera vraiment gagner du temps à tout le monde ? Cela nous donnera-t-il l’assurance que le code livré fonctionne et qu’il ne casse rien ? Je pense que c’est sans doute la considération la plus cruciale dans la définition et la sélection de ce que nous voulons automatiser dans notre processus.
Idéalement, cette décision devrait être prise par toute l’équipe, y compris les analystes d’affaires et les responsables du budget. Nous savons tous que la création de tests automatisés, comme la maintenance d’un système, n’est pas bon marché, de même que la maintenance ; mais si c’est important d’un point de vue d’affaires, alors vous obtiendrez le support nécessaire pour l’implémenter. Il est essentiel d’être agile dans ce processus : lorsque vous constatez que quelque chose tourne mal, arrêter dès les premières étapes pour réévaluer un projet vous permettra d’économiser beaucoup de temps, d’efforts et d’argent en fin de compte.
Exécuter des tests entièrement automatisés et simplement vérifier des rapports après est un rêve pour tout ingénieur AQ. Mais il est n’est pas possible pour l’instant d’automatiser tous les tests. Même dans les processus « entièrement » automatisés, où vous avez une multitude de tests, les développeurs consciencieux vérifient eux-mêmes les fonctionnalités et le code qu’ils veulent déployer. C’est ce qu’on appelle des tests manuels. Peut-être un jour aurons-nous une intelligence artificielle qui sera capable de trouver et/ou même de corriger tous les problèmes et bogues de l’application testée. Mais pour le moment, c’est encore une tâche intéressante et stimulante pour nous, les êtres humains.
