Taller de definición de casos de prueba realizado en Engee

1. Engee IT S.R.L.Taller de testing
Definición de casos de prueba
andres.grosso@engee.com.ar

2. Definiciones
El testing es el proceso que asegura que un sistema hace “lo que debería hacer”.
Casos de test
 Descripciones de qué se va a probar.
 Crear casos es un proceso creativo.
 Debe ser una consecuencia del análisis realizado, en búsqueda de realizar una prueba robusta y
completa sobre una funcionalidad.
Datos de prueba
 Lotes de datos necesarios para ejecutar un caso de test.
 Crear datos de test es un proceso laborioso, y muy poco creativo.
 Los datos de prueba deberán estar indicados en la precondición del caso de prueba, sin estos
datos, el caso no podrá ser ejecutado.
 En caso de no poder ser generados por el equipo de testing, los mismos deberán ser solicitados al
equipo de desarrollo, previo al pasaje a testing, (Ej: Configuración de Roles)
Recordando…

3. Más definiciones
Test Limpio (o positivo)
 Intenta mostrar que el producto satisface sus requerimientos.
Test Sucio (o negativo)
 El objetivo es romper el sistema.
Test de regresión
 Luego de agregar una nueva funcionalidad, se vuelven a probar (casos
más importantes) de las funcionalidades ya existentes. Se comprueba
que lo que funcionaba antes, siga haciéndolo después de
modificaciones.
Recordando…

4. Técnicas de derivación de casos de test
Partición de equivalencias
 Particiona el dominio de entrada en un conjunto de clases de entrada (o
inputs) que tienen comportamientos similares .
 Luego se selecciona un valor representativo de cada partición para ser
testeado. Análisis de condiciones de borde
 Variación de la técnica de partición de equivalencias, que se focaliza en los
bordes de cada clase de equivalencia: por arriba y por debajo de cada clase.
Test de robustez
 Es una variación de la técnica de análisis de borde.
 Consiste en ingresar no un valor apenas superior al máximo valor sino
muchísimo mayor, y un valor muchísimo inferior al mínimo valor.
Recordando…

5. Definición de casos de prueba
o Comunicación hacia el equipo del proyecto sobre el estado de las pruebas
realizadas.
o Se deben definir casos de prueba que aseguren la calidad del software.
o Los casos de pruebas útiles son aquellos que ayudan a encontrar defectos.
Los lineamientos que se exponen a continuación buscan:
 Uniformizar la manera en que se definen Casos de Prueba.
 Asegurar la calidad de su contenido con el objetivo de que pueda ser
ejecutado por cualquier tester.
 Acelerar los tiempos de definición y ejecución.

6. Definición de casos de prueba
• ID del caso
 Se debe establecer un identificador para cada caso de prueba.
• Título
 La estructura debe ser lo suficientemente clara como para que se entienda sin problemas
qué pantalla/funcionalidad se desea probar.
• Descripción
 Se deberá dar un grado mayor de detalle al caso de prueba, deberá poner en contexto a
quien lo desee ejecutar
• Pre Requisito
 Especifican todo lo que necesita el usuario para poder realizar las pruebas

7. Definición de casos de prueba
• Prioridad
 Alta, media y baja. Permite priorizar el orden de ejecución.
• Pasos
 Se deben escribir los pasos necesarios para poder realizar el caso.
• Resultado esperado
 Es la consecuencia esperada de la ejecución del caso.
• Resultado Obtenido / Evidencia
 Se deberá dejar indicado en la planilla cual fue el resultado obtenido, en los casos
en que la ejecución del caso de prueba fue exitoso,

8. Título
o Ser claros, breves, simples.
o Estructurar el titulo del caso de prueba de manera que resulte claro que
pantalla/funcionalidad se desea probar (y en lo posible en que contexto
se debe producir).
o Incorrecto
 “Verificar que al grabar se de el alta de forma correcta.”
o Correcto:
 “Usuarios. Alta. Datos válidos. Grabar. ”
Lineamientos

9. o Debe ser un buen resumen de la prueba a realizar.
o No debería ser necesario más detalle para entenderlo a alto nivel.
o Incorrecto
 “Se debe dar el alta de un usuario completando algunos campos (ver detalle).”
o Correcto
 “Usuario. Alta. Campos obligatorios (ver detalle). Datos válidos. Grabar.”
Lineamientos
Título

10. o Identificación rápida y unívoca
o Debe contener las palabras clave que faciliten su búsqueda.
o No deben existir dos casos de prueba con el mismo título.
o Incorrecto
 “Probar ingresar al sistema con usuario y clave incorrectas.”
o Correcto
 “Login. Usuario incorrecto. Clave correcta. Ingresar”
 “Login. Usuario correcto. Clave incorrecta. Ingresar”
Lineamientos
Título

11. o Primero el contexto
o Al final el desencadenador
Incorrecto
 “Verificar la exportación de un archivo de novedades.”
Correcto
 “Exportación. Novedades. Exportar”
Desencadenador
Contexto
Lineamientos
Título

12. Título
o Usar operadores lógicos siempre que se pueda!
o Ayuda a identificar los casos ‘N’
Incorrecto
 “Eliminar un cliente con facturas asociadas.”
Correcto
 “Cliente. Facturas > 1. Eliminar.”
Esto ayuda a identificar más
rápido otros casos:
Cliente. Facturas = 0. Eliminar.
Cliente. Facturas = 1. Eliminar.
Lineamientos

13. Pasos
o Acciones que debe realizar el Tester para realizar la prueba
o Primer paso
 Especificar con quién se ingresa al sistema (usuario/rol/perfil).
o Segundo a ante ultimo paso
 Detallar que acciones se debe realizar para llegar al último paso.
o Ultimo paso
 Ultima acción necesaria para ejecutar poder verificar el resultado de la prueba.
Lineamientos

14. Pasos
o Ejemplo
1. Ingresar al sistema con un usuario con rol Vendedor.
2. Ingresar al módulo Cobranzas.
3. Ingresar a la opción “Generar cobranza”.
4. Completar los campos de la cobranza con datos válidos.
5. Presionar el botón “Generar”.
Lineamientos

15. Pre requisitos
o En general, no es obligatorio completarlo, pero siempre agrega valor.
o Se especifica un dominio de datos con los que se puede/debe realizar la
prueba.
o Detallar las condiciones que deben cumplirse para poder ejecutar el caso.
o Cuando el dominio de datos es específico, es obligatorio detallar el lote
de datos.
Lineamientos

16. Resultado esperado
o Cualquier discrepancia entre el resultado obtenido y el esperado debe ser
reportado como un error.
o Se debe especificar con el mayor detalle posible.
o Cada caso de prueba debe tener un único resultado esperado.
o ¡Hay que ser explícitos!
Lineamientos

17. Resultado esperado - Ejemplos
o Definición
 Ventas. Cobranzas. Datos válidos. Grabar.
o Resultado esperado
 Se da de alta la cobranza ingresada. Se redirige a la pantalla de Listado de
Cobranzas y se ve reflejada como primer cobranza la recientemente generada.
o Definición
 Ventas. Cobranzas. Datos válidos. Grabar. Mail enviado.
o Resultado esperado
 Se envía un mail a los usuarios del departamento de ventas.
Lineamientos
Ejemplo 1
Ejemplo 2

18. Prioridades
o Alta
 Testing positivo, son los que nos aseguran que la aplicación se puede usar.
 Generalmente imposibilitan realizar otras pruebas
 Se utilizan para hacer regresión
o Media
 Testing positivo, casos n
 Son los casos , generalmente, presentan más errores
o Baja
 Testing negativo
 Agregan calidad al producto
 No son bloqueantes
Lineamientos

19. Prioridades - Ejemplo
o Alta
 Desc.: Login. Usuario correcto. Clave correcta.
 Resul. Esper.: Se ingresa al sistema y cargar la pantalla de Listado de usuarios.
o Media
 Desc.: Login. Usuario correcto. Clave incorrecta.
 Resul. Esper.: No se puede ingresar. El sistema muestra un mensaje indicando que la
clave o el usuario son incorrectos.
o Baja
 Desc.: Login. Ortografía y gramática.
 Resul. Esper.: La ortografía y gramática de la pantalla de ingreso es correcta.
Lineamientos

20. Generales
o La gramática y ortografía deben ser correctas.
o Un caso de prueba debe tener toda la información necesaria para poder
ejecutar una prueba.
o En un módulo/pantalla, nunca debe faltar un CP para la revisión de
gramática y ortografía.
o Si es necesario, indicar un lote de datos con los que se deba realizar la
prueba.
Lineamientos

21. Generales
o No hacer un CP por cada campo obligatorio.
o No hacer un CP por cada dato inválido.
o La definición de casos es un proceso creativo. ¡Se debe pensar para definir!
o ¡Los casos de prueba deben estar actualizados!
Lineamientos

22. Regresión
o Circuitos principales de la aplicación.
o Siempre son de “Alta”.
o Que sea de Alta no significa que debe ser regresión.
o Se deben poder identificar.
o Asegura que toda la funcionalidad correspondiente a un modulo
funcione correctamente.

23. Regresión
o ¿Cómo saber cuando es regresión?
 ¿Es un caso feliz de la funcionalidad?
 ¿Es un circuito principal o secundario de la aplicación?
 ¿Tiene un grado de ocurrencia elevado en la aplicación?
 ¿Su posible falla, imposibilita realizar circuitos principales?
Si las respuestas fueron Sí, el caso de prueba es un buen candidato!

24. ¿Preguntas?