El testing depende del contexto: por qué copiar la estrategia de otro equipo te puede hundir

Llevas meses perfeccionando tu estrategia de testing. Tienes cobertura alta, pipelines verdes, tests end-to-end que cubren los flujos principales. Entonces cambias de proyecto y descubres que nada de lo que hacías encaja. Las pruebas que eran imprescindibles en tu equipo anterior aquí son innecesarias, y las que aquí necesitan con urgencia ni siquiera las habías considerado. No es que tu estrategia estuviera mal. Es que el testing no funciona con recetas universales.

El principio que muchos equipos ignoran

El sexto principio de ISTQB lo dice de forma directa: el testing depende del contexto. No se prueba igual una aplicación bancaria que un juego móvil, un marcapasos que un blog personal. Cada sistema tiene riesgos distintos, usuarios distintos, consecuencias de fallo distintas y restricciones regulatorias distintas. La estrategia de testing tiene que reflejar esas diferencias.

Parece obvio cuando lo lees así. Pero en la práctica, la mayoría de los equipos aplican la misma plantilla de testing a todos sus proyectos. La misma pirámide de tests, la misma distribución de esfuerzo, las mismas herramientas. Como si el contexto no existiera.

Tres mundos, tres realidades

Para entender por qué el contexto lo cambia todo, veamos cómo se prueba software en tres sectores con presiones completamente distintas.

Banca y servicios financieros

En banca, un bug puede significar que un cliente pierde dinero real. O que el banco incumple una regulación y recibe una multa millonaria. He trabajado con equipos donde cada cambio en el motor de cálculo de intereses requería trazabilidad completa desde el requisito hasta el test case, revisión por auditoría y aprobación formal antes de desplegar.

Los tests no son solo una herramienta de calidad, son evidencia regulatoria. Necesitas demostrar que probaste exactamente lo que dice la normativa, con los datos que la normativa exige, y que guardaste los resultados. La automatización importa, pero la documentación importa igual o más. Un test que pasa pero no deja rastro auditable es como si no existiera.

Aquí el testing de seguridad no es opcional: penetration testing, análisis de vulnerabilidades, validación de cifrado. Y el testing de rendimiento tiene requisitos contractuales. Si el sistema tarda más de dos segundos en procesar una transferencia, estás incumpliendo el SLA.

Startup en fase de validación

Ahora imagina el escenario opuesto. Una startup con seis personas, tres meses de runway y un MVP que necesita llegar al mercado antes de que se acabe el dinero. Si aplicas aquí el mismo rigor de testing que en banca, la empresa cierra antes de lanzar.

En este contexto, la velocidad de iteración es la prioridad absoluta. El producto va a cambiar radicalmente cada dos semanas según el feedback de los primeros usuarios. Escribir una suite exhaustiva de tests para una feature que probablemente se reescribirá el mes que viene es un desperdicio.

Eso no significa no testear. Significa elegir con mucho criterio qué testear. Los flujos críticos de negocio, como el proceso de pago o el registro, merecen tests sólidos. El resto se cubre con testing exploratorio, smoke tests rápidos y mucha observabilidad en producción para detectar problemas antes de que los usuarios los reporten.

Software médico

En dispositivos médicos el testing alcanza otro nivel. Un fallo en un marcapasos o en un sistema de dosificación puede matar a alguien. No es una exageración, es el motivo por el que existen estándares como IEC 62304 y procesos de certificación que pueden durar meses.

Cada requisito tiene que estar vinculado a tests específicos. Cada test tiene que estar vinculado a resultados documentados. Cada cambio, por mínimo que sea, dispara un ciclo de regresión completo. El concepto de “mover rápido y romper cosas” simplemente no existe en este mundo.

Aquí el testing no solo verifica que el software funciona correctamente, sino que demuestra que es seguro para el uso clínico. La trazabilidad no es burocracia, es lo que permite reconstruir exactamente qué se probó, cuándo y con qué resultado si algo sale mal con un paciente.

El error de copiar estrategias sin adaptarlas

El problema más frecuente que veo en equipos es importar frameworks de testing sin preguntarse si encajan. Ocurre en ambas direcciones.

Equipos pequeños que imitan a las grandes empresas. Leen que Google tiene millones de tests unitarios y deciden que ellos también necesitan una cobertura del 95 %. Con un equipo de tres desarrolladores y un producto que cambia cada semana. El resultado es una suite de tests que nadie mantiene, que se rompe constantemente por cambios en la UI y que acaba siendo ignorada o desactivada.

Equipos grandes que adoptan prácticas de startup. Escuchan que las startups exitosas despliegan diez veces al día con tests mínimos y deciden relajar sus controles. En un producto con miles de usuarios, dependencias regulatorias y un equipo de treinta personas donde no todos conocen todas las partes del sistema. Los bugs empiezan a llegar a producción con frecuencia creciente.

También he visto casos más sutiles. Equipos que aplican la misma estrategia a todos sus microservicios, cuando algunos son stateless y triviales y otros gestionan transacciones financieras. O equipos que testean la API interna con el mismo rigor que la API pública, cuando los riesgos y la superficie de ataque son completamente diferentes.

Cómo adaptar tu estrategia al contexto real

1. Empieza por el análisis de riesgo, no por las herramientas

Antes de decidir qué tests necesitas, hazte una pregunta simple para cada componente del sistema: qué pasa si esto falla. Las respuestas te dirán dónde concentrar el esfuerzo.

• Si el fallo afecta a dinero real, datos sensibles o la seguridad de personas, necesitas el máximo rigor.
• Si el fallo causa una molestia menor que se puede revertir rápidamente, puedes permitirte una cobertura más ligera con buena observabilidad.
• Si el componente es temporal o experimental, quizá baste con tests manuales y monitorización.

No todos los módulos de tu sistema merecen el mismo nivel de testing. Tratar todo con la misma intensidad es tan ineficiente como no testear nada.

2. Conoce las restricciones reales de tu entorno

Tu estrategia de testing tiene que ser viable dentro de las restricciones que tienes, no de las que te gustaría tener. Eso incluye el tamaño del equipo, el presupuesto, los plazos, las regulaciones aplicables y la madurez técnica del proyecto.

Un equipo de dos personas con un deadline agresivo no puede permitirse el mismo proceso que un equipo de veinte con ciclos de release trimestrales. Reconocer esa realidad no es conformismo, es pragmatismo profesional. Lo importante es maximizar el valor del testing dentro de tus limitaciones, no pretender que las limitaciones no existen.

3. Adapta la pirámide de tests al producto

La famosa pirámide con muchos tests unitarios, menos de integración y pocos end-to-end es un punto de partida razonable, pero no una ley universal. En una aplicación con lógica de negocio compleja y poca interfaz de usuario, los tests unitarios aportan mucho valor. En una aplicación que es básicamente un formulario conectado a una API externa, los tests de integración y los end-to-end son mucho más útiles que cientos de tests unitarios para validadores triviales.

Hay equipos que trabajan mejor con un “trofeo de tests” donde la mayor inversión está en integración, y otros donde los tests de contrato entre servicios son la pieza clave. La forma correcta depende de dónde están los riesgos reales de tu producto, no de lo que diga un artículo genérico.

4. Revisa la estrategia periódicamente

El contexto cambia. Un producto que empezó como un MVP puede convertirse en un sistema crítico para el negocio. Un equipo de tres personas puede crecer a quince. Una regulación nueva puede añadir requisitos de trazabilidad que antes no existían.

Revisa tu estrategia de testing al menos cada trimestre. Pregúntate si las prioridades siguen siendo las mismas, si los riesgos han cambiado, si hay zonas del sistema que ahora necesitan más atención. No esperes a que un incidente grave te obligue a replantearlo todo.

No hay una forma correcta de testear

Si hay algo que me ha enseñado la experiencia trabajando en proyectos muy distintos es que las mejores estrategias de testing son las que se diseñan para un contexto específico. No existen las mejores prácticas universales, solo prácticas apropiadas para cada situación.

El principio de ISTQB no dice que unos contextos necesitan más testing y otros menos. Dice que necesitan testing diferente. Un blog personal y un marcapasos pueden requerir niveles de esfuerzo muy distintos, pero ambos necesitan una estrategia de testing pensada para sus riesgos reales.

La próxima vez que alguien te diga que “hay que tener al menos un 80 % de cobertura” o que “los tests end-to-end no escalan”, antes de aceptarlo o rechazarlo pregúntate: en mi contexto, con mis riesgos, con mi equipo y mis restricciones, eso tiene sentido. A veces la respuesta será sí. Otras veces descubrirás que la receta genérica no aplica, y que la mejor decisión es diseñar tu propia estrategia desde cero.

Principio sexto de los siete del testing ISTQB. Vienes de La paradoja del pesticida y sigues con La falacia de la ausencia de errores.