# Estrategias para escribir casos de prueba

**Categoría:** Testing y QA · **Nivel:** Intermedio · **Lectura:** 16 min
**Publicada:** 2026-07-27 · **Actualizada:** 2026-07-27 · **Autoría:** Underc0de
**Versión HTML (canónica):** https://underc0de.org/guias/testing/estrategias-para-escribir-casos-de-prueba/

Las técnicas de diseño que usan los equipos de QA: particiones de equivalencia, valores límite, tablas de decisión, transición de estados, cobertura y experiencia.

## Respuesta rápida

Las **técnicas de diseño de pruebas** existen para construir, en palabras de ISTQB, «un conjunto relativamente pequeño pero suficiente de casos de prueba, de forma sistemática». Se agrupan en tres familias: **caja negra**, que parte del comportamiento especificado (particiones de equivalencia, valores límite, tablas de decisión, transición de estados); **caja blanca**, que parte de la estructura del código (cobertura de sentencias y de ramas); y **basadas en experiencia** (conjetura de errores, exploratorias, listas de comprobación). No son alternativas: cada familia encuentra defectos que las otras dos no ven.

## Antes de escribir: análisis y diseño

Hay una distinción del programa Foundation de ISTQB que ordena todo lo que viene después. Las técnicas de prueba «apoyan a quien prueba en el **análisis de prueba** (qué probar) y en el **diseño de prueba** (cómo probarlo)».

Son dos actividades distintas y se hacen en ese orden. En el análisis se recorre la **base de prueba** —los requisitos, la historia, el diseño, la conversación con quien pidió la funcionalidad— y se identifican las **condiciones de prueba**: los aspectos verificables que vale la pena cubrir. En el diseño, cada condición se convierte en casos concretos, y ahí es donde entran las técnicas.

Saltear el análisis es el error más caro y el más frecuente: se empieza a escribir casos sobre lo primero que salta a la vista y se termina con veinte casos del formulario principal y ninguno del proceso que corre de noche. Las técnicas no arreglan eso, porque una técnica bien aplicada a la condición equivocada sigue siendo esfuerzo perdido.

> **Dónde encaja esta guía:** si todavía no tenés claro qué es exactamente un caso de prueba y cuáles son sus partes, empezá por [qué es un caso de prueba](../que-es-un-caso-de-prueba/index.md). Si lo que necesitás es decidir *cuánto* probar y con qué criterio de suficiencia —una decisión que está por encima de las técnicas—, eso está en [estrategias de prueba](../estrategias-de-prueba/index.md).

## Las tres familias de técnicas

ISTQB clasifica las técnicas en tres grupos según de dónde sacan la información para diseñar los casos. La clasificación no es académica: determina *cuándo* podés aplicar cada técnica y *qué tipo* de defecto encuentra.

![Tres columnas comparadas: caja negra o basada en especificación, con particiones de equivalencia, valores límite, tablas de decisión y transición de estados, cuya ventaja es que los casos sobreviven a cambios de implementación; caja blanca o basada en estructura, con cobertura de sentencias y de ramas, que solo se puede aplicar después del diseño; y basadas en experiencia, con conjetura de errores, pruebas exploratorias y listas de comprobación, que detectan defectos que las otras dos pasan por alto.](../../assets/img/guias/estrategias-para-escribir-casos-de-prueba-familias.svg)

*Las tres familias según ISTQB. La de caja blanca es la única que exige que el código ya exista.*

Dos consecuencias prácticas que salen directamente de esa clasificación:

- **Los casos de caja negra se pueden escribir antes de que exista el código.** Como se derivan del comportamiento especificado y no de la implementación, se pueden diseñar en paralelo al desarrollo. Y como dice el programa: «si la implementación cambia pero el comportamiento requerido se mantiene, los casos de prueba siguen siendo útiles». Es lo que los hace duraderos.
- **Los de caja blanca solo se pueden crear después del diseño o la implementación**, porque dependen de cómo está construido el software. Su contracara es que se rompen cuando alguien refactoriza, aunque el comportamiento no haya cambiado.

## Particiones de equivalencia

Es la técnica que más reduce el trabajo y la primera que conviene dominar. ISTQB la define como «una técnica de caja negra en la que las condiciones de prueba son particiones de equivalencia, ejercitadas por un miembro representativo de cada partición».

La idea de fondo: si el sistema debería tratar igual a todos los valores de un grupo, probar dos valores del mismo grupo no agrega información. Alcanza con uno.

Tomemos un campo que acepta una cantidad de licencias entre 1 y 50, con un descuento distinto a partir de 10. Las particiones son:

| Partición | Tipo | Representante | Qué debería pasar |
|---|---|---|---|
| Menor que 1 | Inválida | 0 | Rechaza con mensaje de mínimo |
| De 1 a 9 | Válida | 5 | Acepta sin descuento |
| De 10 a 50 | Válida | 25 | Acepta con descuento |
| Mayor que 50 | Inválida | 60 | Rechaza con mensaje de máximo |
| No numérico | Inválida | `abc` | Rechaza o no permite escribir |
| Vacío | Inválida | — | Rechaza como campo obligatorio |

Seis casos en lugar de cincuenta y pico. Y notá algo que se pasa por alto seguido: **el descuento a partir de 10 crea una partición**. Si solo hubiéramos mirado el rango 1-50, habríamos escrito un caso con el valor 25 y otro con el 30, que pertenecen a la misma clase, y ninguno con un valor menor a 10. Las particiones no salen solo de los límites del campo: salen de *cada regla que cambia el comportamiento*.

> **Una partición inválida por caso:** cuando pruebes valores inválidos, poné uno por caso. Si mandás un formulario con la cantidad vacía *y* el correo mal escrito, y el sistema rechaza, no sabés cuál de las dos validaciones actuó, ni si la otra existe. Los valores válidos, en cambio, se pueden combinar sin problema.

## Análisis de valores límite

ISTQB la define de forma escueta: «una técnica de caja negra en la que las condiciones de prueba son valores límite». Se usa siempre **después** de identificar las particiones, porque los límites son los bordes de esas particiones.

La razón de ser es empírica: los defectos se concentran en los bordes, porque ahí es donde se escriben las comparaciones y donde es fácil equivocar un `>` por un `>=`, o contar desde cero cuando había que contar desde uno.

El programa Foundation cubre **dos variantes**, y conviene saber que existen las dos porque cambian bastante la cantidad de casos:

| Variante | Qué prueba en cada borde | Valores para el rango 1–50 |
|---|---|---|
| **Dos valores** | El límite y su vecino del lado opuesto | 0, 1 … 50, 51 |
| **Tres valores** | El límite y sus dos vecinos | 0, 1, 2 … 49, 50, 51 |

La de dos valores alcanza en la enorme mayoría de los contextos. La de tres se justifica cuando el costo de un fallo es alto: cálculos financieros, dosis, control industrial. Cuál usar no es una decisión de diseño caso por caso, sino algo que corresponde definir en la estrategia de prueba del proyecto.

Un detalle que se olvida: **los límites no son solo numéricos**. Hay bordes en la longitud de un texto (0 caracteres, 1, el máximo, el máximo más uno), en las fechas (el 28, 29, 30 y 31 de febrero de un año bisiesto y de uno común), en el tamaño de un archivo, en la cantidad de elementos de una lista y en el final de una página de resultados.

## Tablas de decisión

Cuando el comportamiento depende de la **combinación** de varias condiciones, las particiones por sí solas no alcanzan. ISTQB define esta técnica como aquella «en la que las condiciones de prueba son las combinaciones de condiciones y las acciones resultantes mostradas en una tabla de decisión».

Se arma poniendo las condiciones arriba y las acciones abajo, con una columna por combinación. Ejemplo con tres condiciones para aplicar un descuento:

| Condición | R1 | R2 | R3 | R4 |
|---|---|---|---|---|
| Cliente registrado | Sí | Sí | Sí | No |
| Cantidad ≥ 10 | Sí | Sí | No | — |
| Paga por transferencia | Sí | No | — | — |
| **Descuento aplicado** | **15 %** | **10 %** | **0 %** | **0 %** |

Los guiones marcan condiciones **irrelevantes** para esa regla: si el cliente no está registrado, no importa la cantidad ni el medio de pago. Esa simplificación es la que evita que la tabla crezca a las ocho combinaciones que darían tres condiciones binarias.

> **El verdadero valor de la técnica:** lo más útil de una tabla de decisión no son los casos que produce, sino las **preguntas que obliga a hacer**. Al enumerar las combinaciones, casi siempre aparecen dos o tres que el requisito no especifica. Descubrirlas antes de que alguien programe cuesta una conversación; descubrirlas en producción cuesta bastante más.

## Transición de estados

Esta técnica aplica cuando el sistema **se comporta distinto según en qué situación esté**, y no solo según lo que se le manda. ISTQB: «una técnica de caja negra en la que las condiciones de prueba son transiciones de estado o secuencias de ellas».

Los casos típicos son abundantes: el ciclo de un pedido (nuevo, pagado, enviado, entregado, cancelado), una sesión (anónima, autenticada, expirada), un defecto en el gestor de incidencias, un reproductor de video, un cajero automático.

Se dibuja el diagrama de estados y de ahí salen tres niveles de cobertura, cada uno con más casos que el anterior:

1. **Todos los estados.** Cada estado se alcanza al menos una vez. Es el mínimo y suele ser insuficiente.
2. **Todas las transiciones válidas.** Cada flecha del diagrama se recorre al menos una vez. Es el objetivo razonable en la mayoría de los proyectos.
3. **Las transiciones inválidas.** Los intentos que *no* deberían funcionar: cancelar un pedido ya entregado, pagar dos veces el mismo pedido. Acá aparecen los defectos más costosos.

Ese tercer nivel es el que distingue a un equipo que aplica la técnica de uno que solo dibujó el diagrama. Un pedido que se puede cancelar después de entregado, o una sesión expirada que sigue permitiendo operaciones, son exactamente el tipo de fallo que ninguna prueba del camino feliz va a encontrar.

## Caja blanca y cobertura

Las técnicas de caja blanca parten de la estructura interna del código. El programa Foundation cubre dos medidas de cobertura:

- **Cobertura de sentencias:** «la cobertura de las sentencias ejecutables del código fuente». Qué porcentaje de las líneas ejecutables se ejecutó al menos una vez.
- **Cobertura de ramas:** «la cobertura de las ramas en un grafo de flujo de control». Qué porcentaje de los resultados posibles de las decisiones se ejercitó.

La diferencia entre ambas importa más de lo que parece. Un `if` sin `else` que se ejecuta con la condición verdadera da 100 % de cobertura de sentencias y solo 50 % de ramas, porque la rama «falso» nunca se recorrió. Por eso la cobertura de ramas es la medida más informativa de las dos.

> **La cobertura detecta huecos, no mide calidad:** un 0 % de cobertura en un módulo crítico es una señal inequívoca de que nadie lo probó, y ahí la métrica es valiosísima. Pero el 100 % no garantiza nada: se puede ejecutar todo el código sin una sola aserción útil. Ejecutar una línea no es comprobar que hace lo correcto. Usá la cobertura para encontrar lo que falta probar, nunca como objetivo del equipo.

En la práctica cotidiana, quien escribe pruebas unitarias usa caja blanca casi sin nombrarla: mira el código, ve que hay tres ramas y escribe tres pruebas. Y para profundizar en técnicas más allá del nivel Foundation, el propio programa remite al estándar ISO/IEC/IEEE 29119-4, que es la parte de la serie dedicada específicamente a técnicas de prueba.

## Técnicas basadas en experiencia

Esta familia suele mirarse con desconfianza porque no es sistemática, y es un error: el programa de ISTQB señala que «pueden detectar defectos que las técnicas de caja negra y de caja blanca pasarían por alto», y que por eso son **complementarias**. También advierte lo obvio: «su efectividad depende mucho de las habilidades de quien prueba».

### Conjetura de errores

«Una técnica en la que las condiciones de prueba se basan en el conocimiento de quien prueba sobre fallos pasados o modos de fallo». En concreto: uno ya sabe dónde suele romperse el software. Campos con apóstrofos y acentos, nombres muy largos, dobles clics, el botón «atrás» del navegador a mitad de un flujo, pérdida de conexión al confirmar, dos pestañas con la misma sesión, husos horarios, importes con muchos decimales.

La forma de institucionalizarla es llevar una lista de los defectos que ya aparecieron en el proyecto, porque los modos de fallo se repiten.

### Pruebas exploratorias

«Un enfoque en el que las pruebas se diseñan y ejecutan de forma dinámica en función del conocimiento de quien prueba, la exploración del objeto de prueba y los resultados de pruebas previas». No es tocar botones al azar: la versión disciplinada trabaja con **sesiones acotadas**, con una misión escrita, un tiempo fijo y notas de lo encontrado.

Lo que hace irremplazable a lo exploratorio es que los casos preescritos solo pueden encontrar lo que alguien ya imaginó. Y lo que la vuelve insuficiente por sí sola es que no es repetible: cuando encontrás un defecto explorando, el paso siguiente es escribir el caso que lo cubra, para que la regresión lo detecte de ahí en adelante.

### Listas de comprobación

«Una técnica basada en experiencia en la que los casos de prueba se diseñan para ejercitar los elementos de una lista de comprobación». Son ideales para verificaciones transversales que aplican a muchas pantallas: accesibilidad, comportamiento en móvil, mensajes de error, estados de carga y de listas vacías. Más livianas que un caso completo y más confiables que la memoria.

## Cómo combinarlas en un caso real

Las técnicas no se eligen: se encadenan. Este es un orden de trabajo que funciona para una funcionalidad nueva.

1. **Leé la base de prueba y listá condiciones.** Sin escribir casos todavía. Cada regla, cada validación, cada estado, cada mensaje.
2. **Aplicá particiones a cada entrada.** Agrupá los valores por comportamiento esperado, incluyendo las clases inválidas.
3. **Tomá los límites de cada partición.** Con la variante de dos valores, salvo que el riesgo justifique la de tres.
4. **Si hay reglas combinadas, armá la tabla de decisión.** Y anotá las combinaciones que el requisito no especifica: son preguntas, no casos.
5. **Si hay estados, dibujá el diagrama.** Cubrí todas las transiciones válidas y elegí las inválidas más riesgosas.
6. **Sumá conjetura de errores.** Repasá la lista de fallos históricos del proyecto y agregá los que apliquen.
7. **Reservá tiempo para explorar.** Una sesión acotada sobre lo nuevo, con misión escrita, después de ejecutar lo sistemático.
8. **Aplicá la lista de comprobación transversal.** Accesibilidad, móvil, estados vacíos y mensajes, sobre las pantallas afectadas.

Los pasos 1 a 5 se pueden hacer **antes de que exista el código**, y conviene hacerlo: es la forma más económica de encontrar ambigüedades en los requisitos. Los pasos 6 a 8 necesitan la aplicación funcionando.

Cuando estos casos ya estén estabilizados y se repitan en cada entrega, es el momento de pensar en automatizarlos. Para eso, la [comparativa de Selenium, Cypress y Playwright](../selenium-cypress-playwright/index.md) ayuda a elegir con qué.

## Errores frecuentes al diseñar

- **Escribir casos sin haber hecho el análisis.** Se termina con veinte casos de la pantalla principal y ninguno del proceso que corre de noche.
- **Confundir cantidad con rigor.** Dos casos de la misma partición son un caso y un duplicado.
- **Probar solo particiones válidas.** El camino feliz es donde menos defectos hay, porque es lo que más se usó durante el desarrollo.
- **Combinar varias entradas inválidas en un caso.** Si el sistema rechaza, no sabés qué validación actuó ni si las otras existen.
- **Buscar límites solo en los números.** Longitud de texto, fechas, tamaños de archivo, listas vacías y paginación también tienen bordes.
- **Ignorar las transiciones inválidas.** Ahí viven los defectos que llegan a producción y salen caros.
- **Tratar la cobertura como meta.** Se llega al 100 % sin una sola aserción útil.
- **Descartar lo exploratorio por «poco riguroso».** Encuentra justamente lo que nadie pensó en escribir.
- **No documentar el criterio de suficiencia.** Si no está escrito cuánto alcanza, la discusión se repite en cada entrega.

## Preguntas frecuentes

**¿Cuántos casos de prueba hay que escribir?**
La respuesta normativa es elegante: ISTQB dice que las técnicas sirven para desarrollar «un conjunto relativamente pequeño, pero suficiente, de casos de prueba de forma sistemática». No hay un número: hay un criterio de suficiencia que vos definís y documentás. En la práctica, la cantidad la determina el riesgo. Un campo de texto en un formulario interno se cubre con tres casos; el cálculo de una liquidación de sueldos puede necesitar treinta. Escribir muchos casos no es señal de rigor: si dos casos pertenecen a la misma partición de equivalencia, el segundo no agrega información.

**¿Cuál es la diferencia entre partición de equivalencia y valores límite?**
Son complementarias y se usan casi siempre juntas. Las particiones de equivalencia agrupan las entradas en clases donde el sistema debería comportarse igual, y se prueba un representante de cada clase: cubren el interior de cada grupo. El análisis de valores límite se concentra en los bordes entre esas clases, que es donde se escriben las comparaciones y donde es fácil confundir «mayor que» con «mayor o igual que». Primero se identifican las particiones y después se toman sus límites: la segunda técnica necesita la primera.

**¿Qué son los valores límite de dos y de tres valores?**
Son dos variantes de la misma técnica, y ambas están en el programa Foundation de ISTQB. En la de dos valores se prueba el límite y su vecino inmediato del otro lado: para un rango de 18 a 65 serían 17, 18, 65 y 66. En la de tres valores se agrega el vecino del mismo lado del límite: 17, 18, 19 y 64, 65, 66. La de tres valores es más exhaustiva y cuesta más casos; la de dos alcanza en la mayoría de los contextos. Cuál usar es una decisión que corresponde a la estrategia de prueba, no al diseño de cada caso.

**¿Las pruebas exploratorias reemplazan a los casos escritos?**
No, y tampoco al revés. ISTQB clasifica lo exploratorio como un enfoque en el que las pruebas se diseñan y ejecutan de forma dinámica según el conocimiento de quien prueba, la exploración del objeto y los resultados previos. Encuentra cosas que nadie pensó en escribir, que es precisamente lo que los casos preescritos no pueden hacer. Pero no es repetible ni auditable por sí sola: si encontrás un defecto explorando, el paso siguiente es escribir el caso que lo cubra para que la regresión lo detecte en el futuro.

**¿Sirve para algo la cobertura de código?**
Sirve para detectar huecos, no para medir calidad. La cobertura de sentencias mide qué porcentaje de las sentencias ejecutables se ejecutaron, y la de ramas qué porcentaje de los resultados de las decisiones. Son útiles porque un 0 % en un módulo crítico es una señal inequívoca de que nadie lo probó. El problema es tratarlas como meta: se puede llegar al 100 % de cobertura sin una sola aserción útil, porque ejecutar una línea no es lo mismo que comprobar que hace lo correcto. Cobertura baja es un problema; cobertura alta no es una garantía.

**¿Cuándo conviene una tabla de decisión?**
Cuando el comportamiento depende de la combinación de varias condiciones, no de una sola. El caso típico son las reglas de negocio con varios criterios: descuentos que dependen del tipo de cliente, del monto y del medio de pago. La tabla obliga a enumerar las combinaciones y ahí es donde aparece lo valioso: casi siempre se descubre que el requisito no dice qué pasa en dos o tres combinaciones. Ese hallazgo, hecho antes de programar, vale más que los casos que salen de la tabla.

## Fuentes

Programa de certificación, glosario normativo y estándares consultados para esta guía. Fecha de consulta: 27 de julio de 2026.

1. **ISTQB, vía ASTQB.** [Foundation Level Syllabus — 4.1 Test Techniques Overview](https://astqb.org/4-1-test-techniques-overview/). Clasificación en caja negra, caja blanca y experiencia; distinción entre análisis y diseño; carácter complementario de las tres familias.
2. **ISTQB.** [Glosario: *equivalence partitioning*](https://glossary.istqb.org/en_US/term/equivalence-partitioning) y [*boundary value analysis*](https://glossary.istqb.org/en_US/term/boundary-value-analysis). Definiciones de las dos técnicas de caja negra más usadas.
3. **ISTQB.** [Glosario: *decision table testing*](https://glossary.istqb.org/en_US/term/decision-table-testing) y [*state transition testing*](https://glossary.istqb.org/en_US/term/state-transition-testing). Técnicas para reglas combinadas y para sistemas con estados.
4. **ISTQB.** [Glosario: *statement coverage*](https://glossary.istqb.org/en_US/term/statement-coverage) y [*branch coverage*](https://glossary.istqb.org/en_US/term/branch-coverage). Las dos medidas de cobertura del nivel Foundation.
5. **ISTQB.** [Glosario: *error guessing*](https://glossary.istqb.org/en_US/term/error-guessing), [*exploratory testing*](https://glossary.istqb.org/en_US/term/exploratory-testing) y [*checklist-based testing*](https://glossary.istqb.org/en_US/term/checklist-based-testing). Las tres técnicas basadas en experiencia.
6. **ISO/IEC/IEEE.** [ISO/IEC/IEEE 29119 Software Testing](https://www.softwaretestingstandard.org/). La Parte 4 de la serie está dedicada a técnicas de prueba, y es la referencia que cita el propio programa de ISTQB para profundizar.
7. **Underc0de, foro.** [«Plantilla para armar casos de prueba (Checklist)»](https://underc0de.org/foro/qa-testing/plantilla-para-armar-casos-de-prueba-checklist/), por *ANTRAX*, 16 de mayo de 2023, sección QA. Plantilla de la comunidad donde volcar los casos que salen de estas técnicas.

## Guías relacionadas

- [Qué es un caso de prueba y cómo se compone](../que-es-un-caso-de-prueba/index.md) — la anatomía de la unidad básica.
- [Estrategias de prueba: qué probar, cuánto y por qué](../estrategias-de-prueba/index.md) — el nivel de decisión que está por encima de las técnicas.
- [Testing de software: guía para empezar en QA](../introduccion-al-testing/index.md) — el panorama completo.
- [Guías de Testing y QA](../index.md)

---

Esta guía forma parte de un proyecto de la comunidad Underc0de para organizar conocimiento técnico en español. Fuente canónica: https://underc0de.org/guias/testing/estrategias-para-escribir-casos-de-prueba/