"Necessitem construir el nostre propi framework de testing. Les eines estàndard no cobreixen els nostres casos d'ús específics."
El teu Tech Lead t'acaba de presentar una proposta de 6 setmanes per desenvolupar un framework de testing custom per a la teva aplicació SaaS. Arguments sòlids: més flexibilitat, integració perfecta amb el teu stack, control total sobre les features.
Però abans d'aprovar aquestes 6 setmanes de desenvolupament, hauries de fer-te una pregunta: La teva startup realment necessita un framework custom, o estàs caient en la trampa del "Not Invented Here"?
Aquesta és la guia completa de decisió build-vs-buy per a frameworks de testing, basada en 17 implementacions de QA en startups Sèrie A-B que hem fet a onext.
La síndrome "Not Invented Here" en testing
La síndrome NIH (Not Invented Here) és la tendència d'equips tècnics a preferir solucions desenvolupades internament per damunt de solucions externes provades, fins i tot quan les externes són objectivament millors.
En testing, es manifesta així:
- "El nostre cas d'ús és únic": Creiem que la nostra aplicació és tan especial que els frameworks estàndard (Jest, Cypress, Playwright) no la poden gestionar
- "Volem control total": Preferim escriure abstraccions pròpies per damunt d'eines existents per a "més flexibilitat"
- "És més ràpid fer-ho nosaltres": Subestimem l'esforç de mantenir infraestructura custom
- "Els nostres developers són millors": Creiem que podem construir alguna cosa superior a eines amb milions d'usuaris i anys de maduresa
Realitat dura: En 14 de 17 startups que vam auditar, el framework de testing custom que van construir en 4-8 setmanes va acabar abandonat o reemplaçat per eines estàndard en menys de 12 mesos. Cost: 30-60k € en developer time sense ROI.
Framework de decisió: 4 criteris per a Build vs Buy
Fes servir aquests 4 criteris per decidir si hauries de construir un framework de testing custom o adoptar eines estàndard:
Criteri 1: El teu cas d'ús és realment únic?
Test d'unicitat: Respon aquestes preguntes amb honestedat.
- Hi ha més de 100 empreses al món fent alguna cosa similar al que fas? → No ets únic
- El teu stack és Node/Python/Java + SQL/NoSQL + REST/GraphQL? → No ets únic
- Testeges UI web, APIs, o integració de serveis? → No ets únic
- Necessites tests unitaris, d'integració, i e2e? → No ets únic
Si has respost "sí" a alguna, les eines estàndard ja cobreixen el teu cas d'ús.
Casos on SÍ ets únic (build pot tenir sentit):
- Testeges hardware encastat amb protocols propietaris
- Testeges sistemes de temps real amb restriccions de latència <1ms
- Testeges algoritmes de trading d'alta freqüència on el timing és crític
- Testeges sistemes legacy amb protocols binaris custom dels anys 90
Regla d'or: Si Google, Facebook, Airbnb, i 10.000 startups més van resoldre el mateix problema de testing amb eines open-source, probablement tu també ho pots fer.
Criteri 2: Quin és el TCO (Total Cost of Ownership)?
Comparem el cost total de build vs buy en 3 anys:
Escenari A: Build (framework custom)
Any 1:
- Desenvolupament inicial: 6 setmanes x 2 developers sènior x 65 €/hora x 40h = 31.200 €
- Debugging i estabilització: 2 setmanes addicionals = 10.400 €
- Documentació interna: 1 setmana = 5.200 €
- Total any 1: 46.800 €
Any 2-3:
- Manteniment (bug fixes, compatibilitat amb noves versions de dependències): 2 hores/setmana x 52 setmanes x 65 €/h = 6.760 €/any
- Noves features (suport per a nous tipus de tests): 3 setmanes/any = 15.600 €/any
- Onboarding de nous developers: 4 hores per developer x 6 developers x 65 €/h = 1.560 €/any
- Total any 2-3: 23.920 €/any x 2 anys = 47.840 €
Cost total 3 anys: 94.640 €
Escenari B: Buy (eines estàndard: Jest + Playwright + GitHub Actions)
Any 1:
- Setup inicial: 1 setmana x 1 developer sènior = 2.600 €
- Configuració custom (reporters, fixtures, helpers): 1 setmana = 2.600 €
- Training de l'equip: 4 hores = 260 €
- Llicències: 0 € (eines open-source)
- CI runners (GitHub Actions): 50 €/mes x 12 = 600 €
- Total any 1: 6.060 €
Any 2-3:
- Manteniment: 0 (la comunitat manté les eines)
- Actualitzacions: 2 hores/any x 65 €/h = 130 €/any
- CI runners: 600 €/any
- Onboarding: 0 (documentació oficial + Stack Overflow)
- Total any 2-3: 730 €/any x 2 anys = 1.460 €
Cost total 3 anys: 7.520 €
Criteri 3: Tens l'expertise intern per mantenir-lo?
Construir un framework de testing no és només escriure codi. És:
- Dissenyar APIs intuïtives perquè l'equip les adopti
- Mantenir la compatibilitat amb actualitzacions de les teves dependències (Node, browsers, llibreries)
- Debuggejar edge cases que només apareixen en CI i no en local
- Documentar exhaustivament per a l'onboarding de nous developers
- Donar suport intern quan alguna cosa no funciona ("per què aquest test és flaky?")
Pregunta crítica: Tens algú a l'equip que vulgui ser el "maintainer" d'aquest framework durant els pròxims 2-3 anys?
Si la resposta és "no", no el construeixis. Tindràs un framework semi-abandonat que ningú no entén bé i que ningú no vol tocar.
"Vam construir un framework de testing custom el 2022. El developer que el va dissenyar va marxar de l'empresa el 2023. Ara ningú no sap com funciona internament. Cada cop que alguna cosa es trenca, perdem hores debuggejant. L'hauríem d'haver migrat a Playwright fa un any."
— CTO de SaaS B2B (Barcelona), 12 developers
Criteri 4: Construir el framework et dona avantatge competitiu?
La pregunta definitiva: Tenir un framework de testing millor que els teus competidors fa que els teus clients t'escullin a tu en lloc d'ells?
Resposta honesta: No. Als teus clients no els importa si fas servir Jest o un framework custom. Els importa que el teu producte funcioni sense bugs.
El teu avantatge competitiu és a:
- Features que els teus competidors no tenen
- UX superior
- Performance millor
- Integracions que altres no ofereixen
- Pricing més intel·ligent
El teu framework de testing és infraestructura interna. No genera revenue directament. Inverteix developer time en el que SÍ diferencia el teu producte.
Regla de Bezos aplicada al testing: "Amazon construeix internament només el que genera avantatge competitiu directe. Tota la resta es compra o es fa servir open-source." Aplica la mateixa regla al teu framework de testing.
Quan SÍ té sentit invertir en QA custom
No tot és blanc o negre. Hi ha escenaris on invertir en infraestructura de QA pròpia té sentit. Però l'enfocament és diferent de "construir un framework des de zero".
Opció smart: Centre d'Excel·lència de QA (no framework custom)
En lloc de construir un framework, construeixes metodologia, processos, i expertise per damunt d'eines estàndard.
Un CoE de QA inclou:
- Testing strategy documentada
- Què testejar a cada nivell (unit, integration, e2e)
- Cobertura target per tipus de codi (business logic: 80%, UI: 50%, utils: 95%)
- Quan fer servir mocks vs real dependencies
- Eines estàndard configurades amb best practices
- Jest amb custom reporters per a mètriques de cobertura
- Playwright amb page object model per a tests e2e mantenibles
- GitHub Actions amb matrix testing (multi-browser, multi-OS)
- Visual regression testing amb Percy o Chromatic
- Helpers i utilities custom (no framework complet)
- Factories per crear test data consistent
- Custom matchers per a assercions específiques del teu domini
- Fixtures per a setup/teardown de test environments
- CI/CD optimitzat per a testing ràpid
- Parallelization de tests (córrer 100 tests en 3 minuts en lloc de 20)
- Smart test selection (córrer només els tests afectats pel changeset)
- Flaky test detection i auto-retry
- Cultura de quality ownership
- Els developers escriuen tests com a part del PR (no un QA team separat)
- El code review inclou review de tests
- Mètriques de qualitat visibles (coverage, flakiness, MTTR de bugs)
Resultat: Tens testing de classe mundial sense mantenir un framework custom.
Cas d'èxit real: SaaS d'eCommerce (Sèrie B, 2,5 M€ ARR)
Context inicial (2024):
- Equip de 14 developers, 0 QA engineers
- Coverage: 28% (principalment tests escrits "per obligació", no per convicció)
- Tests e2e: 0 (testing manual abans de cada release)
- Bugs en producció: 12-15 per mes
- Temps de testing manual pre-release: 8 hores per developer
Transformació (8 setmanes de CoE de QA amb onext):
Setmana 1-2: Auditoria + Testing strategy
- Vam identificar 3 àrees crítiques amb 0 coverage que causaven el 70% de bugs en producció
- Vam dissenyar la testing pyramid: 70% unit, 20% integration, 10% e2e
- Vam definir coverage targets per tipus de codi
Setmana 3-4: Setup d'eines + Quick wins
- Vam configurar Jest amb custom reporters per visualitzar el coverage per feature
- Vam implementar Playwright per a tests e2e de user flows crítics
- Vam afegir 187 tests unitaris en àrees crítiques (business logic de checkout i payments)
- El coverage va pujar de 28% a 54%
Setmana 5-6: CI/CD optimization + Flaky tests elimination
- Vam configurar GitHub Actions amb matrix testing (3 browsers x 2 OS)
- Vam implementar paral·lelització: els tests van baixar de 18 minuts a 4 minuts
- Vam identificar i arreglar 12 tests flaky (de 14 en total)
Setmana 7-8: Enablement + Handoff
- Training de 4 sessions per a tot l'equip de desenvolupament
- Documentació interna: Testing playbook amb exemples reals del codebase
- Vam definir 2 "testing champions" interns per evangelitzar
Resultats (6 mesos post-implementació):
- Coverage: 76% (vs 28% inicial)
- Tests e2e: 42 tests cobrint el 90% de user flows crítics
- Bugs en producció: 3-4 per mes (reducció del 75%)
- Temps de testing manual pre-release: 0 (tot automatitzat)
- Confidence de l'equip: "Ara despleguem sense por"
Decision tree: Build vs Buy vs CoE
Fes servir aquest arbre de decisió per determinar la teva estratègia:
El teu cas d'ús és genuïnament únic?
- Sí (hardware encastat, trading HFT, protocols propietaris) → Consider BUILD framework custom
- No (web app, mobile app, APIs estàndard) → Continuar anàlisi ↓
Tens >100k € de developer time disponible per invertir en 3 anys?
- No → BUY eines estàndard (Jest, Cypress, Playwright)
- Sí → Continuar anàlisi ↓
Tens expertise intern en testing frameworks i algú committed a mantenir-lo?
- No → BUY eines estàndard
- Sí → Continuar anàlisi ↓
Un framework millor et dona avantatge competitiu directe?
- No → BUY eines estàndard
- Sí (ets una empresa de testing-as-a-service) → BUILD pot tenir sentit
El teu testing actual té cobertura <60% i bugs freqüents en producció?
- Sí → Implementar CENTRE D'EXCEL·LÈNCIA DE QA per damunt d'eines estàndard
- No → Mantenir les eines actuals i optimitzar els processos
Errors comuns en decidir Build vs Buy
- Subestimar el cost de manteniment a llarg termini
El 80% del cost d'un framework custom no és el desenvolupament inicial, és el manteniment durant 3+ anys. No ho oblidis. - Overengineer la solució des del dia 1
Si decideixes build, comença amb un MVP súper simple. No construeixis abstraccions per a casos d'ús que encara no existeixen. - No mesurar el ROI de la decisió
Defineix mètriques abans de començar: Quant temps estalvies? Quants bugs menys? Quant més ràpid fas l'onboarding dels developers? Si no millores aquestes mètriques, la decisió va ser incorrecta. - Ignorar el "time to market"
6 setmanes construint un framework són 6 setmanes sense lliurar features. Val la pena el trade-off? - No considerar l'opció híbrida (CoE)
No és build o buy. Pots fer servir eines estàndard + metodologia de classe mundial. Això és un Centre d'Excel·lència de QA.
El teu equip està debatent build vs buy per al testing?
Si el teu equip ha proposat construir un framework de testing custom, no l'aprovis immediatament ni el rebutgis d'entrada.
Fes una auditoria tècnica de 2-3 dies per avaluar:
- El cas d'ús és realment únic o ja existeix una solució provada?
- Quin és el TCO real de build vs buy en 3 anys?
- Quines mètriques de qualitat estem tractant de millorar?
- Un Centre d'Excel·lència de QA resoldria el problema sense build custom?
A onext implementem Centres d'Excel·lència de QA en startups Sèrie A-B. En 6-8 setmanes, transformem el teu testing de "coverage <40% amb bugs freqüents" a "coverage >70% amb tests ràpids i fiables".
Sense construir frameworks custom. Sense mantenir infraestructura pròpia. Sense paralitzar lliuraments.
Peça escrita per l'equip tècnic d'onext, consultora espanyola d'IA aplicada. Recull la pràctica de l'equip en transformació d'equips de desenvolupament, cloud, DevSecOps i qualitat: 12 equips transformats i 0 sprints perduts.