CabraFlow
Montrez votre métier, le test s'écrit.
Les outils de test d'interface se paient toujours quelque part. Les frameworks code-first sont réservés aux développeurs. Le record & playback classique enregistre des sélecteurs morts qui cassent au premier changement d'écran. Et les tests truffés de XPath passent plus de temps en réparation qu'en détection de bugs. Le point commun : le test capture le comment technique (un sélecteur) au lieu du quoi métier (une intention).
L'essentiel
- Quoi : un orchestrateur de tests keyword-driven au-dessus de Playwright, pensé pour qu'un profil fonctionnel crée un test aussi naturellement qu'un développeur.
- Le langage : des micro-phrases métier créées à la volée avec les mots de celui qui montre son métier (« Valider la commande urgente »), jamais un vocabulaire d'outil ni du code.
- Les cibles : résolues par l'arbre d'accessibilité (rôle et nom accessibles, comme un utilisateur ou un lecteur d'écran), sans CSS ni XPath. Un agent local propose la réparation quand l'interface change.
- La capture : une démonstration commentée à voix haute suffit : vous naviguez, vous expliquez, le flow s'écrit sous vos yeux. Transcription et réconciliation tournent en local.
- Rejouable partout : le même test s'exécute sur le runner natif, s'exporte en Playwright pur ou en Robot Framework, et se documente en cas de test ISTQB.
- Statut : programme R&D en phase de conception chez AI Cabra ; rien n'est annoncé qui ne soit exécutable et mesuré.
Le principe
Vous ouvrez votre application dans le navigateur piloté, vous activez le micro, et vous faites une démonstration de votre métier en la commentant : « je me connecte en tant qu'administrateur, je remplis le formulaire, je valide la commande ». Deux sondes travaillent en silence : l'une capte chaque geste avec son rôle d'accessibilité, l'autre transcrit la voix en local. Un moteur de réconciliation aligne les deux flux : la voix donne l'intention et le nom du mot-clé, le geste donne la cible technique. À la fin de la démo, le test existe : nommé dans vos mots, exécutable, robuste.
Trois façons de créer un test, un seul artefact
- Le fonctionnel fait une démo commentée à voix haute : les blocs de mots-clés apparaissent en direct pendant qu'il navigue.
- Le technico-fonctionnel assemble et affine les mots-clés dans un studio graphique : composition par blocs, paramètres typés, essai immédiat d'un mot-clé seul.
- Le développeur édite directement le fichier texte (YAML) dans son éditeur, avec autocomplétion, et voit le code Playwright généré s'il le souhaite.
Les trois portes mènent au même fichier, versionnable dans git comme du code. Et les agents IA y ont leur propre porte : la capture, le rejeu et la réparation sont exposés via MCP, le standard ouvert que nos outils utilisent déjà.
Ni fork, ni réinvention
CabraFlow ne forke ni Robot Framework ni Playwright : il emprunte les idées, pas le code. À Robot Framework, le principe keyword-driven et la composition de mots-clés. À Playwright, le moteur d'exécution et les localisateurs orientés utilisateur (rôle et nom accessibles). La différence : le vocabulaire visible n'est ni celui de l'outil ni du TypeScript, ce sont les mots de votre métier. Et personne n'est enfermé : une équipe Robot Framework rejoue les flows chez elle via l'export .robot, une équipe Playwright via l'export .spec.ts.
Où en est le programme
CabraFlow est un programme de R&D en phase de conception, mené selon la méthode AI Cabra : l'architecture et les critères de preuve d'abord, l'exécutable ensuite, la communication en dernier. Nous publierons des démonstrations exécutables et des mesures, pas des promesses. Pour en parler pour votre équipe QA, écrivez-nous.
Les questions fréquentes sur CabraFlow sont regroupées sur la page FAQ du site.
Parlons de votre chaîne de tests
Dites-nous où vous en êtes. Vous recevrez un avis, pas une plaquette.