Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.
Engee IT S.R.L.Taller de testing
Definición de casos de prueba
andres.grosso@engee.com.ar
Definiciones
El testing es el proceso que asegura que un sistema hace “lo que debería hacer”.
Casos de test
 Descripcione...
Más definiciones
Test Limpio (o positivo)
 Intenta mostrar que el producto satisface sus requerimientos.
Test Sucio (o ne...
Técnicas de derivación de casos de test
Partición de equivalencias
 Particiona el dominio de entrada en un conjunto de cl...
Definición de casos de prueba
o Comunicación hacia el equipo del proyecto sobre el estado de las pruebas
realizadas.
o Se ...
Definición de casos de prueba
• ID del caso
 Se debe establecer un identificador para cada caso de prueba.
• Título
 La ...
Definición de casos de prueba
• Prioridad
 Alta, media y baja. Permite priorizar el orden de ejecución.
• Pasos
 Se debe...
Título
o Ser claros, breves, simples.
o Estructurar el titulo del caso de prueba de manera que resulte claro que
pantalla/...
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...
o Identificación rápida y unívoca
o Debe contener las palabras clave que faciliten su búsqueda.
o No deben existir dos cas...
o Primero el contexto
o Al final el desencadenador
Incorrecto
 “Verificar la exportación de un archivo de novedades.”
Cor...
Título
o Usar operadores lógicos siempre que se pueda!
o Ayuda a identificar los casos ‘N’
Incorrecto
 “Eliminar un clien...
Pasos
o Acciones que debe realizar el Tester para realizar la prueba
o Primer paso
 Especificar con quién se ingresa al s...
Pasos
o Ejemplo
1. Ingresar al sistema con un usuario con rol Vendedor.
2. Ingresar al módulo Cobranzas.
3. Ingresar a la ...
Pre requisitos
o En general, no es obligatorio completarlo, pero siempre agrega valor.
o Se especifica un dominio de datos...
Resultado esperado
o Cualquier discrepancia entre el resultado obtenido y el esperado debe ser
reportado como un error.
o ...
Resultado esperado - Ejemplos
o Definición
 Ventas. Cobranzas. Datos válidos. Grabar.
o Resultado esperado
 Se da de alt...
Prioridades
o Alta
 Testing positivo, son los que nos aseguran que la aplicación se puede usar.
 Generalmente imposibili...
Prioridades - Ejemplo
o Alta
 Desc.: Login. Usuario correcto. Clave correcta.
 Resul. Esper.: Se ingresa al sistema y ca...
Generales
o La gramática y ortografía deben ser correctas.
o Un caso de prueba debe tener toda la información necesaria pa...
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 e...
Regresión
o Circuitos principales de la aplicación.
o Siempre son de “Alta”.
o Que sea de Alta no significa que debe ser r...
Regresión
o ¿Cómo saber cuando es regresión?
 ¿Es un caso feliz de la funcionalidad?
 ¿Es un circuito principal o secund...
¿Preguntas?
Próxima SlideShare
Cargando en…5
×

Taller casos de prueba

26.585 visualizaciones

Publicado el

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

Publicado en: Tecnología
  • Sé el primero en comentar

Taller casos de prueba

  1. 1. Engee IT S.R.L.Taller de testing Definición de casos de prueba andres.grosso@engee.com.ar
  2. 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. 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. 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 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 24. ¿Preguntas?

×