Casos de prueba

h_melluso@alianza.edu.uy
alianzapro.alianza.edu.uy
 Deconstruyendo el caso de
prueba.
En la clase pasada hablamos de los campos que
debería contener un caso de prueba. En el día de
hoy vamos a profundizar y consolidar el
conocimiento sobre ellos.
 Título
El título debe hacer referencia directa a lo que
vamos a probar. “Lo que vamos a probar” es
conocido como Test Objective o Objetivo de
prueba. Es normal cometer el error de indicar el
objetivo de prueba a medias, solo describiendo la
funcionalidad. Un buen título, aparte de ser breve
debe de ser claro y contener el objetivo de prueba.

Ej: Login con credenciales válidas.

 Título

Como podemos ver, el título describe la

funcionalidad y el objetivo de test. El caso de
prueba debe incluir ambas, es necesario remarcar
esto, pues un caso de prueba sin un buen título no
es reutilizable y es candidato a ser desechado o a
tener que ser actualizado al no tener exactitud o
ser poco claro.
 Descripción
La descripción debe ser clara y concisa. Es muy
posible que ya hayamos dicho en el título todo lo
que había para decir sobre la funcionalidad, por lo
que la descripción puede ser una copia del título.
Normalmente siempre haya algo más para decir,
pero en términos prácticos y sin ser esto un
axioma, una buena descripción no debería superar
los 3 o 5 renglones. Todo depende de la
complejidad del caso de prueba y la información
que poseamos.
 Precondición

Una precondición es una condición que ha de

satisfacerse justo antes del comienzo de la
ejecución de una prueba. Con esto queremos
decir, que las precondiciones, son todos los pasos
o acciones necesarias PREVIAS a la ejecución de
nuestra prueba. Por ejemplo si debemos entrar en
una página para poder ejecutar la prueba, eso es
una precondición y no un paso.
 Test Data

Con Test Data nos referimos a datos que

necesitemos para ejecutar el caso. Esto hace
referencia a credenciales, archivos de
configuración o cualquier otro tipo de archivo que
necesite ser introducido en el sistema. Muchas
veces carecemos de este campo u opción por lo
que introducimos las credenciales o
configuraciones en las precondiciones.
 Pasos para ejecutar

Los pasos deben de ser claros y comprender

solamente lo necesario para ejecutar la prueba.
No deben añadirse pasos que están fuera del
objetivo de prueba. Los pasos deben de ir
recorriendo la funcionalidad desde principio a fin y
remarcar lo que esperemos en el siguiente paso.
El ultimo paso del caso es el que nos lleva al
RESULTADO ESPERADO.
 Resultado Esperado
El resultado esperado o postcondición, viene
derivado del requerimiento a probar, debe servir
como punto y final para el caso de prueba y debe
de estar escrito de manera que verifique el 100%
del requerimiento a testear. Dependiendo de la
información que tengamos podremos ser más o
menos específicos, recordando los casos de
pruebas específicos o abstractos y recordando
que a medida que obtengamos más información
podemos actualizarlos. (Un caso de prueba
abstracto puede convertirse en uno específico si
obtenemos más información sobre la
funcionalidad.
 Estado
El estado refleja simplemente si la prueba pasó
(Passed, Pass), si falló (Fail, Failed) o si
simplemente por falta de datos no pudo ser
ejecutada por tanto fue salteada (Skipped). Esto
nos ayuda a conocer la cantidad de casos que
llevamos ejecutados y gracias a esto podemos
sacar métricas y conocer qué tanto llevamos
testeado y cuánto nos queda para finalizar la
ejecución de la suite.
 ¿Qué es un requerimiento?
Propiedad o restricción, determinada con
precisión, que un producto software debe
satisfacer.
Esta definición nos indica que un requerimiento es
algo que se solicita que el software haga de
manera muy clara. En base a esto nosotros
podemos utilizar las técnicas para desarrollar
casos de prueba. Todas las técnicas siguientes,
son de caja negra o black-box.
 ¡Muchas gracias!

Fuentes:
Manual de estudio ISTQB - Libro Testing Computer Software, 2nd Edition -
elaboración propia.