Projets, environnements, cas de test, étapes, exécutions, résultats, problèmes et mémoire.

Autonomy emploie partout le même petit vocabulaire : dans le tableau de bord, les notifications, l'API et les assistants IA. Cette page en donne les définitions.

Projets

Un projet est un produit que vous testez, comme une application web, une application mobile ou une API. Tout ce que vous testez vit dans un projet : ses cas de test, ses plans de test, ses environnements, ses connexions, ses problèmes, ses digests, sa mémoire et ses fichiers.

Votre organisation se situe au-dessus de ses projets. Les membres, la facturation, le crédit d'exécution et les intégrations appartiennent à l'organisation et sont partagés par tous les projets. Voir Projets.

Environnements

Un environnement est un endroit où un projet s'exécute, comme Production, Staging ou un déploiement de prévisualisation. Il possède une cible de plateforme pour chaque plateforme testée : une URL pour le web et l'API, un build d'application pour Android. Les tests iOS arrivent bientôt.

Chaque exécution a lieu dans un environnement. Le même cas de test s'exécute sur n'importe quel environnement de son projet, car c'est l'environnement qui fournit l'URL, le build et les valeurs.

Les valeurs d'environnement sont des valeurs nommées, utilisées dans les étapes sous la forme {{env.NAME}}. Chaque exécution les renseigne à partir de l'environnement dans lequel elle s'exécute. Marquez une valeur comme secret pour les mots de passe et les jetons : personne ne peut plus la consulter après l'enregistrement, et seules les exécutions la reçoivent. Voir Environnements.

Cas de test et étapes

Un cas de test est un parcours dont vous voulez prouver qu'il fonctionne, rédigé sous forme d'une courte liste d'étapes. Chaque étape est un résultat attendu formulé en langage courant : quelque chose qu'une personne pourrait vérifier une fois l'étape terminée.

Un nouveau compte producteur existe pour une adresse e-mail inédite.
Le profil indique Maïs comme culture préférée.
L'e-mail de reçu arrive avec le montant total de la commande.

Les étapes n'indiquent pas où cliquer. L'agent détermine comment atteindre chaque résultat attendu sur le produit en ligne, comme le ferait un testeur attentif, et montre tout ce qu'il a fait.

Une étape peut comporter des pièces jointes : ce dont l'agent se sert pour atteindre le résultat attendu.

Pièce jointe	Ce qu'elle apporte à l'agent
Compte	Une connexion enregistrée à utiliser.
Boîte de réception	Une nouvelle boîte de réception pour l'exécution, pour recevoir codes, liens et reçus.
Téléphone	Un numéro de téléphone qui peut recevoir des codes SMS.
Fichier	Un fichier à téléverser.
Capture d'écran	Une capture d'écran du résultat atteint, à conserver comme preuve.
Données	Une valeur à utiliser, une valeur à générer (comme un mot de passe robuste) ou une valeur masquée.

Les pièces jointes sont des données de test, sauf si vous les marquez Exact. Si le produit refuse une valeur de test uniquement parce qu'elle est déjà prise, l'agent utilise une nouvelle valeur du même type et le signale. Une valeur Exact est utilisée telle quelle : si le produit la refuse, c'est sur ce refus que l'étape est jugée. Voir Rédaction.

Plans de test

Un plan de test est une sélection nommée de cas de test au sein d'un projet. Exécuter un plan lance une exécution par cas de test, regroupées ensemble. Un cas de test n'a pas besoin de plan, et le même cas de test peut figurer dans plusieurs plans. Voir Plans de test et planifications.

Exécutions

Une exécution est le passage d'un cas de test dans un environnement. C'est la seule source de preuves dans Autonomy : rien n'est affirmé sur votre produit qu'une exécution n'ait constaté.

L'agent traite les étapes dans l'ordre. Sous chaque étape, vous voyez ses Step Actions : chaque action que l'agent a effectuée pour atteindre le résultat attendu, au moment où elle a lieu. Les valeurs que l'exécution a produites ou reçues, comme un mot de passe généré ou un code reçu par e-mail, sont affichées telles quelles. Seules les valeurs que vous avez enregistrées comme secrets sont renseignées par référence : l'agent ne les voit jamais, et elles n'apparaissent jamais dans les preuves.

Chaque étape se termine par une Final check : un nouveau regard sur le produit à la fin de l'étape. Le résultat d'une étape doit concorder avec sa Final check, et sans preuve récente, une étape n'est jamais marquée comme réussie.

Résultats d'exécution

Chaque étape reçoit un résultat : réussie ou échouée. Le résultat de l'exécution découle de celui de ses étapes.

Résultat	Signification
Queued	En attente d'un runner disponible.
Running	En cours. Avant la première étape, l'exécution affiche Getting ready.
Passed	Chaque étape a atteint son résultat attendu, et chaque Final check concorde. flaky signifie qu'une étape a dû être relancée.
Failed	Une étape n'a pas atteint son résultat attendu, ou l'agent n'a pas pu montrer qu'elle l'avait atteint : par exemple, l'étape a manqué de temps ou un compte n'a pas pu se connecter. Chaque étape échouée en donne la raison, en termes simples.
Couldn't start	L'environnement n'a pas pu être testé, donc aucune étape ne s'est exécutée : par exemple, l'application ne s'est pas ouverte ou a bloqué le navigateur de test comme un robot. Elle n'est pas facturée.
Cancelled	Quelqu'un a arrêté l'exécution.

Une exécution est Failed si une étape a échoué, et Passed quand toutes les étapes ont réussi. Une étape ne réussit que si des preuves récentes montrent son résultat attendu : une étape que l'agent n'a pas pu prouver est donc Failed, avec sa raison. Le taux de réussite exclut les exécutions Couldn't start.

Runner problem. Si une exécution échoue parce que quelque chose a cassé du côté d'Autonomy, par exemple le modèle d'IA était indisponible, le runner a planté ou son navigateur ou son appareil s'est arrêté, Autonomy la relance une fois, automatiquement. Si la seconde tentative casse de la même façon, l'exécution est Failed avec une étiquette Runner problem. Les tentatives en Runner problem ne sont pas facturées.

Voir Exécutions et résultats pour le contenu d'une page d'exécution.

Problèmes

Un problème est un défaut de votre produit, signalé par une personne ou détecté par Autonomy. Son type est Bug (quelque chose est cassé) ou Risk (une lacune ou un point d'attention ; rien n'est encore cassé).

Les problèmes sont tenus à l'écart des résultats. Une exécution réussie peut tout de même signaler un problème, comme une erreur de console ou une requête en erreur constatée en chemin, et un problème ne modifie jamais le résultat d'une étape ou d'une exécution. Vous pouvez transformer un problème en ticket dans Linear ou Jira. Voir Problèmes.

Mémoire

La mémoire rassemble ce que l'agent sait sur la façon d'atteindre les choses dans votre projet : où une page a été déplacée, quel e-mail est lent, ce qu'il faut attendre. Les exécutions suggèrent des entrées de mémoire, et les personnes peuvent en ajouter. La mémoire n'ajoute jamais d'étapes, n'enregistre jamais de bugs et ne change jamais un résultat. Les connaissances produit sont un briefing que vous rédigez pour l'agent, comme pour un nouveau testeur. Voir Mémoire.

Où tournent les exécutions

Les exécutions tournent sur les runners d'Autonomy : les machines qui hébergent le navigateur, l'appareil ou le client HTTP qu'utilise une exécution. Chaque exécution démarre déconnectée, avec une session de navigateur ou d'application vierge. Les offres Enterprise peuvent aussi s'exécuter sur leurs propres machines. Voir Runners auto-hébergés.

Une note sur les noms

Le tableau de bord, l'API et cette documentation disent cas de test pour le parcours qui s'exécute et plan de test pour une sélection de cas de test. Quelques identifiants d'API portent encore d'anciens noms ; quand cela compte, la page le précise.

Concepts clés