# Cómo diseñar casos de prueba a partir de requisitos

**Categoría:** Testing y QA · **Nivel:** Intermedio · **Lectura:** 11 min
**Publicada:** 2026-07-28 · **Actualizada:** 2026-07-28 · **Autoría:** Underc0de
**Versión HTML (canónica):** https://underc0de.org/guias/testing/disenar-casos-de-prueba-a-partir-de-requisitos/

## Respuesta rápida

Diseñar casos de prueba **a partir de requisitos** es el proceso que convierte una especificación —un requisito, una historia de usuario con sus criterios de aceptación— en un conjunto de casos que la comprueban por completo. El método: primero **leer el requisito** extrayendo sus condiciones de prueba (cada cosa comprobable que afirma); después **derivar los casos**, cubriendo tanto el comportamiento esperado (casos positivos) como el rechazo de lo inválido (casos negativos), apoyándose en técnicas como clases de equivalencia y valores límite; luego **trazar** cada caso a su requisito con una **matriz de trazabilidad**, para detectar requisitos sin cubrir y casos sin motivo; y por último decidir **cuánta cobertura** es suficiente según el riesgo. La diferencia con otras guías: [qué es un caso](../que-es-un-caso-de-prueba/index.md) explica su anatomía y [las estrategias](../estrategias-para-escribir-casos-de-prueba/index.md) explican las técnicas; esta explica cómo ir *desde el requisito* hasta un conjunto que lo cubra sin huecos.

## El puente entre requisito y prueba

Un **requisito** dice qué debe hacer el sistema. Un **caso de prueba** comprueba que lo hace. El diseño de casos a partir de requisitos es el trabajo de tender ese puente de forma que se cumplan dos condiciones a la vez: que **ningún requisito quede sin comprobar** y que **ninguna prueba exista sin un motivo** que la respalde.

> **Atención**
>
> Tres guías tocan los casos de prueba desde ángulos distintos y complementarios. [Qué es un caso de prueba](../que-es-un-caso-de-prueba/index.md) explica su *anatomía*: precondiciones, pasos, datos, resultado esperado. [Estrategias para escribir casos](../estrategias-para-escribir-casos-de-prueba/index.md) explica las *técnicas* para generar casos a partir de las entradas. Y esta guía explica el *proceso*: cómo partir de un requisito concreto y llegar a un conjunto que lo cubra. Se usan juntas.

En el vocabulario del ISTQB, el requisito es parte de la **base de prueba**: el material del que se derivan las pruebas. De esa base se extraen **condiciones de prueba** (cada aspecto comprobable), y de cada condición nacen uno o más casos.

## Leer el requisito como tester

El primer paso es leer la especificación buscando *todo lo comprobable que afirma*, incluido lo que no dice explícitamente. Tomemos una historia de usuario típica con su criterio de aceptación:

```text
Historia: Como cliente, quiero aplicar un cupón de descuento
          para pagar menos por mi compra.

Criterios de aceptación:
  - El cupón se aplica sobre el subtotal, antes del envío.
  - Un cupón vencido no se aplica y muestra un aviso.
  - Solo se puede usar un cupón por compra.
  - El descuento nunca deja el total por debajo de cero.
```

De ahí se extraen las **condiciones de prueba**, que son afirmaciones comprobables. Cada criterio da al menos una, y el buen ojo del tester agrega las que el requisito *implica* pero no escribe:

- Un cupón válido reduce el subtotal correctamente (explícito).
- El descuento se calcula sobre el subtotal, no sobre el total con envío (explícito).
- Un cupón vencido se rechaza con aviso (explícito).
- Un segundo cupón se rechaza (explícito).
- ¿Qué pasa con un cupón inexistente o mal escrito? (implícito: el requisito no lo dice, y ese hueco es un hallazgo).
- ¿Y un cupón cuyo descuento supera el subtotal? (relacionado con «nunca por debajo de cero»).

Las preguntas por lo implícito son oro: los huecos en un requisito son defectos futuros, y detectarlos *antes* de programar es lo más barato que hace el testing.

## Derivar los casos

Cada condición de prueba se convierte en uno o más casos, y aquí entra una distinción clave: los casos **positivos** y **negativos**.

|  | Caso positivo | Caso negativo |
|---|---|---|
| **Qué comprueba** | Que el sistema hace lo que debe con entradas válidas | Que el sistema rechaza bien lo inválido |
| **Ejemplo (cupón)** | Cupón válido de 10 % reduce el subtotal en 10 % | Cupón vencido muestra aviso y no aplica |
| **Cuántos suele haber** | Menos: el camino feliz es uno | Más: hay muchas formas de estar mal |

Un error habitual de quien empieza es diseñar solo casos positivos —comprobar que funciona cuando todo está bien— y olvidar los negativos, que son los que más defectos encuentran. Para elegir *qué valores* probar en cada caso se aplican las técnicas de [clases de equivalencia y valores límite](../estrategias-para-escribir-casos-de-prueba/index.md): por ejemplo, para el criterio «nunca por debajo de cero», el valor límite es un cupón cuyo descuento iguala exactamente el subtotal, y otro que lo supera.

## La matriz de trazabilidad

La **matriz de trazabilidad** es una tabla simple que conecta cada requisito con los casos que lo comprueban. Parece burocracia, pero responde dos preguntas que de otro modo quedan en el aire:

| Criterio | Casos que lo cubren | Estado |
|---|---|---|
| Aplica sobre el subtotal | CP-01, CP-02 | Cubierto |
| Cupón vencido se rechaza | CP-03 | Cubierto |
| Un cupón por compra | CP-04 | Cubierto |
| Total nunca bajo cero | CP-05, CP-06 | Cubierto |
| Cupón inexistente | — | Sin cubrir |

> **Las dos preguntas que responde la trazabilidad**
>
> **¿Hay algún requisito sin ningún caso?** Es un hueco de cobertura: algo que nadie va a comprobar. **¿Hay algún caso que no corresponde a ningún requisito?** Es una prueba sin motivo, que quizás sobra o quizás señala un requisito no escrito. En el ejemplo, «cupón inexistente» quedó sin cubrir: o falta un caso, o falta que el equipo defina qué debe pasar. Las dos cosas son hallazgos valiosos.

## Cuánta cobertura es suficiente

Probarlo todo es imposible, así que «cuántos casos» no tiene una respuesta fija: depende del **riesgo**. La cobertura se decide preguntando, para cada parte, qué probabilidad hay de que falle y qué impacto tendría si falla.

- **Alto riesgo** (el cálculo del cobro, la seguridad, la pérdida de datos): cobertura exhaustiva, todos los casos positivos y negativos, todos los valores límite.
- **Riesgo medio**: los casos principales y los límites más probables.
- **Bajo riesgo** (un texto de ayuda, una preferencia cosmética): un caso que confirme que funciona, y a otra cosa.

Esta priorización por riesgo es el corazón de la estrategia de pruebas, y se desarrolla en [estrategias de prueba: qué probar, cuánto y por qué](../estrategias-de-prueba/index.md). La regla práctica: cubrir todas las *condiciones* de prueba (que nada quede sin comprobar) y concentrar la *profundidad* donde el riesgo lo justifica.

## Errores frecuentes

- **Diseñar solo casos positivos.** Los negativos encuentran más defectos y suelen ser más numerosos.
- **Ignorar lo implícito del requisito.** Los huecos de la especificación son defectos futuros; detectarlos temprano es lo más barato.
- **No trazar los casos a los requisitos.** Sin trazabilidad no sabés si algo quedó sin cubrir ni por qué existe cada prueba.
- **Buscar cobertura total.** Es imposible; la cobertura se prioriza por riesgo.
- **Confundir esta tarea con las técnicas.** Las técnicas eligen valores; el diseño desde requisitos define qué condiciones cubrir.
- **Escribir casos irreproducibles.** Cada caso necesita precondiciones, pasos y datos claros, como en la anatomía del caso.
- **Tratar la trazabilidad como burocracia.** Es la herramienta que detecta huecos y pruebas huérfanas.

## Preguntas frecuentes

**¿En qué se diferencia esto de las estrategias para escribir casos?**
Son dos partes complementarias del mismo trabajo. Las estrategias para escribir casos se ocupan de las técnicas para elegir qué valores probar a partir de las entradas: clases de equivalencia, valores límite, tablas de decisión. Responden a la pregunta de qué datos concretos usar. Esta guía, en cambio, se ocupa del proceso completo que va desde un requisito hasta un conjunto de casos que lo cubra: cómo leer la especificación, extraer sus condiciones de prueba explícitas e implícitas, derivar casos positivos y negativos, y trazar cada uno de vuelta al requisito para no dejar huecos. En resumen, esta guía define qué hay que cubrir partiendo de la especificación, y las estrategias definen cómo elegir los valores dentro de cada caso; se usan juntas.

**¿Qué es una condición de prueba?**
Es cada aspecto comprobable que se extrae de la base de prueba, es decir, del requisito, la historia de usuario o cualquier material que describa qué debe hacer el sistema. Una historia con cuatro criterios de aceptación suele dar al menos cuatro condiciones de prueba explícitas, una por criterio, pero un buen análisis agrega también las condiciones implícitas: lo que el requisito da por supuesto pero no escribe, como qué debe pasar con una entrada inexistente o mal formada. De cada condición de prueba nacen luego uno o más casos concretos. Pensar primero en condiciones y después en casos evita el error de saltar directamente a escribir pruebas y descubrir tarde que quedaron aspectos del requisito sin comprobar.

**¿Para qué sirve una matriz de trazabilidad?**
Sirve para conectar cada caso de prueba con el requisito del que nació, y con eso responder dos preguntas que de otro modo quedan sin respuesta. La primera: ¿hay algún requisito que no tenga ningún caso que lo compruebe? Eso es un hueco de cobertura, algo que nadie va a verificar y que puede llegar roto a producción. La segunda: ¿hay algún caso que no corresponda a ningún requisito? Eso es una prueba sin justificación, que o bien sobra o bien está señalando un requisito que nadie escribió. Aunque parezca burocracia, la matriz es una herramienta de detección muy eficaz, especialmente cuando un requisito cambia y hay que saber rápidamente qué casos se ven afectados.

**¿Por qué son tan importantes los casos negativos?**
Porque el software suele fallar más al manejar lo inesperado que al hacer lo correcto. Un caso positivo comprueba que el sistema hace lo que debe cuando todo está bien, y normalmente hay un solo camino feliz. Los casos negativos comprueban que el sistema rechaza adecuadamente lo inválido, y hay muchísimas formas de estar mal: un dato vacío, uno enorme, uno con símbolos raros, uno fuera de rango, una acción fuera de orden. Quien diseña solo casos positivos verifica que la aplicación funciona en el mejor escenario y deja sin comprobar justamente donde se esconden la mayoría de los defectos. Por eso un buen conjunto de casos suele tener más casos negativos que positivos, y por eso conviene preguntarse siempre qué pasa cuando la entrada no es la esperada.

**¿Cuántos casos de prueba debería escribir para un requisito?**
Los necesarios para cubrir todas sus condiciones de prueba, con una profundidad que depende del riesgo. No hay un número fijo, porque probarlo todo es imposible. La regla es cubrir cada condición —que ningún aspecto del requisito quede sin comprobar— y luego concentrar el esfuerzo donde más importa. Para las partes de alto riesgo, como el cálculo de un cobro, la seguridad o algo que pueda causar pérdida de datos, conviene cobertura exhaustiva: todos los casos positivos y negativos y todos los valores límite. Para partes de riesgo medio, los casos principales y los límites más probables. Y para algo de bajo riesgo, como un texto de ayuda, un solo caso que confirme que funciona suele bastar. Esa priorización por riesgo es lo que hace sostenible el diseño de casos.

**¿Qué hago si el requisito está incompleto o es ambiguo?**
Tratarlo como un hallazgo, no como un obstáculo. Cuando al derivar condiciones de prueba aparecen preguntas que el requisito no responde —qué pasa con un cupón inexistente, qué ocurre si dos condiciones se contradicen, cuál es el límite exacto de un rango—, esas preguntas son defectos detectados antes de programar, y encontrarlos en esta etapa es lo más barato que puede hacer el testing. La matriz de trazabilidad los deja a la vista como requisitos sin cubrir o casos sin requisito claro. Lo correcto es llevar esas dudas a quien definió el requisito para que las aclare, y recién entonces terminar de diseñar los casos. Diseñar sobre un requisito ambiguo sin plantear las dudas solo traslada la ambigüedad a las pruebas, que quedarán tan poco claras como la especificación.

## Fuentes

Documentación oficial y material de la comunidad consultados para esta guía. Fecha de consulta: 28 de julio de 2026.

### Aportes de la comunidad Underc0de

1. **Underc0de, foro.** [Sección QA (Quality Assurance)](https://underc0de.org/foro/qa-testing/). Consultas sobre diseño de casos, criterios de aceptación y cobertura.
2. **Underc0de, foro.** [Sección Informática](https://underc0de.org/foro/informatica/). Aportes sobre requisitos y metodología de calidad.

### Documentación oficial

1. **ISTQB.** [Foundation Level Syllabus](https://www.istqb.org/certifications/certified-tester-foundation-level). El marco sobre trazabilidad entre bases de prueba y casos, y las técnicas de diseño.
2. **ISO/IEC/IEEE.** [29119 Software Testing](https://www.iso.org/standard/81291.html). El estándar internacional de procesos y documentación de pruebas.
3. **ISTQB.** [Glosario](https://glossary.istqb.org/). Definiciones de base de prueba, condición de prueba, caso de prueba y trazabilidad.
4. **Agile Alliance.** [Acceptance Criteria](https://www.agilealliance.org/glossary/acceptance/). El rol de los criterios de aceptación en las historias de usuario.

## Guías relacionadas

- [Qué es un caso de prueba](../que-es-un-caso-de-prueba/index.md)
- [Estrategias para escribir casos](../estrategias-para-escribir-casos-de-prueba/index.md)
- [Testing manual desde cero](../testing-manual-desde-cero/index.md)
- [Estrategias de prueba](../estrategias-de-prueba/index.md)
- [Índice de Testing y QA](../index.md)