Este enfoque aborda uno de los desafíos más difíciles que enfrentan los equipos en el desarrollo de software: romper el hábito de tratar las pruebas como una actividad posterior al desarrollo.
En muchas organizaciones, esa separación entre desarrollo y pruebas está profundamente arraigada en la estructura organizacional, la definición de roles y procesos.
El modelo de pruebas holísticas, desarrollado por Janet Gregory y Lisa Crispin, ayuda a los equipos a superar esa separación. Propone entender la calidad como un enfoque intencional que comienza en las primeras conversaciones sobre el valor de negocio y continúa a lo largo de la entrega y el aprendizaje continuo.
En lugar de preguntarnos: “¿Ya se realizaron las pruebas?”, el modelo promueve formular preguntas más profundas:
- ¿Cómo estamos previniendo malentendidos?
- ¿Cómo estamos reduciendo el riesgo desde etapas tempranas?
- ¿Cómo estamos validando los resultados?
- ¿Cómo estamos aprendiendo del uso real?
- ¿Cómo estamos fortaleciendo la responsabilidad compartida?
Este enfoque hace visibles distintas prácticas de calidad a lo largo del ciclo de vida, articulando necesidades del negocio, prácticas de ingeniería y retroalimentación continua.
El enfoque del modelo de pruebas holísticas
El modelo se inspiró en parte en la visualización “We test here” de Dan Ashby y evolucionó a partir de la mentalidad de pruebas ágiles, extendiendo su énfasis en la colaboración y la retroalimentación continua más allá de las iteraciones. Explicita que las prácticas de pruebas y calidad están presentes a lo largo del ciclo de vida, incluyendo ejemplos que los equipos pueden aplicar en distintos momentos del ciclo.
Estas prácticas no son prescriptivas ni exhaustivas. El objetivo no es que los equipos apliquen todas las prácticas, sino que cada equipo aplique aquellas que tengan sentido según su contexto, complejidad del sistema, riesgos y restricciones organizacionales. El modelo ofrece un punto de referencia compartido para conversar sobre cómo se construye y valida la calidad a lo largo de todo el ciclo.
En el lado izquierdo del ciclo, los equipos se enfocan en clarificar expectativas, hacer visibles los riesgos y construir un entendimiento compartido del sistema a desarrollar que guíe el desarrollo y contribuya a prevenir defectos.
En el lado derecho, el foco está en evaluar lo que ya fue construido. Aquí se valida el comportamiento del sistema, se identifican defectos que escaparon durante la construcción y se aprende del uso del sistema en producción. La retroalimentación proveniente del despliegue y producción influye en las próximas versiones.
El equilibrio entre prevención, validación y aprendizaje es lo que hace que el enfoque sea holístico.
Prevención: diseñar calidad antes de que exista el código
Durante las fases de descubrir, planificar y entender, los equipos se enfocan en actividades como:
- Probar las ideas y supuestos
- Identificar riesgos antes de la implementación
- Desglosar funcionalidades en historias pequeñas y testeables
- Utilizar ejemplos concretos para clarificar expectativas
- Definir atributos de calidad relevantes para su contexto, como rendimiento, confiabilidad y seguridad
Prácticas como ATDD, BDD y TDD funcionan como prácticas de colaboración que aclaran expectativas antes de implementarlas.
Este tipo de actividades ayudan a los equipos a construir un entendimiento compartido de lo que se quiere desarrollar, lo que se traduce en beneficios como:
- Disminución del rechazo de historias
- Reducción del retrabajo
- Acortamiento de los ciclos de retroalimentación
- Aumento de la confianza
Validación: retroalimentación continua a lo largo del ciclo de vida
La prevención construye alineación y reduce el riesgo. La validación se centra en evaluar lo que ya fue construido, asegurando que funcione como se espera en condiciones reales e identificando defectos que se escaparon durante la construcción. Ambos aspectos son esenciales, por lo que el lado derecho del ciclo es igualmente importante.
Durante las fases de desplegar, liberar, observar y aprender, los equipos validan el comportamiento del sistema y aprenden a partir de su funcionamiento en producción.
Para validar, los equipos se apoyan en prácticas como:
- Suites automatizadas de regresión diseñadas con propósito
- Flujos de despliegue que priorizan retroalimentación rápida
- Pruebas de atributos de calidad en entornos adecuados
- Pruebas exploratorias para descubrir escenarios no contemplados
- Estrategias de liberación seguras, como feature toggles
- Prácticas de monitoreo y observabilidad
La observabilidad es especialmente relevante. Cambia la conversación de reaccionar ante defectos a comprender el comportamiento del sistema en producción.
Aprender desde producción
Las prácticas de calidad y pruebas no terminan después de la liberación. El entorno de producción también es un espacio para generar aprendizaje que oriente las próximas decisiones.
Este aprendizaje se apoya en:
- Monitoreo y observabilidad del sistema
- Analítica de uso
- Experimentos guiados por hipótesis
La información obtenida en producción influye en las próximas fases de descubrimiento, la priorización de riesgos, el refinamiento de funcionalidades y mejoras en la arquitectura del sistema. De esta forma, las decisiones de mejora se basan en datos reales y no en suposiciones.
La calidad como responsabilidad compartida
Un principio central de este enfoque es que la calidad no puede delegarse a un rol o área específica. Es una responsabilidad compartida de todo el equipo.
Cada rol o perfil contribuye desde su expertise:
- Representantes del negocio contribuyendo al entendimiento del propósito y validando el valor entregado
- Desarrolladores diseñando para la testabilidad
- Testers facilitando la exploración de riesgos y promoviendo prácticas de pruebas a lo largo del proceso
- Profesionales de UX representando las necesidades de los usuarios
- Liderazgo creando seguridad psicológica
El rol de tester no se concibe como un guardián o policía de la calidad, sino como un facilitador y promotor de prácticas de calidad y pruebas en todo el proceso.
Alinear la calidad del proceso y la calidad del sistema
Una de las distinciones más importantes en el modelo de pruebas holísticas es la diferencia entre calidad del proceso y calidad del sistema.
La calidad del proceso se centra en cómo construimos:
- Estándares de codificación
- Cobertura de automatización
- Integración continua
- Definición de Hecho
La calidad del sistema se centra en lo que experimentan los usuarios:
- Usabilidad
- Rendimiento
- Confiabilidad
- Accesibilidad
- Valor de negocio
Ambas dimensiones son necesarias y complementarias. La disciplina interna del proceso no se traduce automáticamente en valor externo. Los equipos que optimizan solo métricas internas pueden perder de vista los resultados para los usuarios. Por el contrario, los equipos que se enfocan únicamente en la experiencia externa pueden acumular deuda técnica oculta.
La calidad sostenible depende del equilibrio consciente entre la disciplina interna y el valor externo. El modelo de pruebas holísticas hace explícita esa necesidad de alineación a lo largo de todo el ciclo de vida.
Por qué importa el modelo de pruebas holísticas
Los sistemas actuales, ya sean nuevos o heredados, suelen evolucionar constantemente e integrar múltiples componentes y dependencias. Las estrategias lineales de pruebas tienen dificultades para responder a este nivel de complejidad y cambio.
El modelo de pruebas holísticas hace visibles las prácticas de calidad y las convierte en un tema explícito de conversación, ayudando a:
- Construir con calidad desde el inicio
- Crear ciclos de retroalimentación más rápidos
- Reducir el riesgo sistémico
- Fortalecer la colaboración
- Impulsar la mejora continua
Preguntas frecuentes sobre el modelo de pruebas holísticas
¿Qué es el modelo de pruebas holísticas?
¿Cómo mejora los resultados de calidad el modelo de pruebas holísticas?
¿Es lo mismo que las pruebas ágiles?
¿Por qué es relevante para sistemas modernos?
¿Por qué debería importarle a los líderes tecnológicos?
¿Cuáles son las barreras comunes al adoptarlo?
Evalúa la madurez de tu estrategia de calidad de software
La calidad sostenible requiere más que esfuerzos aislados de pruebas. Nuestra Evaluación de madurez de calidad de software te permite analizar cómo tu equipo equilibra prevención, validación y aprendizaje, e identificar los siguientes pasos estratégicos.
