Respuesta.

La creación de casos de prueba es una de las bases de las pruebas manuales y una etapa clave para la verificación de la funcionalidad de la aplicación.

Historia de la pregunta: Durante mucho tiempo, los casos de prueba han sido el método central de control de calidad: permiten estructurar la verificación de requisitos y garantizan la repetibilidad de las pruebas independientemente de los cambios de probadores.

Problema: La principal dificultad es el equilibrio entre el exceso de detalle y la insuficiente elaboración. Los casos excesivamente detallados convierten las pruebas en una rutina lenta, mientras que los demasiado concisos pueden pasar por alto escenarios importantes. Se presentan problemas comunes:

Conexión insuficiente con los requisitos.
Omisión de casos límite.
Duplicación de escenarios.
Irrelevancia debido a cambios en el producto.

Solución: Para un caso de prueba efectivo es necesario:

Establecer una conexión de cada prueba con los requisitos (matriz de trazabilidad).
Utilizar técnicas de diseño de pruebas (partición equivalente, análisis de valores límite).
Realizar auditorías y actualizaciones regulares de los casos de prueba.
Involucrar al equipo de desarrollo y analistas para aclarar momentos complicados.

Características clave:

Estructuración según el principio "una prueba — un resultado esperado".
Actualización ante cambios en los requisitos.
Cobertura de todos los caminos, incluidos los casos negativos.

Preguntas capciosas.

¿Siempre se crean los casos de prueba antes del desarrollo?

No. Aunque es deseable escribirlos antes de la implementación (shift-left), en la práctica a menudo se mejoran a medida que llega nueva información o después de que se establece el entorno de pruebas.

¿Debería un caso de prueba verificar solo un escenario?

Sí, el principio clásico: "una prueba — un resultado" facilita el análisis de errores y la comprensión de lo que se ha probado. Las excepciones son posibles para escenarios end-to-end, pero también allí es importante delimitar claramente los resultados esperados.

¿Se puede confiar completamente en casos de prueba generados automáticamente a partir de requisitos?

No. Tales casos a menudo son superficiales y pueden pasar por alto lógicas de negocio importantes, valores límite o combinaciones de acciones: se necesita un análisis manual.

Errores comunes y antipatrón

Copiar casos antiguos sin adaptarlos a nuevos requisitos.
Omitir escenarios negativos.
Usar formulaciones vagas (por ejemplo, "el sistema funciona correctamente").

Ejemplo de la vida real

Caso negativo

El equipo tomó documentación de prueba antigua sin revisión y comenzó a usar casos de prueba que no se adaptaron a la funcionalidad cambiante.

Ventajas:

Ahorro de tiempo en la creación de nuevos documentos.

Desventajas:

Se pasaron por alto nuevas reglas de negocio, se descubrieron errores solo después de salir a producción.

Caso positivo

El probador revisó los casos de prueba, discutió los momentos difíciles con los analistas, identificó los obsoletos y llevó a cabo una revisión del nuevo equipo.