Nos expertises / Qualité logicielle
Des tests automatisés qui protègent votre logiciel à chaque évolution
Livrer une nouvelle fonctionnalité sans craindre de casser l'existant : c'est ce que permet notre méthode de travail en intégrant des analyses et des tests automatisés dès le départ. Ce n'est pas une assurance invisible mais une stratégie de rentabilité sur le long terme.
Chez SmartBooster, la qualité logicielle est intégrée à nos développements dès la conception du ticket, là où d'autres traitent ce sujet en revue de code.
Ça vous parle ?
Les symptômes d'un projet sans stratégie de tests
Chaque livraison apporte son lot de régressions
Une nouvelle fonctionnalité casse une autre qui fonctionnait. Les corrections de bugs génèrent de nouveaux bugs. L'équipe passe plus de temps à corriger qu'à construire.
Retester tout manuellement à chaque sprint
Sans tests automatisés, chaque mise en production impose un cycle de recette complet. Le moindre changement prend deux fois plus de temps que prévu et reste incertain.
Personne ne sait ce qu'un changement peut casser
Le logiciel devient une boîte noire. Modifier une règle de calcul ou un processus métier est une prise de risque que l'équipe redoute et que vos utilisateurs finissent par ressentir.
POURQUOI TESTER
Les tests stabilisent votre logiciel
La vraie question n'est pas 'combien coûtent les tests' mais 'combien coûte l'absence de tests'. Régressions, recette manuelle, corrections urgentes voilà le coût réel d'un code non couvert. De plus, des tests pensés et mis en place dès le départ améliorent la qualité de votre conception et de vos premières livraisons.
ROI sur plusieurs années
Un code couvert par des tests coûte sensiblement moins cher à maintenir. Chaque fonctionnalité s'appuie sur une base fiable et pas sur la mémoire des développeurs.
Livrer sereinement
Les tests sont vos crash-tests. Comme dans l'automobile, on ne met pas les utilisateurs en production pour découvrir les problèmes : on les détecte avant.
Documentation à jour
Un test unitaire qui vérifie une règle de calcul décrit aussi comment ce calcul fonctionne. Les tests sont la documentation la plus à jour qui soit.
Zéro régression sur l'existant
Chaque nouveau développement est validé contre l'ensemble des comportements attendus. Ce qui fonctionnait hier fonctionnera encore demain.
NOTRE STRATÉGIE QUALITÉ
5 niveaux de validation pour un logiciel qui ne tombe pas en panne
Les niveaux 1 et 2 (PHPStan + tests unitaires) sont appliqués sur tous nos projets, y compris les prototypes. Ils constituent un socle qui nous permet d'aller plus vite. Les niveaux suivants s'activent selon la criticité du projet et la maturité des fonctionnalités : un projet en production avec des parcours métier critiques justifie les tests E2E Playwright ; un prototype en phase de validation n'en a pas encore besoin.
Niveau 1 : Analyse statique
PHPStan : détecter les erreurs avant l'exécution
PHPStan analyse votre code PHP sans l'exécuter. Configuré au niveau maximum, il détecte les erreurs de typage, les appels incorrects, les variables non définies et les incohérences de syntaxe. Avec PHP CS Fixer, qui corrige automatiquement le formatage et les conventions de style, ils scannent l'intégralité du code en quelques secondes.
C'est le premier filet de sécurité à installer sur un projet : il bloque immédiatement tout code défaillant avant même qu'un test ne soit lancé.
En complément, nous utilisons Rector en mode --dry-run pour détecter le code qui dévie des standards et PHPArkitect pour valider les règles d'architecture définies sur le projet (par exemple que les controllers hérite tous de l'AbstractController du projet ou qu'une entité n'appelle jamais directement un service). Ensemble, c'est l'anti-dette technique en continu.
Niveau max : le plus strict
Toutes les règles activées : typage strict, méthodes non nullables, cas impossibles. Aucun faux positif toléré : tout ce que PHPStan remonte est un problème potentiel à analyser.
Bloquant dans le pipeline CI/CD
PHPStan s'exécute à chaque push sur une merge request GitLab. Si une erreur est détectée, le déploiement est impossible. Le code défaillant ne franchit pas cette étape.
Niveau 2 : Tests unitaires
PHPUnit : sécuriser chaque règle métier
Les tests unitaires vérifient chaque objet métier isolément : formules de calcul, règles de validation, transformations de données. Chaque comportement attendu est codifié avec un jeu de données exhaustif grâce aux Data Providers.
C'est le niveau qui offre le meilleur retour sur investissement : rapide à écrire, rapide à exécuter, et directement relié aux règles métier qui font la valeur de votre logiciel.
Pattern AAA et Data Providers
Arrange, Act, Assert : chaque test suit une structure lisible préparation, test et validation des résultats. Les Data Providers couvrent N cas sans dupliquer le code : une règle métier, tous ses cas limites.
Mocks pour isoler les dépendances
Les dépendances externes (appels API, services tiers) sont simulées pour que chaque test reste déterministe, indépendant de l'extérieur et rapide.
Niveau 3 : Tests de services
PHPUnit KernelTestCase : valider les interactions réelles
Les tests de services valident les interactions entre plusieurs classes avec le vrai container Symfony et la vraie base de données. Ils couvrent ce que les tests unitaires ne peuvent pas couvrir : requêtes Doctrine complexes, transactions, chargement de relations imbriquées.
Nous n'utilisons pas le crawler Symfony (WebTestCase) car nous pensons que les tests E2E sont mieux couvert par Playwright, plus réaliste et sans duplication. Les appels API externes restent mockés pour ne pas créer de dépendance vers des services tiers dans le pipeline.
Dama/doctrine-test-bundle
Chaque test s'exécute dans une transaction annulée automatiquement. Les fixtures sont chargées une fois, les tests sont rapides et reproductibles à l'infini.
Documentation Symfony Testing
Notre approche s'appuie sur les recommandations officielles Symfony. Consulter la documentation Symfony Testing.
Niveau 4 : Tests de composants Vue.js
Storybook + Vitest : isoler et documenter l'interface
Les composants Vue.js sont développés et testés isolément dans Storybook. Chaque composant est décliné dans ses états possibles (vide, erreur, chargement, données réelles) ce qui constitue une documentation visuelle accessible à toute l'équipe, y compris non-technique.
Vitest couvre la logique unitaire JavaScript : transformations de données, formatage, calculs côté frontend. Natif Vite, compatible avec les conventions Jest, il s'intègre nativement dans le pipeline sans configuration supplémentaire.
Stories : documentation visuelle des composants
L'équipe (dev, design, client) peut explorer chaque composant dans tous ses états sans lancer l'application. Les règles d'affichage deviennent visibles et vérifiables.
Vitest : logique JavaScript testée
Transformations, formatage, règles de calcul côté Vue.js. Exécution ultra-rapide, retour immédiat dans le pipeline CI/CD à chaque push.
Niveau 5 : Tests end-to-end
Playwright : simuler les parcours critiques utilisateur
Playwright pilote un vrai navigateur pour simuler les actions d'un utilisateur réel : connexion, saisie de formulaire, validation métier, navigation inter-pages. Les tests E2E valident les parcours critiques de bout en bout, dans les mêmes conditions que la production.
Nous réservons les tests Playwright aux parcours à fort enjeu (tunnel de commande, processus de validation, exports critiques) pour un rapport qualité/effort optimal.
Multi-navigateurs natif
Chromium, Firefox et WebKit en un seul run. Les bugs spécifiques à un navigateur sont détectés automatiquement avant la production.
Screenshots et vidéos en cas d'échec
Playwright génère une capture d'écran et une vidéo à chaque échec. Le débogage est visuel : on voit exactement ce que l'utilisateur aurait vu.
MÉTHODOLOGIE
Les fixtures YAML : premier livrable d'un ticket
Chez SmartBooster, les fixtures ne sont pas un outil de test. Ce sont un outil de conception.
Avant d'écrire une ligne de code, les données de référence du ticket sont définies en YAML. Elles formalisent les cas nominaux, les cas limites et les rôles utilisateurs et servent de référence commune pour les développements, les tests et la recette.
Créées pendant la phase de conception du ticket
Avant d'écrire une ligne de code, les données de test sont définies en YAML. Les fixtures formalisent les cas nominaux et les cas limites. Elles complètent et illustrent les spécifications pour garantir la parfaite compréhension du développement à réaliser. Elles servent de référence commune entre développeur et product owner lors de la phase de recette.
Environnement cohérent pour toute l'équipe
Chaque développeur démarre dans un état identique dès le premier 'git clone'. Pas de 'ça marche chez moi' : les données de référence sont partagées, versionnées et maintenues comme n'importe quel autre fichier du projet.
Double usage : tests et recette
Les fixtures alimentent les tests de services (données de départ reproductibles) et les démonstrations fonctionnelles en recette (exemples concrets à valider avec le client). Plusieurs jeu de données pour des usages complémentaires. Nous utilisons également la génération de fixtures pour les tests de performances
LE CIMENT
Rector + GitLab CI : automatiser la vigilance
Les tests n'ont de valeur que s'ils s'exécutent à chaque modification. Rector et GitLab CI s'en chargent automatiquement — sans dépendre de la discipline de chaque développeur.
Rector — conformité automatique du code
Rector modernise le code PHP et applique les règles d'architecture automatiquement. En mode --dry-run dans le pipeline CI, il échoue si du nouveau code dévie des standards définis — sans modifier le code en place. C'est l'anti-dette technique en continu.
GitLab CI — pipeline de validation à chaque push
PHPStan, PHPUnit, Rector et Playwright s'exécutent automatiquement sur chaque branche. Si un test échoue, le déploiement est impossible. La production n'accepte que du code qui a passé l'intégralité des validations.
DOCUMENTATION
La documentation : un livrable au même titre que le code
Nous versionnons la documentation dans le dépôt Git. Elle évolue avec le code — jamais en retard d'une version, jamais perdue dans un outil externe.
Versionnée dans le dépôt Git
La documentation est dans le dépôt, pas dans un Notion oublié. Chaque commit peut l'enrichir ou la corriger. Le client la reçoit avec le code — elle ne peut pas être perdue ou désynchronisée.
Diagrammes Mermaid pour les processus complexes
Flux métier, séquences d'interaction entre services, schémas entité-relation — les diagrammes Mermaid sont écrits en texte, versionnés, et rendus automatiquement dans GitLab. Un schéma complexe devient lisible en quelques secondes.
Livrable à part entière, pas une option
À chaque fin de sprint, la documentation reflète l'état réel du logiciel. Un nouveau développeur peut démarrer en quelques heures. Votre équipe comprend votre outil sans dépendre d'une seule personne pour l'expliquer.
LEXIQUE
Les termes clés de la qualité logicielle
Un vocabulaire partagé entre l'équipe technique et les décideurs. Ces concepts reviennent dans toutes les conversations sur la qualité.
- Régression
- Bug apparu suite à une modification, dans une partie du code qui n'a pas été intentionnellement changée. Les régressions sont le symptôme le plus fréquent d'un projet sans tests.
- Mock
- Simulation d'une dépendance externe (appel API, envoi d'email, service tiers) pour tester la logique du composant sans dépendre de l'extérieur. Le test reste rapide et déterministe.
- Isolation
- Principe de tester un composant indépendamment de ses dépendances réelles. Garantit que le test échoue uniquement si ce composant est défaillant et pas à cause d'une autre partie du code ou d'un service tiers.
- Pattern AAA
- Arrange, Act, Assert. Structure universelle d'un test : préparer les données, exécuter l'action, vérifier le résultat. Rend les tests lisibles par toute l'équipe, même sans connaître le code en détail.
- Pipeline CI/CD
- Chaîne d'exécution automatique déclenchée à chaque modification du code : analyse statique, tests, vérification d'architecture. Si un test échoue, le déploiement est bloqué. La production n'accepte que du code validé.
- E2E (End-to-End)
- Test qui simule le parcours complet d'un utilisateur réel dans un vrai navigateur, du clic sur le bouton jusqu'à la réponse en base de données. Le niveau de validation le plus proche des conditions réelles d'utilisation.
- Coverage (couverture)
- Pourcentage du code exécuté lors des tests. Un coverage élevé est rassurant, mais ne garantit pas la qualité des tests. Un coverage faible signale des zones non sécurisées qui peuvent cacher des régressions.
- Fixture
- Jeu de données de référence défini en YAML, chargé avant les tests ou au démarrage du projet. Garantit que chaque développeur et chaque test démarre dans un état connu et reproductible.
TECHNOLOGIES
Les 7 outils de notre stratégie qualité
Chaque outil a été sélectionné parce qu'il est le meilleur de sa catégorie pour notre usage. C'est notre veille technique continue qui nous permet de rester à jour et lorsque nous identifions un outil plus adapté, nous le remplaçons.
Pas d'attachement aux outils : notre attachement, c'est à la qualité de vos projets.
Analyse statique du code PHP pour détecter les erreurs avant qu'elles n'arrivent en production.
En savoir plus
Notre outil de tests unitaires pour garantir la fiabilité de chaque composant de votre application.
En savoir plus
Outil de refactoring automatique PHP qui modernise le code et applique les migrations de version sans intervention manuelle.
En savoir plus
Notre plateforme de versionning et CI/CD pour des déploiements automatisés et fiables.
En savoir plus
Notre framework de tests unitaires JavaScript natif Vite, utilisé pour tester nos composants Vue.js. Nous avons migré nos suites Jest vers Vitest.
En savoir plus
Notre outil de documentation et de développement isolé de composants Vue.js, utilisé pour documenter les composants UI et les règles métier de nos projets.
En savoir plus
Notre outil de tests end-to-end pour valider les parcours utilisateurs critiques de nos applications Vue.js et Symfony en conditions réelles de navigation.
En savoir plus« Les préconisations de Nicolas sur la mise en oeuvre d'une stack de développement Gitlab et sa parfaite connaissance du Framework Symfony m'ont fait gagner un temps précieux.
Toujours pro et dynamique, c'est un plaisir de travailler avec Nicolas. »
« Tout au long de notre collaboration, Nicolas a toujours su être un professionnel exemplaire. En tant que project manager, il sait prendre tous les sujets à bras-le-corps et les prioriser avec intelligence.
Il sait aussi donner la visibilité suffisante et rassurante sur les avancées de ses équipes. Nicolas se révèle être un interlocuteur crédible et efficace autant sur le plan technique que sur le plan de la gestion projet. »
Pour aller plus loin
Approfondir votre réflexion
La qualité de votre code actuel n'est pas mesurée ? Un audit technique vous donne un état des lieux objectif : couverture de tests, dette technique, risques et un plan d'action priorisé.
Les tests automatisés et l'analyse du code sont les premiers outils que nous déployons sur une reprise : ils sécurisent le projet avant de toucher au code existant.
La qualité est intégrée dès le premier sprint : fixtures en conception, PHPStan en CI, tests progressifs à chaque livraison.
FAQ
Les réponses à vos questions
Et si vous ne trouvez pas ce que vous cherchez, nous serons ravis de vous répondre en direct lors d'un rendez-vous entre humains !
Sur le premier développement, l'écriture des tests niveau 1 et 2 ajoute environ 10 à 15 % de temps sur une fonctionnalité. Nous constatons que ce temps est rentabilisé dès la phase de recette. Pour les autres niveaux il faut généralement 6 mois pour que cet investissement est largement rentabilisé : moins de régressions, moins de recette manuelle, moins de corrections urgentes. À terme, les tests accélèrent les nouveaux développements en donnant la confiance de modifier le code existant sans craindre de tout casser.
Cela dépend de la taille et de la complexité du code. Sur un projet Symfony de taille moyenne, commencer par PHPStan et les tests unitaires sur les objets métier critiques représente 5 à 10 jours. Cela nous permet également de monter en compétence sur votre métier et votre code. Nous recommandons de procéder progressivement : les parties les plus risquées en premier, puis d'élargir la couverture sprint après sprint plutôt qu'une mise à niveau complète en une fois.
Non. Nous ne maintenons pas de tests WebTestCase. Nous préférons couvrir les controllers et les parcours HTTP directement avec Playwright, qui teste dans un vrai navigateur et produit des screenshots en cas d'échec. Cela évite de maintenir deux niveaux de tests sur la même couche HTTP et donne une validation plus réaliste. Mais si votre projet utilise déjà ce type de tests, nous savons les maintenirs et les faire évoluer.
Les fixtures YAML sont créées pendant la phase de conception du ticket, avant le développement. Elles formalisent les données de référence : cas nominaux, cas limites, rôles utilisateurs. Chaque développeur travaille dans un environnement identique dès le premier clone du dépôt. Ces mêmes fixtures servent de base pour les tests de services et les démonstrations en recette.
Oui, sur deux niveaux. Vitest couvre la logique unitaire JavaScript : formatage, calculs, transformations. Storybook documente et teste chaque composant Vue.js dans ses états possibles. Playwright couvre les parcours utilisateurs complets dans un vrai navigateur, ce qui valide l'ensemble de la couche frontend en conditions réelles.
Elle est maintenue en continu, versionnée dans le dépôt Git. Chaque ticket peut inclure une mise à jour de la documentation associée. Les diagrammes Mermaid sont écrits directement dans les fichiers Markdown du dépôt, rendus automatiquement en HTML dans votre backoffice. En fin de projet, la documentation reflète l'état réel du logiciel, pas un état théorique rédigé des mois plus tôt.
Vous avez un projet ?
Contactez-nous pour savoir comment nous pouvons vous aider.