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!
Engee es una empresa de calidad, desarrollo y consultoría de software.
Nota: Los tests de regresión no se ejecutan únicamente cuando se agrega nueva funcionalidad. También pueden ser cuando se modifique otra ya existente. El concepto, es simplemente, asegurarse de que lo que ya se desarrollo siga funcionando
Input: Es el nombre que se conoce para referirse a un cuadro de entrada de texto.
Contexto: Debe brindar todos los datos necesarios para encontrar lo que se desea probar y en donde se encuentra.
Desencadenador: Acción que lleva lo que se desea probar al resultado esperado.
Operadores lógicos: Igual (=), Mayor (>), Menor (<), Distinto (!= o <>)