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.xlsx
  • Test_Cases_v2_FINAL.xlsx
  • Test_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.

QA Dispersé Entre Outils

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 :

  1. Lister les 12 features
  2. Ouvrir Excel, compter combien de test cases par feature
  3. Compter combien de tests « Passed » vs « Not Run »
  4. 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

Goulot QA En Fin De Sprint

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é.

Dev et QA Séparés

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 credentials
  • TC-002 : Test user login with invalid credentials
  • TC-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 :

  1. Ouvrir Excel
  2. Compter manuellement
  3. Vérifier Jira pour les bugs
  4. Consulter ses notes
  5. 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 :

  1. Une capability est créée (ex: « Authentification SSO »)
  2. Les issues de développement sont ajoutées sous la capability
  3. Les testings (test cases) sont créés et liés à la capability
  4. La QA exécute les testings et enregistre les résultats
  5. 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.

Testings Liés Aux Capabilities

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

Historique Complet Des Tests

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.

Dashboard Progression QA

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 :

  1. Chaque capability a des testings définis dès la conception
  2. QA crée test cases directement dans Sinra (liés à la capability)
  3. Quand dev complète une issue, Marie est notifiée automatiquement
  4. Marie exécute tests, enregistre résultats, crée bugs si nécessaire
  5. 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. »

HealthTech Avant/Après Sinra

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

  1. Créez vos premiers testings dans Sinra. Prenez 1 capability, définissez 5-10 test cases.
  2. Liez testings aux issues de développement. Assurez visibilité Dev ↔ QA.
  3. Exécutez et enregistrez résultats. Construisez historique complet.
  4. Suivez progression QA en temps réel. Utilisez vue release pour visibilité.
  5. 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 »

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.