Probar software sin organización puede generar esfuerzo repetido, zonas importantes sin cubrir, defectos reportados tarde y poca claridad sobre el estado real del producto. Para evitarlo, los equipos definen un plan de pruebas y una estrategia de testing.
El plan de pruebas ordena qué se probará, cómo, cuándo, con qué recursos y bajo qué condiciones. La estrategia de testing define el enfoque general para cubrir riesgos y obtener información útil sobre la calidad.
En este tema veremos ambos conceptos de forma introductoria y práctica, sin convertirlos en documentación excesiva.
Un plan de pruebas es un documento o acuerdo que describe cómo se organizará el trabajo de testing para una funcionalidad, versión, proyecto o producto.
Puede incluir:
El nivel de detalle depende del contexto. Un proyecto grande puede requerir un documento formal. Un equipo pequeño puede trabajar con una planificación más liviana, pero igual necesita acuerdos claros.
La estrategia de testing define el enfoque general que se usará para probar. Responde cómo se cubrirán los riesgos y qué tipos de pruebas serán más importantes.
Ejemplos de decisiones estratégicas:
La estrategia orienta las decisiones. El plan las baja a una organización concreta para un alcance determinado.
| Concepto | Pregunta principal | Ejemplo |
|---|---|---|
| Estrategia | ¿Qué enfoque general usaremos para probar y reducir riesgos? | Automatizar regresión crítica y complementar con pruebas exploratorias. |
| Plan | ¿Cómo organizaremos las pruebas de esta entrega concreta? | Ejecutar suite de humo el lunes, regresión el martes y aceptación el miércoles. |
En proyectos pequeños ambos conceptos pueden mezclarse en un mismo documento. Lo importante es que el equipo sepa qué probará y por qué.
El plan debe indicar qué se busca lograr con las pruebas. Los objetivos deben ser claros y realistas.
Ejemplos:
Un objetivo como "probar todo" no es útil porque no define prioridades ni alcance realista.
El alcance indica qué funcionalidades, módulos, flujos o requisitos serán probados.
Ejemplo de alcance:
Definir alcance evita malentendidos. Si una funcionalidad no será probada, también conviene indicarlo en el fuera de alcance.
El fuera de alcance indica qué no se probará en esa etapa o entrega. Esto es tan importante como definir lo que sí se probará.
Ejemplos:
Documentar fuera de alcance ayuda a comunicar riesgos pendientes.
Una buena estrategia de testing se basa en riesgos. No todas las funcionalidades tienen el mismo impacto si fallan.
Preguntas útiles:
El análisis de riesgo ayuda a decidir dónde concentrar el esfuerzo cuando el tiempo es limitado.
Una vez identificados los riesgos, se priorizan las pruebas. No todos los casos se ejecutan con la misma urgencia.
Ejemplo de prioridad:
| Prioridad | Criterio | Ejemplo |
|---|---|---|
| Alta | Flujo crítico, alto impacto o requisito obligatorio. | Pago, login, permisos, datos sensibles. |
| Media | Funcionalidad importante, pero no bloqueante. | Filtros, edición de perfil, notificaciones. |
| Baja | Caso poco frecuente o impacto menor. | Textos secundarios, combinaciones raras no críticas. |
El plan debe indicar qué niveles y tipos de prueba se ejecutarán. Por ejemplo:
Esta definición evita asumir que "probar" significa lo mismo para todos.
El plan debe indicar dónde se probará y qué datos se necesitan.
Ejemplo:
Si el ambiente o los datos no están listos, las pruebas pueden bloquearse. Por eso deben planificarse antes de la ejecución.
El plan puede indicar quién hará cada actividad. Ejemplo:
Definir responsabilidades reduce confusiones y evita que tareas importantes queden sin dueño.
Los criterios de entrada son condiciones que deben cumplirse antes de iniciar una etapa de pruebas.
Ejemplos:
Si no se cumplen los criterios de entrada, la ejecución puede ser ineficiente o inválida.
Los criterios de salida indican cuándo se considera finalizada una etapa de pruebas o cuándo una versión está en condiciones de avanzar.
Ejemplos:
Los criterios de salida no significan que el sistema no tenga defectos. Significan que se alcanzó un nivel de confianza acordado.
Los entregables son los resultados o documentos generados durante el proceso de pruebas.
Ejemplos:
No todos los proyectos requieren todos estos entregables. Deben elegirse según valor y contexto.
El plan puede incluir cuándo se ejecutarán las pruebas y cuánto tiempo se espera dedicar. Esto es importante porque testing suele depender de entregas, ambientes, datos y disponibilidad de personas.
Ejemplo:
El cronograma debe ser realista y contemplar tiempo para reprobar defectos corregidos.
| Objetivo | Validar la versión 2.4.0 antes de publicación. |
|---|---|
| Alcance | Login, recuperación de contraseña, compra y administración de productos. |
| Fuera de alcance | Pruebas de rendimiento y navegadores no soportados. |
| Riesgos principales | Pagos, permisos administrativos, stock y regresión de login. |
| Tipos de prueba | Funcionales, regresión, humo, permisos y aceptación. |
| Ambiente | QA con sandbox de pagos y datos preparados. |
| Criterio de salida | Sin defectos bloqueantes abiertos y casos críticos ejecutados. |
Este ejemplo es breve, pero ya comunica información clave para organizar la ejecución.
No todos los proyectos necesitan el mismo nivel de formalidad. Un producto regulado, financiero o médico puede requerir documentación detallada. Un equipo pequeño con entregas frecuentes puede trabajar con un plan más liviano.
Lo importante es que el plan sea útil. Debe ayudar a coordinar, priorizar y comunicar riesgos. Si el documento existe pero nadie lo usa, no aporta valor.
Al definir planes y estrategias de testing, algunos errores frecuentes son:
Estos errores reducen la utilidad del testing y aumentan la incertidumbre.
Para crear planes y estrategias útiles conviene:
El plan de pruebas y la estrategia de testing ayudan a transformar el esfuerzo de pruebas en un trabajo organizado y orientado por riesgos. No se trata de documentar por documentar, sino de tomar mejores decisiones sobre qué probar, con qué profundidad y con qué objetivo.
Un buen plan comunica alcance, prioridades, ambientes, responsabilidades, criterios y riesgos. Una buena estrategia asegura que el testing se enfoque en lo que realmente importa para la calidad del producto.
En el próximo tema estudiaremos ejecución de pruebas y registro de resultados, para ver cómo llevar el plan a la práctica y documentar lo observado.