Testing en startups: quants tests calen per anar ràpid sense trencar res
He vist dos tipus de startups que fracassen amb el testing. I tots dos fracassen pel mateix motiu: el dogma.
La primera és la startup que no testeja res. "Som una startup, necessitem velocitat. Els tests ens alenteixen. Ja els escriurem quan tinguem product-market fit." Fan deploy de cada commit directament a producció, un divendres a la tarda, i el dilluns tenen tres clients enterprise amb tickets crítics que ningú no sap reproduir.
La segona és la startup que ho testeja tot. Cobertura del 95%. Cada component d'UI té tests de snapshot. Cada endpoint té tests per a edge cases que afecten el 0,01% dels usuaris. L'equip triga el doble a lliurar cada feature perquè cada canvi trenca 40 tests que ningú entén. I quan arriba una oportunitat de mercat, no poden pivotar perquè moure una funció significa reescriure 200 tests.
Cap dels dos extrems funciona. La resposta és a mig camí, i és més senzilla del que sembla.
La pregunta correcta no és «quant», sinó «què»
Deixa de pensar en percentatges de cobertura. La cobertura de codi és una mètrica de vanitat quan es fa servir com a objectiu. Pots tenir un 90% de cobertura i que cap dels teus tests no cobreixi la lògica de pagaments que de debò importa.
La pregunta correcta és: quines parts del meu sistema em deixen dormir tranquil si no tenen tests, i quines no?
Si el teu sistema de processament de pagaments falla i cobres dues vegades a un client, tens un problema existencial. Si un botó té 2px de marge extra a Safari, no es mor ningú.
El testing pragmàtic comença per identificar què pot fer mal de veritat i concentrar-hi els recursos limitats del teu equip.
La piràmide de testing encara aguanta — però les proporcions canvien
La piràmide clàssica de testing (molts unit tests, menys d'integració, pocs E2E) encara val, però en una startup les proporcions canvien:
Unit tests: la base, però només per a lògica de negoci. No testegis cada funció helper, cada utilitat de format de dates, cada mapper trivial. Testeja la lògica que calcula preus, que determina permisos, que processa dades de negoci. Si una funció conté un if que afecta els diners o les dades de l'usuari, mereix un test.
Integration tests: el teu millor aliat. Per a startups, els integration tests són els que més valor aporten per hora invertida. Un test que verifica que la teva API de creació de comandes funciona de punta a punta — validació, processament, persistència, resposta — et cobreix més terreny que 20 unit tests individuals de cada pas.
E2E tests: pocs, però crítics. Un test E2E que verifica el happy path complet del teu flux principal d'usuari (registre, acció core, pagament) és suficient per començar. No necessites 50 tests E2E cobrint cada variant. Necessites 3-5 que cobreixin els fluxos que generen ingressos.
En una startup en fase inicial, les proporcions haurien de ser, si fa no fa, aquestes:
- 60% integration tests per a fluxos de negoci crítics
- 30% unit tests per a lògica de negoci complexa
- 10% E2E tests per als happy paths principals
El que SEMPRE has de testejar
Hi ha components que no admeten discussió. Si no els testeges, estàs jugant a la ruleta:
Pagaments i facturació. Tot. Creació de cobraments, renovacions, cancel·lacions, reemborsaments, upgrades, downgrades. Cada edge case. Si cobres de més a un client, en perds la confiança per sempre. Si cobres de menys, perds diners. Testeja els càlculs de preus amb dades reals. Testeja la integració amb el teu processador de pagaments en mode sandbox.
Autenticació i autorització. Login, logout, refresh de tokens, expiració de sessions, control d'accés per rols. Si un usuari pot accedir a dades d'un altre usuari per culpa d'un bug d'autorització, tens un incident de seguretat que et pot enfonsar l'empresa. Comprova que un usuari amb rol X no pugui fer accions de rol Y.
Mutacions de dades crítiques. Qualsevol operació que modifiqui dades que no pots recuperar fàcilment. Creació de comptes, eliminació de recursos, canvis d'estat irreversibles. Comprova que les dades acaben en l'estat correcte després de cada operació, incloent-hi els edge cases de concurrència si escau.
Lògica de negoci core. L'algorisme que fa que el teu producte sigui el teu producte. Si és un sistema de matching, testeja el matching. Si és un motor de recomanacions, testeja les recomanacions. Si és un pipeline de processament, testeja cada transformació. Aquesta és la part que els teus usuaris paguen per fer servir.
El que pots saltar-te (de moment)
No tot mereix un test en una startup que encara no escala. Aquests són candidats raonables a posposar:
Tests d'UI pixel-perfect. Els tests de snapshot per a components d'UI generen soroll constant. Cada canvi de disseny trenca 30 snapshots i l'equip acaba fent --update automàticament sense revisar. El valor real és gairebé zero.
Edge cases extrems. Si tens 200 usuaris, no necessites testejar què passa quan 10.000 usuaris concurrents fan la mateixa operació. Aquell test té valor, però no avui. El necessitaràs abans d'escalar, no abans de tenir product-market fit.
Tests d'integració amb serveis externs per a fluxos no crítics. Si fas servir una API de geolocalització per mostrar l'hora local, no necessites un test E2E que verifiqui aquella integració. Amb un mock en tens prou.
Codi que canviarà radicalment. Si estàs prototipant un flux que saps que reescriuràs d'aquí a 2 mesos, invertir en tests exhaustius és cremar diners. Per a codi temporal, amb un smoke test bàsic ja fas.
Quan toca afegir més tests
El nivell de testing no és fix. Hauria de créixer amb el teu producte i el teu equip:
Abans del teu primer client enterprise. Els clients enterprise pregunten per testing, QA i pràctiques de desenvolupament. A més, les seves dades són més sensibles i les seves expectatives d'uptime són més altes. És el moment d'apujar el llistó.
Quan comences a tenir bugs recurrents en producció. Si el mateix tipus de bug apareix dues vegades, és un senyal clar que aquella àrea necessita tests. La regla és simple: cada bug en producció es converteix en un test abans del fix. Així no torna a passar mai més.
Abans de cada salt d'escala. Abans de passar de 100 a 1.000 usuaris, revisa quins fluxos queden exposats. Abans de passar de 1.000 a 10.000, fes el mateix. Cada ordre de magnitud revela debilitats que a una escala més petita quedaven amagades.
Quan l'equip creix. Amb 2 persones, tothom coneix tot el codi. Amb 8, no el coneix ningú. Els tests es converteixen en documentació viva que permet als nous membres de l'equip entendre què fa el sistema i modificar-lo amb confiança.
Eines: no et compliquis
No necessites 10 eines de testing. En necessites poques, ben configurades:
- Jest per a unit i integration tests en JavaScript/TypeScript. És l'estàndard de facto i funciona bé per al 90% dels casos.
- Playwright per a tests E2E. És més estable i més ràpid que Selenium, i l'experiència de desenvolupament és millor. Si ja fas servir Cypress, no migris només per migrar — totes dues eines fan la feina.
- Testing Library per a tests de components. Testeja comportament, no implementació.
- GitHub Actions o GitLab CI per executar els tests a cada PR. Si els tests no s'executen sols, no existeixen.
La clau és que els tests s'executin a la pipeline de CI/CD a cada pull request. Un test que només passa en local és un test que no existeix, perquè ningú no l'executarà de manera consistent.
Configura el CI perquè bloquegi els merges si els tests fallen. Sense excepcions. El dia que algú diu "és urgent, faig merge sense tests" és el dia que es mor la teva cultura de testing.
El cost real de no testejar
No testejar no és gratis. És deute que pagues amb interessos:
Els bugs en producció costen més. Un bug que atrapa un test es resol en qüestió de minuts. El mateix bug detectat per un client costa hores d'investigació, un hotfix sota pressió, comunicació amb el client afectat, i un dany reputacional que no es pot mesurar en hores.
La por de fer deploy. Sense tests, cada deploy és un acte de fe. L'equip comença a fer deploys cada cop menys sovint. Els canvis s'acumulen. Els deploys es fan més grossos i més arriscats. És un cercle viciós.
Refactoring impossible. Sense tests, ningú no gosa tocar el codi existent. La base de codi es va degradant perquè l'alternativa (refactoritzar i resar) és massa arriscada. Acabes amb un codebase que ningú no vol mantenir.
El testing és criteri d'enginyeria
I ara ve la veritat incòmoda: saber què testejar és més difícil que saber com testejar. Qualsevol desenvolupador pot aprendre Jest en una tarda. Però decidir què mereix un test, quin nivell de testing necessita cada component, i quan ha arribat el moment d'invertir més en qualitat — això demana experiència.
Un enginyer júnior ho testeja tot o no testeja res. Un enginyer sènior testeja exactament el que importa, i sap defensar la decisió davant de l'equip i del negoci.
A Conectia, quan validem enginyers, avaluem exactament això: criteri. No busquem gent que sàpiga escriure tests — busquem gent que sàpiga decidir quins tests escriure i per què. És un dels senyals més clars de seniority real enfront dels anys d'experiència en un CV.
Els enginyers sènior de LATAM que connectem amb startups europees aporten aquest criteri. Han treballat en productes en producció amb usuaris reals, han viscut les conseqüències de no testejar el que importa, i han après on és l'equilibri entre velocitat i confiança.
No necessites un equip de QA de 5 persones. Necessites 2-3 enginyers sènior que sàpiguen exactament on posar cada test.
El teu equip necessita enginyers sènior que sàpiguen equilibrar velocitat i qualitat des del primer dia? Parla amb un CTO — et presentem enginyers prevalidats que aporten criteri, no només codi.
