Lorsque, au fur et à mesure de l’avancement du projet le nombre de tests prend des proportions incompatibles avec le rythme des sprints et les contraintes de time-to-market, alors se pose la question de l’automatisation. Il existe pour cela sur le marché des automates de test.
Quelque soit celui sur lequel se portera votre choix, l’utilisation de ces outils nécessitent un certain savoir-faire qui ne se limite pas aux compétences en développement de scripts de test.
1er piège : Utiliser la fonction d’enregistrement automatique de l’automate de test.
C’est tentant, il suffit de cliquer sur le bouton rouge, d’exécuter le test et le tour est joué. Sauf qu’il est impossible d’obtenir des tests opérationnels de cette manière. D’abord parce que l’identification des objets graphiques est souvent insuffisamment discriminante. Du coup, lors de la prochaine livraison de l’application, le test ne fonctionnera plus parce qu’il ne reconnaîtra plus les objets. Ensuite parce que tôt ou tard, il vous faudra mettre les mains dans le script pour faire des adaptations, ne serait-ce que pour variabiliser le test. Et là vous serez face à du code généré automatiquement pas toujours très propre, ni très lisible.
2ème piège : Coder un script de test qui fait tout
C’est le penchant naturel de tout développeur de prévoir tous les comportements possibles de son programme. Typiquement vérifier un paramètre en entrée et prévoir un comportement différent de l’application selon la valeur de ce paramètre. Ce qui est légitime et louable pour le codage d’une application devient un travers pour l’automatisation parce que cela revient à faire plusieurs tests distincts avec le même script.
Il y a une règle d’or à respecter absolument dans le test, qu’il soit automatique ou manuel :
1 test = 1 parcours.
Le test doit être construit comme une histoire qui a un début, un cheminement et une fin. Les données fournies en entrée sont sélectionnées pour satisfaire ce parcours. Il n’y a donc aucun doute sur le comportement attendu de l’application.
Ce parcours unique totalement dépourvu de « if » et de « for » est la condition sine qua none pour une maintenance aisée et pour que les statistiques de test aient du sens. Et cela rend aussi plus aisé les investigations en cas de dysfonctionnement, que ce dysfonctionnement vienne d’un bug de l’application ou d’un incident extérieur (perte de connexion ou autre).
3ème piège : Se laisser séduire par le Data Driven Testing
C’est une antienne que vantent beaucoup d’outils mais dont l’intérêt est très limité. De quoi s’agit-il ? Le Data Driven Testing (DDT) repose sur l’utilisation d’un tableau pour alimenter les données en entrée du test et les données attendues en sortie. Malheureusement, dès lors que, d’un jeu de données à l’autre, le comportement de l’application change, cela abouti à un créer un test qui emprunte plusieurs parcours ce qui contrevient à la règle d’or citée ci-dessus. Très vite, si on se laisse aller dans cette dérive le test devient un programme qui teste une application. Chargé de boucles et de conditions ce programme de test devient si complexe qu’il devient indispensable de le tester ! Quant à sa maintenance … !
Le champ d’application du DDT est, et doit être, limité aux tests de type « boite noire » qui se caractérisent par le fait que le test n’interagit pas avec l’élément testé mais se contente d’appliquer des données en entrées et de vérifier les données produites. Parfait pour des tests simples qui vérifient par exemple des montants en fonction d’un taux de TVA. Sans intérêt pour des tests fonctionnels end-to-end qui naviguent dans une application.
En conclusion ce type de test trouve davantage sa place dans les tests unitaires qui ont pour objectif de vérifier des couches profondes de l’application.
4ème piège : Factoriser le code
Là encore, c’est un penchant naturel de tout développeur qui se respecte. C’est une bonne pratique que d’éviter la duplication de code et donc d’utiliser tous les moyens que permet le langage pour cela. En automatisation la factorisation ne doit pas être exclue mais maniée avec précaution. Si une factorisation couvre une portion de parcours trop importante, toute modification du comportement de l’application sur cette portion de parcours va concerner tous les tests qui utilisent cette factorisation. Certains outils d’aide à l’automatisation présentent cela comme un avantage au motif qu’il suffit de modifier la partie factorisée pour que tous les tests qui l’utilisent soient mis à jour. Malheureusement, dans la pratique la modification apportée entraîne souvent un changement de comportement de l’application. Du coup, soit ce n’est pas le cas et alors la mise à jour n’a aucun impact et ne sert à rien, soit c’est le cas et là , on a un problème.
Prenons l’exemple concret d’une mire de login : deux champs de saisie, « Email », « Mot de passe » et un bouton « Se connecter ». Vient une nouvelle version avec un lien « Mot de passe oublié ». L’ajout du lien n’a aucun impact sur tous les tests existants qui continuent de fonctionner comme avant. Dans ce cas précis la mise à jour de la portion factorisée n’a aucun intérêt puisque ces tests n’utilisent pas le nouveau lien. Alors à quoi sert cette mise à jour ? A rien !
Prenons un cas moins évident mais beaucoup plus courant. Dans le formulaire de la version 1 de l’application vous avez une liste déroulante ou un radio-bouton qui propose à l’utilisateur un choix entre les valeurs A et B. Vous avez fait 5 tests qui utilisent A et 5 qui utilisent B. Vient la version 2 de l’application dans laquelle un contrôle est appliqué sur le bouton de validation du formulaire lorsque la valeur B est utilisée. Concrètement, une case à cocher s’affiche lorsque B est sélectionné qu’il faut cocher pour rendre le bouton de validation cliquable. Et là vous êtes bien embêté. Vous avez la moitié de vos tests qui ne fonctionnent plus et vous ne pouvez pas les corriger sans casser l’autre moitié. Pour contrer ce problème vous serez tenté d’intégrer dans la portion factorisée les deux comportements. Et c’est ainsi que vous allez en venir à multiplier les parcours ce qui revient à mener plusieurs tests dans le même script.
5ème piège : Perdre de vue la démarche de test
Coder des scripts de test nécessite une double compétence, celle du développeur mais aussi celle du testeur. Or ces 2 compétences ont des impératifs contradictoires. La règle d’or du testeur qui impose « un test – un parcours unique » va à l’encontre des bonnes pratiques du développement comme nous venons de le voir dans les paragraphes ci-dessus.
Si c’est la compétence développeur qui domine, alors vous obtiendrez quelque chose qui ressemble à une application qui teste une application. Laquelle application devra être testée pour pouvoir tester l’application à tester. Autrement dit quelque chose de lourd, couteux, difficile à maintenir et qui n’empêchera pas les bugs de passer au travers.
Il est donc essentiel que ce soit la compétence testeur qui domine. Cela afin que la démarche de test ne soit pas perdue de vue, noyée dans la technicité de l’automatisation. Cette démarche de test doit permettre de relier les objectifs de test aux tests. Les objectifs de test regroupent les exigences fonctionnelles, les règles de gestion, les contraintes techniques, etc., c’est-à -dire tout ce qu’il faut tester. Ces objectifs de tests sont donnés en vue de la livraison d’une version de l’application à tester. Dans certaines situations la démarche de test doit intégrer des stratégies de priorisation ou de gestion du risque. Il est donc primordial que l’automatisation soit pilotée par la démarche de test et ne se fasse pas « en roue libre ».