taller casos de prueba
DESCRIPTION
Taller de definición de casos de prueba realizado en EngeeTRANSCRIPT
Definiciones
• El testing es el proceso que compara “lo que es” con “lo que
debería ser”.
• Casos de test
Descripciones de qué se va a probar.
Crear casos es un proceso creativo.
• Datos de test
Lotes de datos necesarios para ejecutar un caso de test.
Crear datos de test es un proceso laborioso, y muy poco creativo.
Recordando . . .
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 las funcionalidades ya existentes(casos más
importantes).
Recordando . . .
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 . . .
Definición de casos de prueba
• Comunicación hacia el equipo del proyecto sobre el estado de las
pruebas realizadas.
• Se deben definir casos de prueba que aseguren la calidad del software.
• 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 mínima de su contenido.
Acelerar los tiempos de definición y ejecución.
Definición de casos de prueba
• ID del caso• Se debe establecer un identificador para cada prueba.
• Descripción • De la prueba a realizar
• Pasos• Se deben escribir los pasos necesarios para poder realizar el caso.
• Datos• Se debe especificar el lote de prueba.
• Resultado esperado• Es la consecuencia esperada de la ejecución del caso.
• Prioridad• Alta, media y baja. Generalmente los de alta son los de regresión.
Descripción
• Ser claros, breves, simples.
• Estructurar la descripción de manera que resulte claro
que pantalla/funcionalidad se desea probar (y en lo
posible en que contexto se debe producir).
• Incorrecto
“Verificar que al grabar se de el alta de forma correcta.”
• Correcto:
“Usuarios. Alta. Datos válidos. Grabar. ”
Lineamientos
Descripción
• Debe ser un buen resumen de la prueba a realizar.
• No debería ser necesario más detalle para entenderlo a alto nivel.
• Incorrecto “Se debe dar el alta de un usuario completando algunos campos (ver
detalle).”
• Correcto “Usuario. Alta. Campos obligatorios (ver detalle). Datos válidos.
Grabar.”
Lineamientos
Descripción
• Identificación rápida y unívoca
Debe contener las palabras clave que faciliten su búsqueda.
No deben existir dos casos de prueba con la misma
descripción.
• Incorrecto “Probar ingresar al sistema con usuario y clave incorrectas.”
• Correcto “Login. Usuario incorrecto. Clave correcta. Ingresar” “Login. Usuario correcto. Clave incorrecta. Ingresar”
Lineamientos
Descripción
• Primero el contexto
• Al final el desencadenador
• Incorrecto “Verificar la exportación de un archivo de novedades.”
• Correcto “Exportación. Novedades. Exportar”
ContextoDesencadenador
Descripción
• Usar operadores lógicos siempre que se pueda!
• 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.
Pasos
• Acciones que debe realizar el Tester para realizar la
prueba
• Primer paso
• Especificar con quién se ingresa al sistema (usuario/rol/perfil).
• Segundo a ante ultimo paso
• Detallar que acciones se debe realizar para llegar al último paso.
• Ultimo paso
• Ultima acción necesaria para ejecutar poder verificar el
resultado de la prueba.
Lineamientos
Pasos
• 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
Datos de prueba
• En general, no es obligatorio agregarlos, pero
siempre agrega valor.
• Se especifica un dominio de datos con los que se
puede/debe realizar la prueba.
• Cuando el dominio de datos es especifico,
especificar el lote de datos es obligatorio.
Lineamientos
Datos - Ejemplo
• Pasos
1. Ingresar al sistema con un usuario con rol (ver datos).
2. Ingresar al módulo Cobranzas.
3. Ingresar a la opción “Generar cobranza”.
4. Completar los campos de la cobranza con datos inválidos (ver
datos).
5. Presionar el botón “Generar”.
• Datos
Roles: Vendedor, Jefe de ventas, administrador
Datos inválidos:
o Importe: -500, 1321321312, etc.
o Fecha: 001/002/2022, 1/1/1, etc.
Lineamientos
Resultado esperado
• Cualquier discrepancia entre el resultado obtenido y
el esperado debe ser reportado como un error.
• Se debe especificar con el mayor detalle posible.
• Las diferencias pueden generar uno o más errores.
• ¡Hay que ser explícitos!
Lineamientos
Resultado esperado - Ejemplo
• Definición
• Ventas. Cobranzas. Datos válidos. Grabar.
• Resultado esperado
• Se da de alta la cobranza ingresada. Se envía un mail a
los usuarios del departamento de ventas (ver datos). Se
redirige a la pantalla de Listado de Cobranzas y se ve
reflejada como primer cobranza la recientemente
generada.
Lineamientos
Prioridades
• 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
• Media
• Testing positivo, casos n
• Son los casos , generalmente, presentan más errores
• Baja
• Testing negativo
• Agregan calidad al producto
• No son bloqueantes
Lineamientos
Prioridades - Ejemplo
• Alta
• Desc.: Login. Usuario correcto. Clave correcta.
• Resul. Esper.: Se ingresa al sistema y cargar la pantalla de Listado de
usuarios.
• 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.
• Baja
• Desc.: Login. Ortografía y gramática.
• Resul. Esper.: La ortografía y gramática de la pantalla de ingreso es
correcta.
Lineamientos
Generales
• La gramática y ortografía deben ser correctas.
• Un caso de prueba debe tener toda la información necesaria para poder ejecutar
una prueba.
• En un módulo/pantalla, nunca debe faltar un CP para la revisión de gramática y
ortografía.
• La definición de casos es un proceso creativo. ¡Se debe pensar para definir!
• Si es necesario, indicar un lote de datos con los que se deba realizar la prueba.
• ¡Los casos de prueba deben estar actualizados!
• No hacer un CP por cada campo obligatorio
• No hacer un CP por cada campo inválido
Lineamientos
Regresión
• Circuitos principales de la aplicación
• Siempre son de “Alta”
• Que sea de Alta no significa que debe ser
regresión
• Se deben poder identificar
Regresión
• ¿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!
¿Preguntas?