Definición del caso de prueba

Un caso de prueba es una serie de pruebas de entrada, condiciones de ejecución y resultados esperados
desarrollados para un objetivo en particular, tal como ejecutar una ruta particular de un programa o verificar
el cumplimiento con un requerimiento en específico.

Los casos son frecuentemente clasificados por el tipo de prueba o requerimiento para prueba con el que
está asociado, y podrá variar por consiguiente. La mejor práctica es desarrollar por lo menos dos casos de
pruebas para cada requerimiento para prueba.
 Un caso de prueba para demostrar que el requerimiento ha sido satisfecho, frecuentemente se
refiere a un caso de prueba positiva. (Flujos básicos)

 Otros caso de prueba para reflejar que es inaceptable, anormal o inesperada la condición o dato,
frecuentemente referida a una prueba de casos negativa. (Flujos alternativos)

Objeto de Prueba: El componente o sistema a ser probado.

Ítem de Prueba: El elemento individual a ser probado. Usualmente hay un objeto de prueba y muchos
Ítems de prueba.

Especificación de casos de pruebas

• Realmente el estándar no pide que sean en archivos separados sin embargo exige que sean
independientes dentro del mismo archivo.

• Cuáles son las partes de la especificación de casos de pruebas.

– Identificador del caso de prueba.

– Ítems de prueba.
– Especificación de entradas.
– Especificación de salidas.
– Necesidades de ambientes.
– Requerimientos para el procedimiento.
– Interdependencia de los casos.

El propósito del análisis y diseño es producir diseños de pruebas con las condiciones y casos de pruebas
junto a su ambiente necesario basado en los objetivos y aproximaciones del plan de pruebas.

Pasos para la creación del caso de prueba

1. Definición del escenario de pruebas
Consiste en identificar todos los escenarios (caminos) a probar de un caso de uso: flujo básico, sub flujos y
flujos alternativos.

Definición de flujo, el flujo consiste en los pasos ordenados que se llevan a cabo durante la prueba. Se
pueden extender y alternar como se ve en la siguiente gráfica:

Por cada caso de uso, se debe establecer el flujo básico, que consiste en los pasos para cumplir con la
tarea de forma exitosa. De igual forma se deben establecer cada uno de los flujos alternos, que
normalmente corresponden a flujos disparados por reglas de negocios, validaciones y/o excepciones
presentadas durante la ejecución de la tarea.

Los escenarios de prueba corresponden a las diferentes combinaciones de los flujos anteriormente
identificados.

Escenario 1 Flujo Básico

Escenario 2 Flujo Básico Flujo Alterno 1

Escenario 3 Flujo Básico Flujo Alterno 2

Escenario 4 Flujo Básico Flujo Alterno 3

2. Identificar Caso de prueba

Para la identificación de los casos de prueba se puede realizar la siguiente matriz:

Núm Caso de Prueba Escenario Condición Resultado esperado

En esta matriz se relacionan los escenarios, las diferentes condiciones que se pueden presentar y los
resultados esperados para cada una de las condiciones. En la siguiente sección se incluirá un ejemplo
detallado del proceso.

3. Definición de caso de prueba

Los casos de prueba se definen usando formatos en los que se relacionan todos los detalles que se deben
tener en cuenta para la ejecución de la prueba. Este formato depende de la necesidad del proyecto, a
continuación se presenta un formato que incluye los aspectos básicos a tener en cuenta:

Nombre del Proyecto

ID Caso de Prueba Prueba diseñada por
Prioridad (A/M/B) Fecha de diseño
Nombre del Módulo Prueba ejecutada por
 Título de la prueba Fecha de ejecución

Descripción
Precondiciones

Dependencias
Datos de Resultado Resultado Estado
Paso Descripción prueba esperado actual (Paso/Fallo) Notas

Poscondiciones

El formato está dividido en 4 secciones:

 Encabezado: En esta sección se incluye la información general del caso de uso, se asigna un
identificador único, el módulo al que pertenece, la prioridad (Alta, Media o Baja) el nombre de la
prueba, una breve descripción, quién diseño la prueba, cuando, quien ejecuto la prueba y cuando.
Esta información sirve para controlar el proceso de ejecución y permite tener documentado el
caso de prueba.

 Precondiciones: En esta sección se documentan todas las condiciones necesarias para la ejecución
de la prueba, se divide en dos sub secciones, precondiciones, que incluye un listado de todos los
prerrequisitos necesarios para la ejecución de la prueba, dependencias, en esta sección se incluye
un listado de cualquier dependencia con otro caso de uso o requerimiento de prueba.

 Cuerpo del caso de prueba: El cuerpo del caso de prueba consta de las siguientes secciones:
o Paso: El número del paso dentro del proceso
o Descripción: Detalle de la tarea
o Datos de prueba: Se debe incluir el listado de datos necesarios para la ejecución de la
prueba
o Resultado esperado: Se debe incluir cual es el estado del sistema después de la ejecución
del paso.

 PosCondiciones: Esta sección incluye el estado del sistema después de la ejecución del caso de
prueba.

Ejercicio Práctico
Se requiere definir los casos de pruebas para el caso de uso de Login del módulo genérico de control de
acceso. Se debe tener en cuenta al menos el flujo básico y un flujo alternativo.

 Definición de flujos
Para efectos del ejercicio se consideraran los siguientes flujos:

 Flujo básico: Aceptación del siniestro exitoso.

 Flujo alternativo 1: Siniestro ya atendido.
Para identificar los flujos se deben evaluar todas las posibles condiciones que puedan afectar la operación,
en este caso, se tiene en cuenta como flujo básico, la operación exitosa, se establecen como flujos
alternos, el uso de un nombre de usuario no válido, el uso de una contraseña no válida, adicionalmente se
establece un flujo para el número de intentos.

A continuación se detallan cada uno de los flujos:

1. Flujo Básico
1.1. Ingreso a la URL de la aplicación
1.2. Se muestra la alerta del siniestro
1.3. Aceptar siniestro.
1.4. Cancelar siniestro.

2. Flujo alternativo 1:
2.1. Redirección a la página de Ambulancia con el mensaje Siniestro ya atendido.

 Identificación de los escenarios de prueba

Una vez identificados los diferentes flujos se debe realizar la identificación de los escenarios de prueba.
Para ello se hace uso de la siguiente matriz en la cual se relacionan los diferentes flujos.

Escenario 1- Aceptación del siniestro exitoso Flujo Básico

Escenario 2- Siniestro ya atendido Flujo Básico Flujo Alterno 1

En el ejemplo se identifican 4 escenarios:

El escenario 1 incluye únicamente el flujo básico y es el escenario exitoso. Los restantes 3 escenarios
corresponden a escenarios alternativos, en los cuales que se valida el comportamiento del programa en
condiciones no ideales, el escenario 4 corresponde a una prueba de una regla de negocio (el bloqueo del
usuario después de 3 intentos fallidos).

 Identificación de los casos de uso

Una vez identificados los escenarios de prueba se deben identificar los casos de uso, usando la siguiente
matriz:

Núm Caso Escenario Condición Resultado esperado

de Prueba

CP1 Escenario 1 Aceptación del Redirección a la página Ambulancia mostrando una

siniestro alerta con el nombre del usuario, comentarios y
ubicación del siniestro y las opciones de aceptar o
cancelar siniestro

CP2 Escenario 2 Siniestro ya Redirección a la página de Ambulancia con el mensaje

atendido Siniestro cancelado
Siniestro ya atendido
 En esta matriz se relacionan los diferentes escenarios y las condiciones que pueden afectarlos, así como la
respuesta esperada si se cumple la condición, para efectos del ejemplo, los escenarios 1,2 y 3 solo cuentan
con una condición, y de la misma forma, solo cuentan con un caso de prueba. El escenario 4 cuenta con dos
posibles condiciones, se genera un caso de prueba para cada una, y se relaciona su respuesta.

Una vez identificados los casos de prueba se deben definir, para efectos del ejemplo vamos a usar el
formato definido anteriormente.

 Casos de prueba
CP1 – Aceptación del siniestro exitoso

Nombre del Proyecto Appxilio

ID Caso de Prueba
Prioridad (A/M/B)
Nombre del Módulo
Título de la prueba
Descripción
Precondiciones
Yampier Echeverry
Reyes y Yordan
CP – 1 Prueba diseñada por Fabian Triviño Diaz
A Fecha de diseño 06-02-2015
Aceptación del siniestro Prueba ejecutada por
Aceptación del siniestro exitoso Fecha de ejecución
Se requiere que el usuario haga un llamado de ambulancia para que se genere la solicitud de
la aceptación de la ambulancia.
Instalación pruebas v 1.0

Dependencias Tener el llamado del usuario

Resultado Resultado Estado
Paso Descripción Datos de prueba esperado actual (Paso/Fallo) Notas
Cargue
página
1 Ingreso a la aplicación www.Appxilio.com/Ambulancia Aceptación
Lo que veo hay dos personas
heridas y es un accidente de
2 Se muestra la alerta del siniestro una moto con un carro Alerta
Envió de
mensaje y
Envía un mensaje al usuario carga la
diciendo que ha sido aceptado página de
3 Aceptar siniestro el llamado aceptación
Envió de
mensaje y
carga la
Envía un mensaje al usuario q página de
4 Cancelar siniestro no va hacer atendida la llamada aceptación

El sistema debe cargar la página aceptación del siniestro si el conductor de la ambulancia está registrado en
Poscondiciones appxilio.
 CP2 – Siniestro ya atendido
Nombre del Proyecto Appxilio
Yampier Echeverry
Reyes y Yordan
ID Caso de Prueba CP – 2 Prueba diseñada por Fabian Triviño Diaz
Prioridad (A/M/B) A Fecha de diseño 06-02-2015
Nombre del Módulo Aceptación siniestro Prueba ejecutada por
Título de la prueba Siniestro ya atendido Fecha de ejecución

Descripción Esto ocurre cuando se anticipa otra ambulancia.

Precondiciones Instalación pruebas v 1.0

Dependencias Ubicación más cercana de las ambulancias en el momento del siniestro.

Resultado Resultado Estado
Paso Descripción Datos de prueba esperado actual (Paso/Fallo) Notas
Cargue página
1 Ingreso a la aplicación www.Appxilio.com/Ambulancia Aceptación
Lo que veo hay dos personas
heridas y es un accidente de
2 Se muestra la alerta del siniestro una moto con un carro alerta
Envió de
Envía un mensaje al usuario mensaje y carga
diciendo que ha sido aceptado la página de
3 Aceptar siniestro el llamado aceptación
Llega una alerta diciendo que
el usuario cancelo el llamado Muestra la alerta
debido a que el siniestro ya está y carga la página
4 Siniestro ya atendido siendo atendido de aceptación

Poscondiciones
El sistema carga la página de aceptación y muestra un mensaje que el siniestro ya está siendo atendido