Taller casos de prueba

14,654 views
14,523 views

Published on

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

Published in: Technology
0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
14,654
On SlideShare
0
From Embeds
0
Number of Embeds
796
Actions
Shares
0
Downloads
405
Comments
0
Likes
5
Embeds 0
No embeds

No notes for slide
  • Solo definición de casos de prueba. Sin registro de incidencias.
  • 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 <>)
  • Lote de Datos: Información necesaria para ejecutar un caso de prueba.
  • Des.: Descripción
    Resul. Esper.: Resultado esperado
  • Si un CP es considerado como Regresión, debe ser de Alta.
  • Taller casos de prueba

    1. 1. Taller de Testing andres.grosso@engee.com.ar Definición de casos de prueba
    2. 2. 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 . . .
    3. 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 las funcionalidades ya existentes(casos más importantes). Recordando . . .
    4. 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. 5. 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.
    6. 6. 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.
    7. 7. 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
    8. 8. 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
    9. 9. 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
    10. 10. Descripción • Primero el contexto • Al final el desencadenador • Incorrecto  “Verificar la exportación de un archivo de novedades.” • Correcto  “Exportación. Novedades. Exportar” Contexto Desencadenador
    11. 11. 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.
    12. 12. 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
    13. 13. 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
    14. 14. 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
    15. 15. 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
    16. 16. 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
    17. 17. 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
    18. 18. 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
    19. 19. 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
    20. 20. 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
    21. 21. 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
    22. 22. 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!
    23. 23. ¿Preguntas?

    ×