Metodologa QA

Testing Funcional

Lineamientos para la definicin de casos Indice

* Introduccin * La descripcin * Cubrimiento * EL Resultado esperado * Pasos * Datos * Prioridad * Conclusiones * Introduccin: La definicin de casos de Pruebas constituye el primer paso a la hora de realizar el testing funcional de un sistema de Software. El nivel de profundidad logrado en esta fase y la forma que estn descriptos influir en gran medida en las subsiguientes. A continuacin se describen algunos lineamientos a tener en cuenta a la hora de la definicin de casos para uniformar la estructura de los casos de prueba como a si tambin para asegurar la calidad mnima requerida de su contenido. Adicionalmente el uso de estas prcticas en la definicin de casos permitir: Detectar tempranamente problemas en las especificaciones o el diseo. Evitar que por causa de casos pobremente definidos queden problemas sin detectar. Minimizar el esfuerzo requerido para entender los casos , acelerando consecuentemente los tiempos de ejecucin de los mismo. * La descripcin: El campo descripcin deber contener una descripcin concisa de la situacin representada en el caso, la cual puede expresarse como una accin a realizar representativa del caso. La lectura de la descripcin de dos casos debe ser suficiente para poder determinar que condicin diferente prueba cada uno de ellos. Estructurar: la descripcin de manera tal que quede claro el objetivo del caso y la pantalla o funcionalidad que se debe testear. * Cubrimiento: es necesario verificar que todos los campos son correctos por ejemplo: Campo de tipo combo se tome el valor de la tabla correcta y se muestren ordenados segn criterio establecidos.

Campo de tipo Fecha: no admite el ingreso de fechas invlidas. Campo numrico: ingreso de decimales, negativos, no numricos etc. Campo cuyo valor depende del seteo de otro campo. * Resultado esperado: El campo resultado esperado debe detallar todos las pos condiciones que deben verificarse una vez ejecutada la accin resumida en descripcin y detallada en pasos. Es muy posible que para muchos casos el resultado esperado exprese que deben realizarse verificaciones en distintos sistemas. En el resultado esperado debern enumerarse las verificaciones a realizar luego de la ejecucin, poniendo el foco sobre que hay que verificar, en el lugar del detalle de cmo hacerlo. * Pasos: El campo paso deber contener la secuencia de pasos a realizar para ejecutar el caso de prueba hasta el punto previo a la verificacin del mismo en el resultado esperado, muchas veces los pasos sirven para entender en mayor detalle cual es el resultado esperado a ms bajo nivel en cada paso de la ejecucin de un caso. Los pasos debern estar numerados y detallados en forma algortmica, los datos necesarios para la ejecucin de estos pasos estarn detallados en el campo datos. * Datos: En el campo datos deben especificarse inicialmente todas las entidades de datos necesarios para la ejecucin del caso y las precondiciones que deban cumplir previo a la ejecucin. Sirve para ampliar la informacin proporcionada en la descripcin. - campos involucrados - permisos de usuarios - Precondiciones - variaciones del mismo caso (Ejemplo un valor incorrecto de DNI es un valor no numrico con ms de 8 caracteres, negativos o con decimales). datos puntuales segn contesto y funcionalidad. * Prioridad: es muy importante clasificar correctamente los casos segn su prioridad de manera tal de ordenar la ejecucin. Alta: En estos casos llevan recorrer la aplicacin a lo ancho, probando rpidamente una vez cada funcionalidad en su caso ms bsico y normal. El principal objetivo es detectar tempranamente la existencia de funcionalidades no implementadas o que no funcionen ni siquiera en una situacin sencilla y frecuentemente usada. Media: estos casos permiten probar con mayor profundidad las funcionalidades mas criticas del sistema, se plantean distintas variaciones y situaciones incluyendo las principales pruebas de la seguridad se corresponden con situaciones cuya probabilidad de ocurrencia es alta o media.

Se incluyen en esta categora todos los casos cuya ejecucin no pueden ser pospuesta hasta la puesta en produccin, la falta de estos casos generaran incidentes que impediran el pasaje a produccin del sistema o de algunas de sus funcionalidades. Bajo: Dentro de esta categora se incluyen los casos cuya probabilidad de ocurrencia es baja y cuyo impacto en caso de falla no se supone invalidante para la aceptacin de una funcionalidad o su pasaje a produccin Si bien la ejecucin de estos casos es importante para garantizar el correcto funcionamiento de la aplicacin. Se podr posponer o suspender la ejecucin de los mismos en caso de tener recortar el alcance de las pruebas previas a la fecha de una prueba en produccin. Conclusiones: Hay que aprovechar la oportunidad para detectar tempranamente problemas en la especificacin de diseo.

INDICE
1.- Etapa de planificacin de un proyecto testing 2.- Cronograma de Pruebas funcionales. 3.- Definicin de lnea de tiempo. 4.- Diseo de casos de Pruebas. Ejemplo diseo Bsico de prueba Criterios que deben ser satisfechos para dar por aceptadas las pruebas. Estructura Equipo de trabajo Etapas de planificacin de un proyecto de Testing
A continuacin se detallan cada etapa de las pruebas funcionales y entregables

Plan de Pruebas

Caso de Prueba

Reporte de incidentes

Informe de fin de Ciclo

Planificacin Errores

Diseo

Ejecucin Ciclo 1 Correccin de errores Ejecucin ciclo 2 Correccin de

Descripcin de los entregables de cada etapa

a) b)

Plan de pruebas: contiene el alcance objetivos estrategia y criterios de aceptacin de las pruebas
funcionales.

Casos de pruebas: contiene el diseo de casos de pruebas incluyendo la descripcin pasos, datos de
pruebas, estados, etc.

c)

Reportes de incidentes: Contiene el reporte de Errores encontrados durante la ejecucin de los casos de pruebas. Informe de fin del ciclo: Por cada ciclo de pruebas, se debe generar este informe que contiene el resumen de casos de Pruebas ejecutados, incidentes reportados y se especifica si la aplicacin esta aprobada o no.

d)

Cronograma Pruebas Funcionales

La lnea del tiempo indica la duracin de cada etapa de certificacin del proyecto, se separa por Hitos Hito 1 Hito 2 Hito 3 Hito 4 Hito 5

Planificacin

Diseo de Casos

Checlist de Ambiente 1,5 dias

Ejecucin Ciclo 1 6 dias

Correccin Ejecucin Ciclo Incidentes 2 dias 2 4 dias

1 dia

5 dias

Ejemplo: El proceso de certificacin completo tiene un tiempo de duracin de 19,5 das

Definicin lnea de tiempo - Plan de pruebas: Se estima un da para la confeccin y entrega del plan de pruebas que contiene el alcance objetivos, estrategias y criterios de aceptacin de las pruebas funcionales. - Anlisis y diseo de casos de pruebas: Se estima un periodo de 4 das para la construccin del diseo de casos de pruebas generando entrega parcializada del diseo para dejar las observaciones correspondiente por parte del cliente, una vez terminado el diseo de casos se dar un plazo de un da para generar e incluir las observaciones al diseo. - Checlist de ambiente: Se estima un periodo de 0,5 das dentro del cual se confecciona un listado de componentes bsicos que deben estar disponibles en la aplicacin para dar el comienzo a la ejecucin. Se considera un da para la revisin del ambiente, indicando al final de esta si cada punto esta OK. - Ciclo I: Se realizara la ejecucin total de casos de pruebas. Correccin de Incidentes: Tiempo destinado para la correccin por parte de desarrollo. La empresa confeccionara informe de cierre de ciclo en un da. - Ciclo II : Se realizara la ejecucin del 100% de casos de pruebas NOK y el 20% de los casos Ok, se confeccionara informe de cierre del proyecto.. Diseo casos de Prueba Documentacin requerida para el diseo de casos de Prueba - Diagrama de casos de usos. - Especificacin de Requerimientos. - Manual del Usuario - Todo documento que almacene de forma explcita lo solicitado por el cliente

- Maquetas o pantallas - Base de Licitacin. Pruebas Funcionales: Se pueden validar funciones tales como: - Autentificacin - Formato de pantalla - Navegabilidad - Usabilidad Compatibilidad con diferentes Browser - Validacin de Campos - Clculos o Resultados.

Tipos de Pruebas (test) - Pruebas unitarias o unidad de Pruebas - Pruebas de integracin - Pruebas Funcionales o de Sistema - Pruebas de aceptacin del Usuario (UAT) - Tipo Alfa y Beta - Pruebas de Regresin. Pruebas Tcnicas: que serian Pruebas de Volumen, carga, performance, pruebas de Stress, Pruebas automticas (Pruebas de disponibilidad/ compatibilidad/ usabilidad/ entre otras, Pruebas tcnicas (Performance, stress etc.). Pruebas de seguridad, solo se incluyen las contempladas como partes de las pruebas funcionales, tales como perfilamiento, accesibilidad entre otras.

Ejemplo Diseo Bsico de Pruebas

Tipos de casos de Pruebas Prueba de Borde: destinada a validar la cantidad de caracteres que se podrn ingresar en un campo. Datos Negativos: su ingreso debe ser solo cuando corresponde. Obligatoriedad de datos, campos marcados como obligatorios no deben quedar en blanco. Caracteres invlidos, debe validar el ingreso de este tipo de caracteres. Datos Invlidos, ejemplo, Prohibir el ingreso de fechas tales como 30/11/XXXX

Ejemplo diseo de CASOS DE USO I D Func ional idad Descri pcin Resulta do esperad o D P a as t os o s Est ado s Critici dad T i p o d e c a s Re gre sio n Tester Fecha

. Criterios que deben ser satisfechos para dar por aceptados las Pruebas * Todos los casos de pruebas estarn ejecutados (los casos de pruebas tiene al menos un evento asociado en un estado final). Los estados finales de un evento Son: No Ejecutado: Es el estado que se asocia a un caso de prueba que no ha sido probado. Ejecutados OK: estado que se asocia a un evento cuando se ejecuta un caso de prueba y no se produce ningn error. Ejecutado NOK o ERR: Es el estado que se asocias a un evento cuando como resultado de la ejecucin del caso de prueba se produce un error, considera evento invalidarte que como resultado de la ejecucin del caso de prueba se produce un error que no permite continuar con la ejecucin de las pruebas. Dependientes: Cuando su ejecucin depende de la solucin de otro reporte NOK, por lo cual los casos que vienen a continuacin mantendrn el error. No Aplica: cuando un caso de prueba que haba sido definido ya no est vigente es decir ya no tiene sentido ejecutarlo por el cambio de funcionalidad a testear o cuando se valida que el error reportado no es tal. Los casos de prueba que fallaron tendrn un cambio de evento asociado el estado final podra ser: Solucionado: Cuando se comprueba que el error que haba sido reportado ha sido corregido. Algunos puntos a tener en cuenta son: La definicin debe ser clara y practica para todos los que deban interactuar con los incidentes. El cubrimiento completo debe buscar el menor acoplamiento posible, no debe ser existir superposicin entre las distintas funcionalidades definidas con respecto al alcance que tienen. En los test de sistema, se sugiere crear una funcionalidad que contenga los circuitos funcionales o casos de integracin entre las distintas funcionalidades de manera tal de no olvidarse de realizar este tipo de pruebas. Estructuras Equipo de Trabajo

QA Manager

Lder Equipo QA

Lder Proyecto

Equipo Diseo Y Ejecucin Funcionalidad

Cliente De Sentra

Algunos puntos a tener en cuenta son:

Prioridad

Descripcin

Alta

Funcionalidad esencial para la aplicacin. Es la que primero se debiera implementar y la primera que requiriera el usuario para realizar la operatoria.

Media

Funcionalidad Necesaria al momento de realizar la Implementacin, pero no reviste la relevancia indicada en el punto anterior, sino que es considerada por el usuarios como de segundo orden. Funcionalidad que entra en la categora de lo deseable, por lo que debe ser necesario, podra separarse en una etapa posterior de implementacin

Baja

Algunas definiciones
Pruebas unitarias o unidad de pruebas: son pruebas que se realizan en los mdulos de forma aislada dejando el trabajo de probar la interaccin entre mdulos a las pruebas de integracin (ejemplo: modulo, mail, modulo pagar. etc.). Pruebas de Integracin: Se prueba que la interaccin de los mdulos de una aplicacin para evitar que fallen al trabajar en forma conjunta, aunque si funcionan correctamente de forma individual. Pruebas Funcionales: son pruebas que se realizan para verificar el cumplimiento de la especificacin de requerimientos. Pruebas de Rendimientos: son realizadas para determinar el tiempo/ rapidez el aplicativo o un modulo especifico realiza una tarea.

Pruebas de Estrs: Su finalidad es saber como funciona el programa al trabajar con un gran volumen de informacin/ datos en periodos de tiempos y en forma concurrente. Pruebas de Volumen: Tiene la finalidad de comprobar el comportamiento del programa con volmenes de datos especficos. Caja Blanca: Son pruebas en donde se verifica que los mdulos internos de la aplicacin se cumplan ( Se preocupa que el Output sea el esperado). Caja negra: son pruebas en donde se verifica que las funcionalidades de la aplicacin se cumplan (se preocupa que el output sea el esperado). Prueba de Usuarios: Es una prueba en donde el usuario certifica que la aplicacin cumple con los requerimientos. Pruebas Automticas: Son pruebas que no se realizan en forma manual si no que es una aplicacin que prueba a otra aplicacin. Pruebas de Regresin : son pruebas que se realizan a mdulos o aplicaciones en donde se ha efectuado un cambio en el mismo y se necsita probar que esta modificacin no haya afectado al resto del modulo o aplicacin.