Outils d'automatisation UI : trois catégories et ce que chacune présuppose

Les trois catégories d'outils d'automatisation UI

• Frameworks de code. Vous écrivez vos tests dans un vrai langage de programmation. Présuppose : des ingénieurs qui ont le temps de les écrire et de les maintenir.

• Enregistrement et low-code. Une personne construit des parcours dans un éditeur. Présuppose : quelqu'un dont le métier consiste à construire des parcours de test.

• Approche par agents. La couverture est générée puis affinée en langage naturel. Présuppose : que vous relirez une couverture que vous n'avez pas écrite.

Quelle hypothèse échoue le plus souvent

La deuxième. Les plateformes low-code sont conçues autour d'une fonction de test, et beaucoup d'équipes n'en ont plus. La plateforme est très bien, la licence est payée, et personne ne construit de parcours : la couverture cesse de progresser le mois où le dernier testeur est parti.

La première hypothèse échoue plus lentement. Les ingénieurs savent écrire des tests, mais cela entre en concurrence avec la livraison de fonctionnalités : la suite grossit le premier trimestre, puis s'arrête.

Des questions qui valent mieux qu'une grille de fonctionnalités

• Qui écrit le deux centième test ? Les dix premiers s'écrivent pendant l'évaluation. Posez la question pour le sixième mois.

• Que se passe-t-il quand l'UI est refondue ? C'est là que se situe le coût récurrent, et la réponse diffère nettement d'une catégorie à l'autre.

• À quoi ressemble un échec pour la personne qui doit le corriger ? De plus en plus souvent, c'est un agent de codage, qui ne sait pas interpréter une capture d'écran.

• Une exécution qui n'a jamais atteint ses assertions est-elle rapportée comme réussie ? Cela vaut la peine d'être vérifié volontairement, car la réponse est parfois oui.

Le coût qui n'apparaît pas dans le comparatif

Chacune de ces catégories comporte un coût permanent que les éditeurs ne chiffrent pas, parce qu'il dépend de vous et non d'eux : le coût de décider quoi couvrir.

Avec un framework de code, quelqu'un écrit le test, ce qui suppose que quelqu'un a d'abord décidé que ce test devait exister. Avec un éditeur low-code, c'est pareil. Avec une couverture générée, la décision se déplace vers la relecture d'un plan : plus rapide, mais pas gratuit, et souvent sauté, d'où le mode d'échec de la couverture que personne n'a lue.

Quel que soit votre choix, budgétez ce coût explicitement. Une heure par semaine passée par quelqu'un à regarder ce qui est couvert et ce qui ne l'est pas, c'est la différence entre une suite qui reflète votre produit et une suite qui reflète ce qu'il était commode d'automatiser il y a dix-huit mois.

Comment évaluer

Cassez quelque chose volontairement. Introduisez une vraie régression, par exemple un enregistrement qui ne persiste plus, et observez ce que remonte chaque candidat. S'il échoue, si l'échec nomme l'écart, et si la personne chargée de corriger pourrait partir de cette sortie. Cet unique exercice vous en apprendra plus qu'un mois de comparaison de fonctionnalités.

Si vous préférez ne rien installer, le tableau de bord fait la même chose. Tout ce que la ligne de commande sait faire par ailleurs se trouve dans le dépôt CLI.

Deux voies, et le choix porte en réalité sur qui est propriétaire du pipeline. Connecter la GitHub App depuis le tableau de bord ne demande aucune modification de votre dépôt, puisqu'elle réagit au déploiement que votre build produit déjà. Ajouter une étape GitHub Actions place le contrôle dans le dépôt, où il est relu comme le reste du build.

L'hypothèse que fait TestSprite

Que vous relirez une couverture que vous n'avez pas écrite vous-même. C'est le compromis : aucun auteur n'est nécessaire, et en échange quelqu'un lit le plan et le corrige.

Concrètement, les cas sont générés à partir de votre produit, les étapes sont exprimées comme des intentions afin de survivre aux refontes, et un échec revient sous la forme de ce qui a été tenté, de ce qu'a fait l'application et de l'endroit où les deux ont divergé, ce sur quoi un agent de codage peut agir aussi facilement qu'une personne.

Pour une équipe sans fonction de test dédiée, cette hypothèse est plus facile à satisfaire que les deux autres, parce que relire un plan prend une heure par semaine là où écrire une suite demande un poste. Si vous avez ce poste, un framework de code vous servira peut-être mieux, et la façon honnête de choisir consiste à se demander quelle hypothèse votre équipe pourra réellement tenir dans un an.