Los nuevos evaluadores a menudo escuchan estos dos términos utilizados como si significaran lo mismo. No es así. La diferencia entre un caso de prueba y un escenario de prueba radica principalmente en el nivel de detalle, y comprenderlo le ayuda a decidir cuánto escribir antes de comenzar a realizar la prueba.

Esta guía explica cada uno de ellos y luego trabaja a través de una única función de restablecimiento de contraseña, desde requisitos hasta escenarios y casos de prueba completos. La característica y sus reglas son un ejemplo inventado. La terminología también varía un poco entre equipos y herramientas, así que acuerde lo que significan estas palabras en su propio equipo.

La respuesta corta

Un escenario de prueba describe una situación a verificar, como “verificar que un usuario puede restablecer una contraseña olvidada”. Generalmente es una línea y deja los detalles al evaluador.

Un caso de prueba explica con precisión cómo verificar una condición dentro de esa situación: condiciones previas, pasos, datos de prueba y el resultado esperado. Dos evaluadores que lo sigan deberían llegar al mismo veredicto.

Piense en planificar un viaje. El escenario es “viajar de Pune a Delhi”. El caso de prueba es el itinerario completo, con el número de vuelo, hora de salida y qué hacer en cada etapa.

Caso de prueba versus escenario de prueba uno al lado del otro

¿Qué es un escenario de prueba?

Un escenario de prueba es una breve descripción de algo que un usuario podría hacer o una situación que el sistema debe manejar. Se centra en lo que importa desde el exterior y, por lo general, proviene directamente de un requisito o una historia de usuario.

Los escenarios son valiosos porque son rápidos. Puede enumerar treinta en el tiempo que lleva escribir tres casos detallados, lo que los convierte en una excelente manera de revisar la cobertura con el propietario del producto: “¿hemos pensado en todo?” Un lector no técnico puede seguir una lista de escenarios sin problemas.

¿Qué es un caso de prueba?

Un caso de prueba es un conjunto de condiciones y pasos específicos que se utilizan para determinar si algo funciona. Un caso de prueba típico contiene:

• Un ID único y un título claro
• Condiciones previas, es decir, lo que debe ser cierto antes de comenzar
• pasos numerados
• datos de prueba específicos
• Un resultado esperado
• El resultado real y el estado, completados cuando se ejecuta

Los casos de prueba brillan cuando la coherencia importa. Un nuevo miembro del equipo puede ejecutarlos, los resultados se pueden comparar entre versiones y usted tiene un registro de lo que se verificó. Profundizamos en nuestra guía sobre cómo escribir casos de prueba.

Una característica, de principio a fin

Paso 1: El requisito

Los usuarios que olviden su contraseña pueden solicitar un enlace de restablecimiento por correo electrónico. El enlace funciona una vez y caduca después de 30 minutos. Una nueva contraseña debe tener al menos 8 caracteres.

Paso 2: los escenarios de prueba

Mira TS-02. El requisito nunca dice qué debería suceder con un correo electrónico desconocido, y escribir el escenario expuso esa brecha. ¿La página debería revelar que la dirección no está registrada? Por seguridad, normalmente no debería ser así, ya que permite a los atacantes descubrir cuentas válidas. Encontrar estas preguntas temprano es uno de los mayores beneficios de escribir escenarios.

Paso 3: los casos de prueba

Ahora ampliamos solo TS-05 a casos de prueba. Un escenario se convierte en varios:

Estos valores no fueron aleatorios. TC-051 y TC-052 se ubican a ambos lados del límite, utilizando análisis de valores límite, y los demás provienen de partición de equivalencia.

Una plantilla de caso de prueba

Aquí está el TC-052 escrito en su totalidad. Copie este diseño si su equipo aún no tiene un estándar:

ID:            TC-052
Title:         Reset rejects a password of 7 characters
Scenario:      TS-05 New password rules are enforced
Priority:      High
Preconditions: Account asha@example.com exists
               A valid, unused reset link has been requested
Test data:     New password: abcd123

Steps:
  1. Open the reset link from the email
  2. Enter abcd123 in New password
  3. Enter abcd123 in Confirm password
  4. Click Reset password

Expected:      Error "Password must be at least 8 characters"
               Password is unchanged, and the link stays valid
Actual:        (filled in during the run)
Status:        (Pass / Fail / Blocked)

Observe que el resultado esperado verifica más que el mensaje de error. También confirma que la contraseña anterior aún funciona y que el enlace sigue siendo utilizable. Los casos de prueba débiles a menudo se detienen en lo que se ve en la pantalla.

Dónde encajan en el panorama general

Tradicionalmente, los escenarios y casos se escriben durante la fase de diseño de pruebas del ciclo de vida de las pruebas de software.

Cuando usar cada

Los escenarios suelen ser suficientes cuando:

• El equipo es pequeño, tiene experiencia y conoce bien el producto.
• El tiempo es corto o los requisitos cambian con frecuencia.
• La característica es de bajo riesgo.
• Quiere revisar la cobertura rápidamente con las partes interesadas.
• Estás guiando pruebas exploratorias.

Los casos de prueba detallados merecen el esfuerzo cuando:

• Un fallo sería costoso, como ocurre con los pagos, la seguridad o los datos de salud.
• Los reguladores o auditores necesitan evidencia de lo que se probó.
• Los evaluadores nuevos o subcontratados deben ejecutar las pruebas.
• Los resultados deben repetirse exactamente, como en un conjunto de regresión.
• Los pasos se convertirán en pruebas automatizadas.

La mayoría de los equipos maduros usan ambos. Enumeran escenarios para todo y escriben casos completos sólo para los riesgos más altos. No es necesario documentar cada paso de una página de configuración de bajo riesgo del mismo modo que una transferencia bancaria.

Escenarios, casos y automatización.

Un caso de prueba bien escrito se relaciona casi directamente con una prueba automatizada. Las condiciones previas se convierten en configuración, los pasos se convierten en acciones y el resultado esperado se convierte en una afirmación. Los marcos de desarrollo basados en el comportamiento incluso utilizan la palabra “Escenario” para sus especificaciones ejecutables:

Scenario: Reset rejects a short password
  Given I have opened a valid reset link
  When I submit the new password "abcd123"
  Then I see "Password must be at least 8 characters"
  And my password is unchanged

De manera confusa, lo que BDD llama un escenario está mucho más cerca de un caso de prueba, porque tiene datos y resultados específicos. Éste es un buen recordatorio para llegar a un acuerdo sobre los términos. Para automatizar estas comprobaciones, consulte nuestro tutorial de dramaturgo o el tutorial de pytest.

¿Qué los hace buenos?

Errores comunes

• Escribir solo caminos felices. La mayoría de los errores se encuentran en las condiciones de error, así que incluya lo que debería fallar.
• Usar resultados esperados vagos. “Debería funcionar correctamente” permite que cualquier evaluador decida cualquier cosa.
• Documentar todo en su totalidad. Miles de casos que nadie mantiene son peores que un pequeño conjunto útil.
• Omitir escenarios. Saltar directamente a los casos puede dejar áreas enteras olvidadas.
• Dejar que los casos se vuelvan obsoletos. Cuando el producto cambia, los casos antiguos engañan a la gente. Revíselos periódicamente.
• Asociar pasos a detalles frágiles. “Haga clic en el botón azul en la parte superior” rompe con cualquier rediseño.

Conclusión

Los escenarios le brindan amplitud y los casos de prueba le brindan profundidad. Comience con escenarios para su próxima función y revíselos con un desarrollador y un propietario del producto. Luego expanda sólo los riesgosos a casos completos. Encontrará lagunas antes y dedicará su tiempo a escribir donde sea necesario.

Preguntas frecuentes

sigue aprendiendo