Lección 5 de 7 · 2 min
Criterio de riesgo y plan de pruebas
Al terminar sabrás
9 min- Priorizar qué probar con la fórmula riesgo = probabilidad × impacto
- Armar un plan de pruebas útil que quepa en una página
- Hacer explícita la decisión de qué NO se va a probar, antes del release
Construyes: El plan de pruebas de una página de una app real, listo para defender.
Nunca vas a alcanzar a probar todo
Esta es la lección más importante del curso. El testing exhaustivo es imposible (principio 2 del ISTQB), así que el trabajo real de un QA es decidir qué probar primero y qué aceptar no probar — y hacer esa decisión explícita.
La matriz de riesgo
Riesgo = probabilidad de fallo × impacto si falla. En la práctica:
| | Impacto bajo | Impacto alto | |---|---|---| | Cambia mucho | Prueba ligera | Prueba primero y a fondo | | Cambia poco | Casi no pruebes | Regresión automatizada |
¿Qué sube la probabilidad de fallo? Código nuevo, módulos históricamente buggy (los defectos se agrupan), integraciones con terceros, lógica con fechas y dinero.
¿Qué sube el impacto? Flujo de ingresos, datos de clientes, imagen pública, cumplimiento legal.
Con esa mirada, en una app de reservas: el flujo de reservar y el recordatorio WhatsApp son cuadrante rojo; el footer y la página "Términos" apenas merecen un vistazo.
El plan de pruebas de una página
Los planes de 40 páginas no los lee nadie. Uno útil cabe en una página:
QUÉ SE PRUEBA: Release 2.4 — nuevo flujo de reservas con dashboard
ALCANCE: Reservas, recordatorios, dashboard de ventas
FUERA: Módulo admin (sin cambios), blog
RIESGOS TOP: 1) Doble reserva simultánea 2) Zona horaria en recordatorios
3) Datos del dashboard vs realidad
ESTRATEGIA: Casos diseñados para riesgos top · exploratorio 2h sobre lo nuevo
· regresión automatizada completa · smoke manual en producción
CRITERIO DE SALIDA: 0 bugs críticos/mayores abiertos · suite e2e verde
Lo valioso no es el documento — es que la conversación "¿qué NO vamos a probar?" ocurra antes del release y no en la retrospectiva del incidente.
Estimar con la técnica del presupuesto
En vez de preguntar "¿cuánto demora probar esto?", pregunta "tengo 4 horas: ¿dónde las invierto?". Repartir un presupuesto fijo obliga a priorizar por riesgo de forma natural.
Cierre del curso
Ya tienes el kit completo de QA manual: entender el rol, diseñar casos, aplicar técnicas formales, reportar como profesional y priorizar con criterio. El siguiente paso natural es la automatización — Selenium con Python o directo a Playwright.
Cierra con el quiz y arma tu plan en el reto final de abajo.
Compruébalo
0/3Responde sin mirar atrás. Verás la explicación al instante.
1. ¿Cómo se calcula el riesgo de un área para priorizar?
2. ¿Qué NO sube la probabilidad de que un módulo falle?
3. ¿Cuál es el verdadero valor de un plan de pruebas de una página?
Reto final: arma un plan de una página
Elige una app real y arma su plan de pruebas de una página para un release imaginario: qué se prueba, qué queda fuera, riesgos top, estrategia y criterio de salida.
Compártelo con alguien y defiende tus decisiones de alcance — esa conversación ES el trabajo de QA.