Testing en proyectos a medida: estrategia completa

Un bug en produccion cuesta entre 10 y 100 veces mas que detectarlo durante el desarrollo. Segun un estudio de IBM Systems Sciences Institute, el coste de corregir un defecto se multiplica exponencialmente con cada fase del ciclo de vida en la que pasa desapercibido.

Pese a estos datos, muchos proyectos de software a medida tratan el testing como un lujo opcional. Se escribe codigo, se prueba manualmente, se entrega al cliente, y se cruzan los dedos. Cuando los bugs aparecen (y siempre aparecen), se arreglan en caliente con parches que generan mas deuda tecnica.

Este articulo presenta una estrategia de testing completa y realista para proyectos a medida: que tipos de tests necesitas, cuando merece la pena implementar cada uno, y como construir una cultura de calidad sin paralizar el desarrollo.

Por que el testing es critico en proyectos a medida

El coste real de no testear

En un producto propio, puedes permitirte cierta tolerancia a bugs. Tienes equipos de soporte, puedes desplegar hotfixes rapidamente y tus usuarios (normalmente) te dan el beneficio de la duda.

En un proyecto a medida, la dinamica es diferente:

El cliente paga por calidad. Cada bug que llega a produccion erosiona la confianza del cliente y puede generar reclamaciones contractuales.

No hay segunda oportunidad para la primera impresion. Si la primera entrega esta llena de errores, el cliente cuestionara toda tu competencia tecnica. Recuperar esa confianza es extremadamente dificil.

Los bugs tienen coste directo. Cada bug que hay que corregir despues de la entrega consume horas que no estan presupuestadas. Si el contrato es de precio fijo, esas horas salen de tu margen.

La rotacion de equipo es un riesgo real. En consultoria, los equipos cambian. Sin tests, cada nuevo miembro del equipo tiene miedo de tocar el codigo porque no sabe que puede romper.

La falacia del “no tenemos tiempo para tests”

“No tenemos tiempo para escribir tests” es probablemente la frase mas cara del desarrollo de software. Parece razonable a corto plazo: escribir tests lleva tiempo, y el cliente quiere ver funcionalidades, no tests.

Pero los datos cuentan otra historia. Un estudio de Microsoft Research sobre equipos que implementaron TDD mostro que, aunque la fase inicial de desarrollo era entre un 15% y un 35% mas lenta, los defectos en produccion se reducian entre un 40% y un 90%.

En proyectos a medida, donde corregir un bug despues de la entrega puede costar 5-10 veces mas que prevenirlo, la inversion en testing se paga sola en las primeras semanas.

La pregunta correcta no es “tenemos tiempo para tests?” sino “que nivel de testing necesitamos para este proyecto?”

Tipos de tests y cuando usarlos

La piramide de testing

Mike Cohn popularizo la piramide de testing, que establece una jerarquia:

Base: Tests unitarios. Rapidos, baratos, muchos. Prueban funciones y metodos individuales de forma aislada.

Medio: Tests de integracion. Prueban que varios componentes funcionan correctamente juntos. Mas lentos y caros que los unitarios, pero detectan problemas de interaccion.

Cima: Tests end-to-end (E2E). Prueban flujos completos del usuario. Los mas lentos y caros, pero los que mas se parecen al uso real.

La piramide sugiere tener muchos tests unitarios, menos tests de integracion y pocos tests E2E. Es un buen modelo de referencia, pero no es dogma.

Tests unitarios: la base de todo

Los tests unitarios prueban una funcion, un metodo o una clase de forma aislada. Son los mas rapidos de ejecutar (milisegundos) y los mas baratos de escribir.

Cuando priorizarlos:

• Logica de negocio compleja (calculos, validaciones, transformaciones de datos)
• Funciones puras sin efectos secundarios
• Algoritmos criticos donde un error tiene consecuencias graves
• Codigo que sera reutilizado en multiples partes del sistema

Cuando no obsesionarse:

• Codigo de infraestructura (configuracion, conexiones a bases de datos)
• Controladores simples que solo delegan a servicios
• Getters y setters triviales
• Codigo que va a cambiar drasticamente en las proximas iteraciones

Cobertura objetivo realista: 70-80% en logica de negocio, 40-60% global. El 100% de cobertura es un objetivo contraproducente que lleva a escribir tests sin valor.

Tests de integracion: donde viven los bugs reales

Los tests de integracion prueban que componentes diferentes funcionan correctamente cuando se combinan. Por ejemplo: que tu servicio de usuarios se comunica correctamente con la base de datos y el sistema de autenticacion.

Donde aportan mas valor:

• Interacciones con bases de datos (queries, transacciones, migraciones)
• Llamadas a APIs externas
• Flujos de autenticacion y autorizacion
• Procesamiento de mensajes entre servicios
• Integraciones con servicios de terceros (pasarelas de pago, servicios de email)

Herramientas recomendadas:

• Testcontainers: Para levantar bases de datos, colas de mensajes y otros servicios en contenedores Docker durante los tests.
• WireMock o similar: Para simular APIs externas con respuestas predefinidas.
• Factores de datos (factories/fixtures): Para crear datos de prueba consistentes y mantenibles.

Regla practica: Si tu sistema interactua con componentes externos (bases de datos, APIs, colas), los tests de integracion probablemente detecten mas bugs reales que los unitarios.

Tests end-to-end: el usuario como referencia

Los tests E2E simulan el comportamiento real de un usuario. Abren un navegador (o simulan llamadas HTTP), navegan por la aplicacion, rellenan formularios, hacen clic en botones y verifican que el resultado es correcto.

Cuando implementarlos:

• Flujos criticos de negocio (registro, pago, procesos principales)
• Funcionalidades que generan ingresos directamente
• Flujos que involucran multiples servicios que necesitan funcionar coordinadamente
• Regresion en funcionalidades que ya se entregaron al cliente

Cuando evitarlos:

• Funcionalidades que cambian constantemente (los tests se rompen en cada cambio)
• Flujos no criticos donde un bug seria molesto pero no grave
• Cuando no tienes infraestructura de CI/CD para ejecutarlos automaticamente

Herramientas recomendadas para 2025:

• Playwright: La opcion mas completa. Soporta multiples navegadores, buena API, excelente debugging.
• Cypress: Buena experiencia de desarrollo, pero limitado a un solo navegador por ejecucion.

Numero de tests E2E recomendado: Entre 10 y 30 para un proyecto tipico de tamano medio. Cubren los happy paths criticos y los casos de error mas importantes.

Tests de contrato: para arquitecturas de servicios

Si tu proyecto tiene multiples servicios que se comunican entre si (microservicios, APIs entre frontend y backend), los tests de contrato verifican que ambas partes estan de acuerdo sobre el formato de la comunicacion.

Como funcionan:

1. El consumidor de la API define un contrato: “Espero que cuando llame a GET /users/1, me devuelvas un JSON con campos name y email.”
2. El proveedor de la API verifica que cumple ese contrato.
3. Si alguno de los dos cambia el contrato sin actualizarlo, el test falla.

Herramientas: Pact es el estandar de facto para tests de contrato.

Cuando usarlos: Cuando frontend y backend son desarrollados por equipos diferentes, o cuando tienes multiples servicios que necesitan mantenerse sincronizados.

Estrategia de testing por fase del proyecto

Fase de discovery y prototipado (semanas 1-4)

En esta fase, el objetivo es validar ideas rapidamente. El codigo va a cambiar drasticamente. No tiene sentido invertir mucho en tests automatizados.

Lo minimo necesario:

• Tests unitarios para logica de negocio critica (calculos, validaciones)
• Tests manuales estructurados (checklists de QA para cada entrega)
• Linting y analisis estatico configurados desde el dia uno

Lo que no necesitas todavia:

• Tests E2E completos
• Alta cobertura de codigo
• Tests de integracion exhaustivos

Fase de construccion (semanas 4-12)

Esta es la fase donde se construye el grueso del sistema. Aqui es donde la inversion en testing paga dividendos.

Estrategia recomendada:

• Tests unitarios para toda la logica de negocio nueva (70-80% cobertura en servicios de dominio)
• Tests de integracion para las interacciones con base de datos y APIs externas
• 5-10 tests E2E para los flujos criticos principales
• CI/CD configurado para ejecutar tests en cada push
• Code review con verificacion de que el nuevo codigo tiene tests

Regla del 80/20: El 80% del valor de tus tests viene del 20% del codigo. Identifica las partes criticas y concentrate ahi.

Fase de estabilizacion y entrega (semanas 12+)

Antes de la entrega final, el enfoque cambia de construir funcionalidades a asegurar que todo funciona correctamente.

Acciones clave:

• Ampliar tests E2E para cubrir los flujos secundarios
• Tests de regresion para funcionalidades ya entregadas
• Tests de rendimiento basicos (tiempos de carga, consultas lentas)
• Tests de seguridad basicos (inyeccion SQL, XSS, autenticacion)
• Pruebas de aceptacion con el cliente (UAT)

Fase de mantenimiento

Despues de la entrega, el sistema entra en mantenimiento. Aqui los tests existentes son tu red de seguridad.

Practica recomendada: Cada bug reportado se convierte en un test automatizado antes de corregirlo. Esto asegura que el bug nunca vuelve a aparecer y que la suite de tests mejora con el tiempo.

TDD en proyectos a medida: si o no

Que es TDD realmente

Test-Driven Development es una disciplina de desarrollo donde escribes el test antes del codigo:

1. Escribes un test que falla (rojo)
2. Escribes el minimo codigo para que pase (verde)
3. Refactorizas el codigo manteniendo los tests en verde (refactor)

Este ciclo rojo-verde-refactor se repite continuamente.

Cuando TDD aporta valor en proyectos a medida

Si, usa TDD para:

• Logica de negocio compleja con muchas reglas y casos especiales
• Algoritmos de calculo criticos (precios, impuestos, comisiones)
• Funcionalidades con reglas de validacion complejas
• Codigo que sera mantenido por otros desarrolladores

No, no uses TDD para:

• Prototipos y pruebas de concepto
• Interfaces de usuario que cambian constantemente
• Configuracion de infraestructura
• Codigo que conecta componentes sin logica propia (controllers, adapters triviales)

El enfoque pragmatico

En proyectos a medida, la realidad suele estar entre el TDD puro y no hacer tests. Un enfoque pragmatico:

Tests-first para logica critica. Cuando trabajas en calculos, validaciones o reglas de negocio complejas, escribe los tests primero. Te obliga a pensar en los casos limite antes de escribir el codigo.

Tests-after para el resto. Para controladores, servicios de orquestacion y codigo de infraestructura, escribe los tests despues de la implementacion. Sigue siendo mejor que no tener tests.

Sin tests para lo trivial. No escribas tests para codigo que es obviamente correcto o que es mas facil de verificar manualmente.

Automatizacion y CI/CD

El pipeline minimo viable

Todo proyecto a medida deberia tener, como minimo, un pipeline de CI/CD que ejecute:

1. Linting y formateo: ESLint, Prettier, o equivalentes. Detectan errores triviales y mantienen la consistencia del codigo.
2. Tests unitarios: Se ejecutan en segundos. Si fallan, el merge se bloquea.
3. Tests de integracion: Se ejecutan en minutos. Si fallan, el merge se bloquea.
4. Build: Verifica que el proyecto compila correctamente.

Herramientas recomendadas: GitHub Actions para la mayoria de proyectos. Es gratuito para repositorios privados con limites generosos y su configuracion es sencilla.

Tests E2E en CI/CD

Los tests E2E son los mas lentos y fragiles. Ejecutarlos en cada push puede ralentizar el ciclo de desarrollo.

Enfoque recomendado:

• Ejecutar tests E2E antes de merge a la rama principal (no en cada push a ramas de feature)
• Ejecutar tests E2E nocturnamente como check de regresion
• Mantener el numero de tests E2E por debajo de 30 para que la ejecucion complete en menos de 15 minutos

Entornos de testing

Entorno de desarrollo local: Cada desarrollador puede ejecutar tests unitarios y de integracion en su maquina. Usar Docker Compose para levantar dependencias (base de datos, servicios externos).

Entorno de staging: Replica de produccion donde se ejecutan tests E2E y se hacen pruebas manuales antes de desplegar.

Entorno de produccion: Monitoring y alertas, no tests activos. Opcionalmente, smoke tests post-despliegue que verifican que los endpoints criticos responden correctamente.

Errores comunes en testing

Escribir tests que no aportan valor

No todos los tests son utiles. Tests que verifican implementacion en lugar de comportamiento se rompen con cada refactorizacion sin detectar bugs reales.

Ejemplo de test sin valor: Verificar que un metodo llama a otro metodo especifico con parametros especificos. Si cambias la implementacion interna (pero el resultado es el mismo), el test falla.

Ejemplo de test con valor: Verificar que, dada una entrada especifica, la salida es la esperada. No importa como lo calcula internamente, importa que el resultado es correcto.

Ignorar los tests fragiles (flaky tests)

Los tests que fallan intermitentemente son un cancer. Si tu equipo empieza a ignorar fallos de tests porque “a veces fallan”, has perdido la confianza en tu suite de tests.

Regla estricta: Cada test fragil se investiga y se corrige en un plazo maximo de 48 horas. Si no se puede corregir, se elimina temporalmente y se crea una tarea para reescribirlo.

No mantener los tests

Los tests son codigo. Necesitan las mismas practicas que el codigo de produccion: refactorizacion, actualizacion, y eliminacion cuando ya no son relevantes.

Dedicar un 10% del tiempo de cada sprint a mantenimiento de tests. Actualizar fixtures, eliminar tests obsoletos, refactorizar tests complejos, y mejorar mensajes de error.

Medir cobertura como metrica de calidad

La cobertura de codigo mide cuanto codigo se ejecuta durante los tests. No mide la calidad de los tests.

Puedes tener 100% de cobertura con tests que no verifican nada util. Y puedes tener 50% de cobertura con tests que detectan todos los bugs criticos.

Usa cobertura como indicador, no como objetivo. Si la cobertura baja de un threshold (por ejemplo, 60%), investiga. Pero no optimices para subir la cobertura.

Framework de decision para equipos

Cuanto invertir en testing

La respuesta depende de tres factores:

Criticidad del sistema. Un sistema financiero necesita mas testing que un CMS interno. Un error en un calculo de nomina es mucho mas grave que un error en un widget de dashboard.

Duracion del mantenimiento. Si el sistema se va a mantener durante anos, la inversion en tests se amortiza con el tiempo. Si es un prototipo de 3 meses, invierte menos.

Tamano del equipo. Con mas personas tocando el codigo, mas necesitas tests como red de seguridad. Un equipo de 2 personas que se comunica bien puede confiar mas en el conocimiento compartido.

Tabla de inversion recomendada

Conclusion: testing como inversion, no como coste

El testing en proyectos a medida no es un lujo ni un seguro contra desastres. Es una inversion con retorno medible.

Tres principios para una estrategia de testing pragmatica:

1. Empieza por lo critico. Identifica los flujos que generan ingresos o que un fallo tendria consecuencias graves. Esos se testean primero.
2. Automatiza lo repetitivo. Todo test que vayas a ejecutar mas de 3 veces merece ser automatizado.
3. Mide resultados, no cobertura. Cuenta los bugs que llegan a produccion. Si bajan, tu estrategia funciona.

Si necesitas ayuda para definir la estrategia de testing de tus proyectos de software a medida, en NERVICO integramos testing como parte fundamental del proceso de desarrollo, no como una fase separada al final.