Comment tester votre application avant le lancement : plan pratique

Pour tester votre application avant le lancement, listez les quelques parcours qu'un utilisateur doit pouvoir mener à bien, faites-les tourner en tant que nouvel utilisateur sur un ordinateur et sur un téléphone, puis essayez les manières dont ils peuvent mal tourner : données vides, saisies incorrectes, second compte, connexion lente. Testez avec un soin particulier tout ce qui concerne l'argent ou les données privées, et reprenez les parcours principaux sur l'URL en ligne après publication. Terminez en observant quelqu'un qui n'a jamais vu l'application essayer de s'en servir.

Vous n'avez pas besoin d'une équipe QA ni d'un framework de test pour cela. Il vous faut une liste, une heure ou deux, et la discipline de la parcourir réellement.

Étape 1 : Écrire les parcours qui comptent

Un parcours est une tâche, du début à la fin, qu'un utilisateur vient accomplir. La plupart des applications en ont trois à six qui comptent vraiment. Pour une application de réservation :

1. S'inscrire et confirmer le compte
2. Trouver un cours et le réserver
3. Annuler une réservation
4. Payer un pass de cours
5. Personnel : voir les réservations du jour

Si vous avez rédigé des user stories, leurs critères d'acceptation sont déjà vos cas de test. Sinon, écrivez une ligne par parcours avec ce que signifie « réussi ».

Classez-les par priorité. Les parcours qui rapportent de l'argent ou que tout utilisateur emprunte (inscription, connexion, action principale) sont testés en premier et le plus souvent.

Étape 2 : Tester le parcours nominal en tant que nouvel utilisateur

Le « parcours nominal » est celui qui se déroule exactement comme prévu. Testez-le comme le vivrait un inconnu :

• Utilisez une fenêtre de navigation privée, pour ne pas être connecté et ne pas avoir de données enregistrées.
• Utilisez un compte neuf avec une vraie adresse e-mail que vous pouvez consulter.
• Partez de la page d'accueil ou d'un lien, pas d'une page mise en favori pendant la création.

Les nouveaux utilisateurs n'ont aucune donnée. Beaucoup de bugs n'apparaissent que lorsqu'une liste est vide, qu'un profil n'a pas de photo ou que rien n'a encore été acheté. Votre propre compte, rempli de données de test, les masque.

Étape 3 : Essayer de casser l'application

Refaites maintenant chaque parcours en faisant volontairement la mauvaise chose.

L'actualisation mérite une mention particulière : si l'application fonctionne lorsque vous cliquez, mais qu'une actualisation sur une page profonde affiche une 404, consultez comment corriger les erreurs 404 après un déploiement.

Étape 4 : Tester les droits d'accès avec deux comptes

C'est le test le plus important pour toute application avec des comptes, et celui qu'on oublie le plus souvent.

Créez deux utilisateurs normaux, A et B, et (si votre application en possède) un administrateur.

• En tant que A, créez un enregistrement. Connectez-vous en tant que B. B peut-il le voir, le modifier ou le supprimer ? Il ne devrait pas, sauf si c'est voulu.
• En tant que A, copiez l'URL d'un de vos enregistrements. Connectez-vous en tant que B et ouvrez cette URL directement.
• En tant qu'utilisateur normal, essayez d'ouvrir des pages d'administration en tapant leur URL.
• Déconnectez-vous complètement et refaites les mêmes essais avec les URL.

Si vous trouvez un problème ici, ne lancez pas avant de l'avoir corrigé. La vérification doit se faire sur le serveur, pas seulement en masquant un bouton. Notre liste de contrôle de sécurité pour les applications créées par IA va plus loin.

Étape 5 : Tester sur de vrais appareils

Ouvrez l'application sur un vrai téléphone, pas seulement dans une fenêtre de navigateur étroite.

• Pouvez-vous appuyer sur chaque bouton sans zoomer ?
• Le clavier masque-t-il le champ dans lequel vous écrivez ?
• Les tableaux et les contenus larges défilent-ils ou se replient-ils, au lieu de décaler la page sur le côté ?
• Le texte est-il lisible sans pincer l'écran ?

Essayez au moins un iPhone (Safari) et un téléphone Android (Chrome) si vous pouvez en emprunter. Safari en particulier a ses propres particularités avec les dates, les vidéos et les éléments à position fixe.

Étape 6 : Tester les paiements et les e-mails de bout en bout

Tout ce qui débite une carte ou envoie des e-mails doit faire l'objet d'un parcours complet.

Paiements. Utilisez le mode test de votre prestataire de paiement et ses numéros de carte de test. Vérifiez un paiement réussi, une carte refusée et un paiement annulé. Confirmez que la commande ou l'abonnement apparaît dans votre application après le paiement, et pas seulement dans le tableau de bord du prestataire. Si votre application repose sur des webhooks (messages que le prestataire de paiement envoie à votre serveur), vérifiez qu'ils arrivent sur l'application publiée, et pas seulement en développement. Ensuite, avant le lancement, passez aux clés réelles et effectuez un petit achat réel que vous rembourserez.

E-mails. Inscrivez-vous avec de vraies adresses chez deux ou trois fournisseurs différents. Vérifiez que les e-mails arrivent, ne tombent pas dans les spams, et que chaque lien pointe vers le domaine en ligne, et non vers une adresse d'aperçu.

Étape 7 : Vérifier la vitesse et les erreurs

• Ouvrez les outils de développement du navigateur (clic droit → Inspecter) et regardez l'onglet Console sur chaque page principale. Les erreurs en rouge méritent d'être corrigées, même si rien ne semble cassé.
• Chargez le site sur un téléphone en données mobiles, pas en Wi-Fi. Si le premier écran met plusieurs secondes, commencez par regarder la taille des images.
• Lancez un audit gratuit comme Lighthouse dans les outils de développement de Chrome pour un aperçu rapide des performances et de l'accessibilité.

Étape 8 : Tester l'application publiée, pas seulement l'aperçu

Un aperçu et une application publiée ne sont pas le même environnement. Avant d'en parler autour de vous, reprenez les parcours principaux sur l'URL en ligne :

• Toutes les variables d'environnement et tous les secrets sont-ils définis pour l'application publiée ?
• Utilise-t-elle la bonne base de données, avec les données attendues ?
• Les redirections après connexion et les liens des e-mails utilisent-ils le domaine en ligne ?
• Une actualisation sur une page profonde s'affiche-t-elle correctement ?

Étape 9 : Observer quelqu'un d'autre l'utiliser

Donnez à une ou deux personnes un objectif (« réserver un cours de yoga pour samedi »), pas des instructions. Observez sans aider, et notez les endroits où elles hésitent. C'est le moyen le plus rapide de repérer les formulations confuses et les boutons cachés. Pour une version plus poussée, voir comment organiser un test bêta.

Quand elles tombent sur un bug, notez-le proprement, avec les étapes, le résultat attendu et le résultat obtenu. Notre guide sur la rédaction d'un bon rapport de bug présente le format.

Utiliser l'IA pour vous aider à tester

Si vous construisez avec l'IA, vous pouvez lui demander d'aider à planifier et à exécuter les tests :

Liste les principaux parcours utilisateurs de cette application et, pour chacun, les cas limites les plus susceptibles de casser : états vides, saisies invalides, droits d'accès et actualisation. Présente-les sous forme de liste de contrôle que je peux parcourir.

Connecte-toi avec deux utilisateurs de test différents et vérifie si l'utilisateur B peut voir ou modifier quoi que ce soit créé par l'utilisateur A, y compris en ouvrant directement les URL des enregistrements de A. Signale ce que tu trouves avant de corriger quoi que ce soit.

Considérez le rapport de test de l'IA comme une première passe. Parcourez toujours vous-même les parcours liés à l'argent et aux droits d'accès.

Tester dans Mythex

Dans Mythex, la commande /test lance App Testing : l'agent pilote un navigateur sur votre aperçu en direct, parcourt les pages, prend des captures d'écran et signale les parcours cassés dans le chat. Elle fonctionne mieux avec un parcours précis, par exemple « teste l'inscription et la réservation d'un cours ». Corrigez ce qu'elle trouve avec /fix ou un message normal, puis relancez /test. App Testing utilise l'aperçu : vérifiez donc vous-même les parcours principaux sur l'URL publiée après la publication. Voir App Testing dans la documentation, et notre guide sur le débogage d'une application créée par IA pour les cas où quelque chose échoue.

Erreurs courantes

• Tester uniquement en tant que soi-même. Votre compte administrateur rempli de données masque les bugs d'états vides et de droits d'accès.
• Tester uniquement sur ordinateur. La plupart des visiteurs de nombreux sites arrivent depuis un téléphone.
• Oublier le second compte. La fuite de données entre utilisateurs est le bug le plus grave avec lequel une application puisse être lancée.
• Faire confiance à l'aperçu. L'application en ligne a d'autres paramètres : testez-la aussi.
• Corriger des bugs sans retester les zones voisines. Une correction sur un formulaire peut en casser un autre qui partage le même code.

Liste de contrôle avant lancement

• Parcours principaux listés et classés par priorité
• Chaque parcours réussi en tant que nouvel utilisateur, en fenêtre privée
• Saisies vides, invalides, trop longues et en double gérées
• L'actualisation fonctionne sur chaque page
• Les utilisateurs ne peuvent pas voir ni modifier les données des autres, même via l'URL
• Pages d'administration bloquées pour les utilisateurs normaux et les visiteurs non connectés
• Fonctionne sur un vrai iPhone et un téléphone Android
• Paiements testés : succès, refus, annulation, et l'application se met à jour ensuite
• Les e-mails arrivent, évitent les spams et pointent vers le domaine en ligne
• Aucune erreur rouge dans la console sur les pages principales
• Parcours principaux repris sur l'URL publiée
• Au moins une personne extérieure l'a essayée pendant que vous observiez

Questions