Caso de prueba, escenario y guion: tres cosas que no son la misma

Abres la suite de pruebas que heredaste. Hay una carpeta llamada "escenarios" que contiene archivos con pasos numerados, una carpeta "casos" que contiene código de Selenium, y una hoja de cálculo titulada "guiones de regresión" que en realidad describe comportamiento de negocio. Nadie recuerda por qué. Cada palabra apunta a algo distinto de lo que su nombre promete, y ahora tú tienes que adivinar.

Esto no es un problema estético. Cuando tres conceptos distintos comparten nombres intercambiados, la suite se vuelve ilegible: no sabes qué archivo describe una intención de negocio, cuál define una verificación concreta y cuál es solo código que aprieta botones. La respuesta corta es esta: caso de prueba, escenario y guion de automatización son tres capas diferentes, y confundirlas es la forma más barata de acumular deuda técnica en QA.

01 · la capaEl escenario describe una situación, no una verificación

Un escenario de prueba es la descripción de una situación de negocio que quieres cubrir. Responde a la pregunta "qué condición del mundo real me importa". No dice cómo verificarlo ni con qué datos exactos: dice qué historia estás contando. "Un usuario intenta pagar con una tarjeta vencida" es un escenario. Todavía no es una prueba ejecutable; es una intención.

El escenario vive en el lenguaje del producto, no en el del sistema. Por eso un analista de negocio puede leerlo y asentir sin saber nada de la base de datos. El estándar ISO/IEC/IEEE 29119-1 separa deliberadamente el nivel de la condición de prueba (lo que se quiere ejercitar) del nivel del caso concreto que la materializa [1]. El escenario es la bisagra entre el requisito y la prueba.

El escenario no verifica nada. Enmarca lo que vale la pena verificar.

La utilidad del escenario es de cobertura. Cuando listas escenarios, estás mapeando el espacio de situaciones que el producto debe soportar: tarjeta válida, tarjeta vencida, tarjeta sin fondos, red caída a mitad del pago. Un escenario puede dar origen a varios casos. Es un nivel de abstracción por encima, y perderlo de vista es lo que hace que las suites tengan mil casos sin que nadie sepa qué situaciones cubren de verdad.

02 · el oráculoEl caso de prueba tiene resultado esperado; el guion no decide nada

Un caso de prueba es la verificación concreta. Tiene lo que un escenario no tiene: precondiciones, datos de entrada específicos y, sobre todo, un resultado esperado. Ese resultado esperado es el oráculo: la afirmación de qué debería pasar para que la prueba se considere aprobada. Sin resultado esperado no hay caso de prueba; hay un paseo por la aplicación.

El ISTQB define el caso de prueba precisamente por esa terna: valores de entrada, precondiciones de ejecución y resultados esperados [2]. Un caso es ejecutable por un humano leyendo pasos, o por una máquina. Y aquí entra la tercera capa, la que más gente confunde con las otras dos.

El guion de automatización (el script) es código. Es la implementación mecánica de uno o varios casos para que se ejecuten sin una persona apretando botones. El punto crítico: el guion no aporta el oráculo, lo hereda del caso. Un script que hace clic en cosas y navega pantallas pero no afirma ningún resultado esperado no está probando nada; está automatizando un paseo. El resultado esperado vive en el caso; el guion solo lo comprueba a gran velocidad.

Por eso mezclar los nombres cuesta caro. Si llamas "caso" a un script sin aserciones, tu reporte de cobertura miente: dice que verificas algo que en realidad solo recorres. Si llamas "escenario" a un caso, pierdes el nivel de negocio y ya no puedes razonar sobre qué situaciones faltan. La terminología no es burocracia: es lo que hace que las métricas de la suite signifiquen algo.

03 · la deudaPor qué la higiene terminológica se paga sola dentro de un año

La confusión no duele el día que escribes la suite. Duele doce meses después, cuando otra persona (o tú mismo sin memoria del contexto) tiene que mantenerla. Una suite donde escenario, caso y guion están claramente separados se lee como un índice: arriba las situaciones, en medio las verificaciones, abajo el código. Una suite donde los tres nombres están intercambiados se lee como un jeroglífico.

Hay tres deudas concretas que nacen de la mezcla. La primera es la deuda de cobertura: sin la capa de escenario visible, nadie sabe qué situaciones de negocio quedaron sin probar, así que se descubren en producción. La segunda es la deuda de oráculo: cuando los guiones se llaman casos, se cuela automatización sin aserciones y la suite da falsa confianza. La tercera es la deuda de mantenimiento: cuando cambia una regla de negocio, no sabes qué archivos tocar porque los nombres no te dicen en qué capa vive cada cosa.

La regla operativa es simple. Nombra las carpetas por su capa y no dejes que un archivo suba o baje de nivel sin renombrarlo. Un escenario nunca contiene código. Un caso siempre contiene un resultado esperado. Un guion siempre hereda su oráculo de un caso y jamás inventa el suyo por accidente. Si respetas esas tres fronteras, la persona que abra tu suite dentro de un año podrá leerla sin arqueología.

La palabra descuidada de hoy es el archivo indescifrable de dentro de un año.

Cuando pases de la teoría a la práctica y empieces a convertir casos en guiones, esta separación se vuelve todavía más rentable: la automatización solo escala si cada script sabe exactamente qué caso implementa y qué oráculo comprueba. Sin esa disciplina de nombres, automatizar es multiplicar el desorden en lugar de reducir el esfuerzo.