Tests IA automatisés : deux sens, une erreur commune

Tests IA automatisés, premier sens : l'IA qui automatise vos tests

Une couverture générée à partir de votre produit, des étapes exprimées comme des intentions pour que les changements cosmétiques ne les cassent pas, des échecs restitués sous une forme directement exploitable pour les corriger. Le logiciel testé est ordinaire et déterministe ; l'IA se trouve dans l'outillage.

C'est ce que font la plupart des produits de cette catégorie, et c'est ce dont la plupart des équipes ont besoin.

Deuxième sens : tester un système qui contient de l'IA

Ici, c'est le produit lui-même qui est non déterministe. La même entrée produit une sortie différente : le « attendu égale obtenu » n'est plus disponible et il vous faut un autre type d'assertion.

L'erreur commune aux deux

Supposer qu'une vérification au vert signifie quelque chose sans avoir jamais confirmé qu'elle peut échouer. Dans le cas déterministe, cela produit des suites remplies d'assertions qui ne pourraient jamais passer au rouge. Dans le cas non déterministe, cela produit des harnais d'évaluation qui notent n'importe quoi favorablement.

Cassez quelque chose volontairement. Une minute suffit, et c'est la seule preuve que ces vérifications, dans un cas comme dans l'autre, sont bien reliées à ce qu'elles prétendent mesurer.

Tracer la frontière dans un produit mixte

La plupart des produits qui contiennent de l'IA n'en sont pas, pour l'essentiel, et le geste utile consiste à tracer explicitement la limite plutôt qu'à laisser le non-déterminisme se répandre.

Tout ce qui entoure la fonctionnalité est du logiciel ordinaire : l'authentification, le stockage, les limites de débit, l'interface qui affiche la sortie. Tout cela se teste de façon classique, et considérer l'ensemble du produit comme imprévisible parce qu'un composant l'est vous fait perdre beaucoup de couverture fiable et peu coûteuse.

À l'intérieur de la frontière, passez aux propriétés et aux taux. L'entrée arrive, la sortie varie, et ce que vous affirmez, c'est qu'elle a la bonne forme, qu'elle cite quelque chose de réel et qu'elle refuse ce qu'elle doit refuser. Écrire noir sur blanc, une bonne fois, où passe cette frontière est ce qui évite à une équipe de sur-tester les parties déterministes avec des méthodes statistiques ou de sous-tester la partie IA parce que les assertions exactes échouaient sans cesse.

Lequel des deux avez-vous

Si votre produit donnerait deux fois la même réponse, vous êtes dans le premier cas et vous voulez une couverture générée contre l'application en cours d'exécution. Sinon, vous êtes dans le second et il vous faut des assertions fondées sur des propriétés et des taux, plutôt qu'un simple réussi ou échoué.

Beaucoup de produits sont les deux à la fois : une application déterministe avec une fonctionnalité d'IA à l'intérieur. Testez normalement les parties déterministes et traitez la fonctionnalité d'IA comme un problème à part, au lieu d'étirer une seule approche sur les deux.

Le tableau de bord couvre le même terrain pour qui ne veut pas d'installation locale, et l'ensemble des commandes se trouve dans le dépôt du CLI.

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

Le sens couvert par TestSprite

Le premier. TestSprite utilise l'IA pour vérifier du logiciel ordinaire : une couverture générée à partir de votre produit, des étapes exprimées comme des intentions, une exécution contre l'application déployée, et un échec restitué sous une forme sur laquelle un agent de code peut agir.

Pour un produit qui contient une fonctionnalité d'IA, cela couvre tout ce qui l'entoure, c'est-à-dire l'essentiel du produit : l'authentification, le stockage, la limitation de débit, l'interface, les parcours que les utilisateurs empruntent réellement. Auto-Authentication, Dynamic Variables, Dependency Chains et Auto-Cleanup prennent en charge les problèmes d'état côté API.

La fonctionnalité elle-même demande des assertions fondées sur des propriétés et des taux, ce qui relève d'un autre harnais. C'est en traçant explicitement cette frontière que vous obtenez une couverture fiable et peu coûteuse sur la majorité déterministe, au lieu de traiter tout le produit comme imprévisible.