Comment utiliser l'IA quand on est lead qa ?
Prompts et workflows 2026

En tant que lead qa, tu dois generer des cas de test complets pour le module [NOM_DU_MODULE] de l'application [NOM_APPLICATION]. Pour chaque cas de test, fournis: le titre exact, la precondition necessaire avant execution, les donnees d'entree a utiliser (donnees synthetiques uniquement, jamais de donnees personnelles), le script pas a pas avec etapes numerotees, le resultat attendu en fin de test, et le statut attendu du defect traceur si le test echoue. Structure tes cas selon le format Gherkin: Given (precondition), When (action), Then (resultat attendu). Inclut au minimum [NOMBRE_CAS] cas de test couvrant les chemins heureux, les cas limites et les cas d'erreur. Classe chaque cas par priorite: P0 (critique metier), P1 (fonctionnalite principale), P2 (fonctionnalite secondaire). Pour les cas limites, specifie les frontieres de validation exactes (valeur min, max, caracteres speciaux, valeurs null). Genere une matrice de tracabilite qui lie chaque cas de test aux criteres d'acceptation definis dans [LIEN_DOCUMENT_ACCEPTANCE]. Indique les outils de test recommandes parmi: Selenium, Postman, Cypress ou [OUTIL_PREFERE].

Tu es lead qa, reçois la liste suivante de defauts traces dans [OUTIL_TRACKING]: [LISTE_DEFATS]. Pour chaque defect, realise une analyse structuree en trois etapes. Premiere etape: classification par severite ( blocker, major, minor, trivial ) selon l'impact sur les utilisateurs et la criticite du flux fonctionnel affecte. Deuxieme etape: regroupement par cause racine en utilisant la methode des 5 pourquoi pour identifier les defauts qui partagent une origine commune et qui peuvent etre corriges ensemble. Troisieme etape: priorisation selon la matrice RISK = Impact_utilisateur x Probabilite_occurrence x Complexite_correction. Pour chaque defect, propose une strategie de resolution: correction immediate (hotfix), correction dans le sprint courant, correction planifiee, ou acceptation avec documentation. Identifie les defauts qui bloquent la release [VERSION_PROJET] prevue le [DATE_RELEASE]. Si des defauts sont interconnectes, specifie l'ordre de resolution optimal. Pour les defauts de severite blocker ou major, propose des tests de regression specifiques a executer apres correction. Resume ta priorisation dans un tableau avec colonnes: ID_Defect, Titre, Severite, Cause_Racine, Strategie, Sprint_Cible, Test_Regression_Requis.

En tant que lead qa, tu dois elaborer une strategie de test et un plan de couverture pour le projet [NOM_PROJET] qui entre en phase de test le [DATE_DEBUT_TEST] avec une release prevue le [DATE_RELEASE]. Decris d'abord le contexte projet: type d'application (web, mobile, API, backend), architecture technique, technologies utilisees, et environnements disponibles. Definis la strategie de test en specifiant: les types de test a mettre en oeuvre (unitaire, integration, systeme, UAT, performance, securite) avec justifcation, l'approche de test (sequentielle, agile, shift-left ou DevOps), les critere d'entree et de sortie par phase de test. Pour chaque type de test, indique: l'objectif fonctionnel, la technique de conception utilisee (partitionnement equivalence, analyse valeur limite, transition etat, cas d'utilisation), la couverture cible en pourcentage, les outils et frameworks retenus, et les deliverables attendus. Etablis un scheduling realist en identifiant les jalons critiques, les dependances entre phases, et les points de validation avec les parties prenantes. Identifie les risques QA majeurs (disponibilite environment, competences, dependances externes) et propose des plans de mitigation. Spécifie les critères de definition du 'done' QA: conditions necessaires pour considerer une fonctionnalité testée et livrable. Propose un processus de gestion des defects incluant les seuils de severity pour blocker une release. Le plan doit etre presenté sous forme de tableau de bord avec les métriques clés: taux de couverture, nombre de defects ouverts/fermes, et taux de regression.

Tu es lead qa, compile les données de test du projet [NOM_PROJET] pour la periode [PERIODE_RAPPORT] et produis un rapport executive destine au comite de pilotage. Le rapport doit contenir quatre parties distinctes. Premiere partie: resume executif de 2 paragraphs maximum présentant le statut global du projet en termes de qualite, le nombre total de tests executes, le taux de réussite, et les principales conclusions. Deuxieme partie: métriques cles presentees sous forme de tableau avec comparaison versus la periode precedente. Inclus: nombre total de tests executes (passes, fails, blocked), taux de couverture fonctionnel (en pourcentage), nombre de defects ouverts par severity, nombre de defects critiques toujours ouverts, taux de regression (defects reiteres), et temps moyen de resolution. Troisieme partie: analyse des tendances identifiant les patterns de defects recurring, les zones fonctionnelles les plus defectueuses, et les causes racines principales. Pour chaque pattern, specifie l'impact estimate et la recommendation corrective. Quatrieme partie: recommandations destinees au steering committee avec actions proposees, impact espere, et priorite. Distingue clairement les recommandations 'must do' (bloquantes pour la release) des 'should do' et 'nice to have'. Inclus une section risk register mise a jour avec le statut des risques QA. Termine par un assessment global de readiness pour la release [VERSION_PROJET] avec conclusion nette: green, amber, ou red et justification.