La mayoría de los casos de prueba fallan antes incluso de detectar un solo error. Se redactan como listas de control imprecisas, carecen de condiciones previas, agrupan varias acciones en un solo paso o describen los resultados esperados de forma tan vaga que dos evaluadores que lean el mismo caso discreparían sobre lo que significa «superar la prueba». El resultado: las incidencias pasan desapercibidas, las ejecuciones de las pruebas no se pueden reproducir y el control de calidad se convierte en un cuello de botella en lugar de una red de seguridad.
Redactar un buen caso de prueba no tiene tanto que ver con la habilidad para realizar pruebas como con el diseño de la verificación. En el sector de los servicios financieros se conoce como el proceso «creador-verificador». En el comando nuclear se denomina «regla de las dos personas». El principio es el mismo: las tareas críticas nunca deben depender de una única acción sin verificar. Un caso de prueba bien redactado incorpora ese mismo rigor al software. Separa lo que se espera de lo que se observa, de modo que la diferencia entre ambos se vuelve imposible de ignorar.
Te mostraremos cómo redactar casos de prueba, por qué son importantes y cómo mejorar su calidad con el tiempo.
En resumen
Un caso de prueba define los pasos exactos, los datos de entrada y los resultados esperados necesarios para verificar que una función funciona correctamente. Cada uno debe incluir un ID único, las condiciones previas y los resultados esperados, de modo que se pueda comprobar el resultado. Esta guía describe el proceso de redacción en siete pasos, ofrece tres ejemplos prácticos y explica cómo mantener la fiabilidad de un conjunto de pruebas a medida que el producto evoluciona.
¿Qué son los casos de prueba?
Un caso de prueba es un documento estructurado que define los pasos exactos, los datos de entrada, las condiciones previas y los resultados esperados necesarios para verificar si un software concreto funciona correctamente. No es un plan de pruebas (que describe la estrategia de pruebas) ni un script de pruebas (un código automatizado que ejecuta los pasos mediante programación). Un caso de prueba es la especificación a partir de la cual se elaboran ambos.
Ejemplo: Estás probando la funcionalidad de inicio de sesión de una aplicación web. Un caso de prueba para esta función definiría los siguientes elementos:
- Acciones que describen los pasos que realiza un usuario y las respuestas esperadas del sistema
- Condiciones que definen las reglas que deben cumplirse para que el sistema pueda continuar con cada paso
- Introduce datos con valores de muestra para probar diferentes resultados y verificar tanto los escenarios de éxito como los de fallo.
Comparación entre casos de prueba manuales y de automatización
La IA forma parte ya de la mayoría de los flujos de trabajo de pruebas. El 76,8 % de los profesionales de las pruebas utilizan la IA en el control de calidad, siendo la creación de casos de prueba (69,6 %) y el mantenimiento de scripts (59,6 %) los dos usos más habituales, según el informe «State of Testing Report 2026» de PractiTest. Los casos de prueba automatizados son donde más se nota ese cambio, por lo que merece la pena saber en qué se diferencian de los manuales.
| Parámetro | Casos de prueba manuales | Casos de prueba automatizados |
|---|---|---|
| Ejecución | Realizadas por un probador humano que sigue una serie de pasos documentados | Ejecutados mediante herramientas de software, scripts o agentes de IA |
| Rapidez | Es un proceso lento y que requiere mucho tiempo, ya que las personas deben introducir los datos manualmente y verificar los resultados | Puede ejecutar cientos de casos de prueba simultáneamente |
| Repetibilidad | Propenso a errores humanos y a interpretaciones inconsistentes de los pasos | Altamente repetibles y coherentes cuando los guiones de prueba se mantienen adecuadamente |
| Integración de CI/CD | Difícil de integrar en procesos de entrega dinámicos debido a los cuellos de botella humanos | Se integra directamente en los flujos de CI/CD para ejecutar pruebas en cada compilación |
| Mantenimiento | Requiere actualizaciones manuales de los documentos cada vez que cambian los requisitos. | Requiere mantenimiento técnico para actualizar los scripts cuando cambie la interfaz de usuario o la lógica. |
| Ideal para | Pruebas exploratorias | Pruebas repetitivas y de regresión |
Por qué es importante que los casos de prueba estén bien redactados
Detectas las regresiones antes de que los usuarios envíen incidencias. Cada cambio en el código conlleva el riesgo de que algo que ya funciona deje de hacerlo. Un caso de prueba bien redactado se convierte en un punto de control permanente que se ejecuta tras cada implementación. Cuando un desarrollador refactoriza tu código de inicio de sesión un año después y, sin querer, rompe la gestión de sesiones, ese caso de prueba es el que lo detecta en el entorno de staging.
Haz que «aprobado» o «suspenso» sea un hecho, no una opinión. Los resultados esperados vagos, como «el sistema responde adecuadamente», obligan a cada probador a interpretar qué significa «adecuadamente». Dos probadores ejecutan el mismo caso, uno lo marca como aprobado y el otro señala un defecto, y ahora el equipo está solucionando el desacuerdo en lugar de depurar el software. Cuando el resultado esperado reza «el sistema muestra el mensaje de error: “Contraseña no válida” y mantiene al usuario en la página de inicio de sesión», no hay margen para la interpretación. El resultado coincide o no coincide. Esa es la regla de las dos personas en la práctica: el caso de prueba es el creador, el probador es el verificador, y ambos deben hablar el mismo idioma.
Conviertes el conocimiento tácito en un activo reutilizable. En la mayoría de los equipos, el ingeniero sénior de control de calidad lleva consigo un mapa invisible de cada caso extremo, cada solución alternativa, cada «ah, asegúrate de comprobar también X». Cuando esa persona se va de baja o cambia de equipo, el mapa se va con ella. Los casos de prueba documentados, con precondiciones y valores límite explícitos, conservan ese conocimiento de forma estructurada. Un nuevo probador que se incorpore al equipo puede coger el TC_LOGIN_005 y probar el flujo de bloqueo de cuenta tras cinco intentos desde el primer día, sin tener que preguntar a nadie cuál es el umbral ni cómo se reinicia el cronómetro.
Aísla los fallos en pasos concretos, no en áreas generales. Cuando un caso de prueba agrupa «ir a la página, introducir las credenciales y hacer clic en “Enviar”» en un único paso y la prueba falla, lo único que sabes es que «algo ha fallado en el flujo de inicio de sesión». ». Cuando cada acción es un paso independiente con su propio resultado esperado, el fallo se localiza en el paso 4: «Hacer clic en “Enviar enlace de restablecimiento” → se esperaba un mensaje de éxito, pero se obtuvo un error 500». Esa precisión reduce drásticamente el tiempo de depuración, ya que el desarrollador sabe exactamente qué interacción fue el desencadenante del defecto, y no solo en qué función debe buscar.
Verás qué se ha cubierto y cuáles son los puntos ciegos. Sin casos de prueba estructurados, la cobertura de las pruebas es una mera suposición. Con ellos, puedes correlacionar cada caso con un requisito y detectar al instante las lagunas. Si tu función de restablecimiento de contraseña tiene seis escenarios (intento correcto de restablecimiento, enlace caducado, enlace reutilizado, correo electrónico no registrado, formato no válido, solicitudes múltiples) y solo tienes casos de prueba para tres de ellos, la laguna es visible y cuantificable. Esa visibilidad es lo que transforma las pruebas de «lo hemos probado» a «esto es exactamente lo que hemos probado, esto es lo que no hemos probado y este es el riesgo que estamos asumiendo».
Componentes de un buen caso de prueba
Un caso de prueba útil va más allá de describir qué hay que probar. Recoge el contexto, los pasos de ejecución y el comportamiento esperado del sistema, de modo que otro probador, desarrollador o gestor de producto pueda reproducir la prueba y verificar el resultado.
Los componentes de un caso de prueba son:
- Identificador único
- Objetivo o descripción
- Requisitos previos
- Pasos de ejecución
- Resultados esperados
- Resultados reales a modo de comparación
Para el ejemplo de la función de inicio de sesión en la página web que hemos usado de forma compartida anteriormente, tu caso de prueba debería incluir:
ID del caso de prueba: Cada caso de prueba necesita un identificador único. Al probar una función, los equipos de control de calidad suelen crear varios casos de prueba que validan condiciones similares. El ID del caso de prueba ayuda al seguimiento, la organización y la consulta fáciles durante la depuración o la elaboración de informes.
Ejemplo: TC_LOGIN_001
Descripción: Aquí se explica qué función valida el caso de prueba. Ofrece un breve resumen para que cualquiera que lea el caso de prueba comprenda de inmediato su finalidad.
Ejemplo: Comprueba que un usuario registrado pueda iniciar sesión correctamente en la aplicación utilizando credenciales válidas.
Condiciones previas: Las condiciones previas describen el estado del sistema necesario antes de ejecutar el caso de prueba. Sin ellas, los evaluadores podrían ejecutar la misma prueba en condiciones diferentes y obtener resultados inconsistentes.
Ejemplos:
- La cuenta de usuario debe existir ya en el sistema
- La cuenta de usuario debe estar activa y no bloqueada.
- Se debe poder acceder a la página de inicio de sesión
Pasos: Son las acciones que realiza un usuario o un evaluador para ejecutar el caso de prueba. Cada paso debe ser claro y secuencial, de modo que cualquier miembro del equipo pueda reproducir la prueba.
- El usuario accede a la página de inicio de sesión
- El usuario introduce una dirección de correo electrónico registrada
- El usuario introduce la contraseña correcta
- El usuario hace clic en el botón Iniciar sesión
Resultados esperados: Esto define lo que el sistema debería hacer si la función funciona correctamente.
- Si las credenciales son válidas, el sistema realiza la autenticación del usuario
- El usuario es redirigido al panel de control
- Se ha creado correctamente una sesión de usuario
Si las credenciales no son válidas, el sistema debería mostrar el mensaje de error correspondiente.
Resultados reales: recogen las observaciones del evaluador tras ejecutar el caso de prueba. Si el comportamiento observado difiere del resultado esperado, el problema se registra como un defecto.
Ejemplo de observación:
- Has introducido unas credenciales válidas, pero has recibido un error que dice «Contraseña no válida»
Ahora pongamos en práctica tus habilidades para redactar casos de prueba.
¿Sabías que...? Solo el 2,1 % de los equipos describe sus prácticas de pruebas de IA como optimizadas, mientras que más del 85 % se encuentra todavía en fases iniciales o experimentales. El uso más habitual es la generación de casos de prueba (69,6 %), y no trabajos estratégicos como la identificación de riesgos (19,9 %).
Cómo redactar casos de prueba (proceso paso a paso)
La redacción de un caso de prueba consta de siete pasos: analizar el requisito, crear una lista de escenarios, planificar la estructura, redactar los pasos con los resultados esperados, añadir un adjunto con el contexto, someterlo a revisión y, por último, ejecutarlo y registrar los resultados.
Paso 1: Analizar los requisitos
Antes de redactar el caso de prueba, comprende qué se espera que haga la función. Es en este punto donde debes revisar la documentación disponible —PRD (documentos de requisitos del producto), historias de usuario, especificaciones de funciones y documentos de diseño— e identificar cada uno de los aspectos funcionales que deben verificarse.
Ejemplo: Estás desarrollando una función que permite a los usuarios restablecer sus contraseñas por correo electrónico. Para crear un caso de prueba en torno a esto, debes comprender:
- ¿Qué problema resuelve esta función? Es decir, ¿puede un usuario recuperar el acceso a su cuenta si olvida su contraseña?
- ¿Qué acciones puede realizar el usuario, es decir, solicitar un enlace de restablecimiento, recibirlo por correo electrónico y establecer una nueva contraseña?
- ¿Qué debería ocurrir al realizar esas acciones? Es decir, ¿envía el sistema un enlace de restablecimiento y permite al usuario actualizar su contraseña de manera correcta?
- ¿Hay alguna restricción, es decir, el enlace caduca tras un tiempo determinado o deja de ser válido tras un solo uso?
- ¿Existen validaciones o reglas, es decir, la nueva contraseña debe cumplir requisitos específicos de formato o longitud?
- ¿Hay alguna función que resulte ambigua o esté mal definida? Si es así, acláralo con las partes interesadas correspondientes.
Esta claridad te proporciona la base necesaria para definir un objetivo claro para tu caso de prueba.
Objetivo: Verificar que un usuario registrado pueda restablecer correctamente su contraseña por correo electrónico.
Paso 2: Identificar diferentes escenarios de prueba
A continuación, crea una lista de los escenarios de prueba que necesitas validar. Un escenario de prueba es una situación de alto nivel, que normalmente se ramifica en varios casos de prueba que abarcan diferentes entradas y resultados.
Para la función de restablecimiento de contraseña, tus escenarios podrían ser los siguientes:
- Restablecimiento correcto: Comprueba que un usuario registrado pueda solicitar un enlace de restablecimiento y establecer una nueva contraseña.
- Correo electrónico no registrado: Comprueba qué ocurre cuando se envía un correo electrónico que no existe en el sistema.
- Enlace caducado: Comprueba que el sistema bloquea el acceso cuando se hace clic en el enlace de restablecimiento una vez que ha caducado.
- Enlace reutilizado: Comprueba que un enlace de reinicio ya utilizado no se pueda volver a utilizar
- Nueva contraseña no válida: Comprueba que se rechacen las contraseñas que no cumplan los requisitos de formato.
- Múltiples solicitudes de reinicio: Comprueba qué enlace sigue siendo válido cuando un usuario realiza varias solicitudes seguidas.
Cada uno de los escenarios aquí descritos se traducirá en uno o más casos de prueba que abarquen entradas y condiciones específicas. Desglosar la función de esta manera garantiza que la cobertura de las pruebas abarque tanto el comportamiento esperado como los casos extremos con los que los usuarios reales se encontrarán inevitablemente.
Más información: Cómo crear e implementar una lista de control de calidad
Paso 3: Planifica la prueba y realiza el ajuste de la estructura de los casos de prueba
Para las pruebas de regresión repetitivas, necesitas una estructura que te permita documentar tu caso de prueba y sus resultados de forma coherente. Una plantilla de caso de prueba bien definida aporta esa coherencia y permite la reutilización sin tener que empezar desde cero cada vez.
Planifica la ejecución de tus pruebas aclarando estos elementos:
¿Quién llevará a cabo la prueba?
¿Qué rol o cualificación debe tener la persona que realiza esta prueba? Dependiendo de la complejidad de la prueba y de la intervención humana necesaria, asigna los roles:
- Tester de control de calidad: Pruebas funcionales y de regresión, como la verificación de flujos de inicio de sesión, la validación de formularios o los procesos de pago.
- Equipo de seguridad: Pruebas relacionadas con vulnerabilidades de autenticación, control de acceso o exposición de datos
- Desarrollador: Pruebas unitarias para funciones concretas, como el hash de contraseñas o la generación de tokens
¿Cómo se llevará a cabo la prueba?
- ¿En qué dispositivos y sistemas operativos se ejecutarán las pruebas?
- ¿Qué herramientas o marcos de pruebas se utilizarán?
- ¿Se ejecutará la prueba manualmente o mediante un agente de IA?
- ¿Cómo se registrarán los resultados: en una herramienta de gestión de pruebas, en una hoja de cálculo o en un gestor de errores?
¿Cuáles son los requisitos previos?
Lista todas las condiciones que deben cumplirse antes del paso 1 y haz que cada una de ellas pueda ser comprobada por el evaluador:
Ejemplo:
- Existe una cuenta de usuario con el correo electrónico «test@example.com»
- El usuario ha cerrado sesión en el sistema.
- El servicio de correo electrónico está activo y puede enviar mensajes
- El entorno de pruebas está disponible y en funcionamiento
¿Qué datos de prueba se utilizarán?
Define los valores de entrada exactos necesarios para ejecutar la prueba: datos válidos, datos no válidos y valores límite.
Ejemplo:
- Válido: correo electrónico registrado «test@example.com», contraseña que cumpla los requisitos del formato de reunión
- No válido: correo electrónico no registrado, contraseña por debajo del límite mínimo de caracteres
- Límites: contraseña que cumpla exactamente con el límite mínimo y máximo de caracteres
Paso 4: Redacta los pasos de prueba y los resultados esperados
Desglosa el proceso de ejecución en pasos secuenciales. Utiliza una terminología coherente y asegúrate de que cada paso corresponda a una sola acción. Al definir los pasos, describe también el resultado esperado y qué se considera que el caso ha superado o no la prueba.
Siguiendo con nuestro flujo de restablecimiento de contraseña, estos serían los pasos de las pruebas:
| Pasos | Resultado esperado |
| Accede a la página de inicio de sesión | La página de inicio de sesión se carga con un enlace «¿Has olvidado tu contraseña?» en el que se puede hacer clic. |
| Haz clic en «Olvidé mi contraseña» | El usuario es redirigido a la página de solicitud de restablecimiento de contraseña. |
| Introduce tu correo electrónico en el campo «Correo electrónico» | Se acepta el correo electrónico sin error de validación |
| Haz clic en «Enviar enlace de restablecimiento» | Aparece el mensaje de éxito: «Enviado el enlace de restablecimiento a test@example.com» |
| Abre el enlace de restablecimiento que aparece en el correo electrónico | El usuario es redirigido a la página de creación de una nueva contraseña |
| Introduce una nueva contraseña válida | El campo de contraseña acepta entradas sin mostrar ningún error |
| Haz clic en «Restablecer contraseña» | Aparece un mensaje de intento correcto y se redirige al usuario a la página de inicio de sesión. |
Ahora define los pasos y los resultados esperados para los escenarios alternativos (que se han comentado anteriormente). Explica qué ocurre cuando el usuario introduce un correo electrónico no válido o cuando la contraseña no cumple los criterios preestablecidos.
Extra: A continuación te explicamos cómo puedes realizar la automatización de la documentación mediante IA para todos tus casos de prueba.
Paso 5: Incluye adjuntos relevantes
Incluye documentos o adjuntos relevantes que ayuden a los probadores a ejecutar el caso de prueba con todo el contexto y sin ambigüedades. Esto puede incluir:
- Capturas de pantalla comentadas de la interfaz de usuario en los pasos clave
- Grabaciones de pantalla que muestran cómo ejecutar la prueba en diferentes escenarios y qué resultados cabe esperar.
- Registros del sistema o archivos de configuración que ayuden a diagnosticar problemas del backend cuando falle una prueba
- Documentos de requisitos que correlacionan el caso de prueba con la historia de usuario o los criterios de aceptación que valida
- Archivos de datos de prueba que contengan entradas válidas e inválidas, o datos generados, como números de tarjetas de crédito, direcciones aleatorias o credenciales de usuario
- Elabora documentación que incluya la versión específica del software, el hardware necesario, el sistema operativo y cualquier autorización de seguridad requerida.
- Para las pruebas de API, especificaciones OpenAPI o documentación de los puntos finales que detalle los métodos de solicitud, los parámetros y los códigos de estado esperados.
Paso 6: Haz que revisen el caso de prueba
Usa el caso de prueba redactado de forma compartida con un compañero o con un responsable sénior de control de calidad antes de ejecutarlo. Durante la revisión, comprueba que:
- El caso de prueba es exhaustivo y abarca todos los escenarios posibles derivados de los requisitos.
- Los pasos son claros y representan de forma secuencial el flujo de ejecución real.
- Cada resultado esperado describe un resultado observable (un mensaje, una redirección, un código de estado), no una cualidad como «funciona correctamente».
- Los datos de prueba y las condiciones previas son completos y precisos
- Cualquier suposición que se haga durante la redacción se documenta de forma explícita.
Paso 7: Ejecuta y registra los resultados
Realiza la prueba y registra el resultado real comparándolo con cada resultado esperado. Marca cada paso de la prueba como «aprobado» o «suspendido». Por cada paso suspendido, notifica inmediatamente un error y enlázalo al caso de prueba. Además, si se produce algún comportamiento inesperado que no permita determinar claramente si se ha aprobado o suspendido, anótalo en el campo de comentarios para su posterior revisión.
Más información: Cómo utilizar la IA para el control de calidad
Ejemplos de redacción de casos de prueba
Estos tres ejemplos muestran cómo la misma estructura de caso de prueba se adapta a diferentes tipos de pruebas de software. Cada uno de ellos utiliza los componentes y el formato de pasos descritos anteriormente en esta guía, pero la complejidad, los datos de prueba y los modos de fallo varían en función de lo que se esté verificando.
Ejemplo 1: Flujo de pago en un sitio de comercio electrónico (interfaz de usuario, flujo de trabajo de varios pasos)
El equipo de control de calidad de una tienda online está probando el proceso de pago antes de una oferta navideña. El flujo abarca varias páginas: carrito → envío → pago → confirmación. El principal reto aquí es la dependencia de estado: cada paso depende de que el anterior se haya completado correctamente, y los datos de prueba (contenido del carrito, dirección de envío, forma de pago) deben mantenerse en todos ellos.
Probador: Rahul D.
Fecha del examen: 09/03/2026
ID del caso de prueba: TC_CHECKOUT_003
Descripción: Comprueba que un usuario que haya iniciado sesión pueda completar una compra utilizando una tarjeta de crédito guardada y el envío estándar.
Requisitos previos:
- La cuenta de usuario existe y tiene al menos una tarjeta de crédito guardada y una dirección de envío guardada.
- Hay al menos un elemento en stock y se ha añadido al carrito
- El entorno de pruebas se ejecuta en Chrome 128, macOS
| Paso | Resultado esperado | Resultado real | Aprobado/Suspenso |
| Ir a la página del carrito | El carrito muestra correctamente el elemento, la cantidad y el subtotal | Como era de esperar | Aprobar |
| Haz clic en «Pasar por caja» | La página de envío se carga con la dirección guardada ya seleccionada | Tal y como era de esperar | Aprobar |
| Realiza la selección de «Envío estándar» y haz clic en «Continuar» | La página de pago se carga mostrando el total del pedido con los gastos de envío incluidos | Como era de esperar | Aprobar |
| Confirma los datos de la tarjeta de crédito guardada y haz clic en «Realizar pedido». | Se muestra la página de confirmación del pedido con el número de pedido, el resumen de los elementos y la fecha de entrega estimada. | La página de pago se recarga con el error: «No se puede procesar el pago» | Fallo |
Resumen de resultados: El flujo de pago gestiona correctamente el paso del carrito al envío, pero el procesamiento del pago falla con las tarjetas de crédito guardadas. Defecto registrado: la búsqueda de la tarjeta tokenizada agota el tiempo de espera cuando la pasarela de pago tarda más de 3 segundos en responder.
Ejemplo 2: Punto final de la API REST (sin interfaz de usuario, validación de entrada/salida)
Un ingeniero de backend está probando el punto final de la API «Crear usuario» antes de que lo utilice el equipo de front-end. No hay ninguna interfaz en la que hacer clic: el caso de prueba valida directamente las cargas útiles de las solicitudes, los códigos de respuesta y la persistencia de los datos. El reto principal consiste en probar el contrato entre sistemas, no la experiencia del usuario.
Responsable de pruebas: Sarah S.
Fecha del examen: 09/05/2026
ID del caso de prueba: TC_API_USER_001
Descripción: Comprueba que una solicitud POST a /api/v1/users crea un nuevo usuario y devuelve la respuesta correcta.
Requisitos previos:
- El entorno de pruebas de la API está en funcionamiento y es accesible
- Se ha generado un token de autenticación con permisos de administrador, y es válido
- No existe en la base de datos ningún usuario con la dirección de correo electrónico «newuser@testdomain.com».
| Paso | Resultado esperado | Resultado real | Aprobado/Suspenso |
| Envía una solicitud POST a /api/v1/users con una carga útil válida: { "name": "Usuario de prueba", "correo electrónico": "newuser@testdomain.com", "rol": "viewer" } | La respuesta devuelve 201 Created con un cuerpo JSON que contiene el ID de usuario, el nombre, el correo electrónico y el rol. | 201 devuelto con cuerpo correcto | Aprobar |
| Envía de nuevo la misma solicitud POST con el mismo correo electrónico | La respuesta devuelve un error 409 (Conflicto) con el mensaje: «Ya existe un usuario con esta dirección de correo electrónico». | Se ha devuelto un 200 OK; se ha creado un usuario duplicado | Fallo |
| Enviar una solicitud POST en la que falte el campo «correo electrónico» | La respuesta devuelve un código 400 (Solicitud incorrecta) con el error de validación: «Es obligatorio introducir un correo electrónico». | 400 devuelto según lo esperado | Aprobar |
| Realiza una consulta GET /api/v1/users/{id} utilizando el ID del paso 1 | La respuesta devuelve un 200 OK y los datos del usuario coinciden con la carga útil original. | Como era de esperar | Aprobar |
Resumen de resultados: El punto final crea usuarios correctamente y valida los campos obligatorios, pero no garantiza la unicidad de los correos electrónicos a nivel de la base de datos. Se crearon registros duplicados sin que se produjera ningún error. Defecto registrado con gravedad: Alta.
Ejemplo 3: Control de acceso basado en roles (seguridad, límites de permisos)
Un equipo de seguridad está comprobando si la aplicación restringe correctamente las acciones en función de los roles de los usuarios antes de una auditoría de cumplimiento. El reto principal es que no se está comprobando si una función funciona, sino si se deniega correctamente. El resultado esperado para la mayoría de los pasos es un bloqueo, no un intento correcto.
Evaluador: Marcus L.
Fecha del examen: 09/08/2026
ID del caso de prueba: TC_RBAC_002
Descripción: Verifica que un usuario con el rol de «Visor» no pueda crear, realizar edición ni eliminar proyectos.
Requisitos previos:
- Existen dos cuentas: una con el rol de «Administrador» y otra con el rol de «Lector».
- Debe existir al menos un proyecto en el entorno de trabajo, creado por el administrador.
- El usuario ha iniciado sesión en Firefox 130, Windows 11
| Paso | Resultado esperado | Resultado real | Aprobado/Suspenso |
| Ve a la página de Proyectos | El usuario ve la lista de proyectos en modo de solo lectura; el botón «Crear proyecto» está oculto o desactivado. | El botón está visible, pero aparece atenuado | Aprobar |
| Intenta hacer clic en «Crear proyecto» | El sistema impide la acción; no se carga el formulario de nuevo proyecto | No se ha cargado ningún formulario; la información sobre herramientas muestra «No tienes permiso». | Aprobar |
| Abre un proyecto existente y intenta realizar la edición del título. | El campo «Título» no se puede editar, o el sistema bloquea la edición y impide guardar el cambio | El campo «Título» era editable; los cambios se han guardado de forma correcta. | Fallo |
| Intenta eliminar el proyecto a través del menú de los tres puntos | La opción «Eliminar» está oculta o la acción está bloqueada por un error de permiso | La opción «Eliminar» no tiene visibilidad en el menú | Aprobar |
Resumen de resultados: Los permisos de creación y eliminación están correctamente restringidos para los usuarios con rol de «Visor», pero los permisos de edición no se aplican a nivel de campo. Un usuario con rol de «Visor» puede modificar los títulos de los proyectos a pesar de tener acceso de solo lectura. Defecto registrado con gravedad: Crítico (obstáculo para el cumplimiento).
¿Cuáles son las mejores herramientas para gestionar casos de prueba?
Los casos de prueba se pueden gestionar en una herramienta específica de control de calidad (TestRail, Zephyr), en una herramienta general de gestión de proyectos (ClickUp, Jira) o en una hoja de cálculo; la elección adecuada depende de si necesitas una función de ejecución integrada o solo de seguimiento.
ClickUp
ClickUp for Software Teams es una plataforma de gestión de proyectos en la que los casos de prueba se gestionan como tareas junto con los sprints, los errores y las solicitudes de validación a los que están relacionados. No es una herramienta específica para la gestión de pruebas, pero su estructura flexible de tareas permite a los equipos crear flujos de trabajo para los casos de prueba utilizando estados, campos y tipos de tarea personalizados sin necesidad de una herramienta independiente.
Funciones principales de ClickUp
- Jerarquía flexible para organizar los casos de prueba en espacios, carpetas y listas, con campos personalizados para el tipo de prueba, la prioridad y el entorno.
- Más de 15 vistas de ClickUp (Tablero, Lista, Tabla) para realizar el seguimiento de la ejecución de las pruebas por estado, persona asignada o sprint
- Documentos para mantener los PRD, los planes de pruebas y las guías de configuración del entorno junto a los casos de prueba a los que dan lugar
- Chat integrado para la comunicación entre el equipo de control de calidad y los desarrolladores sin necesidad de cambiar a Slack ni al correo electrónico
- Resúmenes de tareas generados por IA a través de ClickUp Brain para obtener rápidamente el contexto durante las revisiones de sprint
Limitaciones de ClickUp
- Sin motor de ejecución de pruebas nativo
- Los informes específicos de pruebas (cobertura por requisito, tasa de superación por ciclo) requieren paneles de control personalizados, en lugar de la elaboración de informes de control de calidad predeterminados.
Precios de ClickUp
Valoraciones y reseñas de ClickUp
- G2: 4,6/5 (más de 14 100 opiniones)
- Capterra: 4,6/5 (más de 4.600 opiniones)
¿Qué opinan los usuarios reales sobre ClickUp?
Esto es lo que opina un crítico de G2:
Lo que más me gusta de ClickUp es que lo reúne todo en un solo lugar. Las tareas, los cronogramas, las notas y las actualizaciones se encuentran todas en el mismo sistema, lo que reduce el ir y venir entre herramientas. También valoro mucho su flexibilidad. Podemos personalizar los estados, los campos y las vistas para adaptarlos a la forma en que trabaja realmente nuestro equipo. Eso facilita la organización y ofrece una visibilidad clara de quién es responsable de qué y en qué punto se encuentran los proyectos en cada momento.
Lo que más me gusta de ClickUp es que lo reúne todo en un solo lugar. Las tareas, los cronogramas, las notas y las actualizaciones se encuentran todas en el mismo sistema, lo que reduce el ir y venir entre herramientas. También valoro mucho la flexibilidad. Podemos personalizar los estados, los campos y las vistas para que se adapten a la forma en que trabaja realmente nuestro equipo. Eso facilita la organización y ofrece una visión clara de quién es responsable de qué y en qué punto se encuentran los proyectos en cada momento.
Ideal para: Un responsable de control de calidad que quiera que una prueba fallida se convierta en un ticket de error para el desarrollador con un solo clic, con la solicitud de incorporación de cambios (PR), los pasos de la prueba y el sprint visibles desde la misma tarea.
No lo leas si: tu ciclo de pruebas está mayoritariamente automatizado. Si el 80 % de tu conjunto de pruebas se ejecuta desde un proceso de integración continua (CI), necesitas una herramienta que recopile los resultados de la ejecución, no una en la que una persona tenga que actualizar el estado manualmente.
TestRail
TestRail es una plataforma especializada en la gestión de pruebas, diseñada para equipos de control de calidad que necesitan un control estructurado sobre todo su proceso de pruebas. Gestiona el ciclo completo de redacción, ejecución y elaboración de informes sobre los casos de prueba, con integraciones de DevOps y CI/CD que aportan los resultados.
Funciones principales de TestRail
- Gestión centralizada de casos de prueba y conjuntos de pruebas con casos de prueba reutilizables en distintos proyectos
- Planes de pruebas e hitos para organizar y programar las ejecuciones de pruebas a lo largo de los sprints y las versiones
- Informes detallados con análisis de cobertura, seguimiento del progreso e historial de ejecución
- Integraciones con Jira, GitHub, Jenkins, Azure DevOps y más de 20 herramientas de DevOps adicionales
- API REST para automatizar tareas y sincronizar datos de prueba con sistemas externos
Limitaciones de TestRail
- No hay un sistema nativo de gestión de requisitos ni de seguimiento de problemas; los equipos deben recurrir a herramientas externas como Jira, lo que puede fragmentar la trazabilidad.
- La organización basada en carpetas se vuelve difícil de manejar a medida que los repositorios de pruebas crecen hasta alcanzar miles de elementos.
Precios de TestRail
- Professional: 39 $ por asiento al mes
- Enterprise: 78 $ por asiento al mes
Valoraciones y opiniones sobre TestRail
- G2: 4,4/5 (más de 600 opiniones)
- Capterra: 4,3/5 (más de 160 opiniones)
¿Qué opinan los usuarios reales sobre TestRail?
Esto es lo que opina un crítico de G2:
Lo que más valoro de TestRail es que ofrece a nuestro equipo de control de calidad un entorno seguro y bien organizado para gestionar planes de pruebas, casos de prueba y ejecuciones de pruebas. Valoro mucho lo sencillo que resulta estructurar e implementar conjuntos de pruebas, así como reutilizar casos de prueba creados anteriormente. Las integraciones con Jira y las herramientas de CI/CD han hecho que nuestro flujo de trabajo sea más coherente y fácil de seguir. La posibilidad de supervisar el progreso y la cobertura de las pruebas en tiempo real ha resultado increíblemente útil para la planificación de sprints y la elaboración de informes. En mi trabajo diario como ingeniero de control de calidad, el uso de TestRail también me ha ahorrado una cantidad significativa de tiempo.
Lo que más valoro de TestRail es que proporciona a nuestro equipo de control de calidad un entorno seguro y bien organizado para gestionar planes de pruebas, casos de prueba y ejecuciones de pruebas. Valoro mucho lo sencillo que resulta estructurar e implementar conjuntos de pruebas, así como reutilizar casos de prueba creados anteriormente. Las integraciones con Jira y las herramientas de CI/CD han hecho que nuestro flujo de trabajo sea más coherente y fácil de seguir. La posibilidad de supervisar el progreso y la cobertura de las pruebas en tiempo real ha resultado increíblemente útil para la planificación de sprints y la elaboración de informes. En mi trabajo diario como ingeniero de control de calidad, el uso de TestRail también me ha ahorrado una cantidad significativa de tiempo.
Ideal para: Un equipo de control de calidad de cinco o más personas que lleva a cabo ciclos de pruebas formales en cada lanzamiento, en el que un responsable necesita responder a la pregunta «¿qué porcentaje de la versión 2.0 se ha ejecutado y superado?» a partir de un panel, no de una hoja de cálculo.
No lo hagas si: tu conjunto de pruebas tiene menos de unos cientos de casos o tus probadores también son desarrolladores. A esa escala, el coste por usuario y el inicio de sesión independiente solo te proporcionarán la elaboración de informes que no vas a consultar.
Zephyr
Zephyr es el complemento de gestión de pruebas de SmartBear para Jira, diseñado para gestionar casos de prueba desde la propia interfaz de Jira. Admite tanto pruebas manuales como de automatización, con potentes funciones de elaboración de informes y trazabilidad para equipos ágiles y de corporación.
Funciones principales de Zephyr
- Integración nativa con Jira: crea, enlaza y ejecuta casos de prueba directamente desde los problemas de Jira.
- Bibliotecas de pruebas jerárquicas para todos los proyectos, que permiten reutilizar y organizar los casos de prueba a gran escala
- Más de 70 informes listos para usar que abarcan la cobertura de las pruebas, el progreso de la ejecución y el seguimiento de defectos.
- Soporte con BDD mediante la sintaxis de Gherkin para flujos de trabajo de desarrollo basado en el comportamiento
- Integraciones de CI/CD con Jenkins, GitHub, GitLab, Bitbucket y Bamboo
Limitaciones de Zephyr
- Licencia por usuario de Jira, no por evaluador.
- Los grandes repositorios de pruebas (con miles de casos) pueden resultar más difíciles de manejar que en herramientas independientes como TestRail
- El soporte se canaliza a través de Atlassian Marketplace, lo que supone un paso adicional para los equipos acostumbrados a recibir soporte directamente del proveedor.
Precios de Zephyr
- Essential: Desde 5,99 $ al mes por usuario (11-50 usuarios)
- Plan Standard: desde 6,81 $ por usuario al mes (11-50 usuarios)
- Avanzado: desde 8,73 $ por usuario al mes (11-50 usuarios)
Valoraciones y reseñas de Zephyr
- G2: 4,1/5 (más de 80 opiniones)
- Capterra: No hay suficientes reseñas
¿Qué opinan los usuarios reales sobre Zephyr?
Esto es lo que opina un crítico de G2:
Esta es la mejor herramienta para importar casos de prueba directamente desde una hoja de Excel. Con esta herramienta, el trabajo de los probadores resulta más sencillo que importar casos de prueba en Jira. Además, una de las mejores funciones de esta herramienta es la posibilidad de marcar los casos de prueba como «aprobados» o «suspendidos» y añadir adjuntos.
Esta es la mejor herramienta para importar casos de prueba directamente desde una hoja de Excel. Con esta herramienta, el trabajo de los evaluadores resulta más sencillo que importar casos de prueba en Jira. Además, una de las mejores funciones de esta herramienta es la posibilidad de marcar los casos de prueba como aprobados o fallidos y añadir adjuntos.
Ideal para: Equipos sujetos a regulaciones o a numerosas auditorías (tecnología financiera, sanidad) que necesitan que cada prueba se pueda rastrear hasta un requisito de Jira y que cada defecto se pueda enlazar con la prueba que lo detectó, todo ello dentro de una misma instancia de Atlassian.
No lo utilices si: tu instancia de Jira es grande y tu equipo de control de calidad es pequeño. Una instancia de Jira de 200 usuarios con 10 probadores supone el coste de 190 licencias de Zephyr que nadie utiliza; una herramienta independiente con un precio por probador sale más barata.
Jira
Jira es la plataforma de gestión de proyectos y seguimiento de incidencias de Atlassian, ampliamente utilizada por equipos de ingeniería y control de calidad para gestionar sprints, incidencias y flujos de trabajo de desarrollo. Aunque no es una herramienta específica para la gestión de pruebas, muchos equipos la utilizan junto con soluciones como Zephyr Scale o Xray para gestionar los casos de prueba dentro de su configuración actual de Jira.
Funciones principales de Jira
- Tableros de Scrum y Kanban para gestionar sprints, carteras de tareas y flujos de trabajo de pruebas ágiles
- Flujos de trabajo, tipos de problemas y campos personalizables que se adaptan a la forma en que tu equipo realiza el seguimiento del trabajo
- Hoja de ruta avanzada para la planificación entre equipos y el seguimiento de dependencias (Premium)
- Más de 1.000 integraciones con plataformas, entre las que se incluyen GitHub, Confluence, Slack y herramientas de CI/CD
- Reglas de automatización para desencadenar acciones en todos los proyectos en función de las actualizaciones de problemas o los cambios de estado
Limitaciones de Jira
- La gestión de casos de prueba requiere un complemento de Marketplace (Zephyr Scale, Xray) con una tarifa propia por usuario, además de la suscripción a Jira.
- Curva de aprendizaje más pronunciada para los usuarios sin conocimientos técnicos, con unos costes de incorporación que pueden acumularse en equipos más grandes
Precios de Jira
- Free
- Plan Estándar: 7,91 $ por usuario al mes
- Premium: 14,54 $ por usuario al mes
- Enterprise: Precios personalizados
Valoraciones y reseñas de Jira
- G2: 4,3/5 (más de 7.900 opiniones)
- Capterra: 4,4/5 (más de 15 400 opiniones)
¿Qué opinan los usuarios reales sobre Jira?
Esto es lo que opina un crítico de G2:
Jira es uno de mis programas digitales favoritos para realizar el seguimiento y visualizar el rendimiento de todos mis proyectos de trabajo en colaboración con todos los miembros de mi equipo, ya que ofrece las mejores prestaciones virtuales de su categoría, lo que me facilita alcanzar todas mis metas profesionales.
Jira es uno de mis programas digitales favoritos para realizar el seguimiento y visualizar el rendimiento de todos mis proyectos de trabajo en colaboración con todos los miembros de mi equipo, ya que ofrece las mejores prestaciones virtuales de su categoría, lo que me facilita alcanzar todas mis metas profesionales.
Ideal para: Equipos de ingeniería que estén valorando si realmente necesitan una gestión de pruebas específica. Realizar primero unos cuantos ciclos de pruebas utilizando tipos de incidencias personalizados en Jira permite comprobar si el volumen justifica el uso de un complemento.
Sáltate este paso si: Ya sabes que necesitas gestión de pruebas. Ir directamente a un complemento o a una herramienta independiente evita la migración cuando los tipos de problemas personalizados dejan de ser escalables.
Errores comunes que hay que evitar al crear casos de prueba
Evita estos errores a la hora de redactar casos de prueba, ya que pueden reducir su eficacia general.
| Error | Qué hacer en su lugar |
|---|---|
| Redactar los casos de prueba demasiado tarde | Involucra a los probadores en las fases de recopilación de requisitos y diseño para identificar posibles problemas antes de que comience la creación del código. |
| No actualizar los casos de prueba | Actualiza el caso de prueba tan pronto como la función reciba una nueva actualización, un cambio en su funcionalidad o una modificación en la interfaz de usuario. |
| Sin postcondiciones | Indica cómo debería quedar el sistema una vez completada la prueba (usuario de prueba eliminado, carrito vaciado, sesión cerrada) para que el siguiente caso comience desde un estado limpio. |
| Solo datos de la ruta normal | Cada campo de entrada necesita al menos un valor que el sistema deba rechazar. Documenta cómo se genera o se extrae el conjunto de datos. |
| No priorizar los casos de prueba | Asigna a cada caso de prueba una prioridad en función del impacto en la empresa, la frecuencia de uso y el riesgo de fallo. Esto te ayudará a centrar los esfuerzos de prueba y a tomar decisiones más acertadas sobre el presupuesto y los métodos de prueba. |
Cómo mantener la utilidad de los casos de prueba a lo largo del tiempo
Un conjunto de pruebas sigue siendo fiable cuando cada caso es independiente, tiene como objetivo las entradas que tienen más probabilidades de fallar y se retira en cuanto deja de ofrecer un veredicto fiable. Estas seis prácticas marcan la diferencia entre los conjuntos de pruebas que detectan errores durante años y aquellos que se ignoran tras el segundo sprint.
Escribe pruebas independientes y atómicas
Un caso de prueba debe establecer su propio estado y no tener ninguna dependencia con respecto a que se haya ejecutado primero otro caso. Cuando el caso TC_CHECKOUT_003 da por hecho que el caso TC_CHECKOUT_002 ha dejado un elemento en el carrito, un fallo se convierte en cinco, y te pasas toda la mañana intentando averiguar cuál de ellos era el verdadero. Si el título de una prueba contiene la palabra «y», divídela en dos casos.
Realiza pruebas en los límites
Las incidencias se concentran en los extremos de los valores de entrada aceptados, no en el centro. Si un campo de contraseña admite entre 8 y 128 caracteres, prueba con 7, 8, 128 y 129, no solo con una contraseña cómoda de 12 caracteres. El análisis de valores límite es una técnica formal incluida en la norma de diseño de pruebas ISO/IEC/IEEE 29119-4 precisamente por este motivo: detecta errores de «desviación de uno» que las entradas aleatorias pasan por alto.
Utiliza la partición por equivalencias para eliminar casos redundantes
Agrupa las entradas que el sistema debe tratar de forma idéntica y, a continuación, prueba una representativa de cada grupo. Todos los formatos de correo electrónico válidos se comportan de la misma manera en un formulario de inicio de sesión, por lo que basta con un solo correo electrónico válido. Probar user@example.com, jane@company.com y bob@domain.org como tres casos distintos triplica la carga de mantenimiento sin aumentar la cobertura.
Separa los datos de prueba de los pasos de prueba
Introducir de forma fija «introduce test@example.com» en un paso implica reescribir dicho paso cada vez que cambia el entorno de prueba. Mantén los pasos genéricos («introduce un correo electrónico registrado») y guarda los valores reales en un campo de datos de prueba o en un archivo. De este modo, los mismos pasos se ejecutarán en los entornos de staging, control de calidad y preproducción sin necesidad de modificaciones, y sustituir un conjunto de datos nuevo para una prueba negativa supondrá un cambio de una sola línea.
Realiza un seguimiento de las pruebas inestables y de la tasa de defectos no detectados
Una prueba inestable falla de forma inconsistente sin que exista un error real en el producto, y cada prueba inestable enseña al equipo a ignorar los resultados negativos. Realiza un seguimiento de la frecuencia con la que cada caso oscila entre «aprobado» y «fallido» en compilaciones idénticas. Si un caso falla de forma inestable más de un par de veces al mes, reescríbelo o elimínalo. Combina esto con la tasa de escape de incidencias (errores encontrados en producción que un caso de prueba debería haber detectado) para ver dónde la cobertura es insuficiente, y no solo dónde hay ruido.
Realiza la automatización de las pruebas que realizas con más frecuencia
Los casos de regresión, de prueba rápida y los casos funcionales de alta frecuencia son los más adecuados para la automatización, ya que se ejecutan en cada compilación y rara vez cambian. Transfiérelos a scripts en tu canalización de CI/CD y utiliza herramientas asistidas por IA con localizadores autorreparables en los casos en que los elementos de la interfaz de usuario cambien con frecuencia. Esto libera a los probadores humanos para que se dediquen al trabajo exploratorio y a los tipos de pruebas de software que requieren criterio, como la usabilidad y la búsqueda de casos extremos.
Cómo redactar y ejecutar casos de prueba en ClickUp
En la sección de herramientas anterior se explica cuál es el papel de ClickUp. En esta sección se muestra la configuración real, que se corresponde con los pasos descritos anteriormente en la guía.
Estructura tu biblioteca de casos de prueba. Crea un espacio para tu producto, una carpeta para cada área funcional (por ejemplo, autenticación, pagos, incorporación) y una lista para cada ciclo de pruebas o sprint. Cada tarea se convierte en un caso de prueba individual. Utiliza los campos personalizados de ClickUp para registrar datos como el ID del caso de prueba, las condiciones previas, los datos de prueba, el nivel de prioridad y el entorno.
Escribe los pasos de prueba directamente en la tarea. Utiliza la descripción de la tarea para documentar los pasos de ejecución secuenciales y los resultados esperados. Las listas de control funcionan bien para flujos paso a paso en los que el probador debe marcar cada acción, mientras que la descripción recoge el contexto, como las condiciones previas y los datos de prueba.
Realiza un seguimiento de la ejecución y los resultados. Crea estados personalizados que reflejen tu flujo de trabajo de pruebas: No iniciado → En curso → Aprobado → Fallido → Bloqueado. Cuando una prueba falle, conviértela en una tarea de error o crea una tarea enlazada asignada al desarrollador, con prioridad, dependencias y una fecha límite. Las integraciones con GitHub y GitLab te permiten vincular ese error directamente a la solicitud de incorporación de cambios (PR) que lo provocó. Si la causa principal es un defecto en el código, puedes asignar esa tarea de error al agente ClickUp Codegen, que lee la tarea, las especificaciones enlazadas y los comentarios, escribe la corrección y abre una solicitud de validación con el progreso publicado de vuelta en la tarea.
Consejo profesional: Los responsables de control de calidad pueden obtener una visión general instantánea de cualquier tarea pidiendo a ClickUp Brain que resuma las incidencias pendientes. De esta forma, disponen de todo el contexto necesario para las revisiones de sprint sin tener que rebuscar entre las tareas individuales para hacerse una idea general.
Ejecuta ciclos de pruebas con vistas. Utiliza la vista Tablero agrupada por estado para ver de un vistazo la distribución de resultados (aprobados/fallidos) durante la ejecución de una prueba. La vista Tabla funciona como una matriz de pruebas tradicional cuando necesitas examinar los resultados de docenas de casos. Filtra por la persona asignada para equilibrar la carga de trabajo, o por prioridad para centrar primero una prueba de fumada en las rutas críticas.
La plantilla de gestión de pruebas de ClickUp te ofrece una forma centralizada de gestionar todo el flujo de trabajo de pruebas, abarcando múltiples áreas funcionales, escenarios de prueba y casos extremos, todo en un solo lugar. Úsala para realizar el seguimiento de los comentarios de los usuarios, gestionar los calendarios de pruebas, supervisar el progreso de tus pruebas y evaluar los resultados de «aprobado» o «suspendido» sin tener que cambiar de herramienta.
Gestiona tus flujos de trabajo de pruebas de forma eficaz
Un caso de prueba se considera válido en el momento en que dos personas pueden ejecutarlo de forma independiente y obtener el mismo resultado de «aprobado» o «suspendido». Todo lo que se incluye en esta guía (una acción por paso, condiciones previas explícitas, resultados esperados sin margen para la interpretación) responde a ese único criterio. Si ya planificas sprints en ClickUp, la configuración descrita anteriormente te permite redactar, ejecutar y realizar el seguimiento de los casos de prueba junto con las incidencias que detectan, sin necesidad de añadir otra herramienta.
Preguntas frecuentes sobre los casos de prueba
¿Cuántos casos de prueba debe tener un requisito?
Un único requisito puede necesitar un caso de prueba o diez, dependiendo del número de escenarios, casos extremos y variaciones de entrada que implique. La idea es abarcar todas las rutas realistas, ofreciendo una cobertura suficiente sin redundancia.
¿Cuál es la diferencia entre casos de prueba y guiones de prueba?
Un caso de prueba documenta qué hay que probar y qué resultado se espera, y está escrito para su ejecución manual. Un script de prueba, por su parte, es la versión automatizada: código que ejecuta esos mismos pasos de forma programada.
¿Qué nivel de detalle deben tener los pasos de prueba?
Divide la prueba en pasos lógicos y secuenciales que sean fáciles de seguir sin necesidad de conocer el contexto previo. No agrupes varias acciones ni añadas complejidad innecesaria.
Un escenario de prueba indica qué hay que probar en una sola línea («Verificar el restablecimiento de la contraseña»); un caso de prueba especifica cómo hacerlo, con precondiciones, pasos, datos de prueba y resultados esperados. Un escenario suele generar entre 3 y 10 casos de prueba que abarcan el flujo normal, las entradas no válidas y las condiciones límite. Los escenarios son lo primero y marcan la planificación de la cobertura; los casos de prueba vienen después y marcan la ejecución.
Un caso de prueba positivo utiliza datos de entrada válidos y espera un intento correcto: una dirección de correo electrónico y una contraseña correctas permiten al usuario iniciar sesión. Un caso de prueba negativo utiliza datos de entrada no válidos o inesperados y espera que el sistema falle de forma controlada: una contraseña incorrecta muestra el mensaje «Contraseña no válida» sin crear una sesión. Los conjuntos de pruebas maduros presentan una proporción de casos positivos frente a negativos de aproximadamente 1:3 a 1:5, ya que la mayoría de las incidencias en producción se producen en las rutas de error, no en las rutas normales.
Un plan de pruebas define el alcance, el enfoque, los recursos y el calendario del esfuerzo completo de pruebas. Un conjunto de pruebas es una recopilación de casos de prueba agrupados para una única ejecución, como por ejemplo «conjunto de pruebas de regresión para la versión 2.1». Un caso de prueba es la unidad básica de ambos: una comprobación documentada con un resultado de «aprobado» o «suspendido». El plan establece la estrategia, el conjunto de pruebas define el alcance y el caso de prueba determina el veredicto.