Ingénierie logicielle
Des tests qui détectent les régressions, pas des tests qui gonflent un taux de couverture
Une suite de tests vaut la peine d'être maintenue quand elle vous donne envie de déployer un vendredi. La plupart ne le font pas, pour l'une de ces deux raisons : elles testent le code plutôt que le comportement, donc elles cassent à chaque refactoring et passent alors que le panier est défectueux — ou elles sont si instables que tout le monde les relance jusqu'à ce qu'elles passent au vert.
Indicatif
À partir de £4 500
Prix fixe convenu par écrit avant le début de la réalisation.
Demander un devis+44 7488 265083Le problème que cela résout
Le taux de couverture est la métrique qui cause ce problème. Vouloir atteindre 80 % produit des centaines de tests sur des fonctions triviales et aucun sur les quatre parcours qui génèrent vos revenus. Par ailleurs, une suite instable est carrément nuisible : elle habitue l'équipe à ignorer le rouge, ce qui est pire que ne pas avoir de tests du tout.
Ce que vous obtenez
Tester les parcours qui rapportent
Inscription, connexion, recherche, ajout au panier, paiement, traitement administratif. Commencez par couvrir intégralement ces parcours avant de tester quoi que ce soit d'autre.
Le bon test au bon niveau
Tests unitaires pour la logique, tests d'intégration pour la couche de données, tests de bout en bout uniquement pour les parcours réels. Les tests de bout en bout sont lents et fragiles ; les utiliser pour tout est la raison pour laquelle les suites sont abandonnées.
Zéro tolérance pour l'instabilité
Un test instable est un défaut : il doit être corrigé ou supprimé, jamais relancé jusqu'à ce qu'il passe. Attentes déterministes et données préremplies plutôt que des délais arbitraires.
Intégré à la CI en tant que blocage
Exécuté à chaque pull request et bloquant la fusion en cas d'échec, avec un temps d'exécution suffisamment court pour que personne n'ait envie de le sauter.
Vérifications d'accessibilité et multi-navigateurs
Vérifications automatisées axe sur les pages clés, et exécutions réelles dans Chrome, Safari et Firefox. Les bugs de mise en page spécifiques à Safari sont fréquents et invisibles si vous ne testez qu'avec Chrome.
Échecs diagnostiquables
Captures d'écran, vidéos et traces enregistrées en cas d'échec, pour qu'un build rouge se diagnostique en deux minutes plutôt qu'après une après-midi de reproduction locale.
Notre méthode de travail
Identifier les parcours critiques
Quels parcours, s'ils tombaient en panne pendant une heure, vous feraient perdre de l'argent ou des clients. Cette liste constitue le plan de test.
Évaluer ce qui existe
Examen des tests actuels pour déterminer ce qu'ils vérifient réellement. Certains sont conservés, d'autres supprimés — un test qui ne peut pas échouer de manière significative est pire que rien.
Construire l'infrastructure de test
Génération de données de test, jeux de données et environnement permettant des exécutions répétables des tests.
Automatiser les parcours critiques
Couverture des parcours prioritaires en priorité, de bout en bout.
Intégrer à la chaîne CI
Intégration dans la chaîne d'intégration continue avec des vérifications obligatoires, tout en maintenant la rapidité de la suite.
Transfert de compétences
Vos développeurs écrivent des tests selon les mêmes méthodes, car une suite de tests maintenue par un seul prestataire disparaît lorsque celui-ci quitte le projet.
Ce à quoi vous devez vous attendre
- Détection des régressions sur les parcours critiques avant la mise en production
- Une suite de tests fiable, où le rouge signifie arrêt immédiat
- Déploiements ne nécessitant plus de validation manuelle préalable
- Échecs diagnostiquables directement depuis la CI, sans reproduction locale
Créé avec
- Playwright
- Cypress
- Vitest
- Jest
- PHPUnit
- Pest
- Testing Library
- axe-core
- GitHub Actions
- Lighthouse CI
- k6
Mainstream, well-supported technology — chosen so you can hire for it and so another team could take the project over.
Tests QA & logiciels — your questions
Y compris les questions relatives au coût, que la plupart des agences omettent sur leur site.
L’automatisation des parcours critiques d’une application web typique coûte entre £4 500 et £12 000 selon leur nombre et la testabilité actuelle de l’application. Si l’application ne présente aucune séparation logique pour les tests, un refactoring préalable est nécessaire, et nous l’évaluons séparément plutôt que de le dissimuler.
Nous ne ciblons pas un pourcentage, car c'est une mauvaise mesure — 90 % de couverture sans test du processus de paiement est pire que 40 % avec un test couvrant ce processus. L'objectif est que chaque parcours critique pour les revenus soit couvert de bout en bout et que chaque correction de bug s'accompagne d'un test capable de le détecter.
Playwright pour les nouveaux projets : support réel multi-navigateurs incluant Safari, parallélisme supérieur et son outil de traçage permet de diagnostiquer les échecs bien plus rapidement. Cypress est un excellent outil et nous maintenons les suites existantes plutôt que d'imposer une réécriture.
Oui. Parfois, l'application nécessite de petites modifications pour être testable — des sélecteurs stables, un moyen d'injecter des données, un point d'entrée pour contrôler le temps. Ces changements valent la peine d'être apportés, car un code difficile à tester est généralement difficile à modifier.
Pour les tests exploratoires avant une sortie majeure, oui — un humain détecte des problèmes d'utilisabilité que les assertions ne repèrent pas. Pour les tests de régression, non : répéter les mêmes vérifications manuellement à chaque sortie est coûteux, peu fiable et précisément ce que l'automatisation est censée éviter.
Services associés
La plupart des projets touchent à plus d’un de ces services.
Logiciels sur mesure
Systèmes sur mesure qui remplacent les tableurs, les transferts manuels et les outils standard que votre entreprise a dépassés.
Lire la suiteIngénierie DevOps & Cloud
Pipelines automatisés, infrastructure définie en code, et surveillance qui vous informe d’un problème avant qu’un client ne le remarque.
Lire la suiteDéveloppement et intégration d'API
Des API que d'autres développeurs peuvent utiliser sans vous poser de questions, et des intégrations qui gèrent correctement les pannes des services tiers.
Lire la suiteParlez à quelqu'un qui l'a déjà développé
A short call is usually enough to tell you whether this is the right service for your situation — including when it is not.