Le Vendredi Avant La Release
Vendredi 15h00. Release prévue lundi matin.
Le CTO entre dans le bureau QA :
« Marie, on est bons pour livrer lundi ? Tous les tests sont passés ? »
Marie (QA Lead) ouvre son laptop :
Étape 1 : Ouvrir Excel
- Fichier :
Test_Cases_Release_v2.3_FINAL_v4.xlsx - 87 test cases listés
- Colonnes : ID, Description, Priorité, Statut (Passed/Failed/Not Run)
Étape 2 : Compter manuellement
- 62 tests marqués « Passed »
- 18 tests marqués « Not Run »
- 7 tests marqués « Failed »
Étape 3 : Vérifier Jira
- 14 bugs ouverts
- 8 bugs « In Progress »
- 3 bugs « Resolved » (mais pas fermés)
Étape 4 : Consulter ses notes
- Post-it : « Tester feature SSO avec Microsoft OAuth »
- Email : « N’oublie pas de retester le bug AUTH-247 »
- Message Slack : « @marie le bug de pagination est-il fixé ? »
30 minutes plus tard.
Marie répond :
« Euh… je pense qu’on est bons. Il reste 18 tests non critiques que je n’ai pas eu le temps de faire. Les 7 failed sont des bugs connus en cours de fix. Normalement ça devrait aller. »
CTO : « Normalement ? »
Marie : « Oui… enfin, sauf si j’ai oublié quelque chose. »
Le CTO a un choix :
- ✅ Livrer lundi (avec 18 tests non exécutés et 7 bugs actifs)
- ❌ Décaler la release (et décevoir les clients)
Le CTO choisit : Livrer. « On verra bien. »
Lundi 10h00 : Bug critique en production. Feature SSO Microsoft OAuth ne fonctionne pas.
Cause : Marie avait oublié de tester (c’était sur un post-it perdu).
Le Problème Du QA Invisible
La majorité des équipes tech gèrent leurs tests de cette façon : QA dispersé entre outils déconnectés, sans visibilité globale.
Les Cinq Symptômes Du QA Invisible
1. Test Cases Dans Excel (Déconnectés Du Développement)
Le Scénario : Votre QA maintient un fichier Excel avec tous les test cases :
Test_Cases_v1.xlsxTest_Cases_v2_FINAL.xlsxTest_Cases_v2.3_FINAL_v4.xlsx(le vrai fichier… ou pas ?)
Le Problème :
- ❌ Excel n’est pas lié aux features développées
- ❌ Impossible de savoir quels tests couvrent quelle feature
- ❌ Pas de synchronisation avec le code (feature ajoutée = test oublié)
- ❌ Plusieurs versions du fichier Excel (personne ne sait laquelle est à jour)
Résultat Réel : Une équipe découvre 3 semaines après une release qu’une feature critique n’avait aucun test case défini - elle était dans une ancienne version Excel perdue.
2. Bugs Dans Jira (Mais Aucun Lien Avec Les Tests)
Le Scénario : Les bugs sont trackés dans Jira :
[BUG-423] Pagination broken on user list[BUG-424] SSO Microsoft OAuth fails with 500 error[BUG-425] Export PDF crashes on large datasets
Le Problème :
- ❌ Aucun lien entre le bug et le test case qui l’a détecté
- ❌ Impossible de savoir si le bug a été retesté après fix
- ❌ Pas de vue globale « combien de bugs bloquent la release ? »
- ❌ QA doit manuellement croiser Excel (tests) et Jira (bugs)
Scénario Réel :
Marie (QA) : « Le bug AUTH-247 est fixé ? »
Dev : « Oui, fermé hier. »
Marie : « Ok. »
2 semaines plus tard : Bug AUTH-247 réapparaît en prod.
Pourquoi ? Marie n’a jamais retesté. Elle pensait que « fermé » = « validé QA ». Le dev pensait que fermer le bug = QA automatique.
3. Résultats De Tests Perdus (Aucun Historique)
Le Scénario : Marie teste manuellement une feature. Elle trouve un bug, le reporte dans Jira, puis… oublie qu’elle avait déjà testé cette feature.
3 semaines plus tard :
Dev : « Marie, tu as retesté la feature X après mon fix ? »
Marie : « Euh… je crois que oui ? Attends, je vérifie. »
Marie cherche :
- Excel : aucune trace de date/résultat
- Jira : bug fermé mais pas de commentaire QA
- Notes : rien
- Mémoire : « Je pense que je l’ai testé mais je ne suis pas sûre. »
Marie reteste. (Temps perdu : 30 minutes pour quelque chose qu’elle avait déjà fait)
Le Problème :
- ❌ Aucun historique des exécutions de tests
- ❌ Impossible de savoir « qui a testé quoi quand »
- ❌ Tests dupliqués (même test exécuté 2 fois par erreur)
- ❌ Tests oubliés (« Je pensais que quelqu’un l’avait déjà testé »)
4. Couverture QA Invisible
Le Scénario : Vous livrez une release avec 12 features.
Question du CTO : « Quelle est notre couverture de tests pour cette release ? »
Processus de réponse :
- Lister les 12 features
- Ouvrir Excel, compter combien de test cases par feature
- Compter combien de tests « Passed » vs « Not Run »
- Reconstituer mentalement la couverture
Temps nécessaire : 1-2 heures.
Fiabilité : 60% (vous avez probablement oublié quelque chose).
Réponse finale : « Je dirais qu’on est à 70-80% de couverture. »
Le Problème :
- ❌ Aucune vue automatique de la couverture
- ❌ Impossible de savoir « Feature X est-elle bien testée ? »
- ❌ Décisions de livraison basées sur intuition, pas données
- ❌ Pas de métrique QA fiable
5. QA Bloqué En Fin De Sprint (Le Goulot d’Étranglement)
Le Scénario : Lundi-Mercredi : Les devs codent.
Jeudi-Vendredi : « Marie, voilà 8 features à tester pour la release de lundi. »
Marie : « 8 features en 2 jours ?! »
Résultat :
- Marie teste en urgence
- 50% des tests sont survolés (pas de tests approfondis)
- 30% des tests ne sont pas exécutés (pas le temps)
- Bugs trouvés vendredi soir → pas le temps de fixer avant lundi
Le Problème :
- ❌ QA est traité comme une « phase finale » au lieu d’un processus continu
- ❌ Pas de visibilité en temps réel sur ce qui est prêt à tester
- ❌ Marie ne sait pas quand les features seront prêtes pour elle
- ❌ Testing devient un goulot d’étranglement
Pourquoi Le QA Devient Invisible
Raison 1 : Les Outils De Dev Et QA Sont Séparés
Les Devs Utilisent :
- Jira/Linear pour tracker les issues
- GitHub pour le code
- CI/CD pour les tests automatisés
La QA Utilise :
- Excel pour les test cases
- Jira pour reporter les bugs
- Ses notes personnelles pour le suivi
Résultat : Deux mondes parallèles qui ne communiquent jamais.
Les devs ne savent pas ce que QA teste. QA ne sait pas ce que les devs ont développé.
Raison 2 : Les Test Cases Ne Sont Pas Liés Aux Features
Le Problème : Dans Excel, vous avez :
TC-001 : Test user login with valid credentialsTC-002 : Test user login with invalid credentialsTC-003 : Test SSO Google OAuth
Mais aucune information sur :
- Quelle feature ces tests couvrent
- Quelle release nécessite ces tests
- Quel développeur a implémenté la feature testée
- Si la feature a changé depuis la création du test
Résultat : Les test cases flottent dans le vide, déconnectés du travail réel.
Raison 3 : Aucune Visibilité Temps Réel
Le Problème : Le CTO demande : « Où en est le testing de la release ? »
Aujourd’hui, la QA doit :
- Ouvrir Excel
- Compter manuellement
- Vérifier Jira pour les bugs
- Consulter ses notes
- Reconstituer mentalement l’état global
Il n’existe aucune vue temps réel qui montre :
- Combien de tests exécutés vs restants
- Quelles features sont validées QA
- Combien de bugs bloquent la release
- Si la release peut partir
Résultat : Le QA est invisible jusqu’à ce que quelqu’un demande explicitement.
L’Approche Sinra : QA Unifié Avec Le Développement
Sinra a été conçu pour rendre le QA visible, lié au développement, et en temps réel.
Le Concept : Testings Liés Aux Capabilities Et Releases
Dans Sinra, les testings (test cases) sont directement liés aux capabilities (features) et aux releases.
Workflow :
- Une capability est créée (ex: « Authentification SSO »)
- Les issues de développement sont ajoutées sous la capability
- Les testings (test cases) sont créés et liés à la capability
- La QA exécute les testings et enregistre les résultats
- La progression QA est automatiquement synchronisée avec la release
Résultat : Dev et QA travaillent dans le même système, avec visibilité partagée.
Anatomie D’Une Feature Avec Testings Sinra
Étape 1 : Créer La Capability « Authentification SSO »
Description :
- Permettre aux utilisateurs de se connecter via Google et Microsoft OAuth
Issues :
[AUTH-120] Implémenter Google OAuth backend[AUTH-121] Implémenter Microsoft OAuth backend[AUTH-122] Créer UI sélection fournisseur SSO[AUTH-123] Ajouter gestion tokens et refresh
Étape 2 : Créer Les Testings Pour Cette Capability
Testings QA :
| ID | Test Case | Priorité | Lié à |
|---|---|---|---|
| TC-AUTH-01 | Login Google OAuth avec compte valide | Haute | AUTH-120 |
| TC-AUTH-02 | Login Google OAuth avec compte invalide | Haute | AUTH-120 |
| TC-AUTH-03 | Login Microsoft OAuth avec compte valide | Haute | AUTH-121 |
| TC-AUTH-04 | Login Microsoft OAuth avec compte invalide | Haute | AUTH-121 |
| TC-AUTH-05 | Sélection fournisseur SSO dans UI | Moyenne | AUTH-122 |
| TC-AUTH-06 | Gestion refresh token après expiration | Haute | AUTH-123 |
Bénéfices :
- ✅ Chaque test est lié à l’issue de développement
- ✅ Quand l’issue AUTH-120 est complétée, Sinra alerte QA que TC-AUTH-01 et TC-AUTH-02 sont prêts à tester
- ✅ Pas de test oublié (impossible de marquer la capability « Done » si tests non exécutés)
Étape 3 : Exécuter Les Tests Et Enregistrer Les Résultats
Marie (QA) exécute les tests :
TC-AUTH-01 : Login Google OAuth avec compte valide
- Résultat : ✅ Passed
- Date : 2025-12-22 10:34
- Testé par : Marie
- Notes : Fonctionne correctement, redirection OK, token stocké
TC-AUTH-03 : Login Microsoft OAuth avec compte valide
- Résultat : ❌ Failed
- Date : 2025-12-22 11:02
- Testé par : Marie
- Bug créé :
[BUG-456] Microsoft OAuth renvoie erreur 500 - Notes : Erreur serveur lors de la validation du token Microsoft
Bénéfices :
- ✅ Historique complet préservé (qui, quand, résultat, notes)
- ✅ Bug automatiquement lié au test case et à l’issue de développement
- ✅ Dev reçoit notification : « Bug détecté sur AUTH-121 par TC-AUTH-03 »
Étape 4 : Dev Fixe Le Bug, QA Reteste
Dev fixe BUG-456 :
- Commit :
Fix Microsoft OAuth token validation - Marque le bug « Resolved »
- Sinra notifie automatiquement Marie : « BUG-456 résolu, retester TC-AUTH-03 »
Marie reteste :
- TC-AUTH-03 : Login Microsoft OAuth avec compte valide
- Résultat : ✅ Passed (retest)
- Date : 2025-12-22 15:18
- Notes : Fix validé, fonctionne correctement maintenant
Bénéfices :
- ✅ Pas de test oublié (notification automatique)
- ✅ Historique complet (failed → bug → fix → passed)
- ✅ Synchronisation Dev ↔ QA en temps réel
Vue Globale : Progression QA Par Release
Release : SaaS Platform v2.5 (Livraison : 2025-12-30)
| Capability | Tests Total | Passed | Failed | Not Run | Statut QA |
|---|---|---|---|---|---|
| Authentification SSO | 6 | 6 | 0 | 0 | ✅ Validé |
| Analytics Dashboard | 8 | 5 | 1 | 2 | ⚠️ En cours |
| API Webhooks | 10 | 0 | 0 | 10 | 🚨 Pas commencé |
| Export PDF | 5 | 4 | 0 | 1 | ⚠️ En cours |
Progression Globale QA : 15/29 tests passés = 52% complété
Alertes Automatiques :
- 🚨 API Webhooks : 0 tests exécutés (livraison dans 8 jours)
- ⚠️ Analytics Dashboard : 1 bug actif (bloque validation QA)
Bénéfices :
- ✅ Vue temps réel de l’état QA par release
- ✅ Identification immédiate des risques
- ✅ Réponse instantanée à « On peut livrer ? »
Réponse au CTO :
« Non, on ne peut pas livrer lundi. API Webhooks n’a aucun test exécuté, et Analytics a encore 1 bug actif. Je recommande de décaler de 5 jours ou de retirer API Webhooks de la release. »
Temps de réponse : 30 secondes au lieu de 2 heures.
Les Cinq Avantages Du QA Unifié Sinra
1. Tests Liés Aux Features (Pas Excel Déconnecté)
Avant (Excel) :
- Test cases flottent dans le vide
- Aucun lien avec le code développé
- Features ajoutées = tests oubliés
Après (Sinra) :
- Chaque testing lié à une capability
- Impossible de marquer « Done » sans tests validés
- Features nouvelles = créer testings automatiquement suggérés
2. Historique Complet Des Exécutions
Avant (Notes/Mémoire) :
- « Je crois que j’ai testé ça la semaine dernière… »
- Pas de trace de qui a testé quoi quand
- Tests dupliqués
Après (Sinra) :
- Historique complet : date, testeur, résultat, notes
- « TC-AUTH-03 testé par Marie le 22/12 à 11h02 : Failed, bug BUG-456 créé »
- Recherche : « Qui a testé Microsoft OAuth ? » → Réponse instantanée
3. Synchronisation Dev ↔ QA Automatique
Avant (Outils Séparés) :
- Dev termine une issue → QA ne sait pas que c’est prêt
- Bug fixé → QA doit deviner qu’il faut retester
- Désynchronisation constante
Après (Sinra) :
- Issue complétée → QA notifiée automatiquement
- Bug résolu → Test case à ré-exécuter suggéré
- Dev et QA travaillent dans le même système
4. Visibilité Temps Réel De La Couverture QA
Avant (Calcul Manuel) :
- « On est à combien de couverture ? » → 2h de calcul
- Fiabilité 60%
- Décisions basées sur intuition
Après (Sinra) :
- Vue automatique : 15/29 tests passés (52%)
- Par capability : SSO 100%, Webhooks 0%
- Décisions basées sur données réelles
5. Goulot QA Éliminé (Testing Continu)
Avant (QA En Fin De Sprint) :
- Dev code lundi-mercredi
- QA teste jeudi-vendredi en urgence
- Bugs trouvés trop tard
Après (Sinra) :
- QA voit en temps réel quand issues sont prêtes
- Testing continu (dès qu’une issue est complétée)
- Bugs détectés tôt (temps de fixer avant release)
Exemple Réel : HealthTech Solutions
HealthTech Solutions (équipe de 10 personnes, plateforme SaaS santé)
Note : HealthTech Solutions est une entreprise réelle que nous avons anonymisée sous un nom fictif pour protéger leur confidentialité.
Avant Sinra : QA Invisible
Stack d’outils :
- Excel : Test cases (
Test_Cases_v12_FINAL.xlsx) - Jira : Bugs et issues de développement
- Notes personnelles : Résultats de tests
- Slack : Communication Dev ↔ QA
Problèmes Rencontrés :
- Couverture invisible : Impossible de savoir combien de tests manquaient
- Tests oubliés : 2 features livrées sans aucun test (découvert après incidents prod)
- Désynchronisation : QA testait souvent des versions obsolètes (dev avait déjà changé le code)
- Goulot QA : Marie (seule QA) submergée en fin de sprint
- Historique perdu : « J’ai déjà testé ça ou pas ? » (aucune trace)
Incident Révélateur : Release « Patient Portal v3.2 » livrée avec feature « Export dossier médical PDF ».
1 semaine après la release : 12 clients reportent que l’export PDF échoue sur dossiers >50 pages.
Analyse : Aucun test case n’existait pour « Export PDF avec gros dossiers ». Marie avait testé uniquement avec petits dossiers (5 pages).
Coût :
- 3 semaines de fixes urgents
- 12 clients mécontents
- Réputation impactée
Après Sinra : QA Unifié
Workflow :
- Chaque capability a des testings définis dès la conception
- QA crée test cases directement dans Sinra (liés à la capability)
- Quand dev complète une issue, Marie est notifiée automatiquement
- Marie exécute tests, enregistre résultats, crée bugs si nécessaire
- Vue temps réel de la progression QA par release
Résultats (Après 4 Mois) :
- Couverture visible : Vue automatique « Release à 78% testée »
- Tests oubliés : 0 (impossible de livrer sans valider testings)
- Synchronisation : Dev et QA alignés en temps réel
- Goulot QA : Éliminé (testing continu tout au long du sprint)
- Historique complet : « TC-PDF-05 testé 3 fois : 12/12 failed, 15/12 failed, 18/12 passed »
Citation Marie (QA Lead) :
« Avant, je passais 30% de mon temps à chercher ce que j’avais déjà testé et à demander aux devs ce qui était prêt. Maintenant, Sinra me dit exactement quoi tester et je peux tracer tout mon travail. Je teste 2x plus et avec zéro stress. »
Citation CTO :
« Fini les vendredis soir à se demander si on peut livrer lundi. J’ouvre Sinra, je vois la progression QA en temps réel, et je prends une décision basée sur des faits. Game changer. »
Excel + Jira vs. Sinra : Comparaison QA
| Aspect | Excel + Jira | Sinra Testings |
|---|---|---|
| Test cases | Excel déconnecté | Liés aux capabilities |
| Lien avec features | ❌ Aucun | ✅ Automatique |
| Historique exécutions | ❌ Aucun (notes manuelles) | ✅ Complet avec dates/testeurs |
| Synchronisation Dev ↔ QA | ❌ Manuelle | ✅ Automatique |
| Couverture QA visible | ❌ Calcul manuel (2h) | ✅ Temps réel (<10s) |
| Alertes tests manquants | ❌ Aucune | ✅ Automatiques |
| Testing continu | ❌ Goulot en fin de sprint | ✅ Tout au long du sprint |
| Bugs liés aux tests | ❌ Déconnectés | ✅ Liés automatiquement |
| Visibilité release | ❌ « Je pense qu’on est bons » | ✅ « 78% testés, 2 bugs actifs » |
Les Cinq Signes Que Votre QA Est Invisible
Signe 1 : Votre QA Utilise Excel Pour Les Test Cases
Si vos test cases vivent dans un fichier Excel déconnecté du développement, votre QA est invisible.
Signe 2 : Vous Ne Savez Pas Combien De Tests Restent Avant La Release
Si la réponse à « Combien de tests restent ? » nécessite 1h de calcul manuel, votre couverture QA est invisible.
Signe 3 : QA Découvre Les Features Prêtes Par Hasard
Si votre QA doit demander « C’est prêt à tester ? » au lieu d’être notifiée automatiquement, la synchronisation est cassée.
Signe 4 : Vous Livrez Sans Savoir Si Tout Est Testé
Si vous répondez « Je pense que oui » à « Tout est testé ? », vous n’avez aucune visibilité.
Signe 5 : Bugs Réapparaissent Parce Que QA A Oublié De Retester
Si des bugs « fixés » reviennent parce que QA ne savait pas qu’il fallait retester, votre historique est inexistant.
Comment Utiliser Sinra Pour Le QA
Étape 1 : Créer Testings Pour Chaque Capability
Action :
- Chaque capability (feature) a une section « Testings »
- Créer test cases avec priorité (Haute/Moyenne/Basse)
- Lier chaque testing aux issues de développement concernées
Résultat : Test cases liés au travail, pas flottant dans Excel.
Étape 2 : Exécuter Tests Et Enregistrer Résultats
Action :
- Quand une issue est complétée, notification QA
- QA exécute le testing, enregistre résultat (Passed/Failed)
- Si Failed : créer bug directement lié au test
Résultat : Historique complet, bugs tracés.
Étape 3 : Suivre Progression QA Par Release
Action :
- Vue release affiche % tests exécutés
- Alertes automatiques si tests manquants
- Décision de livraison basée sur données réelles
Résultat : Visibilité temps réel, décisions informées.
Étape 4 : Testing Continu (Pas Goulot En Fin De Sprint)
Action :
- QA teste dès qu’issues sont complétées
- Bugs détectés tôt (temps de fixer)
- Pas d’accumulation vendredi
Résultat : QA devient processus continu, pas phase finale.
Points d’Action : Rendre Votre QA Visible
- Créez vos premiers testings dans Sinra. Prenez 1 capability, définissez 5-10 test cases.
- Liez testings aux issues de développement. Assurez visibilité Dev ↔ QA.
- Exécutez et enregistrez résultats. Construisez historique complet.
- Suivez progression QA en temps réel. Utilisez vue release pour visibilité.
- Adoptez testing continu. Testez dès que prêt, pas en fin de sprint.
Le Point Clé
Le QA invisible tue la qualité.
Entre test cases Excel déconnectés, bugs Jira sans lien, résultats perdus, et couverture inconnue, personne ne sait si la release peut partir.
Sinra rend le QA visible et unifié avec le développement.
Les testings sont liés aux capabilities, l’historique est complet, la synchronisation est automatique, et la progression est en temps réel.
Le résultat :
- ✅ Tests liés aux features (pas Excel déconnecté)
- ✅ Historique complet des exécutions
- ✅ Synchronisation Dev ↔ QA automatique
- ✅ Visibilité temps réel de la couverture
- ✅ Goulot QA éliminé (testing continu)
Vous savez exactement ce qui est testé, ce qui reste, et si vous pouvez livrer.
Le futur vous dira merci.
Découvrez aussi la série « Problèmes Invisibles »
- La Documentation Morte - 127 pages Confluence obsolètes : comment rendre la documentation vivante avec Sinra Pages
- Le Chaos Du Backlog - 537 issues chaotiques : comment organiser le travail par releases et cycles
- Les Dépendances Cachées - 47% des features bloquées : comment rendre les dépendances visibles
- Le Syndrome Du Multi-Projet - Développeurs sur 4 projets : comment limiter la surcharge
Prêt à rendre votre QA visible ? Démarrez un essai gratuit de Sinra →
Découvrez une gestion de projet où les tests sont liés au développement, pas perdus dans Excel.