Casos de Prueba

Casos de prueba
Un caso de prueba o test case es, en ingeniería del software, un conjunto de

condiciones o variables bajo las cuales un analista determinará si una aplicación,
un sistema software (software system), o una característica de éstos es parcial o
completamente satisfactoria.
Se pueden realizar muchos casos de
prueba para determinar que un
requisito es completamente
satisfactorio. Con el propósito de
comprobar que todos los requisitos de
una aplicación son revisados, debe
haber al menos un caso de prueba para
cada requisito a menos que un requisito
tenga requisitos secundarios. En ese
caso, cada requisito secundario deberá
tener por lo menos un caso de prueba.
Algunas metodologías
como RUP recomiendan el crear por lo menos dos casos de prueba para cada
requisito. Uno de ellos debe realizar la prueba positiva de los requisitos y el otro
debe realizar la prueba negativa.
Si la aplicación es creada sin requisitos formales, entonces los casos de prueba se

escriben basados en la operación normal de programas de una clase similar.
Lo que caracteriza un escrito formal de caso de prueba es que hay una entrada
conocida y una salida esperada, los cuales son formulados antes de que se ejecute
la prueba. La entrada conocida debe probar una precondición y la salida
esperada debe probar una postcondición.
Bajo circunstancias especiales, podría haber la necesidad de ejecutar la prueba,
producir resultados, y luego un equipo de expertos evaluaría si los resultados se
pueden considerar como "correctos". Esto sucede a menudo en la determinación
del número del rendimiento de productos nuevos. La primera prueba se toma como
línea base para los subsecuentes ciclos de pruebas/lanzamiento del producto.
Los casos de prueba escritos, incluyen una descripción de la funcionalidad que se
probará, la cual es tomada ya sea de los requisitos o de los casos de uso, y la
preparación requerida para asegurarse de que la prueba pueda ser dirigida.
Los casos de prueba escritos se recogen generalmente en una suite de pruebas.
Las variaciones de los casos de prueba son comúnmente utilizados en pruebas de
aceptación. La prueba de aceptación es realizada por un grupo de usuarios finales o
los clientes del sistema, para asegurarse que el sistema desarrollado cumple sus
requisitos. La prueba de aceptación de usuario se distingue generalmente por la
incorporación de un trayecto feliz o casos de prueba positivos.
Estructura de los casos de prueba
Consisten principalmente en tres partes con subdivisiones:
 Introducción/visión general: Contiene información general acerca de los

Casos de Prueba.
o Identificador: Es un identificador único para futuras referencias, por
ejemplo, mientras se describe un defecto encontrado.
o Caso de prueba dueño/creador: Es el nombre del analista o diseñador de
pruebas, quien ha desarrollado pruebas o es responsable de su desarrollo.
o Versión: La actual definición del caso de prueba.
o Nombre: El caso de prueba debe ser un título entendible por personas, para
la fácil comprensión del propósito del caso de prueba y su campo de
aplicación.
o Identificador de requerimientos: el cual está incluido por el caso de
prueba. También aquí puede ser un identificador de casos de uso o
de especificación funcional.
o Propósito: Contiene una breve descripción del propósito de la prueba, y la
funcionalidad que chequea.
o Dependencias: Indica qué otros subsistemas están involucrados y en qué
grado.
 Actividades de los casos de prueba
o Ambiente de prueba/configuración: Contiene información acerca de la
configuración del hardware o software en el cual se ejecutará el caso de
prueba.
o Inicialización: Describe acciones, que deben ser ejecutadas antes de que
los casos de prueba se hayan inicializado. Por ejemplo, debemos abrir algún
archivo.
o Finalización: Describe acciones, que deben ser ejecutadas después de
realizado el caso de prueba. Por ejemplo si el caso de prueba estropea la
base de datos, el analista debe restaurarla antes de que otro caso de prueba
sea ejecutado.
o Acciones: Pasos a realizar para completar la prueba.
o Descripción de los datos de entrada
 Resultados
o Salida esperada: Contiene una descripción de lo que el analista debería ver
tras haber completado todos los pasos de la prueba.
o Salida obtenida: Contiene una breve descripción de lo que el analista
encuentra después de que los pasos de prueba se hayan completado.
o Resultado: Indica el resultado cualitativo de la ejecución del caso de prueba,
a menudo con un Correcto/Fallido.
o Severidad: Indica el impacto del defecto en el sistema: Grave, Mayor,
Normal, Menor.
o Evidencia: En los casos que aplica, contiene información, bien un link al
print de pantalla (screenshot), bien una consulta a una base de datos, bien
el contenido de un fichero de trazas, donde se evidencia la salida obtenida.
o Seguimiento: Si un caso de prueba falla, frecuentemente la referencia al
defecto implicado se debe enumerar en esta columna. Contiene el código
correlativo del defecto, a menudo corresponde al código del sistema de
tracking de bugs que se esté usando.
o Estado: Indica si el caso de prueba está: No iniciado, En curso, o terminado.
¿Cómo se Hacen?
Hay muchos formatos con diferentes tipos de datos, pero en realidad no existe un
formato único para diseñar casos de prueba, dado que dependiendo el negocio o
escenario será necesario personalizar los datos para ajustarlo a lo que se requiere
probar, sin embargo hay campos mínimos que se deben contemplar en todos los
casos, sin embargo es de tener en cuenta ser muy agiles y tener presente que el
caso debe cumplir una regla de oro que es que el caso de prueba sea tan claro y
entendible que sea sencillo para otra persona lograr reproducirlo sin mucho
esfuerzo.
Identificador: identifica el caso de prueba, puede ser numérico o alfanumérico, la
idea es que un caso de prueba se diferencie de otro caso a través de este indicador.
Nombre del Caso de Prueba: es un nombre descriptivo del caso de prueba, en

algunos procesos de calidad se hace necesario cumplir una nomenclatura clara y
definida.
Precondición/es: hace referencia a lo que se debe tener listo para la ejecución del
caso de prueba, pueden ser la ejecución de otros casos de pruebas, un archivo, la
creación de un dato, entre otros.
Pasos: Define las acciones de usuario expresadas en términos de negocio y del

aplicativo para la ejecución del caso de prueba, como por ejemplo ingresar el
nombre en el campo “Nombre usuario” o hacer clic en el botón “Enviar”.
Resultado esperado: Este apartado es muy importante, porque es el que determina

si la ejecución del caso va siendo exitosa por cada paso, en algunos pasos de
prueba no es necesario tener siempre un resultado esperado, se recomienda que
se utilice en los pasos de mayor importancia para el negocio, como lo puede ser al
momento de crear un usuario y se genera una ventana de confirmación, en ese caso
si es válido tener un resultado esperado como “Se genera la ventana confirmación
de xyz” y se puede apoyar también en una imagen que haga referencia al resultado
deseado.
Dato de Prueba: los pasos de pruebas se apoyan en datos, es por esto que por
cada paso de prueba se puede hacer necesario especificar cuál es el dato a usar.
Como lo puede ser un nombre de usuario, un password, etc.
Resultado Real: como se busca que los casos de pruebas sean reproducibles las
veces que sean necesarios, esta opción permite al analista estar registrando los
sucesos de cada paso (Donde sea necesario, no implica uno a uno de los pasos).
Pueden añadirse más, pero como lo he mencionado antes va a depender de que
tan necesario pueda ser en el caso de prueba.
¿Para qué Sirven?
Los casos de prueba son sin duda uno de los elementos más importantes cuando a
pruebas de software se refiere, dado que son un elemento que día a día le dan más
valor al software, tanto así que entre más casos y de mayor calidad se posean casos
el software va a adquirir más valor, adicionalmente cabe mencionar que un caso de
prueba de ejecución manual bien elaborado es insumo clave en un proceso de
automatización de pruebas, también se vuelven un valor agregado que apoya a los
procesos de formación dentro de un área de calidad al ser fuente de información
explicita del negocio. Los indicadores de resultados y la forma en que se puede
medir el desempeño de un equipo de pruebas de software se mide en base a casos
de pruebas, por ejemplo, casos de pruebas ejecutados vs casos de prueba fallidos,
casos de pruebas manuales vs casos de pruebas automatizados, casos de pruebas
ejecutados vs esfuerzo en pruebas, etc.
Los casos de prueba especifican los requisitos de la aplicación, por lo que cada
requisito debe estar cubierto por un mínimo de un caso de prueba. Cada caso de
prueba está compuesto por varios pasos a ejecutar, dependiendo de la complejidad
del caso, y cada paso está compuesto por una acción, que será realizada por el
tester, y un resultado esperado. Para que un caso de prueba resulte exitoso, todos
los pasos deben cumplir el resultado esperado. Si uno de los pasos no lo cumple,
todo el caso de prueba resultará fallido.
Al finalizar un caso de prueba su estado podrá ser:
Pasado: si todos los pasos a ejecutar han sido correctos.

Fallado: si uno o varios pasos han sido erróneos.
Bloqueado: si un caso de prueba anterior bloquea las funciones de los posteriores
casos de prueba.
N/A: si un caso de prueba definido ya no aplica al haber habido cambios en la
funcionalidad o requisitos.
Cuando un caso de prueba se pone en estado fallado es debido a la detección de

un bug o incidencia, lo que supone que por algún motivo ha surgido un fallo en la
aplicación, ya sea de software, estético o por otros motivos. Estos errores son
creados en distintas herramientas con el máximo detalle del error para que el equipo
de desarrollo pueda reproducirlo y corregirlo, asociándolos al caso concreto en el
que ha surgido para poder tener una visión general del estado de la incidencia y del
caso de prueba e indicando otros detalles útiles, como la plataforma en la que ha
tenido lugar y qué tipo de bug son.
Después de que los desarrolladores o responsables del proyecto hayan solucionado

los errores encontrados, crearán una versión posterior de la aplicación para seguir
probando si todo ha quedado perfectamente arreglado o si estos errores pueden
suponer otros distintos. Cuando el equipo de desarrollo notifica que ha solucionado
la incidencia reportada, los casos de prueba asociados a ella serán ejecutados
nuevamente. Esto se repetirá tantas veces como sean necesarias hasta que se
confirme que la incidencia ha sido solucionada y por tanto, el resultado de la acción
es el esperado, por lo que se cerrará la incidencia y se cambiará el estado del caso
de prueba a pasado.
Normalmente, cuando hay varias fases en el proyecto, se crean varias releases de

la aplicación, que permitirán tener un mayor control del tiempo invertido en cada una
de ellas.
Durante la release final de la aplicación, se probarán todos los casos de prueba del
plan y se comprobará si todas las incidencias abiertas están resueltas. De esta
manera, desde Globe nos aseguramos que no se ha pasado por alto ningún detalle
que pueda provocar un error en la aplicación.
Caso de Prueba de ejemplo
Para este ejemplo Netflixvamos a usar “Netflix”, a continuación el diseño del caso y
al final las conclusiones del mismo.
Si quisiéramos pensar en complementar el formato para tener datos de
la propia ejecución del caso de prueba, deberíamos tener un diseño
como el siguiente:
Como se puede ver en las precondiciones se requiere la ejecución de un caso de

prueba, para este caso la autenticación, pero hay que tener claro que como es una
precondición no se requiere tomar evidencias de ese caso, dado que no es el
objetivo sino una precondición, la otra precondición obedece a tener datos de
prueba válidos, en este caso una cuenta de usuario activa.
Seria labor del analista de pruebas dar el concepto final del caso de pruebas acerca
de si se cumplió el objetivo planteado o no, pero siempre basado en evidencias, en
este caso en el paso 1 y 7 se usó como ejemplo una evidencia gráfica, posiblemente
si el caso lo exige que debe ser de algún tipo en particular, dato, texto, etc, si no es
un requisito del caso, queda en potestad del analista tomar una evidencia que
desee, en otros casos como el 2,3,5 y 6 no se especifica un resultado esperado, en
este caso el analista no estaría condicionado a especificar algún resultado,
dependerá de si mismo si quiere o ve importante especificar un resultado.

Casos de Prueba

Cargado por

Copyright:

Formatos disponibles

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

Casos de Prueba

Cargado por

Copyright:

Formatos disponibles

Casos de prueba

Un caso de prueba o test case es, en ingeniería del software, un conjunto de

Si la aplicación es creada sin requisitos formales, entonces los casos de prueba se

Estructura de los casos de prueba

Consisten principalmente en tres partes con subdivisiones:

 Introducción/visión general: Contiene información general acerca de los

Nombre del Caso de Prueba: es un nombre descriptivo del caso de prueba, en

Pasos: Define las acciones de usuario expresadas en términos de negocio y del

Resultado esperado: Este apartado es muy importante, porque es el que determina

¿Para qué Sirven?

Al finalizar un caso de prueba su estado podrá ser:

Pasado: si todos los pasos a ejecutar han sido correctos.

Cuando un caso de prueba se pone en estado fallado es debido a la detección de

Después de que los desarrolladores o responsables del proyecto hayan solucionado

Normalmente, cuando hay varias fases en el proyecto, se crean varias releases de

Como se puede ver en las precondiciones se requiere la ejecución de un caso de

También podría gustarte