Testing en Startup : Combien de Tests Suffisent pour Aller Vite sans Tout Casser
J'ai vu deux types de startups echouer sur le testing. Et les deux echouent pour la meme raison : le dogme.
La premiere est la startup qui ne teste rien. "On est une startup, on a besoin de vitesse. Les tests nous ralentissent. On les ecrira quand on aura le product-market fit." Ils deploient chaque commit directement en production, un vendredi apres-midi, et le lundi ils ont trois clients enterprise avec des tickets critiques que personne ne peut reproduire.
La seconde est la startup qui teste tout. Couverture a 95%. Chaque composant d'UI a des tests de snapshot. Chaque endpoint a des tests pour des edge cases qui concernent 0,01% des utilisateurs. L'equipe met deux fois plus de temps a livrer chaque feature parce que chaque changement casse 40 tests que personne ne comprend. Et quand une opportunite de marche se presente, ils ne peuvent pas pivoter parce que deplacer une fonction signifie reecrire 200 tests.
Aucun des deux extremes ne fonctionne. La reponse est au milieu, et elle est plus simple qu'il n'y parait.
La bonne question n'est pas "combien", mais "quoi"
Arretez de penser en pourcentage de couverture. La couverture de code est une metrique de vanite quand elle est utilisee comme objectif. Vous pouvez avoir 90% de couverture sans qu'aucun de vos tests ne couvre la logique de paiement qui compte vraiment.
La bonne question est : quelles parties de mon systeme me laissent dormir tranquille sans tests, et lesquelles non ?
Si votre systeme de traitement des paiements plante et facture deux fois un client, vous avez un probleme existentiel. Si un bouton a 2px de marge en trop sur Safari, personne n'en meurt.
Le testing pragmatique commence par identifier ce qui peut causer un vrai dommage et concentrer les ressources limitees de votre equipe a cet endroit.
La pyramide de testing pour les startups
La pyramide classique de testing (beaucoup de tests unitaires, moins d'integration, peu de E2E) reste valide, mais pour les startups les proportions changent :
Tests unitaires : la base, mais uniquement pour la logique metier. Ne testez pas chaque fonction helper, chaque utilitaire de formatage de date, chaque mapper trivial. Testez la logique qui calcule les prix, qui determine les permissions, qui traite les donnees metier. Si une fonction contient un if qui affecte l'argent ou les donnees utilisateur, elle merite un test.
Tests d'integration : votre meilleur allie. Pour les startups, les tests d'integration sont ceux qui apportent le plus de valeur par heure investie. Un test qui verifie que votre API de creation de commandes fonctionne de bout en bout — validation, traitement, persistance, reponse — couvre plus de terrain que 20 tests unitaires individuels de chaque etape.
Tests E2E : peu, mais critiques. Un test E2E qui verifie le happy path complet de votre flux principal (inscription, action core, paiement) suffit pour commencer. Vous n'avez pas besoin de 50 tests E2E couvrant chaque variante. Vous avez besoin de 3 a 5 qui couvrent les flux qui generent du revenu.
La proportion pour une startup en phase initiale devrait ressembler a ceci :
- 60% de tests d'integration pour les flux metier critiques
- 30% de tests unitaires pour la logique metier complexe
- 10% de tests E2E pour les happy paths principaux
Ce que vous devez TOUJOURS tester
Il y a des composants qui ne se discutent pas. Si vous ne les testez pas, vous jouez a la roulette :
Paiements et facturation. Tout. Creation de charges, renouvellements, annulations, remboursements, upgrades, downgrades. Chaque edge case. Si vous facturez trop un client, vous perdez sa confiance pour toujours. Si vous facturez trop peu, vous perdez de l'argent. Testez les calculs de prix avec des donnees reelles. Testez l'integration avec votre processeur de paiement en mode sandbox.
Authentification et autorisation. Login, logout, refresh de tokens, expiration de sessions, controle d'acces par roles. Si un utilisateur peut acceder aux donnees d'un autre utilisateur a cause d'un bug d'autorisation, vous avez un incident de securite qui peut couler votre entreprise. Testez qu'un utilisateur avec le role X ne peut pas effectuer les actions du role Y.
Mutations de donnees critiques. Toute operation qui modifie des donnees que vous ne pouvez pas facilement recuperer. Creation de comptes, suppression de ressources, changements d'etat irreversibles. Testez que les donnees sont dans l'etat correct apres chaque operation, y compris les edge cases de concurrence si applicable.
Logique metier core. L'algorithme qui fait que votre produit est votre produit. Si c'est un systeme de matching, testez le matching. Si c'est un moteur de recommandation, testez les recommandations. Si c'est un pipeline de traitement, testez chaque transformation. C'est la partie pour laquelle vos utilisateurs paient.
Ce que vous pouvez sauter (pour l'instant)
Tout ne merite pas un test dans une startup pre-scale. Voici des candidats raisonnables a reporter :
Tests d'UI pixel-perfect. Les tests de snapshot pour les composants d'UI generent du bruit en permanence. Chaque changement de design casse 30 snapshots et l'equipe finit par faire --update automatiquement sans verifier. La valeur reelle est proche de zero.
Edge cases extremes. Si vous avez 200 utilisateurs, vous n'avez pas besoin de tester ce qui se passe quand 10 000 utilisateurs concurrents font la meme operation. Ce test a de la valeur, mais pas aujourd'hui. Vous en aurez besoin avant de scaler, pas avant d'avoir le product-market fit.
Tests d'integration avec des services externes pour des flux non critiques. Si vous utilisez une API de geolocalisation pour afficher l'heure locale, vous n'avez pas besoin d'un test E2E qui verifie cette integration. Un mock suffit.
Code qui va radicalement changer. Si vous prototypez un flux que vous savez devoir reecrire dans 2 mois, investir dans des tests exhaustifs c'est bruler de l'argent. Un smoke test basique suffit pour ce code temporaire.
Quand ajouter plus de tests
Le niveau de testing n'est pas fixe. Il devrait croitre avec votre produit et votre equipe :
Avant votre premier client enterprise. Les clients enterprise posent des questions sur le testing, la QA et les pratiques de developpement. En plus, leurs donnees sont plus sensibles et leurs attentes en termes d'uptime plus elevees. C'est le moment de monter en gamme.
Quand vous commencez a avoir des bugs recurrents en production. Si le meme type de bug apparait deux fois, c'est un signal clair que cette zone a besoin de tests. La regle est simple : chaque bug en production se transforme en test avant le fix. Ainsi il ne se reproduit plus jamais.
Avant chaque palier de croissance. Avant de passer de 100 a 1 000 utilisateurs, examinez quels flux sont exposes. Avant de passer de 1 000 a 10 000, meme chose. Chaque ordre de grandeur revele des faiblesses cachees a plus petite echelle.
Quand l'equipe grandit. Avec 2 personnes, tout le monde connait tout le code. Avec 8, personne ne connait tout. Les tests deviennent de la documentation vivante qui permet aux nouveaux membres de comprendre ce que fait le systeme et de le modifier en confiance.
Outils : restez simple
Vous n'avez pas besoin de 10 outils de testing. Vous en avez besoin de quelques-uns, bien configures :
- Jest pour les tests unitaires et d'integration en JavaScript/TypeScript. C'est le standard de facto et ca fonctionne pour 90% des cas.
- Playwright pour les tests E2E. Plus stable et plus rapide que Selenium, avec une meilleure experience developpeur. Si vous utilisez deja Cypress, ne migrez pas juste pour migrer — les deux font le travail.
- Testing Library pour les tests de composants. Testez le comportement, pas l'implementation.
- GitHub Actions ou GitLab CI pour executer les tests sur chaque PR. Si les tests ne tournent pas automatiquement, ils n'existent pas.
L'essentiel est que les tests tournent dans votre pipeline CI/CD a chaque pull request. Un test qui ne tourne qu'en local est un test qui n'existe pas, parce que personne ne l'executera regulierement.
Configurez votre CI pour bloquer les merges si les tests echouent. Sans exception. Le jour ou quelqu'un dit "c'est urgent, je merge sans tests" est le jour ou la culture de testing meurt.
Le cout reel de ne pas tester
Ne pas tester n'est pas gratuit. C'est de la dette que vous payez avec des interets :
Les bugs en production coutent plus cher. Un bug detecte par un test coute 15 minutes de fix. Le meme bug detecte par un client coute des heures d'investigation, un hotfix sous pression, une communication avec le client affecte, et des dommages a la reputation qui ne se mesurent pas en heures.
La peur de deployer. Sans tests, chaque deploy est un acte de foi. L'equipe commence a deployer moins frequemment. Les changements s'accumulent. Les deploys deviennent plus gros et plus risques. C'est un cercle vicieux.
Refactoring impossible. Sans tests, personne n'ose toucher au code existant. Le code se degrade progressivement parce que l'alternative (refactorer et prier) est trop risquee. Vous finissez avec un codebase que personne ne veut maintenir.
Le testing est une question de jugement d'ingenierie
Et voici la verite inconfortable : savoir quoi tester est plus difficile que savoir comment tester. N'importe quel developpeur peut apprendre Jest en un apres-midi. Mais decider ce qui merite un test, quel niveau de testing chaque composant necessite, et quand il est temps d'investir davantage dans la qualite — ca demande de l'experience.
Un ingenieur junior teste tout ou ne teste rien. Un ingenieur senior teste exactement ce qui compte, et sait defendre cette decision devant l'equipe et devant le business.
Chez Conectia, quand nous validons des ingenieurs, nous evaluons exactement cela : le jugement. Nous ne cherchons pas des gens qui savent ecrire des tests — nous cherchons des gens qui savent decider quels tests ecrire et pourquoi. C'est l'un des signaux les plus clairs de seniority reelle vs. des annees d'experience sur un CV.
Les ingenieurs senior d'Amerique latine que nous connectons avec des startups europeennes apportent ce jugement. Ils ont travaille sur des produits en production avec de vrais utilisateurs, ils ont vecu les consequences de ne pas tester ce qui compte, et ils ont appris ou se trouve l'equilibre entre vitesse et confiance.
Vous n'avez pas besoin d'une equipe QA de 5 personnes. Vous avez besoin de 2 a 3 ingenieurs senior qui savent exactement ou placer chaque test.
Votre equipe a besoin d'ingenieurs senior qui savent equilibrer vitesse et qualite des le premier jour ? Parlez a un CTO — nous vous presentons des ingenieurs pre-valides qui apportent du jugement, pas seulement du code.
