Un formulario de checkout con cuatro campos (nombre, email, número de tarjeta, dirección de envío) tiene miles de combinaciones posibles de inputs antes de considerar las diferencias entre navegadores o las condiciones de red. El testing exhaustivo es matemáticamente imposible en cualquier funcionalidad real. El testing basado en riesgo resuelve esto con una fórmula de probabilidad por impacto: este artículo cubre cómo puntuar el riesgo para cualquier área de una aplicación, cómo construir una matriz que tu equipo pueda usar en la planificación del sprint, y cómo ajustar la cobertura cuando las prioridades cambian a mitad del sprint.
Por qué "probar todo" es una fantasía
Imagina un flujo de checkout con cuatro campos de formulario: nombre, email, número de tarjeta de pago y dirección de envío. Cada campo tiene un puñado de estados válidos e inválidos. Las combinaciones de inputs en los cuatro campos llegan a los miles antes de considerar siquiera las diferencias entre navegadores, las condiciones de red o los estados de sesión del usuario. Añade un campo de código de descuento y multiplicaste el espacio de prueba de nuevo.
Esto es la explosión combinatoria, y hace que el testing exhaustivo sea matemáticamente imposible en cualquier funcionalidad no trivial. El número de casos de prueba posibles crece exponencialmente a medida que añades variables. No puedes probarlos todos. La pregunta nunca es "¿probamos todo?" La pregunta es "¿probamos las cosas correctas?"
También está el problema de los rendimientos decrecientes. Tus primeros diez tests sobre una funcionalidad nueva detectan los bugs más obvios. Los siguientes diez detectan algunos más. Para el test cincuenta, estás generando casos que casi nunca fallan en la práctica, contra inputs que casi ningún usuario proporciona. El tiempo que inviertes en el test cincuenta podría usarse para cubrir otra área de alto riesgo que tiene cero tests.
El tiempo es finito. Los sprints terminan. Los releases salen. Necesitas una manera de asignar tu presupuesto de testing que refleje cuánto daño causaría realmente un fallo en cualquier área dada.
Riesgo = probabilidad × impacto
Cada área de un sistema lleva un nivel de riesgo. Ese riesgo tiene dos componentes: qué tan probable es que algo salga mal acá, y qué tan grave sería si pasara.
La probabilidad depende de factores como la complejidad del código, los cambios recientes, cuántos desarrolladores tocaron esta área, si involucra integraciones de terceros y cuánta lógica condicional hay. Una página estática simple que no se tocó en seis meses tiene baja probabilidad de fallo. Un módulo de procesamiento de pagos recién refactorizado que fue reescrito por dos desarrolladores en paralelo tiene alta probabilidad.
El impacto depende de qué se rompe si esta área falla. Una función de "ordenar por" rota es molesta. Un botón de checkout roto cuesta dinero cada segundo que está caído. Un bug de exposición de datos en perfiles de usuario es un problema legal. El impacto se mapea al riesgo de negocio: ingresos, reputación, cumplimiento, datos de usuarios.
Multiplica estos dos mentalmente y obtienes un nivel de riesgo para cualquier área dada. Alta probabilidad de fallo combinada con alto impacto significa que esta área recibe tu atención más profunda. Baja probabilidad combinada con bajo impacto significa un smoke test y seguir adelante.
La versión práctica no es una fórmula con números precisos. Es una conversación y un juicio. "Si esto falla, ¿qué pasa?" combinado con "¿Qué tan probable es que falle dado lo que sabemos?" te da suficiente para priorizar.
Identificar el riesgo: a quién preguntar y qué preguntar
La mejor información de riesgo no viene de mirar la funcionalidad sola. Viene de las personas que saben qué es frágil, qué cambió y qué salió mal antes.
Habla con el desarrollador que construyó la funcionalidad. Pregúntale dónde está inseguro. Los desarrolladores frecuentemente saben exactamente dónde vive la lógica complicada: el caso extremo que manejaron con un workaround, la integración que tiene un problema de timeout, la validación sobre la que no estaban seguros. Rara vez ofrecen esta información sin que se la pidan, pero responden directamente si preguntas.
Habla con el product manager o product owner. Pregúntale qué escenarios de usuario le generan más incertidumbre. Los PMs frecuentemente saben dónde se concentra el riesgo de negocio: el flujo que genera más ingresos, la funcionalidad que los clientes pidieron específicamente y que notarán si se comporta mal.
Mira los tickets de soporte y reportes de bugs anteriores. Si un área particular generó tres tickets de soporte en el último trimestre, te está diciendo algo. La inestabilidad pasada es uno de los mejores predictores de inestabilidad futura. Un bug tracker lleno de problemas del flujo de pago significa que el flujo de pago recibe atención extra, aunque los cambios del sprint actual parezcan pequeños.
Mira qué cambió. El código nuevo tiene más bugs que el código viejo. El código que se modificó mucho en este sprint es de mayor riesgo que el código que se tocó mínimamente. El diff te dice dónde mirar.
Finalmente, piensa en las integraciones. Cualquier lugar donde dos sistemas se comunican es de mayor riesgo que cualquiera de los sistemas por separado. La unión entre tu front end y la API de pago. La conexión entre tu servicio y el sistema de notificaciones por email. Los puntos de integración fallan de formas que los tests unitarios nunca detectan, porque cada lado se prueba a sí mismo de forma aislada.
Construir una matriz de riesgo: el ejemplo del flujo de pago
Toma una funcionalidad realista: un checkout de e-commerce con procesamiento de pagos. Así construirías una matriz de riesgo para ella.
Empieza listando las áreas del flujo: selección de producto, actualización de cantidad, aplicación de cupón, ingreso de dirección, selección de método de pago, ingreso de tarjeta, envío del pedido, email de confirmación, creación del registro del pedido, decremento de inventario.
Para cada área, evalúas probabilidad e impacto. El ingreso de tarjeta se integra con un procesador de pagos de terceros. La integración es compleja y los fallos acá pierden ingresos directamente. Alta probabilidad, alto impacto: esto recibe cobertura de tests con scripts completos más testing exploratorio. El envío del pedido une todo el flujo. Un fallo acá significa que no se realiza ningún pedido. Aunque la probabilidad sea moderada, el impacto es crítico. La validación de dirección es de menor riesgo: es lógica directa que no cambió recientemente, y un fallo solo muestra al usuario un mensaje de error. Menor prioridad.
La matriz podría verse así en la práctica:
| Área | Probabilidad | Impacto | Prioridad |
|------|-------------|---------|-----------|
| Integración de procesamiento de tarjetas | Alta | Crítico | P1: scripts + exploratorio |
| Envío del pedido / confirmación | Media | Crítico | P1: scripts |
| Lógica de código de cupón | Alta | Medio | P2: scripts |
| Validación de dirección | Baja | Bajo | P3: solo smoke test |
| Página de producto a carrito | Baja | Medio | P3: solo smoke test |
La matriz no tiene que ser exactamente esta tabla. Puede ser un documento simple, una página de Confluence, una tabla de Notion. El formato importa menos que el acto de hacer estos juicios explícitos y visibles, para que todo el equipo trabaje desde el mismo entendimiento de lo que está en juego.
Asignar cobertura de tests según el nivel de riesgo
Una vez que tienes una matriz de riesgo, las decisiones de cobertura siguen naturalmente. Las áreas de alto riesgo reciben cobertura en capas: casos de prueba con scripts para los escenarios conocidos, regresión automatizada para la ejecución repetida, y sesiones exploratorias para encontrar lo que los scripts no cubrieron. Las áreas de menor riesgo reciben un tratamiento más ligero.
Para el ejemplo del flujo de pago: la integración de procesamiento de tarjetas recibe tests con scripts para el camino feliz (tarjeta válida, cargo exitoso), caminos de error (tarjeta rechazada, tarjeta vencida, fondos insuficientes, CVV inválido) y casos extremos (tarjetas con códigos de país específicos, tarjetas que activan verificaciones de fraude). Luego recibe una sesión exploratoria enfocada en la gestión de estado: ¿qué pasa si el usuario envía el formulario dos veces? ¿Qué pasa si la red cae durante la llamada a la API? ¿Qué pasa si la respuesta se retrasa diez segundos?
El campo de validación de dirección recibe un smoke test: ingresa una dirección válida, confirma que se guarda. Eso es todo. Si falla, el impacto es recuperable: el usuario ve un error e intenta de nuevo. No justifica la misma inversión.
Esta asignación de cobertura es el output práctico del testing basado en riesgo. No estás recortando trabajo de forma arbitraria; estás siendo explícito sobre dónde se justifica la profundidad y dónde es suficiente la amplitud.
El mismo principio aplica a las suites de regresión. No todos los casos de prueba necesitan ejecutarse cada sprint. Los flujos de alto riesgo corren cada sprint, o en cada build si tienes la automatización. Los flujos de riesgo medio corren cada sprint. Los flujos de menor riesgo pueden rotar o correr solo cuando el código relevante cambió.
Comunicar las decisiones de riesgo a los stakeholders
El testing basado en riesgo requiere consenso, porque significa decidir explícitamente no probar ciertas cosas en profundidad. Esa decisión necesita ser visible y documentada, no invisible.
La herramienta práctica para esto es un log de riesgo o reporte de cobertura. No necesita ser elaborado. Lo esencial es: qué probaste, qué no probaste y por qué. "No ejecutamos regresión completa en el módulo de validación de dirección este sprint porque no hubo cambios de código y el área no tiene historial de fallos. Riesgo aceptado." Esa oración, en un resumen de testing del sprint, es lo que te protege de la pregunta "¿por qué no lo detectaste?" cuando algo de bajo riesgo finalmente falla.
Un reporte de cobertura cumple un propósito diferente: le muestra a los stakeholders dónde se concentró tu testing. Si un VP pregunta si probaste el flujo de pago antes del release de Black Friday, quieres señalar un documento que muestre cobertura P1 con tests con scripts, automatización y una sesión exploratoria, no dar una respuesta verbal de memoria.
Las decisiones de riesgo tomadas de forma explícita y documentadas crean responsabilidad sin culpa. Hiciste un juicio basado en la información disponible. Si el juicio resulta incorrecto porque un área de bajo riesgo falló inesperadamente, revisas la matriz y actualizas tu evaluación. No es un fallo del proceso; es el proceso funcionando como se diseñó.
Testing basado en riesgo en sprints Agile
En Agile, el riesgo no es estático. Cada sprint trae código nuevo, funcionalidades nuevas e información nueva sobre qué es frágil. Una evaluación de riesgo válida hace tres sprints puede ser completamente incorrecta hoy si el módulo de pago fue reescrito.
La disciplina es reevaluar el riesgo al inicio de cada sprint, como parte de la planificación del sprint o el kickoff de testing. Mira qué cambió. Pregunta a los desarrolladores sobre qué están inseguros. Revisa el diff. Actualiza la matriz. Esto lleva quince minutos si lo haces de forma consistente, y mantiene tus prioridades de testing actualizadas en lugar de derivar hacia la costumbre.
El backlog del sprint en sí te da señales de riesgo. Historias con estimaciones grandes, historias que tocan integraciones, historias que se debatieron en el refinement: estas son candidatas para una clasificación de mayor riesgo. Una historia que pasó el refinement con una estimación de dos puntos de un desarrollador que es dueño de ese código probablemente es de menor riesgo que una historia de seis puntos que requirió tres sesiones de refinement para delimitar su alcance.
La calidad de los criterios de aceptación es otra señal. Cuando los criterios de aceptación son detallados y específicos, el comportamiento esperado de la funcionalidad está bien entendido. Cuando son vagos (por ejemplo, "el usuario puede gestionar la configuración de su perfil"), hay más ambigüedad, lo que generalmente significa que más casos extremos no se pensaron, lo que generalmente significa mayor riesgo.
El objetivo en Agile no es construir una matriz de riesgo perfecta una vez. Es tener un panorama de riesgo ligero y revisable al inicio de cada sprint. Con el tiempo, esto se vuelve rápido. Desarrollas intuición para dónde se concentra el riesgo en tu producto específico, y la evaluación formal se agiliza porque actualizas un panorama familiar en lugar de construir uno desde cero.
Cómo aplicar esto el lunes por la mañana
No necesitas una herramienta nueva ni un proceso nuevo para empezar. Esto es lo que puedes hacer en tu próximo sprint.
Antes de empezar a probar una funcionalidad nueva, dedica diez minutos a escribir las áreas de esa funcionalidad y clasificarlas como riesgo alto, medio o bajo. Usa dos preguntas: "¿Qué tan compleja o incierta es esta área?" y "¿Qué se rompe en el negocio si esta área falla?" Ese ranking es tu matriz de riesgo.
Asigna tu tiempo antes de empezar a ejecutar. Si tienes ocho horas para una funcionalidad, decide de antemano: cuatro horas en el flujo de pago (scripts y exploratorio), dos horas en la validación del formulario (scripts), una hora en la pantalla de éxito (smoke), una hora en documentación y casos extremos que quieres investigar. Esa asignación, escrita, hace explícita la decisión de riesgo.
Haz una pregunta directa a un desarrollador antes de que empiece el testing: "¿Dónde en esta funcionalidad estás más inseguro?" Anota la respuesta y añádela a tu evaluación de riesgo. Este hábito único detecta más bugs que muchas técnicas de testing, porque los desarrolladores frecuentemente saben exactamente dónde están enterrados los problemas.
Al final del sprint, escribe un párrafo en tu resumen de testing sobre qué probaste y qué no. Guárdalo en un lugar compartido. En tres sprints, tendrás un historial de riesgo que te dice qué áreas han tenido consistentemente cobertura ligera, y cuáles pueden estar atrasadas para una mirada más profunda.
→ See also: Pruebas Exploratorias: La Habilidad que la IA No Puede Reemplazar | Cómo Escribir un Caso de Prueba: Formato, Ejemplos y Errores Comunes
