Un caso de prueba bien escrito permite ejecutar una verificación de forma clara, repetirla cuando sea necesario y comunicar qué se esperaba del sistema. También ayuda a que otra persona pueda entender la intención de la prueba sin depender únicamente de explicaciones verbales.
No todos los proyectos necesitan casos de prueba extensos, pero sí necesitan claridad. Un caso mal escrito puede generar dudas, ejecuciones diferentes, reportes incompletos y pérdida de tiempo.
En este tema veremos las partes más importantes de un caso de prueba y cómo escribirlas de manera útil.
Un buen caso de prueba debe responder tres preguntas fundamentales:
Si alguna de estas preguntas no está clara, la prueba puede quedar incompleta. Por ejemplo, "probar registro de usuario" no alcanza porque no indica qué datos usar, qué pasos ejecutar ni qué resultado esperar.
El identificador es un código único que permite referenciar el caso de prueba. Es útil para organizar, buscar, relacionar con requisitos y reportar defectos.
Ejemplos:
El identificador debe ser estable. Si el caso se menciona en un defecto o reporte, el equipo debería poder encontrarlo sin confusión.
El título debe resumir qué verifica el caso. Debe ser breve, pero suficientemente descriptivo.
Ejemplos poco claros:
Ejemplos más claros:
Un buen título permite entender rápidamente la intención del caso sin leer todos los detalles.
El objetivo explica qué se quiere comprobar y por qué la prueba existe. Es especialmente útil cuando el título no alcanza para expresar la intención completa.
Ejemplo:
El objetivo debe enfocarse en el comportamiento a validar, no en detalles irrelevantes de ejecución.
Cuando sea posible, conviene relacionar el caso de prueba con un requisito, historia de usuario, criterio de aceptación, caso de uso o defecto previo.
Ejemplos de referencias:
Esta relación mejora la trazabilidad. Si cambia un requisito, podemos identificar qué pruebas deben revisarse.
Las precondiciones describen lo que debe cumplirse antes de ejecutar el caso de prueba. Si las precondiciones no se cumplen, el caso puede fallar por una razón externa al comportamiento que queremos evaluar.
Ejemplos:
Una precondición clara evita confundir defectos reales con problemas de preparación.
Los datos de prueba son los valores que se usarán durante la ejecución. Pueden incluir usuarios, contraseñas, importes, fechas, productos, permisos, archivos o cualquier dato necesario.
Ejemplo:
Los datos deben ser controlados y adecuados para el ambiente. Nunca conviene usar datos sensibles reales si no es necesario y autorizado.
Los pasos describen las acciones que se deben realizar. Deben ser claros, ordenados y suficientes para reproducir la prueba.
Ejemplo:
Los pasos no deben ser tan vagos que generen dudas ni tan detallados que vuelvan el caso difícil de mantener. El nivel de detalle debe adaptarse al equipo y al riesgo de la prueba.
El resultado esperado es una de las partes más importantes del caso de prueba. Define qué debe ocurrir si el sistema funciona correctamente.
Ejemplo:
Un resultado esperado debe ser observable. Si decimos "el sistema funciona bien", no estamos definiendo una expectativa verificable.
Ejemplos de resultados esperados claros:
El resultado obtenido se completa durante la ejecución. Describe lo que realmente ocurrió.
Si coincide con el resultado esperado, el caso puede marcarse como aprobado. Si no coincide, puede marcarse como fallido y, si corresponde, registrarse una incidencia.
Ejemplo:
Registrar el resultado obtenido con precisión ayuda a analizar defectos y evita discusiones basadas en memoria o interpretaciones.
El estado resume el resultado de ejecutar el caso. Los estados más comunes son:
Usar estados consistentes permite generar reportes de avance y calidad.
La evidencia es información que respalda el resultado de una prueba. Puede ser especialmente importante cuando un caso falla o cuando se necesita demostrar que una validación fue realizada.
Ejemplos de evidencia:
No siempre hace falta adjuntar evidencia para cada prueba aprobada. Pero ante fallas, pruebas críticas o auditorías, puede ser fundamental.
Algunos equipos agregan una prioridad al caso de prueba. Esto ayuda a decidir qué ejecutar primero cuando el tiempo es limitado.
Ejemplo de clasificación:
La prioridad del caso no es lo mismo que la severidad de un defecto. La prioridad del caso indica qué tan importante es ejecutar esa prueba.
El ambiente indica dónde se ejecuta la prueba. Puede ser local, testing, QA, integración, preproducción o producción controlada.
Registrar el ambiente ayuda porque un caso puede comportarse distinto según configuración, datos, versión o servicios conectados.
Ejemplo:
Cuando un defecto solo ocurre en cierto ambiente, esta información es clave para reproducirlo.
| Identificador | CP-COMPRA-001 |
|---|---|
| Título | Compra exitosa de producto con stock disponible. |
| Objetivo | Verificar que un cliente pueda comprar un producto disponible y recibir confirmación. |
| Referencia | R-COMPRA-01, CA-COMPRA-01 |
| Precondiciones | Cliente activo. Producto con stock. Medio de pago de prueba habilitado. |
| Datos | Usuario cliente.activo@correo.com. Producto Notebook QA-100. Tarjeta de prueba aprobada. |
| Pasos | Iniciar sesión, buscar producto, agregarlo al carrito, confirmar compra, seleccionar medio de pago y finalizar operación. |
| Resultado esperado | El sistema registra la compra, descuenta stock, muestra número de pedido y envía confirmación. |
| Prioridad | Alta |
| Ambiente | QA |
Este ejemplo concentra las partes principales de un caso de prueba. En un proyecto real se podría agregar resultado obtenido, estado, evidencia, fecha y responsable de ejecución.
Ejemplo de caso mal escrito:
Problemas:
Versión mejorada:
La versión mejorada sigue siendo breve, pero ya contiene información suficiente para ejecutar y evaluar la prueba.
Al escribir casos de prueba, algunos errores frecuentes son:
Estos errores reducen la utilidad de la documentación y pueden generar pruebas inconsistentes.
Para escribir mejores casos de prueba conviene:
Un buen caso de prueba debe ser claro, útil y mantenible.
Un caso de prueba bien escrito no necesita ser largo, pero sí debe ser claro. Debe permitir entender qué se quiere verificar, cómo se ejecuta la prueba y qué resultado se espera.
La documentación de pruebas es útil cuando ayuda a repetir verificaciones, comunicar resultados, analizar defectos y mantener trazabilidad. Si se vuelve ambigua o excesiva, pierde valor.
En el próximo tema estudiaremos datos de prueba y preparación del ambiente, dos elementos fundamentales para que los casos puedan ejecutarse de manera confiable.