Stratégies de Test pour les Équipes Agiles
Intégrez la qualité dans votre processus avec des tests efficaces. Planifiez l'automatisation des tests, gérez le travail QA et livrez avec confiance.
8 min de lecture
Les tests ne sont pas une phase — c'est continu. GitScrum aide les équipes à intégrer les tests dans chaque sprint et à livrer des logiciels de qualité de façon cohérente.
Pyramide de Tests
Niveaux de Test
PYRAMIDE DE TESTS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ /\ │
│ / \ TESTS E2E │
│ / \ Peu, lents, coûteux │
│ /──────\ Testent les parcours utilisa. │
│ / \ │
│ / \ TESTS D'INTÉGRATION │
│ / \ Quantité moyenne │
│ /──────────────\ Testent interaction compos. │
│ / \ │
│ / \ TESTS UNITAIRES │
│ / \ Beaucoup, rapides, peu │
│ /────────────────────── coûteux. Testent unités │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ RATIO GUIDE: │
│ 70% Tests unitaires │
│ 20% Tests d'intégration │
│ 10% Tests E2E │
│ │
│ PRINCIPE CLÉ: │
│ Feedback plus rapide = plus bas dans la pyramide │
│ Confiance plus haute = plus haut dans la pyramide │
│ Équilibrer les deux besoins │
└─────────────────────────────────────────────────────────────┘
Tests dans les Sprints
Tests Intégrés
TESTS INTÉGRÉS DANS LES STORIES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ STORY AVEC TESTS INTÉGRÉS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ PROJ-200: Inscription Utilisateur ││
│ │ ││
│ │ CRITÈRES D'ACCEPTATION: ││
│ │ ☐ L'utilisateur peut s'inscrire avec email/mot de passe││
│ │ ☐ La validation d'email fonctionne ││
│ │ ☐ La force du mot de passe est vérifiée ││
│ │ ☐ L'email de confirmation est envoyé ││
│ │ ☐ L'email en double est prévenu ││
│ │ ││
│ │ EXIGENCES DE TEST: ││
│ │ ☐ Tests unitaires pour la logique de validation ││
│ │ ☐ Test d'intégration pour le flux d'inscription ││
│ │ ☐ Test E2E pour le chemin heureux ││
│ │ ☐ Cas limites testés ││
│ │ ││
│ │ CAS LIMITES À TESTER: ││
│ │ ☐ Formats d'email invalides ││
│ │ ☐ Mots de passe faibles ││
│ │ ☐ Inscription en double ││
│ │ ☐ Échec du service email ││
│ │ ││
│ │ ESTIMATION: 5 points (tests inclus) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ANTI-PATTERN: │
│ ❌ Story: 3 points │
│ ❌ Tâche "Tests" séparée: 2 points │
│ │
│ CORRECT: │
│ ✅ Story: 5 points (tests inclus) │
│ ✅ Pas terminé tant que les tests ne passent pas │
└─────────────────────────────────────────────────────────────┘
Workflow QA
QA DANS LE WORKFLOW AGILE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ QA CONTINUE (pas en fin de sprint): │
│ │
│ TIMELINE DU SPRINT: │
│ │
│ Jour 1-2: │
│ • Dev commence la fonctionnalité │
│ • QA revoit les critères d'acceptation │
│ • QA écrit les cas de test │
│ │
│ Jour 3-5: │
│ • Dev termine la fonctionnalité │
│ • QA teste au fur et à mesure │
│ • Bugs corrigés immédiatement │
│ │
│ Jour 6-8: │
│ • Tests complets de la fonctionnalité │
│ • Tests de régression │
│ • Polish et corrections │
│ │
│ Jour 9-10: │
│ • Vérification finale │
│ • Préparation de la release │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ PAS CELA: │
│ │
│ Jour 1-8: Dev seulement │
│ Jour 9-10: "Phase QA" → bugs, stress, retard │
└─────────────────────────────────────────────────────────────┘
Stratégie d'Automatisation
Quoi Automatiser
DÉCISIONS D'AUTOMATISATION:
┌─────────────────────────────────────────────────────────────┐
│ │
│ AUTOMATISER: │
│ │
│ ✅ Tests unitaires (logique métier) │
│ ✅ Tests d'API (contrats) │
│ ✅ Parcours critiques (inscription, paiement) │
│ ✅ Suite de régression │
│ ✅ Vérifications de données │
│ ✅ Tests de performance de base │
│ │
│ GARDER MANUEL: │
│ │
│ 👤 Tests exploratoires │
│ 👤 Tests d'utilisabilité │
│ 👤 Nouvelles fonctionnalités (premier passage) │
│ 👤 Tests visuels complexes │
│ 👤 Cas limites rares │
│ 👤 Tests d'accessibilité (partie) │
│ │
│ CRITÈRES DE DÉCISION: │
│ │
│ Automatiser si: │
│ • Exécuté souvent (chaque build) │
│ • Résultat prévisible │
│ • Stable et fiable │
│ • Coût de maintenance acceptable │
│ │
│ Garder manuel si: │
│ • Exécuté rarement │
│ • Nécessite jugement humain │
│ • Fonctionnalité instable │
│ • Coût d'automatisation > bénéfice │
└─────────────────────────────────────────────────────────────┘
Types de Tests
Portfolio de Tests
TYPES DE TESTS DANS L'ÉQUIPE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TESTS UNITAIRES: │
│ • Testent une fonction/méthode │
│ • Pas de dépendances externes │
│ • Exécution en millisecondes │
│ • Responsabilité: Développeur │
│ │
│ TESTS D'INTÉGRATION: │
│ • Testent plusieurs composants ensemble │
│ • Base de données, API, services │
│ • Exécution en secondes │
│ • Responsabilité: Dev + QA │
│ │
│ TESTS API: │
│ • Testent les endpoints │
│ • Contrats, formats, erreurs │
│ • Automatisés dans CI │
│ • Responsabilité: Dev backend │
│ │
│ TESTS E2E (End-to-End): │
│ • Testent le parcours utilisateur complet │
│ • Navigateur, frontend, backend, DB │
│ • Exécution en minutes │
│ • Responsabilité: QA + Dev │
│ │
│ TESTS EXPLORATOIRES: │
│ • Exploration non scriptée │
│ • Trouver ce que l'automatisation manque │
│ • Créativité et curiosité │
│ • Responsabilité: QA │
│ │
│ TESTS DE PERFORMANCE: │
│ • Temps de réponse, charge │
│ • Automatisés périodiquement │
│ • Alertes sur régression │
│ • Responsabilité: Dev + QA │
└─────────────────────────────────────────────────────────────┘
Gestion des Bugs
Workflow de Bugs
GESTION DES BUGS DANS LE SPRINT:
┌─────────────────────────────────────────────────────────────┐
│ │
│ BUG TROUVÉ PENDANT LE SPRINT: │
│ │
│ 1. QA trouve le bug │
│ 2. QA crée le ticket dans GitScrum │
│ • Description claire │
│ • Étapes de reproduction │
│ • Résultat attendu vs actuel │
│ • Capture d'écran/vidéo │
│ 3. Priorisation immédiate: │
│ • Critique: Arrête tout, corrige maintenant │
│ • Haut: Corrige aujourd'hui │
│ • Moyen: Corrige cette semaine │
│ • Bas: Backlog pour refinement │
│ │
│ BUG DE PRODUCTION: │
│ │
│ • Entrer dans le sprint actuel │
│ • Priorité sur le travail planifié │
│ • Post-mortem après correction │
│ • Test de régression ajouté │
│ │
│ MÉTRIQUE À SUIVRE: │
│ │
│ • Bugs trouvés en sprint vs production │
│ • Temps de correction moyen │
│ • Taux de réouverture │
│ • Couverture de régression │
└─────────────────────────────────────────────────────────────┘
Tests avec GitScrum
Intégration QA
GitScrum supporte les stratégies de test avec :
Stories avec Tests:
- Critères d'acceptation détaillés
- Checklist de tests intégrée
- Statut de test visible
- Type de tâche "Bug"
- Priorité et sévérité
- Lien vers la story originale
- Historique de reproduction
- Bugs par sprint
- Temps de résolution
- Vélocité avec qualité
- Tendances de régression
- Colonnes QA sur le board
- Transitions de statut
- Assignation au testeur
- Definition of Done avec tests