Testing en Startups: Cuánto Testing es Suficiente para Ir Rápido sin Romper Cosas
He visto dos tipos de startups que fracasan en testing. Y los dos fracasan por la misma razón: dogma.
La primera es la startup que no testea nada. "Somos una startup, necesitamos velocidad. Los tests nos ralentizan. Ya los escribiremos cuando tengamos product-market fit." Hacen deploy de cada commit directamente a producción, un viernes por la tarde, y el lunes tienen tres clientes enterprise con tickets críticos que nadie puede reproducir.
La segunda es la startup que testea todo. Cobertura del 95%. Cada componente de UI tiene tests de snapshot. Cada endpoint tiene tests para edge cases que afectan a 0,01% de los usuarios. El equipo tarda el doble en entregar cada feature porque cada cambio rompe 40 tests que nadie entiende. Y cuando llega una oportunidad de mercado, no pueden pivotar porque mover una función significa reescribir 200 tests.
Ninguno de los dos extremos funciona. La respuesta está en el medio, y es más simple de lo que parece.
La pregunta correcta no es "cuánto", sino "qué"
Deja de pensar en porcentaje de cobertura. La cobertura de código es una métrica de vanidad cuando se usa como objetivo. Puedes tener 90% de cobertura y que ninguno de tus tests cubra la lógica de pagos que realmente importa.
La pregunta correcta es: ¿qué partes de mi sistema me dejan dormir tranquilo si no tienen tests, y cuáles no?
Si tu sistema de procesamiento de pagos falla y cobras dos veces a un cliente, tienes un problema existencial. Si un botón tiene 2px de margen extra en Safari, nadie se muere.
El testing pragmático empieza por identificar qué puede causar daño real y enfocar ahí los recursos limitados de tu equipo.
La pirámide de testing para startups
La pirámide clásica de testing (muchos unit tests, menos integration, pocos E2E) sigue siendo válida, pero para startups la proporción cambia:
Unit tests: la base, pero solo para lógica de negocio. No testees cada función helper, cada utilidad de formato de fechas, cada mapper trivial. Testea la lógica que calcula precios, que determina permisos, que procesa datos de negocio. Si una función contiene un if que afecta al dinero o a los datos del usuario, merece un test.
Integration tests: tu mayor aliado. Para startups, los integration tests son los que más valor aportan por hora invertida. Un test que verifica que tu API de creación de pedidos funciona de extremo a extremo — validación, procesamiento, persistencia, respuesta — te cubre más terreno que 20 unit tests individuales de cada paso.
E2E tests: pocos, pero críticos. Un test E2E que verifica el happy path completo de tu flujo principal de usuario (registro, acción core, pago) es suficiente para empezar. No necesitas 50 tests E2E cubriendo cada variante. Necesitas 3-5 que cubran los flujos que generan revenue.
La proporción para una startup en etapa temprana debería ser algo así:
- 60% integration tests para flujos de negocio críticos
- 30% unit tests para lógica de negocio compleja
- 10% E2E tests para los happy paths principales
Lo que SIEMPRE debes testear
Hay componentes que no admiten discusión. Si no los testeas, estás jugando a la ruleta:
Pagos y billing. Todo. Creación de cobros, renovaciones, cancelaciones, reembolsos, upgrades, downgrades. Cada edge case. Si cobras de más a un cliente, pierdes su confianza para siempre. Si cobras de menos, pierdes dinero. Testea los cálculos de precios con datos reales. Testea la integración con tu procesador de pagos en modo sandbox.
Autenticación y autorización. Login, logout, refresh de tokens, expiración de sesiones, control de acceso por roles. Si un usuario puede acceder a datos de otro usuario por un bug de autorización, tienes un incidente de seguridad que puede hundir tu empresa. Testea que un usuario con rol X no puede hacer acciones de rol Y.
Mutaciones de datos críticas. Cualquier operación que modifique datos que no puedes recuperar fácilmente. Creación de cuentas, eliminación de recursos, cambios de estado irreversibles. Testea que los datos quedan en el estado correcto después de cada operación, incluyendo los edge cases de concurrencia si aplican.
Lógica de negocio core. El algoritmo que hace que tu producto sea tu producto. Si es un sistema de matching, testea el matching. Si es un motor de recomendaciones, testea las recomendaciones. Si es un pipeline de procesamiento, testea cada transformación. Esta es la parte que tus usuarios pagan por usar.
Lo que puedes saltarte (por ahora)
No todo merece un test en una startup pre-escala. Estos son candidatos razonables para posponer:
Tests de UI pixel-perfect. Los tests de snapshot para componentes de UI generan ruido constante. Cada cambio de diseño rompe 30 snapshots y el equipo termina haciendo --update automáticamente sin revisar. El valor real es cercano a cero.
Edge cases extremos. Si tienes 200 usuarios, no necesitas testear qué pasa cuando 10.000 usuarios concurrentes hacen la misma operación. Ese test tiene valor, pero no hoy. Lo necesitarás antes de escalar, no antes de tener product-market fit.
Tests de integración con servicios externos para flujos no críticos. Si usas una API de geolocalización para mostrar el tiempo local, no necesitas un test E2E que verifique esa integración. Un mock es suficiente.
Código que va a cambiar radicalmente. Si estás prototipando un flujo que sabes que vas a reescribir en 2 meses, invertir en tests exhaustivos es quemar dinero. Un smoke test básico es suficiente para ese código temporal.
Cuándo añadir más tests
El nivel de testing no es fijo. Debería crecer con tu producto y tu equipo:
Antes de tu primer cliente enterprise. Los clientes enterprise preguntan por testing, QA y prácticas de desarrollo. Además, sus datos son más sensibles y sus expectativas de uptime son más altas. Este es el momento de subir el nivel.
Cuando empiezas a tener bugs recurrentes en producción. Si el mismo tipo de bug aparece dos veces, es una señal clara de que esa área necesita tests. La regla es simple: cada bug en producción se convierte en un test antes del fix. Así nunca vuelve a pasar.
Antes de cada milestone de escala. Antes de pasar de 100 a 1.000 usuarios, revisa qué flujos están expuestos. Antes de pasar de 1.000 a 10.000, lo mismo. Cada orden de magnitud revela debilidades que a menor escala estaban ocultas.
Cuando el equipo crece. Con 2 personas, todos conocen todo el código. Con 8, nadie conoce todo. Los tests se convierten en documentación viva que permite a nuevos miembros entender qué hace el sistema y modificarlo con confianza.
Herramientas: mantenlo simple
No necesitas 10 herramientas de testing. Necesitas pocas, bien configuradas:
- Jest para unit e integration tests en JavaScript/TypeScript. Es el estándar de facto y funciona bien para el 90% de los casos.
- Playwright para E2E tests. Es más estable y más rápido que Selenium, con mejor developer experience. Si ya usas Cypress, no migres solo por migrar — ambos cumplen.
- Testing Library para tests de componentes. Testea comportamiento, no implementación.
- GitHub Actions o GitLab CI para ejecutar tests en cada PR. Si los tests no corren automáticamente, no existen.
La clave es que los tests corran en tu CI/CD pipeline en cada pull request. Un test que solo corre en local es un test que no existe, porque nadie lo va a ejecutar consistentemente.
Configura tu CI para que bloquee merges si los tests fallan. Sin excepciones. El día que alguien dice "es urgente, lo mergeo sin tests" es el día que la cultura de testing muere.
El coste real de no testear
No testear no es gratis. Es deuda que pagas con intereses:
Bugs en producción cuestan más. Un bug detectado por un test cuesta 15 minutos de fix. El mismo bug detectado por un cliente cuesta horas de investigación, un hotfix bajo presión, comunicación con el cliente afectado, y daño reputacional que no se mide en horas.
El miedo a deployar. Sin tests, cada deploy es un acto de fe. El equipo empieza a deployar menos frecuentemente. Los cambios se acumulan. Los deploys se hacen más grandes y más arriesgados. Es un ciclo vicioso.
Refactoring imposible. Sin tests, nadie se atreve a tocar código existente. El código se degrada progresivamente porque la alternativa (refactorizar y rezar) es demasiado arriesgada. Acabas con un codebase que nadie quiere mantener.
El testing es criterio de ingeniería
Y aquí está la verdad incómoda: saber qué testear es más difícil que saber cómo testear. Cualquier desarrollador puede aprender Jest en una tarde. Pero decidir qué merece un test, qué nivel de testing necesita cada componente, y cuándo es momento de invertir más en calidad — eso requiere experiencia.
Un ingeniero junior testea todo o no testea nada. Un ingeniero senior testea exactamente lo que importa, y sabe defender esa decisión ante el equipo y ante el negocio.
En Conectia, cuando validamos ingenieros, evaluamos exactamente eso: criterio. No buscamos gente que sepa escribir tests — buscamos gente que sepa decidir qué tests escribir y por qué. Es una de las señales más claras de seniority real vs. años de experiencia en un CV.
Los ingenieros senior de LATAM que conectamos con startups europeas traen ese criterio. Han trabajado en productos en producción con usuarios reales, han vivido las consecuencias de no testear lo que importa, y han aprendido dónde está el equilibrio entre velocidad y confianza.
No necesitas un QA team de 5 personas. Necesitas 2-3 ingenieros senior que sepan exactamente dónde poner cada test.
¿Tu equipo necesita ingenieros senior que sepan equilibrar velocidad y calidad desde el día uno? Habla con un CTO — te presentamos ingenieros pre-validados que aportan criterio, no solo código.
