Capítulo 3 - Definición de Casos de Prueba

Procedimiento
Definición de Casos de Prueba
1.Objetivo
Especificar los conceptos básicos del significado de los casos de prueba, su estructura, nivel de
cobertura y como llevar adelante su diseño.
2.Alcance
Este documento da soporte a los equipos involucrados en todos los servicios de QA y QC ejecutados
por Tsoft.
3.Responsabilidad
El Responsable de QA es el responsable máximo de concientizar a los equipos de QA sobre lo
establecido en este documento, como así también de su comunicación y capacitación.
4.Referencia
Norma ISO 9001 (La Versión Vigente de la Norma se define en el Registro de Documentos Externos del SGC).
5.Desarrollo
5.1. Definición ................................................................................................................................ 2
5.2. Estructura de un Caso de Prueba .......................................................................................... 3
5.3. Técnicas de testing basadas en la cobertura ......................................................................... 6
5.3.1. Clases de Equivalencia ....................................................................................................... 6
5.4. Reutilización de casos de prueba. ........................................................................................ 10
5.5. Artefactos .............................................................................................................................. 10
Aprobó su
En caso de que este documento esté impreso o se encuentre en una ubicación Elaborado y Aprobado por
Publicación
distinta a la especificada oficialmente para copias controladas en el procedimiento
“PRO-01 -Control de Documentos”, se convierte automática-mente en “COPIA NO K. Fernandez, P. Dedonato,
CONTROLADA” y es solamente para información. Walter Grasso
C. Plakoudakis
DOC-04 – Definición de Casos de Prueba (Rev. 01)
1 / 11
TSOFT | Av. Belgrano 687 7P C1092AAG Buenos Aires, Argentina | Tel. (+54 11) 5128-3000 | www.tsoft.com.ar
Procedimiento
Casos de Prueba
5.1. Definición
Un caso de test (caso de prueba, test case) es la descripción de condiciones o situaciones a

testear.
La definición de casos de prueba constituye el primer paso a la hora de realizar el testing de un

sistema de software. El nivel de profundidad y precisión logrado en esta fase influirá en gran
medida en las subsiguientes. Además, durante la fase de definición de casos es posible tomar
conocimiento de todo el sistema, y adquirir una noción más precisa del alcance y costo de cada
uno de los test a realizar.
A partir de la recepción de documentación, ya sea lista de requerimientos, especificación

funcional, un manual o casos de uso, etc, se comienza con la definición de casos de prueba.
En esta etapa se generan conjuntos de casos de prueba clasificados por prioridad para cada
funcionalidad incluida en el alcance del test. El orden y el alcance de la definición de los casos
se define previamente en la Estrategia de Testing.
La cantidad y tipo de información disponible como entrada para esta actividad varía mucho de
acuerdo al proyecto.
En las aplicaciones pequeñas o de menor complejidad, se sugiere diseñar mayor cantidad de

casos de prueba, y más detallados, donde cada uno puede incluir una validación a nivel de
campo, por ejemplo. En cambio, si se tratara de una aplicación de mayor tamaño o
complejidad, tal vez convenga diseñar menor cantidad de casos de prueba, pero más
generales. Esto ayudará a la administración de los mismos.
Es recomendable realizar la definición de casos de prueba para todo el sistema al comienzo del
proyecto de Testing para luego dedicarse a la ejecución, pero en muchos casos es necesario
modificar esos casos de prueba luego de la recepción del sistema a testear.
También es probable que se deban modificar casos de prueba luego de ejecutarlos, debido a
que es posible que ciertos requerimientos no estén disponibles aún al momento de definir los
casos. En este tipo de situaciones, un esquema alternativo es realizar la definición seguida de
la ejecución para los requerimientos disponibles, y luego repetir este esquema a medida que se
reciben la totalidad de requerimientos faltantes incluidos en el test.
El entregable de esta etapa está constituido por los documentos de casos de prueba de cada
funcionalidad del producto.
Una vez escritos los casos de prueba completos (con su resultado esperado, pasos, etc.) es
importante validarlos. Esta validación la realiza el funcional, desarrollador y/o usuario final. El
objetivo es reducir al máximo la diferencia existente entre lo implementado y lo requerido o
especificado. Es muy importante validar tanto la completitud en la definición como la
especificación del resultado esperado de cada caso de prueba, como así también la prioridad
de ejecución asignada.
Aprobó su
Publicación
C. Plakoudakis
2 / 11
Procedimiento
5.2. Estructura de un Caso de Prueba
El caso de prueba puede estar compuesto por los siguientes datos:
- Id: Identificador único para futuras referencias, por ejemplo, mientras se describe un defecto
encontrado. Es aconsejable que se numeren los casos de prueba de forma secuencial.
- Descripción: Breve descripción de qué se va a probar. Es un título entendible para la fácil

comprensión del propósito del caso de prueba.
Ejemplo:
Descripción incorrecta:
Ingresar el número de cuenta de un cliente existente como cuenta origen, un monto menor al
saldo disponible y luego realizar una transferencia a una cuenta de un beneficiario de la misma
moneda que la cuenta origen.
Descripción correcta:
Transferencia de fondos. Cuenta origen = caja de ahorro en pesos.
Saldo > Monto. Moneda de cuenta beneficiario = moneda cuenta origen.
 El orden de las condiciones incluidas en la descripción es importante. Al ordenar los casos

por descripción debe ser fácil verificar el cubrimiento. Siempre comenzar por la acción o
pantalla por donde se comienza la ejecución.
 No incluir en la descripción palabras como: “Intentar”, “Verificar”, “Probar”, pues la misma

acción de ejecución del caso implica que se realicen estas acciones.
- Pasos a ejecutar: Detalle de los pasos a seguir para poder ejecutar el caso.
Ejemplo:
1. Ingresar al módulo Transferencias -> A cuentas de otros bancos.

2. Ingresar en el campo: “Número de cuenta”, una cuenta válida. (numérico de 9 dígitos
con 1 guión)
3. Presionar Botón: Aceptar.
Aprobó su
Publicación
C. Plakoudakis
3 / 11
Procedimiento
- Datos (casuística): Dato o lote de datos necesario para ejecutar un caso de test. Un dato de
test es un elemento del dominio de entrada que satisface uno o más casos de test; es un valor
concreto. Dependen del ambiente de prueba con que se esté trabajando, y se pueden
seleccionar a priori o en el momento de la ejecución.
Ejemplo:
Número de cuenta: Número de cuenta con la que se desea operar (tipo y longitud)
Moneda: moneda en la que se quiere obtener los datos del informe (tipo y longitud)
Período Desde: período que quiere comparar (formato fecha y valor válido)
Período Hasta: período que quiere comparar (formato fecha y valor válido)
Fecha de Cotización (formato fecha y valor válido)
 Si la descripción del caso hace referencia a un valor inválido, incorrecto, etc. se debe aclarar
qué condiciones se deben dar para que eso se cumpla.
Ejemplo:
Fecha inválida: 30/02/2007
Es conveniente que al momento de realizar las pruebas se lleve un registro de los

cambios que puede tener el dato utilizado durante la ejecución de las pruebas.
- Resultado esperado: Breve descripción de lo que el analista debería ver tras haber
completado todos los pasos de la prueba. El tiempo verbal utilizado en la descripción del
resultado esperado es en presente, ya que es el momento en el que se realiza la prueba, no se
realiza la prueba a futuro.
Ejemplos:
- El sistema genera la transferencia dejándola pendiente de firma.
- El sistema muestra por pantalla, una grilla con registros según los datos ingresados.
Si el mismo caso de prueba tiene dos o más resultados esperados, entonces hay que
generar tantos casos de pruebas como condiciones hayan.
Ejemplo:
Caso incorrecto:
Descripción: Recarga de saldo. Monto > $50.

Resultado esperado: Se realiza la recarga. Si el cliente posee plan “A”, la recarga se
realiza en el momento. Si el cliente posee plan “B”, la recarga se realiza al día
siguiente.
Aprobó su
Publicación
C. Plakoudakis
4 / 11
Procedimiento
Caso correcto 1:
Descripción: Recarga de saldo. Cliente con plan “A”. Monto > $50.
Resultado esperado: Se realiza la recarga en el momento.
Caso correcto 2:
Descripción: Recarga de saldo. Cliente con plan “B”. Monto > $50.
Resultado esperado: Se realiza la recarga al día siguiente.
No hay que incluir detalles sobre el resultado esperado del caso de prueba dentro de la
descripción del mismo.
Ejemplo:
Caso incorrecto:
Descripción: Verificar que el usuario no tiene permisos para realizar una transferencia.
Resultado esperado: Error.
Caso correcto:
Descripción: Seguridad. Operador sin permiso para realizar transferencia.
Resultado esperado: La aplicación muestra mensaje informando que el operador no

tiene permiso para realizar la transferencia.
Si el resultado esperado es ambiguo o incompleto, podría darse por exitosa una

ejecución fallida o podría no poder demostrarse que en algún momento fue exitosa.
Resultado real (opcional): contienen una breve descripción de lo que el analista encuentra
después de que los pasos del caso de prueba se hayan completado.
- Prioridad: la prioridad es usada para identificar cuál es la importancia de un Caso de

Prueba dentro de un contexto definido. Podemos definir las prioridades como: Alta, Media,
Baja; donde un caso de prueba con prioridad alta es el que prueba el flujo principal y flujos
críticos. El caso de prueba de prioridad media prueba los caminos con menor importancia y
los de baja prioridad pueden ser las validaciones, completitud de pantalla, cosmética, etc.
Claro está, que esta definición es a modo de ejemplo, ya que debe analizarse en el contexto
en el que nos encontramos cuando analizamos el sistema a probar.
Aprobó su
Publicación
C. Plakoudakis
5 / 11
Procedimiento
- Precondiciones: Condiciones que deben darse con anterioridad a la ejecución del caso de
prueba. Por ej.: Si la prueba a realizar es dar de alta un usuario, la precondición es: El usuario
a dar de alta no debe existir en el sistema.
Otro ejemplo es: Para ejecutar el caso de prueba B es necesario ejecutar previamente el caso
de prueba A.
- Estado: Estado del caso de prueba. Un ejemplo de los estados que puede tomar un caso de
prueba durante el diseño, podría ser:
 En diseño
 Diseñado
 Ejecutado
 Pendiente de ejecución
- Complejidad / severidad: Está dada por la dificultad para ejecutar el caso de prueba. Una
pauta para saber si un caso de prueba es complejo o no, sería la cantidad de pasos
necesarios para poder completar la acción.
Una posible categorización de complejidad ó severidad sería: Alta, Media, Baja. O como se
defina en la Estrategia de Testing.
5.3. Técnicas de testing basadas en la cobertura
5.3.1. Clases de Equivalencia
En las pruebas de sistema, los datos de prueba deberán cubrir los posibles valores de cada
parámetro basado en los requerimientos. Debido a que probar cada uno de los valores es
impráctico, se deberán de escoger unos cuantos valores de cada clase de equivalencia. Una
clase de equivalencia es un conjunto de valores que deberán ser tratados igual.
Idealmente, los casos de prueba que evalúan condiciones de error son escritos de forma
separada de los casos de prueba funcionales y deberán incluir pasos para verificar los
mensajes de error y los registros.
Ejemplos de clases de equivalencia:
Cadenas
 cadena vacía
 cadena consistente de únicamente un espacio vacío
 cadena que empieza o termina en un espacio en blanco
 sintácticamente correcta: valores cortos y largos
Aprobó su
Publicación
C. Plakoudakis
6 / 11
Procedimiento
 sintácticamente correcta: valores semánticamente válidos e inválidos
 valor sintácticamente incorrecto: caracteres o combinaciones ilegales
 asegúrese de probar caracteres especiales como #, ", ', &, <, espacios
 asegúrese de probar caracteres "extranjeros" escritos desde teclados internacionales
 Números
 cadena vacía, si es posible
 0 (cero)
 pequeños y largos en rangos positivos
 pequeños y largos en rangos negativos
 fuera del rango de positivos
 fuera del rango de negativos
 que comiencen con ceros
 sintácticamente inválidos (por ejemplo, que incluya letras)
 si el formato es decimal con dos posiciones, probar más dígitos detrás del símbolo
separador de decimales.
Identificadores
 cadena vacía
 valor sintácticamente correcto
 sintácticamente correcto: referencia a un ID existente, referencia inválida
 valor sintácticamente incorrecto
Botones de opción (radio)

 un objeto seleccionado
 nada seleccionado, si es posible
 más de uno seleccionado, si es posible
Botones de opción múltiple

 seleccionados
 sin seleccionar
Aprobó su
Publicación
C. Plakoudakis
7 / 11
Procedimiento
Menú de pestaña
 Verificar que en el menú se encuentren todas las opciones definidas por análisis; puede
faltar alguna función, o bien que estuviera presente, pero inhabilitada.
 Verificar que todas las opciones del menú ejecuten las transacciones para las cuales fueron
definidas.
 Salidas de los menúes. Cada menú debe tener al menos una opción para volver hacia atrás
o para salir de la aplicación.
Listas con Scroll
 no seleccione ningún elemento, si es posible

 seleccione un elemento en cada turno
 seleccione combinaciones de elementos, si es posible
 seleccione todos los elementos, si es posible
Subir archivos
 en blanco
 archivo de 0 byte
 archivos grandes
 archivo con formato distinto al válido
 archivo con nombre corto
 archivo con nombre grande
 archivo dañado (para el caso de importación)
 nombre de archivo sintácticamente incorrecto, si es posible (por ejemplo, "Nombre
Con Espacios.tar.gz")
Exportar archivos
 abrir archivo
 guardar en disco
 Cancelar exportación
Ingreso de datos
 Ingresar datos válidos e inválidos.

 Ingresar caracteres especiales, ej.: “, -, ?, /, 1/2, 1/4, EOF, „, #, $, %, &, etc.
 Utilizar las teclas de función (F9, F10, etc.).
 Ingresar combinaciones de teclas (Alt+254, Alt+255, etc.).
 Ingresar datos con contenido repetido pero con distinto formato (ej.: “Juán Pérez”,
“Juán Pérez”, “JUÁN PÉREZ”, “ Juán Pérez”, “Juán Pérez “, etc.).
Selección de datos u opciones
Aprobó su
Publicación
C. Plakoudakis
8 / 11
Procedimiento
 Verificar que los datos de carga solo por selección no queden posibles de ser
editables (ej.: fechas tomadas de un pop-up calendario, estados posibles desde una
lista desplegable, etc.).
 Trabajando con una lista con ítems seleccionables, verificar que la selección
realizada no se pierda al paginar, ordenar, o filtrar.
 Verificar que no se puedan seleccionar simultáneamente dos opciones
contradictorias, y que, teniendo una ya seleccionada, al seleccionar la otra, la
primera quede deseleccionada (ej.: uso de radio-buttons o botones de selección
única de datos tipo Sexo, Estado Civil, Tipo de Documento, etc.).
Alta de registros
 Adicionar un registro ya existente.

 Adicionar un registro con datos iguales a uno recientemente eliminado.
 Trabajando con objetos que heredan atributos y/o comportamientos de una clase,
ingresar valores inconsistentes (ej.: valores de Período de Vigencia fuera del rango
del Período de Vigencia del objeto padre). – válido también para la modificación.
 Actualizar un registro con datos inválidos.
 Actualizar un registro ingresando datos iguales a uno ya existente.
 Actualizar un registro ingresando datos iguales a uno recientemente eliminado.
 Actualizar un registro dejando en definitiva datos iguales a los que se tenía antes de
la modificación. Se busca comprobar que no lo procese como un alta duplicada.
 Realizar múltiples actualizaciones sobre un mismo registro.
Baja o eliminación de registros
 Verificar que se presente una solicitud de confirmación previo a efectivamente

impactar la baja del registro o dato seleccionado, pudiendo el usuario optar por
cancelar la operación.
 Verificar que se realice una comprobación de la posibilidad, o no, de hacer efectiva
la baja del registro (ej.: teniendo registros relacionados con el registro a eliminar).
 En caso de una baja posible de registros con otros registros relacionados, verificar
el comportamiento vs la especificación funcional.
 Restricciones
Transacciones on-line
 Interrumpir la transacción antes de que se complete.

 Procesar con valores nulos.
Revisión de pantallas
 Verificar que no se produzcan cancelaciones al entrar y salir.

 Verificar estándares de presentación.
 Verificar que no existan errores de ortografía.
 Verificar que el tamaño, color, disposición, etc. de los objetos permitan la correcta
lectura y comprensión de los contenidos.
 Verificar que estén incluidas todas las validaciones definidas por análisis para cada
transacción.
Aprobó su
Publicación
C. Plakoudakis
9 / 11
Procedimiento
 Verificar que los campos con valores obtenidos de alguna operación, sean
mostrados correctamente (el cálculo puede ser correcto, y el valor obtenido
mostrado incorrectamente).
 Verificar que la secuencia de navegación o ingreso de campos en pantalla
responda al ordenamiento de izquierda a derecha y de arriba hacia abajo.
 Verificar que el orden de los campos en la pantalla sea el correcto. Por ejemplo que
un código con su correspondiente descripción se asocien fácilmente.
 Verificar el comportamiento del cursor al utilizar la tabulación.
 Verificar que la presentación de objetos en común en varias pantallas se realice en
forma homogénea, manteniendo los mismos atributos.
5.4. Reutilización de casos de prueba.
Reutilizar casos de prueba es usar los casos ya definidos en otros requerimientos para la
solución del requerimiento actual.
Ventajas:
 Reducción de los costos de desarrollo de casos de prueba.
 Aumento en la calidad de los casos de prueba.
 Aumento en la productividad, mediante la disminución de los tiempos en la definición de

casos de prueba.
5.5. Artefactos
Documentos complementarios que ayudan al entendimiento y organización de los casos de

prueba
De todo lo dicho anteriormente podemos organizar los ítems relevantes (precondiciones,

resultados esperados, pasos, descripción del caso, datos) en una matriz que nos permita
visualizar claramente los distintos escenarios en los que se puede ejecutar la prueba.
La distribución de los datos en la matriz facilita la definición de distintos escenarios de prueba.

(Ver y analizar Matriz)
TIPS
 Debe evitarse la generación de casos de prueba redundantes. Luego de la generación,
si se identifica que dos casos son redundantes, eliminar uno de ellos.
 Reutilizar casos de prueba. En los casos en que se prueben funcionalidades similares

de distintos módulos, utilizar el mismo caso de prueba, adaptado al módulo en cuestión.
 Un buen caso de prueba es aquel que tiene alta probabilidad de mostrar un defecto no
descubierto hasta entonces.
 La definición del resultado esperado a la salida del programa es una parte integrante y
Aprobó su
Publicación
C. Plakoudakis
10 / 11
Procedimiento
necesaria de un caso de prueba
 En el caso en que exista un mismo componente utilizado en distintos módulos/pantallas,

diseñar un solo caso de prueba (o un set de casos de prueba). Por ejemplo, si el
modulo “A” y el modulo “B” realizan búsquedas (utilizando el mismo componente),
definir los casos de prueba para el componente y utilizarlo en ambos módulos.
 Si se cuenta con pantallas/prototipos/bocetos etc., se sugiere adjuntarlos para

complementar los casos de prueba.
6.Diagrama de flujo
No Aplica.
7.Anexos
No Aplica.
Aprobó su
Publicación
C. Plakoudakis
11 / 11

Capítulo 3 - Definición de Casos de Prueba

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Capítulo 3 - Definición de Casos de Prueba

Cargado por

Copyright:

Formatos disponibles

Procedimiento

Definición de Casos de Prueba

Un caso de test (caso de prueba, test case) es la descripción de condiciones o situaciones a

La definición de casos de prueba constituye el primer paso a la hora de realizar el testing de un

A partir de la recepción de documentación, ya sea lista de requerimientos, especificación

En las aplicaciones pequeñas o de menor complejidad, se sugiere diseñar mayor cantidad de

5.2. Estructura de un Caso de Prueba

El caso de prueba puede estar compuesto por los siguientes datos:

- Descripción: Breve descripción de qué se va a probar. Es un título entendible para la fácil

Transferencia de fondos. Cuenta origen = caja de ahorro en pesos.

Saldo > Monto. Moneda de cuenta beneficiario = moneda cuenta origen.

 El orden de las condiciones incluidas en la descripción es importante. Al ordenar los casos

 No incluir en la descripción palabras como: “Intentar”, “Verificar”, “Probar”, pues la misma

1. Ingresar al módulo Transferencias -> A cuentas de otros bancos.

Fecha de Cotización (formato fecha y valor válido)

Es conveniente que al momento de realizar las pruebas se lleve un registro de los

Descripción: Recarga de saldo. Monto > $50.

Resultado esperado: Error.

Descripción: Seguridad. Operador sin permiso para realizar transferencia.

Resultado esperado: La aplicación muestra mensaje informando que el operador no

Si el resultado esperado es ambiguo o incompleto, podría darse por exitosa una

- Prioridad: la prioridad es usada para identificar cuál es la importancia de un Caso de

5.3. Técnicas de testing basadas en la cobertura

5.3.1. Clases de Equivalencia

Ejemplos de clases de equivalencia:

 cadena consistente de únicamente un espacio vacío

 cadena que empieza o termina en un espacio en blanco

 sintácticamente correcta: valores cortos y largos

 valor sintácticamente incorrecto: caracteres o combinaciones ilegales

 asegúrese de probar caracteres "extranjeros" escritos desde teclados internacionales

 cadena vacía, si es posible

 pequeños y largos en rangos positivos

 pequeños y largos en rangos negativos

 fuera del rango de positivos

 fuera del rango de negativos

 que comiencen con ceros

 sintácticamente inválidos (por ejemplo, que incluya letras)

 valor sintácticamente correcto

 sintácticamente correcto: referencia a un ID existente, referencia inválida

 valor sintácticamente incorrecto

Botones de opción (radio)

 nada seleccionado, si es posible

 más de uno seleccionado, si es posible

Botones de opción múltiple

Listas con Scroll

 no seleccione ningún elemento, si es posible

 Ingresar datos válidos e inválidos.

Selección de datos u opciones

 Adicionar un registro ya existente.

Baja o eliminación de registros

 Verificar que se presente una solicitud de confirmación previo a efectivamente

 Interrumpir la transacción antes de que se complete.

 Verificar que no se produzcan cancelaciones al entrar y salir.

5.4. Reutilización de casos de prueba.

 Reducción de los costos de desarrollo de casos de prueba.

 Aumento en la calidad de los casos de prueba.

 Aumento en la productividad, mediante la disminución de los tiempos en la definición de

Documentos complementarios que ayudan al entendimiento y organización de los casos de

De todo lo dicho anteriormente podemos organizar los ítems relevantes (precondiciones,

La distribución de los datos en la matriz facilita la definición de distintos escenarios de prueba.

 Reutilizar casos de prueba. En los casos en que se prueben funcionalidades similares

 En el caso en que exista un mismo componente utilizado en distintos módulos/pantallas,

 Si se cuenta con pantallas/prototipos/bocetos etc., se sugiere adjuntarlos para