Tests no-code : ce qu'ils ont résolu et ce qu'ils ont déplacé

Ce que les tests no-code ont réellement résolu

• L'accès à la création de tests. Une personne qui connaît le produit sans connaître de framework peut construire un test. C'est réel, et cela compte.

• La lisibilité pour les non-développeurs. Un flux visuel est lisible par un chef de produit là où un fichier de code ne l'est pas.

• Des premiers tests plus rapides. Le délai jusqu'à la première vérification qui fonctionne a nettement diminué.

Ce qu'ils ont déplacé plutôt que supprimé

Rien de tout cela n'est rédhibitoire. C'est ce qui donne à la promesse un goût d'inachevé, et c'est ce qui explique que tant de suites no-code s'essoufflent passé le premier trimestre.

L'hypothèse sous-jacente

Les plateformes no-code supposent une personne dont le métier est de construire des flux de test. Quand ce rôle existe, elles fonctionnent bien. Quand il n'existe pas, la plateforme tourne à vide, parce que les développeurs n'utiliseront généralement pas un éditeur visuel et qu'il n'y a personne d'autre.

Cette hypothèse qui ne se vérifie pas est de loin la raison la plus fréquente pour laquelle une suite no-code cesse de s'étoffer, et elle relève de l'organisation plutôt que de la technique.

Le problème de la passation

Cette catégorie d'outils connaît une défaillance qui lui est propre et qu'il vaut mieux anticiper, car elle survient d'un coup plutôt que progressivement.

Les flux visuels sont construits par une seule personne et restent lisibles par tout le monde, ce qui ressemble à l'inverse d'un problème de bus factor. Mais lisible n'est pas maintenable. Un flux de trente étapes, avec des branches conditionnelles et des variables partagées, est aussi enchevêtré que du code, et la personne qui l'a construit garde en tête une représentation de la raison d'être de chaque étape que l'éditeur n'affiche pas.

Quand elle s'en va, les flux continuent de s'exécuter jusqu'à ce que quelque chose change, et plus personne ne sait quelles étapes étaient porteuses. Le code, lui, s'accompagne au moins de commentaires et d'un historique de commits. La parade consiste à exiger sur chaque flux une courte description écrite de ce qu'il protège : cela paraît redondant tant que son auteur est là, et c'est la seule chose qui lui survit.

Ce que change la génération suivante

Décrire une vérification en langage courant et laisser un agent la construire et l'entretenir conserve l'accessibilité tout en supprimant complètement l'étape de création. Des étapes exprimées comme des intentions survivent par ailleurs aux refontes qui cassent les flux enregistrés, là où passait l'essentiel de la maintenance.

La contrepartie, c'est que vous relisez une couverture que vous n'avez pas construite vous-même, ce qui demande une compétence différente de celle de la construire.

Rien de tout cela n'exige un terminal. Créez un projet dans le tableau de bord TestSprite, décrivez la vérification en langage courant et pointez-la vers votre application. Les développeurs de votre équipe peuvent piloter la même chose en ligne de commande s'ils le préfèrent, ce qui se trouve dans le dépôt CLI.

Connectez le dépôt depuis le tableau de bord et les exécutions partent du déploiement que vous produisez déjà, ou ajoutez plutôt une étape à votre propre workflow.

Ce que change le fait de décrire une vérification

L'étape de création disparaît au lieu de devenir visuelle. Vous énoncez en langage courant ce qui doit être vrai et TestSprite détermine comment le vérifier, si bien que la couverture ne dépend plus de quelqu'un installé dans un éditeur à construire des flux.

La maintenance que le no-code avait déplacée plutôt que supprimée diminue elle aussi, parce que les étapes sont stockées comme des intentions et non comme des parcours enregistrés. Une refonte qui déplace un bouton ne casse pas la vérification, ce qui était le principal coût récurrent de la génération précédente.

Ce qu'on vous demande à la place, c'est de relire une couverture que vous n'avez pas construite vous-même. C'est une compétence différente de celle de la construire, et un investissement en temps bien moindre : voilà l'arbitrage à comprendre avant d'adopter l'une ou l'autre approche.