SpiraTest Hildebrando Noviembre, 2010

Presentación del tema: "SpiraTest Hildebrando Noviembre, 2010"— Transcripción de la presentación:

1 SpiraTest Hildebrando Noviembre, 2010
Se terminan los proyectos DTS, ya que entran 5 julio entra Spira Test desde la fase de diseño. 1

2 Acceso a SpiraTest Pantalla de acceso para capturar usuario y contraseña

3 Módulos Principales My Page Project Home Planing Testing Tracking
Reporting

4 Project Home - Estatus Resumen de Requerimientos Estatus de Ejecución
Resumen de Defectos

5 Planning – Requerimientos de prueba
Seleccionar en el menú Planning -> Requirements Poner un ejemplo de los requerimientos que te da herramienta en Spira test (que es parte del Diseño)

6 Testing – Casos de Prueba
Para ingresar a los casos de prueba, en la barra de navegación seleccionar en el menú Testing -> Test Cases No se diseña en excel, el Diseño y captura se va hacer en esta página (Testing->Test Cases), el documento de excel que se obtiene de Spira Test de los casos de prueba es el que se imprime y se van a obtener las firmas y se escanea y se sube al map. Esta es la Firma del diseño de los casos de prueba. El único archivo que se va llevar en Excel es la matriz de pruebas. Ejemplo de casos de prueba sin ejecutar en excel

7 Reporting En el módulo “Reporting” se muestran los tipos de reportes
Ejemplos de casos de prueba ejecutados e incidencias. Cuadro rojo incident list

8 Control y Seguimiento de Defectos
SpiraTest Mayo 2009

9 Control y Seguimiento - Roles
Permisos Administrador Alta, modificación y baja de proyectos, creación de usuarios y contraseñas* QA Acceso a consulta y extracción de información del proyecto asignado. Cambio de severidad a los defectos Líder de proyecto Acceso a consulta y extracción de información del proyecto asignado Tester / Usuario Registro, actualización y consulta de defectos, extracción de información del proyecto asignado Desarrollo Consulta, atención y resolución de defectos, extracción de información del proyecto asignado BSA Mostrar el archivo el diseño se va hacer en spira para altas de usuarios muestra el archivo de alta en excel * Para dar de alta proyectos y usuarios la solicitud se realiza través de QA

10 Severidad - Defectos Severidad Descripción S1 – Alta La aplicación o módulo dejó de funcionar, DETIENE EL FLUJO DE LA OPERACIÓN y NO existe manera alterna de ejecutarlo. NO permite continuar el flujo de pruebas (la funcionalidad relacionada a la incidencia está dentro del alcance). Ej. Aplicación NO está disponible, ambiente de pruebas equivocado y/o no disponible, versión errónea, configuración y/o catalogación, desempeño, concurrencia, tiempo de respuesta, no hay acceso (usuario/contraseña reseteo / bloqueo), parametrización, etc. No se puede probar. Requiere Atención INMEDIATA del proveedor. S2 – Media La aplicación o módulo funciona parcialmente, AFECTA LA OPERACIÓN, sin embargo, existe manera de continuar con la operación o con el flujo de ejecución de las pruebas (la funcionalidad relacionada a la incidencia está dentro del alcance). EJ. Una función/proceso importante está siendo afectado y la ejecución está seriamente obstaculizada, proceso no concluido, caída de datos incorrecta, etc. S3 – Baja La aplicación o módulo funciona pero presenta problemas menores en los resultados, esto NO AFECTA LA OPERACIÓN o ejecución de las pruebas (la funcionalidad relacionada a la incidencia se encuentra dentro del alcance) Ej. Términos, traducción, ortografía, gramática, formato, caracteres especiales, impresión, alineación, “look and feel”, etc. S4 – Sugerencia Cualquier cambio no definido dentro del BRD / Diseño Funcional deberá ser analizado y autorizado para atenderse de la siguiente manera: -Dentro del proyecto: Como variación de alcance, pudiendo impactar el tiempo o presupuesto del proyecto -Fuera del proyecto: Con otro proyecto o una solicitud de mantenimiento. NOTA: Se incluyen en el listado total de incidencias para poder tener un mejor control y darle seguimiento posterior. Los ingenieros de prueba y usuarios asignan la severidad al registrar el defecto

11 Prioridad - Defectos Prioridad Descripción Alta
El defecto se debe de arreglar inmediatamente Media El defecto se debe arreglar en un tiempo próximo Baja El defecto puede se arreglado más adelante Los ingenieros de prueba, usuarios y QA definen la prioridad del defecto

12 Tipos de Atención - Defectos
Descripción Assigned Valor por default al crear el defecto As Designed Esta conforme a la especificación del caso de uso Issue In Production Problema conocido en producción Change Request Cambio al requerimiento inicialmente especificado en el caso de uso Could Not Reproduce No se puede reproducir el defecto Duplicate El defecto ya fue registrado Fixed El defecto esta listo para ser validado por el Ingeniero de Pruebas Need More Info Se requiere más información para su atención Under Construction El defecto esta siendo atendido por el desarrollador Cant be Fixed El defecto no puede ser reparado Disagree El desarrollador no esta de acuerdo con el defecto levantado Incidente asigando.assaing si igual. Marco rojo in produccción es nueva y se esta incluyendo El equipo de desarrollo da una resolución al defecto levantado

13 Estatus - Defectos Estatus Descripción New
Valor por default al crear el defecto Vendor Defecto asignado a un desarrollador Response Regresar defecto al Tester/Usuario para su validación Close Defecto cerrado Nuevo. De que lado esta el defec to y que se esa haciendo con este defecto. Atencion El flujo no cambia los estatus del usuario. Atencion o respuesta del proveedor. Testing / Usuario New Response Close Desarrollo / IT Vendor Reponse

14 Complejidad del defecto
Complejidad para la resolución del defecto Alta Media Baja Seguimietno mas puntual del desarrollo, tiempos de respuesta de desarrollo El equipo de desarrollo califica la complejidad del defecto

15 Clasificación del defecto
Tipo Descripción Funcional Todos los problemas relacionados al alcance y requerimientos del proyecto. Documentación Ambigüedades e inconsistencias que existan en los documentos como DF y DT vs BRD Datos Problemas con la información cargada en la aplicación, problemas de base de datos, parametrización, integridad de datos Ambiente Problemas de infraestructura, comunicación, versiones, etc. Performance Rendimiento de la aplicación Seguridad Problemas con perfiles de usuario, cuentas de usuario, perdida de información por tipos de roles, etc Usabilidad Problemas para manejar la aplicación con facilidad Cosméticos L & F Por clasificar Revisando el tipo de clasificación por parte del equipo de desarrollo Desaroollo y qa cambiar esto. Correciones

16 Ingeniero de Pruebas / Usuario
Transición de estatus Testing / Usuario New Response Close Desarrollo / IT Vendor Ingeniero de Pruebas / Usuario Desarrollo / IT New Vendor Response Close Registrar Cerrar Analizar Atender Rechazar Tipo de Atención Fixed As Designed Could Not Reproduce Disagree with Suggestion Duplicate Need More Info Under Construction Change Request Known Issue production

17 Ejecución del Caso de Prueba
En la pestaña “Testing” -> “Testcase” seleccionamos nuestro caso de prueba que vamos a ejecutar, una vez adentro dar click en “Execute” para correr el caso Poner el mensaje de aceptar

18 Ejecución del Caso de Prueba
Seleccionamos en “Release” la etapa de pruebas en que nos encontramos y le damos click en “Next “ para empezar la ejecucion. Poner el mensaje de aceptar

19 Ejecución del Caso de Prueba
Las opciones que tenemos son: Pass: La ejecución fue OK Caution: La ejecución pasó pero no es aceptable Fail: La ejecución no fue exitosa Pausa: Detiene el tiempo de ejecución Poner el mensaje de aceptar

20 Levantamiento de defecto – campos obligatorios
Actual Result: Descripción del resultado obtenido de la ejecución Name: Nombre del defecto ( mismo nombre del caso) Owner: Persona que documenta el defecto Priority: Prioridad del defecto Severity: La severidad del defecto Aplication: Aplicación en la que se localiza el defecto Poner el mensaje de aceptar

21 Levantamiento de defecto – Incidencia creada
Poner el mensaje de aceptar

22 Levantamiento de defecto – campos obligatorios
Para finalizar el proceso de ejecución debemos de dar click en el boton “Finish” Poner el mensaje de aceptar

23 Levantamiento de defecto – campos obligatorios
Si el caso falla queda registrado como “Fail” y se actualiza la fecha a la ultima ejecucion Poner el mensaje de aceptar

24 Levantamiento de defecto
Una vez registrado el defecto en la herramienta manda un correo a la persona de desarrollo que se fue asignado para su atención. Desarrollo accesa a la herramienta y automáticamente le muestra cuáles son los defectos asignados y entrar directamente al defecto asignado deseado. Poner el mensaje de aceptar

25 Defectos – Seguimiento Desarrollo
Para poder regresar las incidencia debemos de llenar los campos: Type: tipo de atención que se le dio al defecto. Owned by: ponemos el nombre de la persona que nos asigno el defecto y puede seguir el flujo mas adelante. Resolved release: seleccionamos la etapa en que fue resuelto el defecto.

26 Defectos – Seguimiento Desarrollo
En la pestaña “Resoltion” encontraremos un cuando en el cual indicamos cual fue el resultad del análisis del defecto así como una descripción del la solución que se llevo a cabo. Actualizar imagen con la fase de inyección como no requerido y aplicación como no obligatorio para desarrollo

27 Defectos – Seguimiento Desarrollo
En la pestaña “Schedule” encontraremos el campo: Estimated Effort: ponemos el tiempo predeterminado para atender el defecto Acual Effort: en este indicamos el tiempo real que tomo resolver el defecto Actualizar imagen con la fase de inyección como no requerido y aplicación como no obligatorio para desarrollo

28 Defectos – Seguimiento Desarrollo
En la pestaña “Custom Props” debemos capturar los campos: Complejidad: Dificultad estimada de atención del defecto Fase de inyección : etapa a la que se debe el defecto Clasificación del defecto: Dónde se originó el defecto? Actualizar imagen con la fase de inyección como no requerido y aplicación como no obligatorio para desarrollo

29 Defectos – Seguimiento Desarrollo
Una vez que se capturaron todos lo campos mencionados anteriormente se procede los cambios efectuados durante el proceso. Debemos de dar click sobre el boto “Save” para llevarlo a cabo

30 Defectos – Seguimiento Desarrollo
Para finalizar debemos de dar click en “Responde” para que cambie el estado y después click en “Save” para guardarlo y puedan terminar de dar el seguimiento al defecto.

31 Validación del Defecto
Una vez que es asignado el defecto manda un correo de aviso para indicar que está listo el defecto para ser verificado. Si el defecto se corrigio correctamente, dentro del “workflow Operations” damos click en “Closed” Señalar el cuadro de resolution

32 Validación del Defecto
Una vez en este flujo debemos de capturar: Verified in Release: el release en cual comprobamos que el defecto fue corregido Pestaña “Resolution” : confirmaos la solucion al defecto Para finalizar damos click en “Save” para cerrar el seguimiento del defecto Señalar el cuadro de resolution

33 Asociar un Defecto con otro
Associations Add Tracking incident

34 Asociar un Defecto con otro
Seleccionar el nombre del defecto o número Add Tracking incident

35 Asociar un Defecto con otro
Te despliega el defecto Asociado Los ingenieros de prueba asocian el defecto

36

37 Herrramienta de Importación
Nueva herramienta de importación y exportación de información. Puedes extraer información del proyecto seleccionado. Puedes hacer modificaciones de la información extraída en el Excel del proyecto y volverla a subir sincronizadamente.

38 Soporte QAIT Karla Lopez Ext 7259 Isaac Gonzalez Ext 7259
Javier Telis Ext 5022

39 GRACIAS ! ! Esta información es confidencial y propiedad de Hildebrando SA de CV Página 39 39