Un caso de prueba es, según la definición de ISTQB, «un conjunto de precondiciones, entradas, acciones, resultados esperados y postcondiciones, desarrollado a partir de condiciones de prueba». En términos prácticos: es la unidad más pequeña de trabajo de prueba que otra persona puede ejecutar sin preguntarte nada y cuyo resultado ambos van a interpretar igual. Todo lo demás que suele aparecer en una plantilla —identificador, prioridad, autoría, trazabilidad— es útil para gestionarlos, pero no forma parte de la definición.
Ver índice de contenidos
- 01La definición, y por qué importa la precisión
- 02Las cinco partes obligatorias
- 03Los campos que no son obligatorios pero sirven
- 04Condición, caso, procedimiento y suite
- 05El resultado esperado es la parte crítica
- 06Por qué cada caso debe poder correr solo
- 07Trazabilidad: para qué existe cada caso
- 08Dónde se guardan y cómo se gestionan
- 09Errores frecuentes al escribirlos
- 10Preguntas frecuentes
- 11Fuentes
La definición, y por qué importa la precisión
El glosario de ISTQB —el organismo que normaliza el vocabulario de testing a nivel internacional— define un caso de prueba como «un conjunto de precondiciones, entradas, acciones (cuando corresponda), resultados esperados y postcondiciones, desarrollado a partir de condiciones de prueba».
Esa definición parece burocrática hasta que se ve para qué sirve. Un caso de prueba tiene dos lectores: la persona que lo va a ejecutar, que necesita saber exactamente qué hacer, y la persona que va a leer el resultado, que necesita saber qué significa. Si falta cualquiera de las cinco partes, uno de los dos queda a ciegas.
En la comunidad de Underc0de hay una formulación equivalente y más directa. En el hilo «QMETRY desde cero», ANTRAX lo define así: «un caso de prueba es un conjunto de condiciones o acciones que se diseñan para verificar si un sistema o componente de software funciona correctamente y cumple con los requisitos y especificaciones establecidos», y agrega para qué sirven: «sirven como documentación, y para ver los alcances de las pruebas: qué se va a probar y cómo».
Un caso de prueba está terminado cuando otra persona del equipo puede ejecutarlo sin consultarte y los dos coinciden en si pasó o falló. Si tiene que preguntarte algo, falta información. Si pueden discutir sobre el resultado, falta precisión.
Esta guía se ocupa de qué es un caso y cómo se compone. Las técnicas para decidir cuáles escribir están en estrategias para escribir casos de prueba, y las decisiones de más arriba —qué probar y hasta dónde— en estrategias de prueba.
Las cinco partes obligatorias
Veámoslas sobre un caso real y completo. El ejemplo comprueba el buscador del índice de este portal, que filtra las guías en el cliente mientras se escribe.
El estado en el que tiene que estar el sistema antes de empezar: usuario, permisos, datos cargados, configuración, versión. Es la parte que más se omite y la que más fallos falsos genera.
Los datos concretos que se van a usar. No «un correo válido», sino el valor exacto, o la regla para generarlo si tiene que ser único.
Los pasos observables, uno por línea, con un solo verbo cada uno. Si un paso necesita una aclaración entre paréntesis, probablemente sean dos pasos.
Qué tiene que ocurrir, de forma verificable. Es la parte que decide si el caso sirve, y tiene su propia sección más abajo.
En qué estado queda el sistema al terminar. Sirve para dos cosas: encadenar casos con seguridad y saber qué hay que limpiar después.
Un detalle de la definición que suele pasarse por alto: dice «acciones cuando corresponda». Hay casos de prueba sin acciones, por ejemplo cuando se verifica el estado inicial de una pantalla o el resultado de un proceso que corre solo. No todo caso implica hacer clic en algo.
Los campos que no son obligatorios pero sirven
Cualquier plantilla real tiene más columnas que las cinco de la definición. Eso no es un error: los campos de gestión existen para poder trabajar con cientos de casos sin perderse. Conviene saber cuáles agregan valor de verdad.
| Campo | Para qué sirve | Vale la pena si… |
|---|---|---|
| Identificador | Referenciar el caso en un reporte de defecto o en una conversación | Siempre. Y estable: no se reutiliza al borrar un caso. |
| Título | Entender qué verifica sin abrir el caso | Siempre. Escribilo como afirmación comprobable, no como tema. |
| Prioridad | Decidir qué se ejecuta cuando no hay tiempo para todo | Siempre que la suite no se pueda ejecutar completa. |
| Trazabilidad | Saber qué requisito cubre y qué queda sin cubrir | Siempre que existan requisitos o historias escritas. |
| Tipo o nivel | Filtrar por funcional, regresión, humo, integración | Cuando la suite es grande y se ejecuta por subconjuntos. |
| Autoría y fecha | Saber a quién preguntar y si el caso envejeció | En equipos con rotación o suites de larga vida. |
| Duración estimada | Planificar una ronda de pruebas manuales | Solo si alguien usa esa estimación para planificar. |
| Resultado de la última ejecución | Ver el estado actual de la suite | Nunca en el caso mismo: va en el registro de ejecución. |
Ese último punto merece énfasis porque es un error estructural muy común: el caso de prueba y su ejecución son cosas distintas. El caso es la definición, que cambia poco; la ejecución es un evento con fecha, versión probada, persona que la corrió y resultado. Si se mezclan en la misma fila de una planilla, se pierde el historial en cuanto se vuelve a ejecutar.
En el foro hay una plantilla para armar casos de prueba que ANTRAX compartió en mayo de 2023, pensada justamente para cuando no hay una herramienta de gestión disponible. Es un buen punto de partida si estás armando la tuya.
Condición, caso, procedimiento y suite
Estos cuatro términos se usan como sinónimos todo el tiempo y no lo son. Tenerlos claros cambia la forma de organizar el trabajo, y además aparecen en entrevistas.
- Condición de prueba. ISTQB: «un aspecto verificable de un componente o sistema que se pretende probar». Es el qué, todavía sin ejecutar: «el buscador filtra resultados». Sus sinónimos reconocidos son situación de prueba, requisito de prueba e idea de prueba.
- Caso de prueba. Esa condición convertida en algo ejecutable, con las cinco partes de la sección anterior. Una condición suele dar lugar a varios casos: el que busca algo que existe, el que busca algo que no existe, el que busca con acentos.
- Procedimiento de prueba. ISTQB: «una secuencia de casos de prueba en orden de ejecución y cualquier acción asociada que sea necesaria para establecer las precondiciones iniciales y las actividades de cierre después de la ejecución». Es lo que se usa para flujos largos.
- Suite de pruebas. «Un conjunto de scripts o procedimientos de prueba que se ejecutan en una corrida determinada». Es la unidad de ejecución, no de diseño.
Hay un quinto término que conviene incorporar: la base de prueba, definida como «el cuerpo de conocimiento usado como base para el análisis y el diseño de pruebas». Son los requisitos, las historias, los diseños, la norma aplicable o la conversación con quien pidió la funcionalidad. Cuando alguien pregunta «¿de dónde saco los casos?», la respuesta es: de la base de prueba.
En español el término se usa con dos sentidos distintos y conviene aclarar cuál se está usando: a veces significa el procedimiento manual escrito paso a paso, y a veces el código de una prueba automatizada. Si trabajás en un equipo mixto, vale la pena acordar el vocabulario en la primera reunión y no en la tercera discusión.
El resultado esperado es la parte crítica
Si hay una sola sección de esta guía para leer con atención, es esta. El resultado esperado es lo que convierte una secuencia de pasos en una prueba: sin él, estás paseando por la aplicación.
La regla es que tiene que ser verificable sin criterio propio. Dos personas distintas mirando la misma pantalla tienen que llegar a la misma conclusión.
| Así no | Así sí |
|---|---|
| Verificar que funcione correctamente | El contador muestra el texto «1 guía encontrada» |
| El sistema responde rápido | La respuesta se completa en menos de 2 segundos |
| Se muestra un mensaje de error | Aparece el mensaje «El correo ya está registrado» debajo del campo |
| Los datos se guardan bien | Al recargar la página, el campo conserva el valor ingresado |
| La pantalla se ve como debe | El botón de envío está visible y habilitado sin necesidad de desplazarse |
Notá el patrón: la columna correcta siempre nombra un elemento concreto y un estado o valor concreto. Cuando no se puede escribir así, casi siempre es porque el requisito de origen también era vago, y eso es un hallazgo valioso: conviene resolverlo antes de que alguien programe sobre esa ambigüedad.
Y un caso especial que se olvida seguido: cuando lo que se prueba es que algo no pasa. «No se envía el formulario» es difícil de verificar en abstracto; «el botón permanece deshabilitado y no se crea ningún registro nuevo» sí lo es.
Por qué cada caso debe poder correr solo
Un caso de prueba tiene que poder ejecutarse en cualquier orden y de forma aislada. Suena a purismo y es lo contrario: es lo que evita perder tardes enteras.
Cuando un caso depende de que otro haya corrido antes —porque el primero creó el usuario que el segundo necesita— aparecen tres problemas concretos. El caso no se puede ejecutar solo para reproducir un defecto. Si el primero falla, el segundo falla también y el informe reporta dos problemas donde hay uno. Y la suite no se puede paralelizar, que es justamente lo que se necesita cuando crece.
La solución es que cada caso declare y prepare su propio estado en las precondiciones. Si necesita un usuario, lo crea o toma uno de un conjunto de datos de prueba conocido. Los datos que un caso deja atrás se limpian en las postcondiciones.
Si podés ejecutar tu suite en orden invertido y sigue dando el mismo resultado, tus casos son independientes. Si falla la mitad, tenés dependencias ocultas que van a costar caro más adelante.
Trazabilidad: para qué existe cada caso
La trazabilidad es el vínculo entre cada caso y el requisito, la historia o el riesgo que justifica su existencia. Es un campo administrativo con dos usos muy prácticos.
El primero es hacia adelante: dado un requisito, ¿qué casos lo cubren? Si la respuesta es «ninguno», hay un hueco. Es la única forma honesta de responder «¿ya probamos esto?» sin leer la suite entera.
El segundo es hacia atrás: dado un caso, ¿por qué existe? Los casos sin trazabilidad son los que nadie se atreve a borrar cuando dejan de tener sentido, y así las suites se llenan de pruebas que verifican comportamientos que ya cambiaron. Un caso que no se puede vincular a nada es candidato a revisión, no necesariamente a borrarse: a veces cubre un riesgo real que nunca se escribió.
El tercer uso aparece cuando algo se rompe: si un requisito cambia, la trazabilidad te dice exactamente qué casos hay que revisar. Sin ella, la alternativa es leerlos todos o —lo habitual— no revisar ninguno.
Dónde se guardan y cómo se gestionan
La herramienta importa menos que las tres propiedades que hay que conservar: identificador estable, versión visible y trazabilidad. Dicho eso, hay una progresión razonable según el tamaño del equipo.
- Planilla o documento compartidoSuficiente para pocas decenas de casos. Es donde encaja la plantilla que compartió la comunidad en el foro. El límite aparece cuando dos personas editan a la vez o cuando hace falta historial de ejecuciones.
- Herramienta de gestión de pruebasSuelen integrarse al gestor de incidencias del equipo, y aportan lo que la planilla no puede: ejecuciones con fecha y versión, trazabilidad automática y reportes. En el foro hay material de la comunidad sobre una de ellas.
- El código, para lo automatizadoCuando un caso está automatizado, su definición vive en el repositorio. El nombre de la prueba pasa a ser el título del caso, y por eso conviene que sea una afirmación comprobable y no
test1.
Ese tercer punto tiene una consecuencia que sorprende a quien viene de trabajo manual: en una suite automatizada bien escrita, no hay un documento aparte con los casos. El código es la documentación, y una prueba llamada el_buscador_filtra_a_una_sola_guia comunica lo mismo que el título de la fila de una planilla. Si te interesa cómo se llega ahí, la comparativa de herramientas de automatización es el siguiente paso.
Errores frecuentes al escribirlos
- Resultado esperado vago. «Verificar que funcione» convierte el caso en una opinión. Nombrá el elemento y el valor.
- Precondiciones implícitas. «Obviamente hay que estar logueado» no es obvio para quien ejecuta el caso a los seis meses.
- Casos que dependen del orden. Funcionan en la corrida completa y fallan al ejecutarlos sueltos, que es justo cuando más los necesitás.
- Varios objetivos en un solo caso. Cuando falla, no informa nada preciso. Un objetivo por caso.
- Pasos con más de una acción. «Completar el formulario y enviarlo» esconde dónde falló.
- Datos genéricos. «Un correo válido» hace que dos personas prueben cosas distintas. Poné el valor o la regla.
- Mezclar el caso con su ejecución. Guardar el último resultado dentro del caso borra el historial en la corrida siguiente.
- Escribir solo el camino feliz. Es donde menos defectos hay, porque es lo que más se usó durante el desarrollo.
Preguntas frecuentes
¿Cuál es la diferencia entre condición de prueba y caso de prueba?
La condición de prueba es el aspecto verificable que querés probar; el caso de prueba es esa condición convertida en algo ejecutable. ISTQB define la condición como «un aspecto verificable de un componente o sistema que se pretende probar», y el caso como «un conjunto de precondiciones, entradas, acciones, resultados esperados y postcondiciones, desarrollado a partir de condiciones de prueba». En la práctica: «el buscador filtra resultados» es una condición; el caso es el que dice con qué texto, desde qué estado y qué tiene que aparecer exactamente.
¿Cuántos pasos debería tener un caso de prueba?
No hay un número normativo, pero hay una señal clara: si pasás de ocho o diez pasos, probablemente estés cubriendo más de una condición en el mismo caso. El problema no es la longitud sino el diagnóstico: cuando un caso de veinte pasos falla, sabés que algo se rompió pero no qué. Casos cortos y con un objetivo cada uno fallan señalando la causa. La excepción legítima son los flujos de negocio largos que hay que recorrer completos, y para eso existe el procedimiento de prueba, que encadena varios casos.
¿Hace falta escribir casos de prueba en un equipo ágil?
Hace falta el pensamiento, no necesariamente el documento extenso. Lo que no se puede saltear es decidir qué se va a verificar y con qué criterio, porque eso es lo que separa probar de tocar botones. Lo que sí cambia es el formato: en muchos equipos ágiles ese contenido vive en los criterios de aceptación de la historia, en una lista de comprobación o directamente en el nombre de una prueba automatizada. La pregunta útil no es «¿escribimos casos?» sino «¿otra persona podría reproducir esto y sabría si pasó o falló?».
¿Un caso de prueba puede tener más de un resultado esperado?
Puede tener varias comprobaciones si todas pertenecen al mismo objetivo. Verificar que el contador diga «1 guía encontrada» y que además quede visible una sola tarjeta es razonable: son dos caras del mismo comportamiento. Lo que conviene evitar es meter en un caso comprobaciones de cosas distintas, porque cuando falla la tercera nadie sabe si las dos primeras se ejecutaron. Si las comprobaciones no comparten objetivo, son casos separados.
¿Dónde se guardan los casos de prueba?
Depende del tamaño del equipo. Con pocas pruebas alcanza una planilla o un documento compartido, y en el foro de Underc0de hay una plantilla de la comunidad para ese caso. Cuando el volumen crece se usan herramientas de gestión de pruebas, muchas integradas al gestor de incidencias del equipo. Lo importante no es la herramienta sino que los casos tengan identificador estable, versión visible y trazabilidad al requisito: sin eso, a los seis meses nadie sabe si un caso sigue siendo válido.
¿Qué hace que un caso de prueba sea malo?
Tres cosas, en orden de frecuencia. Que el resultado esperado sea vago: «verificar que funcione» no permite decidir si pasó. Que dependa de un estado no declarado, típicamente datos que dejó otro caso, lo que lo hace fallar cuando se ejecuta solo. Y que mezcle varios objetivos, con lo cual su resultado no informa nada preciso. Un caso bueno se reconoce por lo contrario: otra persona lo ejecuta sin preguntarte nada y ambos coinciden en si pasó o falló.
Fuentes
Glosario normativo, estándares y material de la comunidad consultados para esta guía. Fecha de consulta: 27 de julio de 2026.
- ISTQB. Glosario: test case. Definición de caso de prueba y sus cinco componentes.
- ISTQB. Glosario: test condition. Definición de condición de prueba y sus sinónimos reconocidos.
- ISTQB. Glosario: test procedure. Definición de procedimiento de prueba.
- ISTQB. Glosario: test suite y test basis. Suite de pruebas y base de prueba.
- ISO/IEC/IEEE. ISO/IEC/IEEE 29119 Software Testing. Serie de estándares de testing; la Parte 3 cubre documentación de pruebas y reemplaza a IEEE 829, todavía citada en material antiguo.
- Underc0de, foro. «Plantilla para armar casos de prueba (Checklist)», por ANTRAX, 16 de mayo de 2023, sección QA. Plantilla de la comunidad para trabajar sin herramienta de gestión.
- Underc0de, foro. «QMETRY desde cero», por ANTRAX, 19 de abril de 2023, sección QA. Definición de caso de prueba en español y gestión con herramientas.