6 min lecture • Guide 108 of 877
Coordonner Quality Assurance et Développement
Quality assurance fonctionne mieux quand intégré tout au long du développement plutôt que traité comme porte finale avant release. GitScrum permet collaboration proche QA-dev à travers vues tâches partagées, critères acceptation structurés, workflows test, et mécanismes feedback qui détectent problèmes tôt, réduisent retravail, et créent ownership partagé qualité dans toute l'équipe.
Modèles Intégration QA
QA Intégré vs Séparé
STRUCTURES ÉQUIPE QA:
┌─────────────────────────────────────────────────────────────┐
│ COMMENT QA S'INTÈGRE AVEC DÉVELOPPEMENT │
├─────────────────────────────────────────────────────────────┤
│ │
│ QA INTÉGRÉ (Recommandé pour Agile): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ ÉQUIPE DEV SCRUM ││
│ │ ┌─────────────────────────────────────────────────────┐ ││
│ │ │ @dev-maria @dev-carlos @dev-ana @qa-tom │ ││
│ │ │ │ ││
│ │ │ QA est membre complet équipe: │ ││
│ │ │ • Participe au sprint planning │ ││
│ │ │ • Participe au raffinement │ ││
│ │ │ • Même standup, rétro │ ││
│ │ │ • Teste pendant sprint, pas après │ ││
│ │ │ │ ││
│ │ │ Ratio: 1 QA pour 3-5 développeurs │ ││
│ │ └─────────────────────────────────────────────────────┘ ││
│ │ ││
│ │ Avantages: ││
│ │ • Boucles feedback plus rapides ││
│ │ • QA a contexte des exigences métier ││
│ │ • Bugs corrigés même sprint qu'ils sont trouvés ││
│ │ • Qualité devient responsabilité équipe ││
│ │ ││
│ │ Inconvénients: ││
│ │ • QA peut être pressé par deadline sprint ││
│ │ • Moins partage connaissances QA-à-QA ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ÉQUIPE QA SÉPARÉE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ BOARD ÉQUIPE DEV BOARD ÉQUIPE QA ││
│ │ ┌─────────────┐ ┌─────────────┐ ││
│ │ │ Tâches dev │ ──► │ File QA │ ││
│ │ │ │ Passer │ │ ││
│ │ │ │ à QA │ │ ││
│ │ └─────────────┘ └─────────────┘ ││
│ │ ││
│ │ QA teste après que dev complète: ││
│ │ • Passage quand "Dev Terminé" ││
│ │ • QA teste en phase séparée ││
│ │ • Bugs retournent au board dev ││
│ │ ││
│ │ Avantages: ││
│ │ • Spécialisation et expertise QA ││
│ │ • Test objectif (non influencé par dev) ││
│ │ • Mieux pour industries compliance/réglementées ││
│ │ ││
│ │ Inconvénients: ││
│ │ • Délais de passage ││
│ │ • Mentalité "jeter par-dessus le mur" ││
│ │ • Bugs trouvés plus tard coûtent plus à corriger ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Conception Workflow
Structure Board Partagé
BOARD INTÉGRÉ QA-DEV:
┌─────────────────────────────────────────────────────────────┐
│ COLONNES WORKFLOW │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────┬──────────┬──────────┬──────────┬──────────────┐│
│ │ Backlog │ En Dev │ En QA │ En UAT │ Terminé ││
│ ├─────────┼──────────┼──────────┼──────────┼──────────────┤│
│ │ │ WIP: 3 │ WIP: 2 │ │ ││
│ │ ┌─────┐ │ ┌─────┐ │ ┌─────┐ │ ┌─────┐ │ ┌─────┐ ││
│ │ │Tâche1││ │Tâche3│ │ │Tâche5│ │ │Tâche7│ │ │Tâche9│ ││
│ │ └─────┘ │ │@maria│ │ │@tom │ │ │@client│ │ │ ✓ │ ││
│ │ ┌─────┐ │ └─────┘ │ └─────┘ │ └─────┘ │ └─────┘ ││
│ │ │Tâche2││ ┌─────┐ │ ┌─────┐ │ │ ┌─────┐ ││
│ │ └─────┘ │ │Tâche4│ │ │Tâche6│ │ │ │Tâche10│ ││
│ │ │ │@carlos│ │ │@tom │ │ │ │ ✓ │ ││
│ │ │ └─────┘ │ └─────┘ │ │ └─────┘ ││
│ │ │ │ │ │ ││
│ └─────────┴──────────┴──────────┴──────────┴──────────────┘│
│ │
│ LIMITES WIP: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Colonne En QA a limite WIP = personnes QA × 2 ││
│ │ ││
│ │ Pourquoi: Empêche goulot QA, maintient flux en mvt ││
│ │ ││
│ │ Quand QA est plein: ││
│ │ • Devs ne peuvent pas déplacer plus vers QA (bloqués) ││
│ │ • Signal: Aider QA ou ralentir nouveau dev ││
│ │ • Considérer: Développeur aide avec tests ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Intégration Critères Acceptation
Écrire Critères Testables
MEILLEURES PRATIQUES CRITÈRES ACCEPTATION:
┌─────────────────────────────────────────────────────────────┐
│ CRITÈRES QUE QA PEUT RÉELLEMENT TESTER │
├─────────────────────────────────────────────────────────────┤
│ │
│ FORMAT: Étant donné-Quand-Alors │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Tâche: Réinitialisation Mot Passe Utilisateur ││
│ │ ││
│ │ Critères Acceptation: ││
│ │ ││
│ │ ✅ TESTABLE: ││
│ │ CA1: Étant donné utilisateur sur page login ││
│ │ Quand il clique "Mot de passe oublié" ││
│ │ Alors formulaire input email est affiché ││
│ │ ││
│ │ CA2: Étant donné email valide entré ││
│ │ Quand il soumet formulaire ││
│ │ Alors email reset envoyé dans 30 secondes ││
│ │ Et message succès affiché ││
│ │ ││
│ │ CA3: Étant donné format email invalide ││
│ │ Quand il soumet formulaire ││
│ │ Alors erreur validation affichée ││
│ │ Et aucun email envoyé ││
│ │ ││
│ │ ❌ VAGUE (Ne pas faire): ││
│ │ • "Reset mot passe devrait fonctionner" ││
│ │ • "Messages erreur conviviaux" ││
│ │ • "Livraison email rapide" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘