Respuesta.

La determinación de los límites de pruebas (scope) es una tarea fundamental para las pruebas manuales, permitiendo enfocarse en las partes más relevantes y críticas de la aplicación.

Historia de la pregunta

Con el desarrollo de proyectos, el volumen de funciones a probar aumenta, y cubrir todos los escenarios de manera manual se vuelve imposible. Con la llegada de Agile/desarrollo incremental, el rol de la determinación del scope ha crecido significativamente.

Problema

Si los límites de pruebas son difusos, surge el riesgo:

Realizar pruebas ineficaces, gastando recursos en funciones poco importantes
Pasar por alto errores críticos en escenarios importantes
Cruzarse con el trabajo de otros testers, creando duplicaciones

Solución

El scope de pruebas debe definirse en base a:

prioridades comerciales, escenarios de usuario y riesgos
análisis de requisitos, historias de usuario y especificaciones
consultas con el equipo (analistas, gerentes de producto, desarrolladores)

Características clave:

Focalización en las funciones principales y zonas de riesgo
Fijación/documentación explícita del alcance en el plan de pruebas para evitar malentendidos
Posibilidad de revisar rápidamente el scope ante cambios en los requisitos

Preguntas capciosas.

¿Es necesario probar absolutamente todo lo que se implementa, incluso los detalles más pequeños?

No, el principio de pruebas es enfocar en las partes prioritarias y críticas, especialmente donde es más probable que ocurran errores y los bugs tengan un impacto significativo en el negocio.

¿Puede el tester ampliar o reducir el scope autónomamente cuando surgen nuevos requisitos sin previa consulta?

No, cualquier cambio en el scope debe ser acordado con el gerente de producto o el líder de equipo para evitar brechas o duplicaciones de trabajo.

¿Es suficiente confiar únicamente en la documentación técnica para definir el scope?

No, se deben considerar también el contexto comercial, las tareas reales de los usuarios y la retroalimentación del cliente.

Errores comunes y anti-patrones

El scope no está fijado y cambia constantemente
Ignorar las prioridades comerciales en favor de funciones secundarias
Falta de comunicación entre los miembros del equipo al cambiar los límites de pruebas

Ejemplo de la vida cotidiana

Caso negativo

El tester decide cubrir todas las funciones y casos por su cuenta, resultando en falta de tiempo para probar los caminos críticos, mientras que los errores principales se escapan.

Pros:

Formalmente se han probado muchos escenarios

Contras:

Bugs críticos bloqueantes quedan sin ser notados debido a la dispersión de la atención
Retrasos por un volumen de pruebas injustificadamente grande

Caso positivo

Al inicio del sprint, el tester participa en la planificación, fija el scope junto con todo el equipo, enfocándose en los escenarios de usuario más importantes, acuerda el volumen de trabajo y lo documenta en Confluence.