Aller au contenu principal
Produit et ingénierie

Mettre en quarantaine un test valable, c'est ainsi qu'un bug part en production

Les tests qui échouent parfois sont mis en quarantaine, et de vrais défauts se trouvent pendant cette quarantaine. Un test qui échoue une fois sur vingt exécutions peut être mal écrit, ou il peut exposer une condition de course qui finira par toucher un client.

Un test instable échoue en général indépendamment du code qu'il couvre, à certains moments, sur certains commits, sur certains runners, et d'une façon différente à chaque fois. Un vrai défaut intermittent est lié à quelque chose : un changement, un schéma de charge, ou un ordre.

Chaque erreur a un coût. Si vous mettez en quarantaine le test qui capte un vrai défaut, le défaut part. Si vous poursuivez un test vraiment instable, l'ingénieur perd une semaine.

L'agent enquête et énonce une position d'après ses preuves. Il ne désactive ni ne met rien en quarantaine. L'équipe qui possède le test prend la décision finale.

Comment l'agent est construit dans Agent Studio

L'entrée principale de l'agent est l'historique d'exécution, stocké dans PostgreSQL et récupéré comme dossiers d'échec complets plutôt que comme taux, parce que les taux masqueraient les schémas qui répondent à la question.

Les prompt skills listent les instabilités connues de l'infrastructure : composants courants, un processus plus lent, et une intégration qui a une limite de débit, pour que ces causes d'environnement n'exigent pas une enquête neuve chaque trimestre.

Le prompt système exige que chaque position énoncée comprenne des preuves qui pourraient la contredire. L'interprétation alternative ne tient que sous des conditions énoncées. L'agent doit dire si les données écartent cette alternative.

Si les preuves sont minces, l'agent ne décide pas. Si l'historique ne suffit pas, il le dit, et il nomme ce qui trancherait la question.

Un flux Start Scheduled rassemble les candidats. Le nœud Agent Chat reçoit le dossier d'échec, et les commits et les métadonnées de runner pour chaque occurrence.

Un nœud GitHub fournit le code source du test et ses changements les plus récents, parce qu'un échec de test après la dernière modification serait sinon un problème tout à fait différent.

Les résultats vont à Linear comme une entrée unique par test, avec l'argument pertinent. Un nœud Human in the Loop tient l'équipe propriétaire entre le constat et toute quarantaine.

De quoi cet agent est constitué

  • PostgreSQL (Data) : le dossier d'échec complet, pas un taux d'instabilité.
  • Prompt skills : les instabilités connues de votre infrastructure.
  • System prompt : une position énoncée avec ses contre-preuves.
  • System prompt : des preuves minces rapportées comme minces, avec ce qui les trancherait.
  • Agent Chat (Util) : dossier d'échec, et commits et métadonnées de runner par occurrence.
  • GitHub (Integration) : le code source du test et ses changements récents.
  • Quand un ActionFlow suffit : Si vous n'avez besoin que d'échecs groupés par signature et séparés en nouveaux contre récurrents, construisez le flux de travail. Ce flux de travail produit d'abord les candidats.

Questions fréquentes

Créer des workflows IA

Créez un compte gratuit, ouvrez un modèle ou une toile vide, puis lancez votre premier ActionFlow.

Newsletter

Recevoir les mises à jour produit

Nouveaux nœuds, agents et notes produit. Nous n'envoyons un e-mail que lorsqu'il vaut la peine de l'ouvrir.

Désabonnement à tout moment.