Tester un site web avec un agent IA et obtenir des rapports de bogues reproductibles

Une page peut se charger correctement alors que son formulaire envoie des données erronées ou que sa navigation vous fait perdre votre travail. Indiquez à l’agent les opérations précises à essayer et le résultat attendu. L’essentiel est d’obtenir un compte rendu des tests et suffisamment d’éléments pour reproduire chaque échec.

Rédiger un descriptif de test pour un parcours utilisateur

Fournissez à Beeuni une URL d’aperçu accessible et décrivez le parcours. L’agent peut ouvrir le site dans son navigateur, passer d’une page à l’autre, remplir des champs et examiner le résultat. Pour un formulaire de contact, indiquez les règles de validation et le message de confirmation attendu. Utilisez des comptes de test et précisez où les soumissions peuvent être envoyées. N’utilisez pas de paiements réels ni de messages destinés à de vrais clients pendant ce test.

Open the preview URL in your browser and navigate to the contact form.
Use the supplied test account and synthetic form data.
Try required fields, invalid email, successful submission, and repeated clicks.
Record the browser and viewport used.
For each check, report expected behavior, observed behavior, and evidence.
Capture screenshots of failures and save a reproduction report.
Mark checks you cannot complete as blocked. Do not report them as passed.

Si la page n’est accessible que depuis votre ordinateur portable, le navigateur de l’agent doit disposer d’un aperçu accessible ou d’une connexion configurée explicitement pour y accéder.

Consulter le compte rendu des tests avant le résumé

Voici un exemple de compte rendu de test pour un formulaire de contact. Chaque ligne porte sur une vérification distincte ; le chargement réussi de la page ne dit rien sur le fonctionnement du formulaire.

Rédiger un rapport de bogue exploitable par une autre personne

Pour chaque échec, demandez l’URL, la version de la page si elle est connue, l’état initial, les étapes exactes, les données de test, le résultat attendu et le résultat observé. Joignez une capture d’écran si possible. Distinguez une erreur visible d’une explication de sa cause : un message de confirmation, à lui seul, ne prouve pas que le serveur a accepté des données invalides.

Recommencez les étapes qui ont échoué depuis une page ou une session vierge. Si l’échec est intermittent, consignez les tentatives infructueuses et ce qui a changé. Conservez les erreurs du navigateur comme éléments complémentaires, sans considérer que chaque avertissement en est la cause.

Voici un exemple de rapport concernant l’échec lié à l’adresse e-mail invalide. Remplacez les détails de l’environnement par l’URL d’aperçu et la version de la page que vous avez testées.

Title: Contact form shows success for an invalid email
Environment: supplied preview URL; record deployed version
Starting state: fresh page, signed out, empty form
Steps:
1. Enter Test user in the name field.
2. Enter test@ in the email field.
3. Enter Test submission in the message field.
4. Click Send once.
Expected: email error appears; form stays available for correction.
Observed: confirmation replaces the form.
Evidence: screenshot of confirmation; record browser and viewport.
Unknown: whether a contact record or email was created.

Le développeur doit encore vérifier si le serveur a rejeté la saisie malgré le message de réussite. Si l’agent est autorisé à consulter une boîte de réception de test ou un journal des soumissions, demandez-lui d’y faire une vérification. Sinon, indiquez que l’acceptation par le serveur reste inconnue.

Choisir les vérifications de régression en fonction de la modification

Si le correctif modifie la validation des adresses e-mail, vérifiez une adresse valide, une adresse vide et une adresse invalide. Incluez les formats explicitement pris en charge par votre produit, comme une adresse contenant un signe plus. Corrigez ensuite l’adresse invalide et soumettez le formulaire à nouveau. Une erreur impossible à faire disparaître constitue un problème d’utilisation distinct.

Si la modification touche à l’état de l’envoi, concentrez-vous sur les clics répétés et la reprise après échec. Le bouton redevient-il disponible après l’échec d’une requête ? Le retour depuis l’écran de confirmation conserve-t-il les anciennes valeurs ? Choisissez les vérifications en fonction du comportement concerné. Répéter une longue liste de contrôle après chaque petite modification risque de faire passer au second plan le cas qui nécessite une attention particulière.

Laissez une vérification avec l’état « bloqué » si elle n’a pas pu être exécutée. Un échec de connexion peut empêcher le lancement du test du formulaire ; il ne prouve pas que le formulaire est défectueux. Une modification de libellé ou de mise en page peut nécessiter une mise à jour des instructions de test. Consignez ces changements avec les résultats de la nouvelle exécution du test, afin qu’un lecteur ultérieur puisse distinguer une révision du test d’un correctif du produit.

Consignez la nouvelle version de la page et conservez le rapport précédent. Il s’agit d’une vérification fonctionnelle ciblée. L’accessibilité, la sécurité, les performances en charge et la compatibilité entre navigateurs nécessitent chacune un périmètre et des outils qui leur sont propres.

Pour déclencher des vérifications depuis votre propre outil de développement, consultez le guide du backend d’agent. Conservez le même descriptif de test et les mêmes champs de rapport lorsque vous passez de requêtes manuelles à une intégration.