Cómo escribir casos de prueba con ejemplos
Tomas Hamilton
🚀 Resumen inteligente
Un caso de prueba es un conjunto documentado de condiciones, entradas, acciones y resultados esperados para verificar que una característica específica funciona correctamente en las aplicaciones de software.
¿Qué es un caso de prueba?
A caso de prueba Es un conjunto de acciones, insumos y resultados esperados que ayuda a los evaluadores a verificar si una característica o funcionalidad específica del software funciona según lo previsto. Sirve como un Guia paso a paso Eso define qué probar, cómo probarlo y qué resultado esperar.
Piensa en un caso de prueba como un receta para la validación — te indica los ingredientes exactos (datos de prueba), el proceso (pasos a seguir) y cómo debería ser un plato perfecto (resultado esperado).
Un caso de prueba bien redactado ayuda a garantizar:
- El software cumple con Requisitos empresariales y de usuario.
- Los errores o comportamientos inesperados son Captado a tiempo.
- Las pruebas pueden ser repetido y revisado por cualquier profesional de control de calidad.
- Los equipos pueden rastrear qué requisito verifica cada prueba.
👉 Inscríbete gratis en el proyecto de pruebas de software en vivo
Pasos para crear casos de prueba en pruebas manuales
Creemos un caso de prueba para el escenario: verificar la funcionalidad de inicio de sesión
Paso 1) Un caso de prueba simple para explicar el escenario sería
| Caso de prueba # | Caso de prueba Description |
|---|---|
| 1 | Verificar respuesta cuando se ingresa un correo electrónico y contraseña válidos |
Paso 2) Pruebe los datos.
Para ejecutar el caso de prueba, necesitaría Datos de prueba. Agregándolo a continuación
| Caso de prueba # | Caso de prueba Description | Datos de prueba |
|---|---|---|
| 1 | Verificar respuesta cuando se ingresa un correo electrónico y contraseña válidos | Correo electrónico: guru99@email.com Contraseña: lNf9^Oti7^2h |
La identificación de datos de prueba puede llevar mucho tiempo y, en ocasiones, puede requerir la creación de datos de prueba nuevos. El motivo por el que es necesario documentarlo.
Paso 3) Realizar acciones.
Para ejecutar un caso de prueba, un evaluador debe realizar un conjunto específico de acciones en la AUT. Esto se documenta a continuación:
| Caso de prueba # | Caso de prueba Description | Pasos de prueba | Datos de prueba |
|---|---|---|---|
| 1 | Verificar respuesta cuando se ingresa un correo electrónico y contraseña válidos | 1) Introduzca la dirección de correo electrónico
2) Ingrese la contraseña 3) Haga clic en Iniciar sesión |
Correo electrónico: guru99@email.com
Contraseña: lNf9^Oti7^2h |
En muchas ocasiones, los pasos de la prueba no son tan sencillos como se indica anteriormente, por lo que requieren documentación. Además, el autor del caso de prueba puede dejar la organización, irse de vacaciones, estar enfermo o muy ocupado con otras tareas críticas. Es posible que se le pida a un empleado recién contratado que ejecute el caso de prueba. Los pasos documentados le serán de gran ayuda y facilitarán las revisiones por parte de otros interesados.
Paso 4) Compruebe el comportamiento del AUT.
El objetivo de los casos de prueba en las pruebas de software es verificar que el comportamiento del sistema bajo prueba (SUT) produzca el resultado esperado. Esto debe documentarse como se muestra a continuación.
| Caso de prueba # | Caso de prueba Description | Datos de prueba | Resultado Esperado |
|---|---|---|---|
| 1 | Verificar respuesta cuando se ingresa un correo electrónico y contraseña válidos | Correo electrónico: guru99@email.com Contraseña: lNf9^Oti7^2h |
El inicio de sesión debe ser exitoso |
Durante el tiempo de ejecución de la prueba, el evaluador comparará los resultados esperados con los resultados reales y asignará un estado de aprobado o reprobado.
| Caso de prueba # | Caso de prueba Description | Datos de prueba | Resultado Esperado | Resultado actual | Contraseña errónea |
|---|---|---|---|---|---|
| 1 | Verificar respuesta cuando se ingresa un correo electrónico y contraseña válidos | Correo electrónico: guru99@email.com Contraseña: lNf9^Oti7^2h | El inicio de sesión debe ser exitoso | El inicio de sesión fue exitoso | Pasó |
Paso 5) Aparte de su caso de prueba, puede tener un campo como,
Una precondición especifica los requisitos que deben cumplirse antes de ejecutar la prueba. En nuestro caso, una precondición sería tener un navegador instalado para acceder al sitio web que se está probando. Un caso de prueba también puede incluir poscondiciones que especifican cualquier acción que se aplique una vez finalizada la prueba. En nuestro caso, una poscondición sería que la fecha y hora de inicio de sesión estén almacenadas en la base de datos.
Elementos clave de un caso de prueba
Un caso de prueba estándar suele incluir:
- ID de caso de prueba – Identificador único (p. ej., TC001)
- Título o Description – Qué verifica la prueba
- Condiciones previas – Lo que debe existir antes de que comience la prueba
- Pasos de prueba – Las acciones exactas a realizar
- Datos de prueba – Valores o parámetros de entrada
- Resultado Esperado – El resultado que debería ver
- Resultado actual – Lo que realmente sucedió
- Estado – Aprobado, Suspenso o Bloqueado
Caso de prueba frente a escenario de prueba
A escenario de prueba Describe qué se debe probar: la funcionalidad general o el recorrido del usuario.
A caso de prueba, Por otro lado, explica cómo se verificará esa funcionalidad: los pasos exactos, los datos y los resultados esperados.
En lenguaje sencillo:
- Escenario de prueba = Idea sobre qué probar.
- Caso de prueba = Implementación sobre cómo poner a prueba esa idea.
Piénsalo de esta manera:
“Si un escenario de prueba es el título de un capítulo, cada caso de prueba es un párrafo que explica ese capítulo en detalle.”
Ilustración de ejemplo:
Veamos un ejemplo para que quede más claro:
Escenario de prueba:
“Comprueba la funcionalidad de inicio de sesión del sitio web.”
Casos de prueba relacionados:
- Verifique el inicio de sesión con un nombre de usuario y contraseña válidos.
- Verifique el mensaje de error con contraseña no válida.
- Verificar inicio de sesión con campos vacíos.
- El campo de verificación de contraseña oculta el texto introducido.
Aquí, el escenario es un objetivo funcional único, mientras que los casos de prueba lo dividen en condiciones específicas y comprobables.
Lea para obtener más información sobre Diferencia entre caso de prueba y escenario de prueba
Beneficios de escribir casos de prueba de alta calidad
- Los casos de prueba de alta calidad garantizan una exhaustiva investigación. cobertura de pruebas, consistencia y trazabilidad en todo el proceso de control de calidad.
- Ayudan a los evaluadores a detectar errores tempranos, mantener estabilidad de regresióny garantizar que cada funcionalidad se ajuste a los requisitos del negocio.
- Los casos de prueba bien escritos son claro, reutilizable y repetible, permitiendo que cualquier herramienta de prueba o automatización las ejecute de manera confiable.
- También actúan como puente de comunicación entre desarrolladores, evaluadores y partes interesadas, reduciendo la ambigüedad y ahorrando tiempo.
- Al documentar los objetivos, los pasos y los resultados de las pruebas, los equipos pueden medir el progreso, cumplir con los estándares, y gestionar las actualizaciones de forma eficiente.
- Lo más importante: buenos casos de prueba reducir los costos de mantenimiento, acelerar la automatización y proporcionar confianza en la calidad del software.
- Sirven como documentación viva para la incorporación de nuevos evaluadores y como entrada estructurada para la IA y Herramientas de gestión de pruebas.
Errores comunes que se deben evitar al escribir casos de prueba
Incluso los evaluadores más experimentados cometen pequeños errores que debilitan la calidad de las pruebas.
Evitar estos errores puede mejorar drásticamente el precisión, claridad y mantenibilidad de su conjunto de pruebas.
- Escribir pasos vagos: Las instrucciones ambiguas como «comprueba la página de inicio de sesión» confunden a los evaluadores. Utiliza pasos claros y orientados a la acción.
- Evitar escenarios negativos: Incluya siempre entradas no válidas o pruebas de límites para garantizar una cobertura completa.
- Reutilización de datos de prueba poco claros: Los datos sin etiquetar o inconsistentes hacen que los resultados de las pruebas no sean fiables. Mantenga una hoja de datos de prueba compartida.
- Complicar en exceso los casos de prueba: Los casos largos y con múltiples pasos son difíciles de mantener. Mantén cada caso conciso y específico.
- Ignorar las actualizaciones tras los cambios del producto: Los casos de prueba obsoletos generan resultados falsos. RevRevisar y repasar regularmente.
- Falta de trazabilidad: Siempre vincule los casos de prueba con los requisitos para realizar un seguimiento de la cobertura y el cumplimiento.
- Omitir las revisiones por pares: Una mirada fresca detecta rápidamente los pasos poco claros o redundantes.
