Les ingénieurs QA de SpaceWeb confient l'écriture des autotests à l'IA : un script fonctionnel en 50 minutes

Tout QA connaît ce calcul : il y a plus de fonctionnalités que de bras, les releases brûlent et la moitié de la journée part dans des cas de test répétitifs et des « squelettes » d'autotests. Evgenia Myasnikova, ingénieure QA chez SpaceWeb, et Vitaly Kireev, responsable R&D, ont voulu vérifier quelle part de cette routine on peut honnêtement confier à un LLM, et où il se contente de générer du blabla qu'on finit de toute façon par réécrire à la main.

Trois tâches pour l'IA et un choix important

L'équipe n'a pas cherché à tout automatiser d'un coup. Trois axes ont été retenus : la documentation et les données de test (vérifications positives, négatives et aux limites, plans de test, checklists), les scripts d'automatisation, ainsi que l'extension des contrôles de sécurité et d'API. Le principe est simple : l'IA produit un brouillon, et le testeur le lit, le complète et le débogue.

Le principal choix pratique concerne les données. En raison d'informations sensibles, l'agent a été connecté au modèle local Qwen3.8-27B. Pour la documentation et le code, on a utilisé un assistant interne, et le tout tournait sur la stack habituelle : Postman, Python, Pytest et Selenium. Si vous travaillez avec du code fermé et des schémas d'API internes, un cloud externe n'est pas indispensable pour ce type de travail.

Pour les formulaires, cela se présente ainsi. On charge dans le modèle les préconditions, les exigences de caractère obligatoire des champs et de validation, et l'on obtient en sortie un tableau de vérifications positives, puis négatives. Pour l'intégration avec GitHub/GitLab, l'IA a en outre mis en évidence les scénarios les plus critiques. Pour l'API, on a donné à l'agent un exemple de JSON valide pour la création d'un VPS et on lui a demandé de préparer des données : requêtes minimales et de référence, valeurs limites, domaines en cyrillique, caractères spéciaux et cas invalides, comme la création d'un serveur dans une région inexistante.

Il faut toutefois lire le résultat attentivement. Dans l'un des exemples, le nom d'hôte est décrit comme « exactement 63 caractères », alors que la chaîne est nettement plus longue, et une espace s'est glissée dans une adresse IPv6. Pour un test aux limites, cela peut être voulu, mais il est plus sûr de vérifier ces points manuellement.

Un autotest en moins d'une heure

Le cas le plus parlant est l'automatisation de la création d'une boîte mail dans le panneau d'hébergement. Le prompt est détaillé étape par étape et contient tout ce que sait la personne devant l'écran : Pytest, Selenium, Chrome, authentification depuis conftest.py, sélecteurs exacts, règles de mot de passe (8 à 20 caractères, lettres, chiffres, caractères spéciaux) et redirection attendue vers la page review. Le modèle a livré un test_mail_add.py prêt à l'emploi, avec commentaires, attentes explicites via WebDriverWait et vérifications du résultat.

Ensuite, la tâche a été compliquée : on a demandé de paramétrer le test pour différents noms de boîte. Cela a donné deux tests : test_create_valid_mail_box et test_reject_invalid_mail_box. Les jeux positifs vérifient des longueurs de 1 et 64 caractères, des caractères spéciaux et des chiffres. Les jeux négatifs vérifient les majuscules, les espaces, la barre oblique et une longueur de 65. Si un cas échoue, on voit tout de suite quel scénario est cassé.

Côté temps : environ 30 minutes pour le prompt et la recherche des sélecteurs, 20 de plus pour le débogage. Ce n'est pas « un clic et c'est fini », mais pour un squelette de routine, le résultat est bon.

Les limites sont aussi visibles dans le code. Dans le test négatif, l'IA ne savait pas comment le système réagit à une erreur ; elle a donc proposé deux variantes : soit le front-end affiche l'erreur, soit le formulaire part et il n'y a pas de redirection. La seconde variante est restée commentée, et le comportement a dû être précisé par un humain.

De plus, dans le test positif, un suffixe aléatoire est ajouté aux noms qui ne se terminent pas par un chiffre. À cause de lui, le cas « exactement 64 caractères » devient un nom plus long que la limite, ce qui casse de fait la vérification aux limites. Seule la relecture permet de détecter ce genre de problème.

IDOR : un début, mais pas encore de résultats

Le troisième cas porte sur la sécurité de l'API. Il s'agissait de vérifier l'IDOR dans la méthode edit (JSON-RPC) : le champ service_ref sert d'identifiant direct de l'objet, et le serveur doit vérifier que l'utilisateur dispose des droits sur celui-ci. L'agent a immédiatement proposé une vérification de base : envoyer la même requête avec le service_ref d'un autre utilisateur. Ensuite, l'équipe lui a demandé d'écrire avec Requests un script qui parcourt les valeurs d'un fichier TXT contenant des identifiants de services tiers.

Dans la partie accessible de la publication, le texte s'interrompt à cette étape ; il n'y a donc pas de résultats finaux sur l'IDOR. Il ne faut pas en conclure que l'IA a trouvé ou non de véritables vulnérabilités.

Ce qu'il faut retenir en pratique

• Donnez au modèle un contexte structuré : préconditions, schéma de la méthode, exemple de JSON valide, sélecteurs concrets. La qualité du résultat dépend du prompt.
• Traitez la sortie comme un brouillon. Vérifiez les valeurs limites, le comportement attendu en cas d'erreur et les localisateurs.
• Pour les données sensibles, déployez un modèle local : SpaceWeb a montré qu'un scénario fonctionnel est possible avec lui aussi.
• Commencez par la routine : cas de test, données de test, squelettes de tests d'interface. C'est là que le gain est le plus net.

La conclusion honnête est la suivante : l'IA ne remplace pas l'ingénieur QA, mais elle lui retire la partie la plus mécanique. Le contrôle qualité reste entre les mains de la personne qui sait comment le système doit se comporter.