Aller au contenu

QA Design

Définition

Vérification, après implémentation et avant ship, que le code rendu respecte la maquette ET couvre tous les états spécifiés (vide, chargement, erreur, edge cases, accessibilité). Différent de la design review (qui challenge la maquette en cours) et différent du QA fonctionnel (qui vérifie que la feature marche).

Page concept V1 — validée avec Rémy (PD) le 2026-05-29.

Pourquoi

Sans QA design systématique :

  • Les edge cases listés dans la spec ne sont pas implémentés → bug en prod.
  • Les états vides / erreur / chargement sont oubliés → mauvaise expérience la première fois qu'un user les rencontre.
  • Le pixel et les tokens dérivent silencieusement → fragmentation du DS.
  • L'accessibilité minimale (contraste, navigation clavier, labels) est ignorée par défaut.

Place dans le cycle

high-fi → handoff dev → implémentation → QA design → ship

QA design = dernière porte avant ship. Si elle est sautée, on a [QA design non passée] à inscrire dans le wiki et l'ADR / la fiche projet.

Checklist QA Design (V1)

À cocher avant de marquer une feature done côté wiki / Linear :

États visuels

  • [ ] Happy path rendu conforme à la maquette
  • [ ] État vide rendu (pas juste un écran blanc)
  • [ ] État de chargement rendu (skeleton, spinner, indicateur)
  • [ ] État d'erreur rendu (message clair, action de rattrapage)
  • [ ] État partiel (données manquantes, tronquées) rendu
  • [ ] État désactivé rendu si pertinent (bouton disabled, formulaire en lecture seule)

Edge cases listés dans la spec

  • [ ] Tous les edge cases listés ont été implémentés ET testés
  • [ ] Aucun edge case implémenté sans avoir été listé (sinon → mettre à jour la spec)

Accessibilité minimale

  • [ ] Contraste texte ≥ ratio WCAG AA (4.5:1 pour texte normal, 3:1 pour large)
  • [ ] Navigation clavier possible (tous les éléments interactifs accessibles via Tab)
  • [ ] Labels présents sur tous les champs de formulaire (visibles ou aria-label)
  • [ ] Focus visible sur tous les éléments interactifs

Cohérence DS

  • [ ] Composants utilisés viennent du DS (pas de one-off)
  • [ ] Tokens (couleurs, spacing, typo) viennent du DS

Responsive (systématique — tous produits Bricks, Investors et EF)

  • [ ] Mobile rendu conforme aux maquettes mobile
  • [ ] Cassures évidentes vérifiées (textes longs, valeurs nulles, listes vides)

Quand on ne peut pas tout cocher

  • Cocher quand même les cases passées
  • Insérer [QA design non passée] ou [QA design partielle] dans la spec / le ticket / l'ADR
  • Lister explicitement ce qui n'a pas été vérifié
  • Ne pas marquer done silencieusement

Qui fait la QA design

Rémy en tant que PD actuel. À terme, partagé avec Pierre (prochain PD, à onboarder) — une fois onboardé, les deux PD se répartissent la QA design selon les sujets en cours.

Anti-patterns

Anti-pattern Signal Correction
Ship sans QA design Feature marquée done sans repasse vs maquette Bloquer le merge sur QA design passée
QA design = QA fonctionnel « Ça marche, on ship » sans vérif visuelle Distinguer : marche ≠ rendu conforme
Edge cases ignorés en QA États non vérifiés parce que rares Forcer la couverture de tous les états listés
Accessibilité = jamais Pas de check contraste / clavier / label Imposer la checklist accessibilité minimale
QA = relecture du PR Lire le code suffit QA design = rendu réel dans l'app, pas en relecture

État actuel

Dernière mise à jour : 2026-05-29

  • V1 stub créée le 2026-05-29 dans le cadre de l'embarquement composante Design Phase 1.
  • V1 validée le 2026-05-29 avec Rémy (PD) : checklist validée, responsive systématique (Investors + EF), owner = Rémy puis partagé avec Pierre (prochain PD) à son onboarding.
  • À enrichir : intégration dans le workflow agent Linear — comment la QA design passée est tracée côté ticket avant merge.

Pages liées

Sources