- Transformez les commentaires des utilisateurs en un plan d'action concret pour les tests et la correction des bogues à l'aide d'un cadre systématique.
- Utilisez le débogage assisté par IA et appliquez le modèle « teach me » pour comprendre les corrections.
- Écrire des tests simples pour vérifier que les corrections fonctionnent et détecter les problèmes de régression potentiels.
- Utilisez les outils de développement du navigateur pour identifier et diagnostiquer les problèmes.
- MVP débogué : votre application MVP avec les bogues P0/P1 corrigés
- Système de triage des commentaires : un plan d'action hiérarchisé utilisant le cadre à trois questions et la méthode MoSCoW.
- Suivi des problèmes : documentation structurée des bogues, des causes profondes et des corrections
- Liste de contrôle des tests : documentation pour la prévention des régressions et le suivi des problèmes
- Les étudiants ont réalisé un MVP fonctionnel (écrans, navigation, fonctionnalité IA) en Construire votre prototype alimenté par l'IA
- Les étudiants ont terminé Itération et perfectionnement de votre MVP à l'aide des commentaires issus des tests utilisateurs réalisés auprès de 5 à 10 utilisateurs.
À ce stade, vous avez développé un MVP basé sur l'IA et testé les cas limites avant de le partager. Vos utilisateurs réels ont désormais essayé votre application et vous ont fait part de leurs commentaires. Certaines fonctionnalités fonctionnent très bien. D'autres peuvent dérouter les utilisateurs ou présenter des dysfonctionnements inattendus. C'est tout à fait normal. Toutes les start-ups passent par là.
Comme vous l'avez vu dans la section « Itérer et affiner votre MVP », il est essentiel de recueillir et de synthétiser les commentaires des utilisateurs pour affiner votre MVP. Le défi consiste désormais à transformer ces commentaires en corrections de code. Lorsque les utilisateurs signalent que « cela ne fonctionne pas », nous devons identifier le problème spécifique et réparable. Lorsque nous trouvons un bug, nous devons non seulement comprendre comment le corriger, mais aussi pourquoi la correction fonctionne, afin de minimiser les risques de récidive.
Dans cette unité, nous aborderons une approche systématique du débogage qui vous aidera à gagner en rapidité et en confiance. Vous utiliserez le débogage assisté par IA, non pas pour écrire du code à l'aveuglette, mais pour vous aider à comprendre ce qui se passe et pourquoi. Vous apprendrez également à écrire des tests pour détecter les problèmes avant que vos utilisateurs ne le fassent.
Du retour d'information au plan d'action
Les commentaires des utilisateurs sont précieux, mais ils sont souvent présentés sous une forme désordonnée.
- « L'application a planté » peut signifier que le bouton n'a rien fait, que la page s'est figée ou qu'une erreur est apparue.
- « Je n'arrivais pas à comprendre » peut signifier que les étiquettes étaient mal faites, que les instructions manquaient ou que le processus était confus.
Dans la section « Itérer et affiner votre MVP », vous avez passé du temps à tester votre MVP auprès des utilisateurs et à recueillir leurs commentaires. Vous avez ensuite classé par ordre de priorité et catégorisé les problèmes qui ont été mis en évidence.
Tout au long de cette unité, nous utiliserons la même application exemple que dans les unités précédentes, TutorMatch, une plateforme destinée aux étudiants qui les aide à identifier le type de tuteur dont ils ont besoin en fonction de leurs difficultés d'apprentissage, construite avec React et Javascript. TutorMatch a été développé dans Github Codespaces. Vous travaillerez avec VOTRE PROPRE MVP ET VOS PROPRES COMMENTAIRES pour cette activité. Les exemples TutorMatch sont présentés à titre de référence uniquement.
ACTIVITÉ 1
Construisez votre système de triage des commentaires
Durée estimée : 20 minutes
Nous allons créer un système permettant de classer les commentaires des utilisateurs et de les transformer en un plan d'action hiérarchisé. Cela nous permettra de gagner du temps en matière de débogage, car nous traiterons en priorité les problèmes les plus importants, et non ceux que nous remarquons en premier ou que nous avons tendance à vouloir résoudre en priorité.
1. Ouvrez Github et Codespaces.
Ouvrez votre référentiel sur Github et ouvrez votre espace de code.
Si vous disposez encore d'une branche de référentiel ouverte, utilisez cette branche et cet espace de code.
Sinon, créez une nouvelle branche. Ouvrez le même espace de code que vous avez utilisé auparavant, mais vous devrez changer de branche en tapant ces commandes dans la fenêtre du terminal.
git pull origin main
git checkout nouveau-nom-de-branche
git checkout -b nouveau-nom-de-branche
2. Recueillir les commentaires des utilisateurs lors des tests
Dans le cadre de vos tests utilisateurs, vous avez classé les problèmes par ordre de priorité et les avez catégorisés à l'aide de la feuille de calcul « Analyse des tests ».
Trouvez ces informations dans votre feuille de travail, car vous en aurez besoin pour cette activité.
3. Demandez à Copilot de vous aider à organiser les problèmes
Nous documenterons ici les problèmes et le plan d'action à l'aide d'un outil de suivi des problèmes.
- Dans votre espace de code, créez un nouveau dossier nommé test et un nouveau fichier appelé issue_tracker.md . Vous pouvez le faire dans le panneau Explorateur de fichiers (cliquez sur l'icône Nouveau fichier).
- Demandez à Github Copilot de fournir un ensemble structuré et classé de problèmes en lui fournissant vos principaux problèmes P0/P1 issus de vos tests. Vous pouvez utiliser ce modèle :
Je débogue mon application en fonction des commentaires des utilisateurs. Aidez-moi à créer des descriptions structurées pour chaque problème.
Pour chaque question ci-dessous, veuillez fournir :
- **Résumé :** Description en une phrase
- **Catégorie :** Bug, ergonomie, fonctionnalité manquante ou amélioration
- **Ce que l'utilisateur a vécu :** ce qu'il a vu ou n'a pas vu
- **Causes possibles :** 2-3 hypothèses expliquant pourquoi cela s'est produit (numérotées)
- **Par où commencer :** quel fichier ou quelle section de code examiner
- **Approche corrective suggérée :** un point de départ (et non une solution complète)
Voici mes problèmes :
- Copiez et collez vos principaux problèmes P0/P1 au bas de l'invite. Vous pouvez inclure ce que vous avez déjà dans votre tableau dans la feuille de calcul.
- Lisez ce que Copilot génère. Pour chaque problème, posez-vous les questions suivantes :
- Les causes possibles sont-elles plausibles pour MON application ?
- « Où chercher en premier » pointe-t-il vers la bonne partie de mon code ?
- Si quelque chose vous semble anormal, signalez-le à Copilot. Par exemple : « Pour le problème n° 1, mon application utilise React et l'API Groq. L'erreur se produit lorsque l'utilisateur soumet le formulaire. Pouvez-vous revoir les causes profondes ? »
- Une fois que vous êtes satisfait, copiez les descriptions affinées dans votre fichier issue_tracker.md et enregistrez le fichier.
4. Mettre en scène et valider les modifications sur Github
Stagnez et validez vos modifications dans la branche de votre référentiel.
Le modèle « Teach Me » (Apprends-moi)
Lorsque quelque chose ne fonctionne plus, nous pouvons être tentés de coller l'erreur dans l'IA et de lui demander de « corriger cela ». L'IA vous fournira généralement un code qui fonctionne (en particulier si vous utilisez les modèles Gemini 3 ou des LLM puissants similaires). Mais vous ne comprendrez pas pourquoi ni comment, ce qui signifie que la prochaine fois qu'un problème similaire se présentera, vous risquez de vous retrouver à nouveau bloqué.
Le modèle « Teach Me » peut changer cela. Au lieu de demander à l'IA de corriger le problème, vous lui demandez d'abord de l'expliquer. Vous ajoutez une instruction à vos invites :
Avant de me donner un code, expliquez-moi les causes potentielles du problème et pourquoi chaque solution pourrait fonctionner. Il est important de ne pas mettre à jour le code avant d'avoir décidé de la meilleure approche à adopter. Mon objectif est de comprendre le problème, pas seulement de le résoudre.
Cette instruction transforme la manière dont l'IA répond. Bien que Copilot soit généralement très doué pour montrer son processus de réflexion et mettre en évidence les modifications apportées au code, demander explicitement une explication avant de mettre à jour le code est un excellent moyen d'apprendre afin de ne pas répéter les mêmes erreurs.
Sans le modèle « Teach Me »
Vous : Mon application affiche « Aucune réponse » lorsque je clique sur « Obtenir des recommandations ». Corrigez cela.
IA : Ajout de 3 lignes à la ligne 61. Le backend a été mis à jour pour vérifier les erreurs de l'API Groq dans la réponse et renvoyer les détails de l'erreur (y compris les codes d'erreur) au frontend au lieu d'afficher par défaut « Aucune réponse ».
C'est rapide, mais vous n'obtenez pas d'explication complète sur ce qui se passe et sur le véritable problème.
Avec le modèle « Teach Me »
Vous : Mon application affiche « Aucune réponse » lorsque je clique sur « Obtenir des recommandations ». Avant de me donner un code, expliquez-moi ce qui cause ce problème, identifiez les causes possibles, élaborez un plan de correction et expliquez-moi pourquoi la solution proposée pourrait fonctionner. Je veux comprendre le problème, pas seulement le résoudre.
IA : La question clé :
fetch ne génère PAS d'erreurs HTTP.
Donc, ce code :
fonctionnera parfaitement même si Groq revient :
401 (clé API incorrecte)
429 (limite de débit)
400 (nom de modèle incorrect)
Dans ces cas, Groq renvoie un erreur JSON, pas choices, donc cette ligne :
retombe à "No response."
L'application affiche le message « Groq n'a pas répondu», alors qu'en réalité, il a répondu, mais avec une erreur.
La solution : ajouter une vérification explicite de l'état immédiatement après la récupération:
Ensuite, analysez le JSON uniquement s'il est correct.
DevTools
Chaque navigateur dispose d'outils de développement intégrés. outils de développement qui vous permettent de voir ce qui se passe en arrière-plan. Vous avez utilisé DevTools brièvement dans la boîte à outils du fondateur pour afficher localStorage. Vous allez maintenant utiliser des onglets supplémentaires :
- Onglet Console – Affiche les erreurs JavaScript et les messages de journal générés par votre application. Les messages rouges correspondent à des erreurs. Les messages jaunes correspondent à des avertissements.
- Onglet Réseau – Affiche toutes les requêtes envoyées par votre application à des services externes (comme l'API Groq). Indique les codes d'état et les données de réponse.
- Onglet Éléments – Affiche la structure HTML et les styles CSS de votre page. Utile pour diagnostiquer les problèmes de mise en page et d'affichage.
Ensemble, ils peuvent mettre en évidence des problèmes que les utilisateurs ne peuvent pas facilement détecter, et vous pouvez les utiliser pour obtenir les preuves nécessaires pour les résoudre.
Dans l'activité suivante, vous allez résoudre vos principaux problèmes en utilisant le processus que vous avez mis en place : commencez par votre liste classée par catégories, formulez une hypothèse, utilisez le modèle « Teach Me » (Apprenez-moi) pour comprendre la cause profonde, puis appliquez la solution.
ACTIVITÉ 2
Le modèle de débogage « Teach Me » (Apprends-moi)
Durée estimée : 30 minutes
1. Ouvrez votre espace de code et votre outil de suivi des problèmes.
- Ouvrez votre espace de code de l'activité 1.
- Localisez le fichier issue_tracker.md contenant vos problèmes P0 et P1 et ouvrez-le.
- Commencez par votre problème P0 le plus important qui a été classé comme bug. Si vous n'avez pas de P0, commencez par votre P1 le plus important, mais il doit s'agir d'un problème identifié comme une erreur ou un bug.
2. Reproduisez le bug et documentez ce que vous observez.
- Exécutez votre application en tapant npm run dev (si l'application est React/JS) dans la fenêtre du terminal.
- Si le bug/problème concerne un problème backend, tel qu'un appel API, démarrez également votre serveur backend. Tapez npm run dev depuis le dossier serveur dans une autre fenêtre de terminal.
- Essayez de reproduire le problème en suivant exactement les instructions du testeur ou vos notes indiquant la cause du problème.
- Notez précisément ce qui se passe :
- La page devient-elle blanche ?
- Un bouton ne sert-il à rien ?
- Un message d'erreur apparaît-il ?
- Si vous voyez un message d'erreur dans l'application elle-même ou dans l'une des fenêtres du terminal (application ou serveur), copiez le texte exact. Ce détail rendra les étapes suivantes beaucoup plus efficaces.
3. Utilisez DevTools pour recueillir des preuves
- Dans la fenêtre du navigateur de l'application, ouvrez DevTools (F12 ou clic droit -> Inspecter).
- Pour tout problème, commencez par la console :
- Cliquez sur l'onglet Console.
- Tapez « clear » pour effacer les anciens messages.
- Reproduisez le bug.
- Copiez tous les messages d'erreur en rouge.
- Si cela concerne l'IA ou les données, consultez Réseau :
- Cliquez sur l'onglet Réseau.
- Reproduisez le bug.
- Trouvez votre requête API (recherchez le domaine de votre API).
- Vérifiez le code d'état et la réponse.
- Si cela concerne l'IA ou les données, et que vous ne voyez rien dans les outils de développement de la fenêtre de l'application :
- Ouvrez DevTools dans la fenêtre du navigateur qui exécute votre serveur backend.
- Cliquez sur l'onglet Console.
- Tapez « clear » pour effacer les anciens messages.
- Reproduisez le bug.
- Copiez tous les messages d'erreur en rouge.
4. Formuler une hypothèse
Avant de demander de l'aide à l'IA, examinez les causes possibles suggérées par Copilot dans l'activité 1 et que vous avez dans votre outil de suivi des problèmes.
- Ouvrez votre outil de suivi des problèmes.
- Sous le problème que vous êtes en train de recréer, examinez la cause possible de ce problème.
- Vous pouvez copier la cause possible indiquée ou noter votre propre hypothèse, mais écrivez quelque chose.
« Je pense que cela se produit parce que _______________ ».
Conseil: avoir une hypothèse, même erronée, peut rendre le processus de débogage plus productif. Vous ne vous contentez pas de dire « ça ne marche pas ». Vous dites « je pense que ça ne marche pas à cause de X, et je veux vérifier cela ». Ce contexte supplémentaire est très utile pour les LLM et peut les aider à réduire l'éventail des possibilités.
5. Demandez de l'aide à Copilot avec le modèle « Teach Me » (Apprenez-moi)
Demandez à Copilot ou à un autre LLM de vous aider à déboguer. Vous pouvez utiliser ce modèle et le remplacer par vos problèmes spécifiques :
Avant de me donner un code et d'apporter la correction, expliquez-moi ce qui cause ce problème et pourquoi la correction fonctionne. Je veux comprendre le problème, pas seulement le résoudre.
Problème : [Copiez et collez le problème, y compris le résumé, la catégorie, les causes possibles, les premiers éléments à vérifier et la solution suggérée]. Fournir autant de contexte que possible au LLM peut l'aider à mieux répondre.
Mon hypothèse : [Ce qui, selon vous, en est la cause]
Résultats attendus : [ce qui devrait se passer selon moi]
6. Lisez les explications avant d'appliquer le correctif.
- Lisez ce que Copilot vous dit avant d'appliquer une correction.
C'est l'étape clé. Lorsque Copilot répond, lisez d'abord l'explication. Assurez-vous de bien comprendre et de pouvoir répondre à ces questions :- Quelle en est la cause profonde ?
- Pourquoi les corrections suggérées traitent-elles la cause ?
- Ce même type de problème pourrait-il apparaître ailleurs dans mon application ?
- Posez des questions complémentaires si quelque chose dans l'explication ne vous semble pas clair, par exemple « Pouvez-vous m'expliquer ce que cela signifie dans ce contexte ? ».
7. Appliquez la correction.
Une fois que vous avez compris le problème et accepté le plan de correction, vous pouvez appliquer les corrections. Vous pouvez soit :
- Apportez les modifications au code manuellement en vous basant sur les explications de Copilot. C'est une excellente occasion pour vous de vous familiariser avec le code et de passer à l'étape suivante de votre apprentissage.
- Demandez à Copilot d'effectuer les modifications : « Appliquez maintenant la correction que vous avez décrite à mon code ».
Copilot appliquera alors les corrections et mettra à jour directement tous les emplacements concernés dans le code. S'il vous demande de vérifier les modifications, lisez la proposition avant de les accepter. C'est ce qu'on appelle le débogage assisté par IA avec intervention humaine.
8. Testez la correction
Testez en exécutant votre application et essayez de reproduire le bug d'origine.
Le problème persiste-t-il ?
Si tel est le cas, répétez les étapes et réitérez.
Dans certains cas, il peut y avoir plusieurs causes hypothétiques aux problèmes, avec différentes solutions proposées. Si tel était le cas, vous pouvez simplement revenir en arrière et demander à Copilot de passer à la solution suivante. Vous pouvez partager des informations supplémentaires sur le bug afin d'aider Copilot à affiner son plan.
9. Mettez à jour votre outil de suivi des problèmes et validez les modifications.
- Une fois que vous avez terminé, veillez à mettre à jour le fichier issue-tracker.md. Vous pouvez ajouter cette documentation sous le ticket que vous avez corrigé.
Par exemple :
- Problème n° 1 : [ description du problème]
- Cause profonde : [Ce qui n'allait pas réellement]
- Ce que j'ai modifié dans le code [Brève description de la correction]
- Testé : [Oui/Non — la correction a-t-elle résolu le problème ?]
- Date : [ Aujourd'hui]
- Commitez cette correction sur GitHub avec la description de commit appropriée, par exemple :
« Correction : [brève description de ce que vous avez corrigé] »
Les bons messages de commit décrivent la correction, pas le bug :
Exemples pertinents :
- Correction : gestion des réponses API vides dans l'affichage des résultats
- Correction : ajout d'un état de chargement pour empêcher la double soumission
Mauvais exemples :
- Correction d'un bug
- Mettre à jour le code
10. Répétez l'opération pour votre prochain numéro.
Revenez à l'étape 1, choisissez le problème suivant le plus prioritaire et suivez le même processus :
Hypothèse → « Apprends-moi » → Comprendre → Corriger → Tester → Valider
Vous pouvez également traiter certains problèmes qui ne sont pas liés à des bogues, tels que des problèmes d'ergonomie ou des fonctionnalités manquantes, à condition de leur avoir attribué la priorité P0 ou P1. Vous devrez procéder de manière légèrement différente pour les signaler, mais vous pouvez tout de même demander à Copilot de vous aider à résoudre ces autres problèmes.
Débogage des problèmes liés à l'interface utilisateur et à l'API à l'aide de DevTools
Pour certains bugs, il ne suffit pas de jeter un œil à l'application pour les diagnostiquer. En voici quelques exemples :
- Un bouton ne fait rien lorsque vous cliquez dessus, mais aucun message d'erreur ne vous indique pourquoi.
- L'IA ne renvoie aucune réponse, mais vous ne pouvez pas savoir si la requête a échoué ou si la réponse était vide.
- Une partie de la page est manquante, mais le code HTML et CSS semble correct.
Dans chacun des cas ci-dessus, vous pouvez voir l'effet, mais pas la cause. DevTools vous permet de voir la cause. Dans cette activité, vous utiliserez DevTools pour recueillir des preuves concernant un problème, puis vous transmettrez ces preuves à Copilot afin d'obtenir une solution plus ciblée.
Dans la vidéo ci-dessous, nous allons corriger certains problèmes dans l'application TutorMatch. Le code a été modifié afin de simuler ces problèmes potentiels.
Comme le montre la vidéo, voici la procédure générale pour corriger les problèmes que vous détectez à l'aide de DevTools.
Ouvrez GitHub Codespace et Dev Tools
- Rendez-vous sur GitHub et accédez à votre dépôt MVP.
- Ouvrez une nouvelle branche (ou utilisez une branche de développement existante). Ouvrez n'importe quel espace de code existant et assurez-vous de passer à la bonne branche.
- Exécutez votre application depuis Codespaces.
- Dans l'onglet du navigateur, cliquez avec le bouton droit n'importe où sur la page et sélectionnez « Inspecter » (ou appuyez sur F12) pour ouvrir le panneau Outils de développement.
2. Émettre l'hypothèse qu'il s'agit d'un problème d'interface utilisateur ou d'un problème de logique/API.
Avant de vous plonger dans les onglets, demandez-vous quel type de problème vous rencontrez. Cela vous permettra de déterminer par où commencer.
Ce que vous voyez
Type
Où chercher dans le panneau DevTools
Élément manquant, mal aligné ou chevauchant
Problème d'interface utilisateur
Onglet Éléments
Le bouton ne fait rien ou des données erronées s'affichent
Problème logique
Onglet Console
La fonctionnalité IA ne renvoie aucune réponse ni erreur.
Problème d'API
Onglet Réseau
La mise en page semble défectueuse après une correction.
Problème d'interface utilisateur
Onglet Éléments
« Impossible de lire la propriété de undefined »
Problème logique
Onglet Console
3. Pour les problèmes d'interface utilisateur - Inspectez à l'aide de l'onglet Éléments.
Si votre problème est d'ordre visuel, comme la mise en page, l'espacement, des éléments manquants, etc.
- Cliquez sur l'onglet Éléments dans DevTools.
- Utilisez l'outil de sélection d'éléments (icône en forme de curseur dans le coin supérieur gauche de DevTools, ou appuyez sur Ctrl+Maj+C / Cmd+Maj+C).
- Passez la souris sur la zone problématique de votre page pour mettre en évidence l'élément HTML et afficher ses styles CSS.
4. Pour les problèmes liés à la logique et à l'API — Vérifiez les onglets Console et Réseau dans le backend.
Si votre problème concerne les données, le comportement ou les appels API, vérifiez la fenêtre du navigateur de votre serveur backend. Commencez par l'onglet Console.
- Cliquez sur l'onglet Console.
- Effacez les anciens messages en cliquant sur le bouton Effacer pour repartir à zéro.
- Reproduisez maintenant le bug dans l'application et commencez à voir apparaître de nouveaux messages.
- Surveillez les nouveaux messages : comme :
- Les messages rouges sont des erreurs qui comprennent souvent un nom de fichier, un numéro de ligne et une description.
- Les messages jaunes sont des avertissements. Il convient d'en tenir compte, mais ils ne causent pas toujours des problèmes.
- Copiez tout message d'erreur s'il en apparaît un.
- Si aucune erreur n'apparaît dans la console, passez à l'onglet Réseau.
- Effacez les entrées existantes et reproduisez le bug (notez que l'onglet Réseau n'enregistre que les requêtes effectuées lorsqu'il est ouvert).
- Recherchez votre appel API. Il s'affiche généralement sous la forme POST:
- rechercher analyze ou /api/analyze
- Si la demande a échoué, le statut apparaîtra en rouge.
- Même si le statut est vert (200), cliquez sur les champs de requête et de réponse à l'extrême droite et vérifiez les détails ci-dessous
- Copiez le code d'état, le corps de la requête et de la réponse, ainsi que tout message d'erreur. Ce sont vos preuves.
Ce qu'il faut vérifier
Où le trouver
Ce que cela signifie
Code d'état
Colonne Statut ou onglet En-têtes
Le numéro vous indique le type d'erreur qui s'est produit.
Demande
Cliquez sur l'onglet Demande (à l'extrême droite).
Ce que votre application a envoyé — permet de vérifier si la saisie était erronée
Réponse
Cliquez sur l'onglet Réponse (à l'extrême droite).
Le message d'erreur réel provenant du serveur, ou la réponse elle-même, qui peut être mal formatée.
Voici quelques codes d'état courants :
Code d'état
Signification
Cause commune
200
Succès
Tout a fonctionné (si les résultats sont toujours incorrects, vérifiez ce que vous avez envoyé et quelle a été la réponse).
400
Demande incorrecte
Votre clé API est manquante, expirée ou incorrecte.
401
Non autorisé
Le message d'erreur réel provenant du serveur, ou la réponse elle-même, qui peut être mal formatée.
403
Interdit
Votre clé API n'a pas l'autorisation nécessaire pour cette action.
429
Trop de demandes
Vous avez atteint la limite de débit. Veuillez patienter une minute et réessayer.
500
Erreur serveur
Le service API rencontre un problème de son côté. Veuillez réessayer plus tard.
5. Utilisez vos preuves avec Copilot
- Retournez dans Codespaces pour transférer les résultats de DevTools vers Copilot. Ces informations permettent d'affiner considérablement vos suggestions de débogage.
- Entrez vos preuves à l'aide de ce modèle :
Ne me donnez pas encore de code. Expliquez-moi simplement ce qui cause ce problème et pourquoi la solution fonctionne. Je veux comprendre le problème, pas seulement le résoudre.
**Problème :** [Ce qui s'est passé lorsque l'utilisateur a déclenché la fonctionnalité]
**Preuve DevTools :**
– Erreur console : [coller le message d'erreur ou « aucune erreur console »]
– Code d'état du réseau : [par exemple, 401]
– Demande : [collez ce que votre application a envoyé, le cas échéant]
– Réponse : [coller l'erreur ou la réponse de contenu provenant de l'API]
Comme vous fournissez des preuves plutôt qu'une description vague, Copilot peut vous donner une explication précise et une solution ciblée.
6. Appliquez la correction et vérifiez dans DevTools.
Une fois que Copilot vous a expliqué le problème et que vous l'avez compris, appliquez la correction dans votre espace de code. Vérifiez ensuite en exécutant l'application et en recréant les étapes qui ont causé le problème. Vous devriez pouvoir vérifier dans l'application elle-même, mais vous pouvez également vérifier à l'aide de DevTools :
- Pour les corrections API : Ouvrez l'onglet Réseau du backend, déclenchez la même action qui a échoué précédemment. Vérifiez :
- La requête renvoie-t-elle désormais 200 (succès) ?
- L'onglet Réponse affiche-t-il les données attendues ?
- Pour les corrections de l'interface utilisateur : utilisez l'onglet Éléments (frontend) pour vérifier que l'élément est désormais visible et correctement stylisé.
- Pour les corrections logiques : vérifiez dans la console (interface utilisateur) qu'aucune nouvelle erreur rouge n'apparaît lorsque vous déclenchez l'action.
7. Mettez en œuvre et validez votre correction
Mettez à jour votre issue-tracker.md avec ce que vous avez trouvé dans DevTools et comment vous l'avez corrigé. Une fois cela fait, préparez les modifications et validez la correction dans votre branche de dépôt.
Vérification et documentation des tests
Vous avez appris à utiliser DevTools pour diagnostiquer certains problèmes complexes. Lors du débogage et des mises à jour du code de votre MVP, vous devez vérifier que tout fonctionne correctement, documenter vos actions et fusionner vos modifications dans votre branche principale.
Les tests permettent de vérifier que vos corrections fonctionnent réellement et qu'elles n'ont pas causé d'autres problèmes. Dans la prochaine activité, vous apprendrez à transformer les plans de test afin qu'ils puissent être utilisés pour tester les fonctionnalités de l'application de manière plus systématique. Cela aidera également l'IA à comprendre quels tests doivent être réussis et elle pourra même les exécuter pour vous.
ACTIVITÉ 3
Testez, validez et documentez vos corrections
Durée estimée : 25 minutes
1. Ouvrez GitHub Codespace et créez votre liste de contrôle pour les tests.
Tester sans liste de contrôle signifie que nous oublions certains cas ou que nous effectuons des tests de manière incohérente. Au lieu de saisir manuellement la structure, nous utiliserons Copilot pour générer une liste de contrôle complète basée sur vos corrections de bogues et les fonctionnalités de votre application.
- Rendez-vous sur GitHub et accédez à votre dépôt MVP.
- Accédez à votre branche de développement (ou créez une nouvelle branche) et ouvrez n'importe quel espace de code existant à partir de l'activité existante.
- Ouvrez votre espace de code.
- Assurez-vous de passer à la branche dev.
- Créez un fichier nommé test-checklist.md dans votre espace de code test .
- Demandez à Copilot de vous aider à présenter vos preuves à l'aide de ce modèle :
Ajoutez du contenu au fichier test_checklist.md dans le dossier test pour [nom de votre application] avec la structure suivante :
– En-tête avec le nom de l'application, la date du dernier test et les espaces réservés pour le nom du testeur
– Section « Fonctionnalités principales » couvrant les fonctionnalités suivantes : [énumérez vos 2 ou 3 fonctionnalités principales]
– Section « Cas limites » avec des scénarios courants : saisie vide, saisie longue (plus de 100 mots), clics rapides, test de la fenêtre d'affichage mobile.
– Section Corrections de bogues récentes
Pour la section « Corrections de bogues récentes », examinez mes commits récents sur la branche actuelle et créez des cas de test spécifiques pour chaque correction. Chaque test doit vérifier que le bogue est résolu et décrire le comportement attendu.
Rendez les cas de test spécifiques et exploitables : quelqu'un d'autre devrait pouvoir les exécuter sans poser de questions.
2. Vérifiez les résultats de votre liste de contrôle.
Passez en revue la liste de contrôle générée et posez-vous les questions suivantes :
- Les tests des fonctionnalités principales couvrent-ils le parcours utilisateur principal à partir de ENT 9 ? Si ce n'est pas le cas, ajoutez les étapes manquantes.
- Y a-t-il des cas particuliers rencontrés par mes utilisateurs qui ne figurent pas dans la liste ? Si oui, ajoutez-les manuellement.
- Les tests de correction des bogues correspondent-ils à ce que j'ai réellement corrigé ?
- Les cas de test sont-ils suffisamment spécifiques ?
Si vous trouvez des lacunes, vous pouvez soit les combler vous-même, soit demander à Copilot d'améliorer certaines sections et de s'assurer qu'elles sont ajoutées au fichier généré.
3. Passez en revue votre liste de contrôle
Travailler chaque rangée de manière systématique :
- Suivez exactement les étapes indiquées.
- Comparez ce qui se passe avec le résultat attendu.
- Marquer « Réussi » ou « Échoué ».
- Si quelque chose échoue, notez ce qui n'a pas fonctionné.
Conseils pour effectuer des tests approfondis :
- Effectuez le test dans une nouvelle fenêtre de navigation privée/incognito afin d'éviter les données mises en cache.
- Testez d'abord le chemin heureux (tout fonctionne comme prévu).
- Testez ensuite les cas limites (entrées vides, entrées très longues, clics rapides).
- Testez sur un écran mobile (DevTools → Mode appareil, ou testez sur votre téléphone)
Si un test échoue :
- Il s'agit d'une problème de régression , ce qui signifie que le correctif a causé un autre problème.
- Revenez à l'activité 2 et appliquez le modèle « Teach Me ».
- Parfois, la première solution traite un symptôme plutôt que la cause profonde.
4. Valider les modifications et fusionner dans le répertoire principal
- Une fois que vous avez effectué tous les tests et rempli les résultats, mettez en scène et validez les modifications apportées à votre branche.
- Allez sur Github et fusionnez votre branche dans la branche principale.
Réflexion
Répondre aux problèmes soulevés lors des tests utilisateurs et déboguer votre application est un processus continu. Posez-vous les questions suivantes :
Termes clés
- Bug : défaut dans votre application qui l'empêche de fonctionner comme prévu. Les plantages, les résultats erronés et les comportements confus sont tous des types de bugs.
- P0 / P1 / P2 / P3 : niveaux de priorité des problèmes. P0 est critique (bloque les utilisateurs), P1 est important (gênant mais gérable), P2 est mineur (faible fréquence), P3 est cosmétique (peaufinage).
- Méthode MoSCoW : cadre de hiérarchisation qui regroupe les éléments en catégories « Must » (indispensable), « Should » (recommandé), « Could » (possible) et « Won't » (inutile) pour une itération donnée.
- Cause profonde : raison sous-jacente à l'apparition d'un bug, qui ne se limite pas à ce que voit l'utilisateur, mais explique pourquoi cela se produit dans le code. Corriger les causes profondes permet d'éviter que le problème ne se reproduise.
- Modèle « Teach Me » : approche de débogage consistant à demander à l'IA d'expliquer le problème avant de fournir une solution. Permet de mieux comprendre le problème plutôt que de se contenter de copier-coller des solutions.
- DevTools : outils de développement du navigateur (F12 ou clic droit → Inspecter). Comprend une console pour les erreurs, un réseau pour les appels API et des éléments pour l'inspection de la mise en page.
- Onglet Console : affiche les erreurs JavaScript, les avertissements et les messages du journal. Les entrées en rouge sont des erreurs avec les noms de fichiers et les numéros de ligne indiquant le problème.
- Onglet Réseau : affiche toutes les requêtes HTTP effectuées par votre application, y compris les appels API. Affiche les codes d'état, les détails des requêtes et les données de réponse.
- Onglet Éléments : affiche la structure HTML et les styles CSS de votre page. Utile pour diagnostiquer les problèmes de mise en page et d'affichage.
- Code d'état : nombre renvoyé par un serveur indiquant la réussite (200), une erreur client (400-499) ou une erreur serveur (500-599).
- Suivi des problèmes : document qui répertorie les bogues, leur priorité, leurs causes profondes et leurs corrections. Permet d'organiser le débogage et fournit un historique des modifications.
- Régression : lorsqu'on corrige un problème, on en casse accidentellement un autre qui marchait avant. Les listes de contrôle des tests aident à repérer les régressions.
Ressources complémentaires
- Documentation Chrome DevTools: guide officiel des outils de développement pour navigateurs
- Codes d'état HTTP: référence pour comprendre les codes de réponse API
- Demandes d'extraction GitHub: comment créer et gérer des demandes d'extraction
- Guide GitHub Copilot: conseils d'utilisateurs expérimentés pour Copilot
