Para probar de manera ordenada necesitamos organizar el trabajo. No alcanza con decir "probar login", "probar compras" o "revisar reportes". Debemos convertir esas ideas en elementos más concretos: escenarios de prueba, casos de prueba y suites de prueba.
Estos conceptos ayudan a planificar qué se probará, cómo se ejecutará, qué resultado se espera y cómo se agruparán las pruebas según el objetivo. También permiten comunicar el estado del testing y repetir verificaciones importantes en futuras versiones.
En este tema veremos qué significa cada concepto, cómo se relacionan y cómo usarlos sin caer en documentación excesiva.
Un escenario de prueba describe una situación o condición general que queremos evaluar. Suele ser más amplio que un caso de prueba y no siempre incluye pasos detallados.
Ejemplos de escenarios:
El escenario indica qué queremos cubrir. Luego, uno o varios casos de prueba indican cómo lo verificaremos concretamente.
Un caso de prueba es una descripción concreta de una verificación. Define condiciones iniciales, datos, pasos, resultado esperado y, durante la ejecución, resultado obtenido.
Un caso de prueba responde preguntas como:
Cuanto más importante o repetible sea una prueba, más conviene documentarla con precisión. Para pruebas exploratorias, la documentación puede ser más liviana, pero el objetivo y los hallazgos deben quedar claros.
Una suite de prueba es un conjunto organizado de casos de prueba relacionados por un objetivo común. Sirve para agrupar pruebas y ejecutarlas de manera ordenada.
Ejemplos de suites:
Una suite permite ejecutar un grupo de verificaciones según una necesidad concreta: validar una funcionalidad, revisar una versión, confirmar un despliegue o cubrir regresión.
| Concepto | Alcance | Ejemplo |
|---|---|---|
| Escenario de prueba | Situación general a evaluar. | Inicio de sesión con contraseña incorrecta. |
| Caso de prueba | Verificación concreta con pasos, datos y resultado esperado. | Ingresar usuario demo@correo.com y contraseña inválida; comprobar mensaje de rechazo. |
| Suite de prueba | Grupo de casos organizados por objetivo. | Suite de inicio de sesión: acceso correcto, contraseña incorrecta, usuario bloqueado y campos vacíos. |
Una forma simple de verlo: la suite agrupa casos; los casos concretan escenarios; los escenarios ayudan a identificar qué situaciones deben cubrirse.
Un caso de prueba puede tener más o menos detalle según el proyecto, pero normalmente incluye:
En el próximo tema profundizaremos específicamente en las partes de un caso de prueba bien escrito.
Escenario general:
Casos de prueba derivados:
Un solo escenario puede generar varios casos porque existen diferentes condiciones, datos y resultados esperados.
| Identificador | CP-LOGIN-001 |
|---|---|
| Título | Inicio de sesión exitoso con usuario registrado. |
| Objetivo | Verificar que un usuario registrado pueda ingresar al sistema con credenciales válidas. |
| Precondiciones | Existe un usuario activo con correo demo@correo.com y contraseña válida. |
| Datos | Correo: demo@correo.com. Contraseña: valor definido para el ambiente de prueba. |
| Pasos | Abrir la pantalla de login, ingresar correo, ingresar contraseña y presionar Ingresar. |
| Resultado esperado | El sistema debe iniciar sesión y mostrar la pantalla principal del usuario. |
| Estado | Se completa durante la ejecución. |
Este caso tiene un objetivo concreto y un resultado esperado claro. Eso facilita decidir si pasa o falla.
Durante la ejecución, los casos suelen marcarse con un estado. Los nombres pueden variar según la herramienta, pero los más comunes son:
Registrar estados permite comunicar avance y calidad de forma más objetiva.
Las suites pueden organizarse según diferentes criterios:
| Suite | Objetivo |
|---|---|
| Suite funcional | Validar una funcionalidad completa. |
| Suite de humo | Confirmar rápidamente que lo básico funciona antes de probar en detalle. |
| Suite de regresión | Comprobar que cambios nuevos no rompieron funcionalidades existentes. |
| Suite de aceptación | Validar que una entrega cumple criterios del usuario o negocio. |
| Suite por módulo | Agrupar pruebas de una zona específica del sistema. |
La misma prueba puede pertenecer a más de una suite si aporta valor en distintos contextos.
Los casos de prueba deberían relacionarse con requisitos, criterios de aceptación o riesgos. Esta relación permite saber por qué existe cada prueba y qué cubre.
Ejemplo de trazabilidad:
Si un requisito cambia, esta relación ayuda a identificar qué casos deben modificarse.
No todos los casos necesitan el mismo nivel de detalle. El detalle depende del contexto:
El objetivo no es escribir documentos largos. El objetivo es que la información sea suficiente para ejecutar, entender y mantener la prueba.
Un caso de prueba puede volverse difícil de mantener si describe cada acción mínima sin necesidad. Por ejemplo:
Ese nivel de detalle rara vez aporta valor y puede hacer que la documentación sea lenta de escribir y actualizar.
Una versión más útil sería:
El detalle debe ayudar, no convertirse en una carga innecesaria.
El problema opuesto es escribir casos tan vagos que no permiten decidir si la prueba pasó o falló.
Este caso no indica datos, pasos, condición ni resultado esperado. Una versión más clara sería:
Un caso demasiado vago depende excesivamente de la memoria o interpretación de quien lo ejecuta.
No todos los escenarios tienen la misma importancia. Al diseñar casos, conviene considerar riesgos:
Diseñar pruebas desde riesgos ayuda a priorizar cuando el tiempo es limitado.
Los casos de prueba no son documentos estáticos. Deben actualizarse cuando cambia el sistema, los requisitos, los datos o los riesgos.
El mantenimiento puede incluir:
Una suite desactualizada puede dar falsa confianza o consumir tiempo sin aportar valor.
Al trabajar con escenarios, casos y suites, algunos errores frecuentes son:
Estos errores dificultan la ejecución, el mantenimiento y la comunicación del estado de calidad.
Para organizar bien las pruebas conviene:
La documentación de pruebas debe ser suficientemente clara para ayudar al equipo, pero no tan pesada que impida trabajar con agilidad.
Escenarios, casos y suites de prueba ayudan a transformar una intención general de probar en un trabajo ordenado y comunicable. Los escenarios identifican situaciones importantes, los casos describen verificaciones concretas y las suites agrupan pruebas con un propósito.
Una buena organización permite repetir pruebas, informar avances, cubrir requisitos y mantener el conocimiento del producto. Pero esa organización debe ser práctica: suficiente para aportar claridad, sin convertirse en burocracia innecesaria.
En el próximo tema estudiaremos las partes de un caso de prueba bien escrito, para aprender a documentar pruebas de forma clara, útil y mantenible.