¿Como hacer casos de Prueba?

CalidadySotware.com / Testing /¿Como hacer casos de Prueba?

Autor: Ing. Daniel Cafferata Salas.

COMO REALIZAR CASOS DE PRUEBA

[pic 1]

[pic 2]

[pic 3]

[pic 4]

[pic 5]

Cuando mi colega Alexander (creador de este Site) me pidió realizar un artículo en base a los Casos de Prueba pensé “que fácil, si crear casos de prueba es parte de nuestro día a día”,  la verdad es que lo difícil es plasmar en forma clara, concisa, entendible y sobretodo útil este conocimiento, he tratado de darles una idea global del tema, orientado a pruebas funcionales pero los conceptos expuestos son aplicables a todo tipo de prueba, espero les sea útil.

Según WIKIPEDIA: “En la Ingeniería del software, los casos de prueba o Test Case son un conjunto de condiciones o variables bajo las cuáles el analista determinará si el requisito de una aplicación es parcial o completamente satisfactorio”, clarísimo ¿no?, pero para reforzar la idea y ser aún más claros,  podemos decir que los casos de prueba nos ayudan a validar que el aplicativo desarrollado realice las funciones para las que ha sido creado en base a los requerimientos del usuario solicitante.

[pic 6][pic 7]

Esto nos indica que por lo menos deberá existir un caso de prueba por cada requerimiento que la aplicación deba cumplir; ¡¡fácil!!, bueno, lo sería si tenemos claro los requerimientos, si el analista de sistemas o llamado también analista funcional realizó un buen levantamiento de la información y lo que  él indica como verdad es lo que el usuario pidió, pero ese es otro tema que da para largo y que podríamos ver en otro artículo, la idea aquí es que nosotros como analistas de pruebas debemos tener claro que debe hacer el aplicativo y cuál será el alcance de las pruebas, una buena documentación es básica, como quien dice papelito manda.

Pensemos que estamos en una empresa que tiene alguna documentación de sus desarrollos y nos puede servir como punto de partida. ¿Que debemos hacer para desarrollar nuestros casos de prueba?

Primero que nada, ¡¡documentarnos!!, no podemos aventurarnos a escribir casos de prueba por que sí, sin algún fundamento o conocimiento previo del tema, debemos tener claro que hará el aplicativo a validar, debemos conversar con el equipo de desarrollo y/o analista funcional o con la persona que levantó la información para que absuelva las dudas que podamos tener, ¡amigo hágalo! vaya que lo espero…¿listo?, pues sigamos.

Ok, ya sabemos que debe hacer la aplicación, aplicativo, sistema o como quiera llamarlo, ahora hagamos una lista de los requerimientos que debemos verificar, por  ejemplo si quisiéramos hacer casos de prueba sobre la calculadora de windows deberíamos primero leer el manual o el help sobre este aplicativo para saber que funciones realiza.

Aplicativo: Calculadora de Windows
Requerimientos:

1. Sumar dos o más números
2. Restar dos números
3. Dividir dos números

Etc …

A cada punto de la lista debemos darle cuerpo con información como: que queremos verificar en ese punto, que tipo de datos de entrada necesitamos (si esto aplica), que acciones previas hay que tomar (si esto aplica), que resultado estamos esperando, ojo resultado correcto o incorrecto, más adelante entenderás a que me refiero, entre otras cosas, en resumen estamos creando nuestros “escenarios de pruebas”, es decir, las diferentes condiciones en las que el aplicativo deberá trabajar y por cada escenario es posible contar con uno o varios casos de pruebas.

¿Que tal?, espero que bien y que algo de lo que te cuento te pueda estar sirviendo o dándote una idea más clara del asunto, bueno pues, hasta el momento hemos dicho que debemos saber que hace el aplicativo y hemos dado alguna pauta para empezar a crear nuestros casos de prueba, ahora bien te cuento que personalmente al crear casos de prueba comienzo por los casos correctos, es decir aquellos requerimientos que la aplicación debe cumplir si o si, y luego en base a estos creó casos de prueba incorrectos, es decir, aquellos en los cuáles espero forzar a errores a la aplicación y esperar una respuesta adecuada pero incorrecta, por ejemplo si la aplicación tiene como un requerimiento enviar un email y para esto tenemos un campo donde ingresar el email destino , si ponemos un email destino con un formato correcto y que existe luego mandamos el mensaje esperando que este llegue a destino, si esto sucede es un caso correcto, pero que pasa si escribimos el email destino con un formato incorrecto o el email no existe y mandamos el mensaje ¿que debe hacer la aplicación? ¿Enviarlo y caerse al no encontrar el destino?, o en otras palabras colgarse!!, sería muy decepcionante que esto suceda, en este caso lo que deberíamos esperar es que al mandar el mensaje de email, nos aparezca una alerta, mensaje, etc. Cualquier tipo de comunicación que nos indique que el formato del email destino es incorrecto, o que el mensaje no se pudo entregar porque el destino no existe, bueno pues ese es un caso de prueba incorrecto pero si el resultado es la alerta esperada esta bien.
En pocas palabras en la creación de casos de prueba debemos aplicar la lógica del “usuario tonto”, es decir, nos ponemos en la situación de un usuario que va a reventar la aplicación ingresando emails falsos (para el caso de ejemplo), o datos con formatos incorrectos o no va a seguir las indicaciones de algún flujo o proceso secuencial, es decir a cada validación de un proceso en situación ideal habría que probar el mismo proceso con situaciones no ideales y que nos ayuden a encontrar errores. En conclusión no solo debemos verificar que el aplicativo haga bien las cosas que debe sino también que no haga lo que no debe.

Cuando tengamos nuestros casos de prueba, ahora debemos alimentarlos, darles vida, existen casos en los cuáles necesitaremos data, otros quizás sean simples en lectura pero impliquen todo el recorrido de un flujo para poder ser completados, otros pueden ser tan simples como dar un clic o verificar el diseño de una pantalla o reporte, esto se puede complicar tanto como queramos por eso es muy importante tener claro el alcance de las pruebas, hasta donde queremos llegar, luego de tener todo listo no nos queda más que ejecutar los casos de prueba y verificar los resultados, la parte más pensada debe ser la creación del caso de prueba y la búsqueda de data correcta de ser el caso, luego de ello la ejecución y verificación será un mero trámite, nuestro mayor logro esta en encontrar errores o defects y contribuir en primera línea a  obtener un producto de calidad. El programador es nuestro amigo, somos del mismo equipo, hay que tener mucho criterio al indicarle los errores encontrados ya que muchos programadores piensan que son infalibles, quizás algunos errores no sean técnicos sino funcionales, depende mucho como hayamos planteado los casos y nuestra estrategia de pruebas.

Bueno para terminar y no desplayarme demasiado, te hablé de la información que debe tener un  caso de prueba, esto es relativo y depende mucho de la información que uno necesite para ejecutar el caso de prueba y que quiera hacer con él, para almacenarlo, para tener un buen registro, para informar sobre las pruebas, es decir, no existe una ley que debamos seguir al pie de la letra pero te indico un formato, plantilla con información que puede ayudarte:

• Id de caso de prueba.
• Módulo a probar
• Descripción del caso
• Pre-requisitos
• Data necesaria (valores a ingresar)
• Pasos o secuencia lógica
• Resultado esperado (correcto o incorrecto)
• Resultado obtenido
• Observaciones o comentarios
• Analista de Pruebas (responsable de las pruebas)
• Fecha de Ejecución
• Estado (concluido, pendiente, en proces

Así por ejemplo usando algunos campos:

Así amigo, puedes utilizar los campos y la información que mejor se adecue a tus necesidades, la idea es estar ordenados, organizados y tener una buena información de las pruebas.

Espero haber podido serte útil con mis comentarios y sugerencias y nos encontramos en algún otro artículo dios mediante.

Slds.

Daniel Cafferata