Lección 5 de 7 · 3 min
Criterio de riesgo y plan de pruebas
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.
Ejercicio final
Elige una app real y arma su plan de pruebas de una página para un release imaginario. Compártelo con alguien y defiende tus decisiones de alcance — esa conversación ES el trabajo de QA.