Testing en Startups: Quant Testing és Suficient per Anar Ràpid sense Trencar Coses
He vist dos tipus de startups que fracassen en testing. I tots dos fracassen per la mateixa raó: 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ú pot 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 al mig, i és més simple del que sembla.
La pregunta correcta no és "quant", sinó "què"
Deixa de pensar en percentatge de cobertura. La cobertura de codi és una mètrica de vanitat quan es fa servir com a objectiu. Pots tenir 90% de cobertura i que cap dels teus tests cobreixi la lògica de pagaments que realment 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, ningú es mor.
El testing pragmàtic comença per identificar què pot causar dany real i enfocar-hi els recursos limitats del teu equip.
La piràmide de testing per a startups
La piràmide clàssica de testing (molts unit tests, menys integration, pocs E2E) segueix sent vàlida, però per a startups la proporció canvia:
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 revenue.
La proporció per a una startup en etapa primerenca hauria de ser alguna cosa així:
- 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 billing. Tot. Creació de cobraments, renovacions, cancel·lacions, reemborsaments, upgrades, downgrades. Cada edge case. Si cobres de més a un client, perds la seva 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 un bug d'autorització, tens un incident de seguretat que pot enfonsar la teva empresa. Testeja que un usuari amb rol X no pot 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. Testeja que les dades queden en l'estat correcte després de cada operació, incloent-hi els edge cases de concurrència si apliquen.
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 pre-escala. Aquests són candidats raonables per 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 proper a 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ó. Un mock n'hi ha prou.
Codi que canviarà radicalment. Si estàs prototipant un flux que saps que reescriuràs en 2 mesos, invertir en tests exhaustius és cremar diners. Un smoke test bàsic n'hi ha prou per a aquell codi temporal.
Quan 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. Aquest és el moment de pujar el nivell.
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í mai torna a passar.
Abans de cada milestone d'escala. Abans de passar de 100 a 1.000 usuaris, revisa quins fluxos estan exposats. Abans de passar de 1.000 a 10.000, el mateix. Cada ordre de magnitud revela debilitats que a menor escala estaven ocultes.
Quan l'equip creix. Amb 2 persones, tothom coneix tot el codi. Amb 8, ningú coneix tot. Els tests es converteixen en documentació viva que permet a nous membres entendre què fa el sistema i modificar-lo amb confiança.
Eines: mantingues-ho simple
No necessites 10 eines de testing. 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 E2E tests. És més estable i més ràpid que Selenium, amb millor developer experience. Si ja fas servir Cypress, no migris només per migrar — tots dos compleixen.
- Testing Library per a tests de components. Testeja comportament, no implementació.
- GitHub Actions o GitLab CI per executar tests a cada PR. Si els tests no corren automàticament, no existeixen.
La clau és que els tests corrin al teu CI/CD pipeline a cada pull request. Un test que només corre en local és un test que no existeix, perquè ningú l'executarà consistentment.
Configura el teu CI perquè bloquegi merges si els tests fallen. Sense excepcions. El dia que algú diu "és urgent, ho mergejo sense tests" és el dia que la cultura de testing mor.
El cost real de no testejar
No testejar no és gratis. És deute que pagues amb interessos:
Bugs en producció costen més. Un bug detectat per un test costa 15 minuts de fix. El mateix bug detectat per un client costa hores d'investigació, un hotfix sota pressió, comunicació amb el client afectat, i dany reputacional que no es mesura en hores.
La por a deployar. Sense tests, cada deploy és un acte de fe. L'equip comença a deployar menys freqüentment. Els canvis s'acumulen. Els deploys es fan més grans i més arriscats. És un cicle viciós.
Refactoring impossible. Sense tests, ningú s'atreveix a tocar codi existent. El codi es degrada progressivament perquè l'alternativa (refactoritzar i resar) és massa arriscada. Acabes amb un codebase que ningú vol mantenir.
El testing és criteri d'enginyeria
I aquí hi ha 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 és moment d'invertir més en qualitat — això requereix 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 aquella decisió davant de l'equip i davant 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 vs. anys d'experiència en un CV.
Els enginyers sènior de LATAM que connectem amb startups europees porten aquell 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 QA team 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 dia u? Parla amb un CTO — et presentem enginyers pre-validats que aporten criteri, no només codi.
