Ejecución
de pruebas en Mercury QC (IAS)
Manual
de usuario
|
CONTROL
DOCUMENTAL
Advanced Windows Server and Desktop tutorials
VERSIÓN
|
DOCUMENTO
|
FECHA
|
1.0_V01
|
Ejecución de pruebas en Mercury
QC (IAS) v.1.0.doc
Primera versión
|
03/02/2010
|
Pruebas en paralelo
Live Analysis, Actualizado
incluir estado “Rejected” en los informes de incidencias
abiertas
|
06/05/2010
|
|
Actualizado incluir estado “In
Test” en los informes de incidencias abiertas
|
26/07/2010
|
|
TABLA DE
CONTENIDO
1Objetivo
Mediante el presente documento se pretende describir el proceso a seguir para realizar las pruebas apoyadas en la utilización de Mercury Quality Center.2Audiencia
Este documento va dirigido a los integrantes de grupo de QA Interno y a todos aquellos que deseen o deban acogerse a su flujo de trabajo.
rabajo.
3Normativa de uso QC para QA Interno
3.1Primer ciclo de pruebas
3.1.1Flujo de trabajo
3.1.2Preparación del Test Set (NO APLICA PARA USUARIOS DE FACTORÍA)
Este punto no aplica para usuarios de factoría de pruebas que recibirán como ítem de entrada la estructura y las baterías de pruebas a realizarCuando se aborda el primer ciclo de pruebas se deberá decidir la estructura de carpetas que se estime más apropiada para recoger las baterías de pruebas. Normalmente, esta estructura estará versada en la ya generada para el Plan de Pruebas.
También se debe definir las características, que servirán para generar las Ejecuciones y para extraer información relativa a incidencias en cualquier Ciclo. Estas características son las siguientes:
- Paquete Funcional. Una vez diferenciados los paquetes
funcionales se debe tramitar su solicitud a administración QC.
- Entrega SW (campo): Tendrá un valor relacionado con la tarea
a probar, tal y como se indica a continuación:
- Tarea relacionada con un DDS: Entrega SW tendrá el nombre del DDS (si se trata de un nuevo DDS se debe solicitar que se dé de alta en el desplegable para poderlo seleccionarlo y asociarlo a las baterías).
- Localización en un Cliente: Entrega SW tendrá el literal “Requerimiento Inicial Cliente”.
3.1.2.1Estructura de carpetas en el Test Lab
El Test LAB es el módulo donde se recogen las ejecuciones de los casos de prueba llevadas a cabo por QA Interno o Factoría y previamente definidas en el Test Plan.El árbol de directorios que se defina para acoger las baterías de pruebas debe partir de la ruta:
GRUPO PROPIETARIO DE LOS TESTSETS\CANAL\APLICACIÓN Y/O PAQUETE FUNCIONAL\VERSIÓN/RELEASE PDP\TIPO DE PRUEBA\REQUERIMIENTO ORIGEN\VERSIÓN ENTREGA SW\CLIENTE\CICLO DE PRUEBAS - EXPEDIENTE
- La de QA_INTERNO: solo accesible por los usuarios del propio
grupo
- La de LABORATORIO: accesible para los usuarios de laboratorio
y los de QA Interno
- La de FACTORÍA_XXX: accesible para los usuarios de la propia
factoría y los pertenecientes a QA_Interno
- Internet
- Contact Center
- Autoservicio
- Oficina
- Movilidad
- Todo Canal
Tipo de prueba:
- P. Integración
- P. Sistema
3.1.2.2Creación de Baterías
Una vez establecido el árbol de carpetas, se pasará a crear las baterías mediante el botón “New Test Set”
Nota:
Muchos de los nombre empleados
en al estructura de carpetas tienen también reflejo en campos de la
batería
El campo “Ciclo Prueba”
debe recoger un valor numérico. Este número debe ser único en
todas las ejecuciones relacionadas con un Ciclo de Pruebas,
independientemente de que todas las pruebas las realice QA Interno o
Factoría, o entre ambos (en este caso el campo Ciclo Prueba tendrá
el mismo valor en ambos.
El campo “Entrega SW”
tendrá un valor único en todas las pruebas relacionadas con una
determinada tarea (Gap, envío a cliente, etc.), en todos los ciclos.
El valor que se desea seleccionar debió ser solicitado previamente
para que aparezca en el desplegable.
Estos datos del Test Set son almacenados dentro de la pestaña de “Test Set Properties” en el enlace de “Details”
- CANAL: Canal sobre el que se realizan las pruebas
(Oficina, Autoservicio, Contact Center, Internet, Movilidad o Todo
Canal)
- GRUPO: Grupo que realiza las pruebas
- EXPEDIENTE: En caso de que el grupo de pruebas sea
factoría, se cumplimenta con el expediente asociado
Una vez creado la batería se procede a añadir los casos de test. Para ello, con el Test Set seleccionado se debe pulsar el botón “Select Tests”
NOTA: Sobre este panel se pueden aplicar filtros para que se visualicen solamente los casos de prueba que se desee.
Para añadir los casos al Test Set se puede optar por:
- Seleccionar el caso o la carpeta y arrastrarlo hacia la zona
donde se listan los casos de prueba del Test Set
- Seleccionar el caso o la carpeta y pulsar el botón “Add
Test to Test Set” presente en la parte superior del panel
3.1.3Estados del caso de test antes y después de la ejecución
En el módulo de Test Lab cada caso de las baterías de pruebas podrá encontrarse en los siguientes estados- BLOCKED: el caso de test está bloqueado porque existe
otro caso de test fallido (FAILED) que no permite la ejecución del
caso. SE DEBE MARCAR MANUALMENTE
- FAILED: Indica que el Caso de Test ejecutado está KO.
Depende del resultado individual de todos los pasos del caso de test
- NO RUN: estado del Caso de test antes de ejecutar
- NOT COMPLETED: no se ha completado la ejecución, es
decir, alguno de los steps no se ha ejecutado
- NOT DELIVERED: mediante este estado se indica que el
software que verifica este Caso de test no se ha enviado y por tanto
no se encuentra disponible. SE DEBE MARCAR MANUALMENTE
- PASSED: indica que el Caso de Test se ha ejecutado de
manera satisfactoria (no se han encontrado incidencias o las que se
detectaron son de categorización P5). Depende del resultado
individual de todos los pasos del caso de test.
- PENDING DATA: Se establece este estado cuando el caso
de test se encuentra pendiente de que laboratorio envíe los datos
necesarios para ejecutarlo. SE DEBE MARCAR MANUALMENTE
3.1.4Ejecución de Casos de Prueba
La operativa de ejecución se lleva a cabo desde el módulo de Test LabPartiendo del Test Set se seleccionará el caso que se desea ejecutar
- Descripción: se trata de las acciones que se deben efectuar
en cada paso
- Resultado esperado: se especifica el efecto que se obtiene de
realizar las acciones enumeradas en la descripción
3.1.4.1Evaluar el resultado del paso ejecutado
Se verifica el resultado obtenido:- Si coincide con el esperado o si la incidencia detectada es
de criticidad baja (de prioridad P5) se valida el paso mediante el
botón “Pass Selected”.
- Si el retorno obtenido NO coincide con el “Resultado
Esperado” deberemos registrarlo estableciendo el estado del paso
seleccionado a fallado mediante el botón (siempre que la
categorización de la incidencia no sea P5)
- Si se trata de un paso de impresión que no se puede ejecutar
por no disponer de impresora financiera se seleccionará como estado
del paso N/A. VER ANEXO IMPRESIÓN
FINANCIERA
NOTA: ÚNICAMENTE en caso de que todos pasos sean correctos, se guardará una evidencia representativa de la ejecución correcta. Se elegirá el paso más relevante para constatar dicha evidencia.
Para adjuntar una captura de pantalla a nivel de paso se debe pulsar el botón de Attachments.
- Botón “Attach Snapshot” (realiza
una captura de la pantalla.
):
- Botón “Attach File” (
): adjunta un fichero con una
imagen que se haya adquirido previamente
- Botón “Attach Clipboard Content” (
): adjunta el
contenido del portapapeles
NOTA: En caso de registrar una incidencia en un paso NO se debe adjuntar también una imagen al paso (es suficiente con la adjuntada en la incidencia)
3.1.4.2Tratar apertura de incidencias
Para decidir si dar de alta una nueva incidencia o vincular una existente se debe tener un conocimiento previo de las incidencias ya abiertas en la aplicación. En caso de vincular una existente es necesario comunicárselo al autor de la incidencia para tenerlo en cuenta en futuras verificaciones de la misma.
Se consultan las incidencias (al menos las que se encuentren en estado New u Open) para verificar si ya se encuentra dada de alta. Para ello:
- Desde el módulo de incidencias se establece como filtro el
Paquete Funcional, Cliente y Entrega SW. (otra alternativa es
realizarlo a nivel de la carpeta/s que contiene las pruebas del
cliente seleccionando el o los “Test Set Folder”).
De esta forma se listan solo las incidencias del grupo.
- Desde el módulo de incidencias se establece como filtro el
Paquete Funcional, Cliente y Entrega SW. (otra alternativa es
realizarlo a nivel de la carpeta/s que contiene las pruebas del
cliente seleccionando el o los “Test Set Folder”).
- Se ordenan por caso de prueba o por “Elemento de SW” (OP)
seleccionando la pestaña de “View Order”
Se pueden aplicar diversas condiciones de filtrado para detectar si la incidencia que se ha detectado ya fue abierta, por ejemplo:- por la categorización que estableceríamos a la nueva
incidencia
- por una palabra clave del título, por ejemplo “Lupa” o
“Calendario” o “Error técnico”
- las que contengan en el título “INC. GENERAL” (son
incidencias que ya se dan en más de un caso)
- Existente abierta (New, Open, Reopen, Rejected o Fixed) y NO
vinculada al caso. Se comprueba el estado de la incidencia (si se
encuentra en estado Fixed, o Rejected y no se está de acuerdo con
el rechazo, se cambia el estado por Reopen) y se procede a vincular
al paso donde nuevamente se detectó. (Véase Vincular
una incidencia existente a una ejecución realizada) A la hora
de considerar que una Incidencia ya existe, hay que asegurarse que
realmente se trata del mismo error antes de abrirla y / o
reutilizarla.
- Existente abierta (New, Open, Reopen, Rejected o Fixed)
vinculada al caso. Se establece el estado de la incidencia como
Reopen en caso de encontrarse en estado Fixed o Rejected y no se
está de acuerdo con el rechazo (Se trata de una situación extraña
que se puede dar en caso de ejecutar varias veces el mismo caso de
prueba sin haber evolucionado el ciclo).
- Nueva. Se abre la nueva incidencia (Véase “Crear una nueva
incidencia durante la ejecución”)
3.1.4.2.1Crear una nueva incidencia durante la ejecución
Para crear una nueva incidencia mientras se ejecuta se deberán seguir los siguientes pasos:
Pulsar el botón de “New Incident”
Se mostrará el formulario de alta de una nueva incidencia
Título: debe contener una descripción breve pero significativa de la incidencia. Si se trata de una incidencia que se produce en varios lugares en la aplicación, debe comenzar por “INC. GENERAL”, para así hacer este tipo de incidencias más fácilmente localizables.
Categorización: Valores de P1 a P5 según la siguiente tabla
PrioridadDescripciónP1CRÍTICOP2MUY ALTOP3ALTOP4MEDIAP5BAJA
Cumplimentando este campo se toma valor automáticamente el campo “Impacto” y “Urgencia”
Impacto: Se cumplimenta automáticamente al seleccionar la categorización pero se permite su modificación. Refleja la relevancia que tiene la incidencia dentro de la aplicación (por ejemplo puede darse una incidencia P1 por ser bloqueante pero encontrarse en una operativa que no se utiliza apenas y por tanto el impacto será bajo). Sus valores posibles son:
- Alta
- Media
- Baja
- Urgente
- Alta
- Media
- Baja
Elemento de SW: se cumplimenta con el nombre de la OP o transacción en la que se ha detectado la incidencia (debe corresponderse de manera EXACTA con el observado en el código fuente de la página)
Entorno: los valores posibles son
- CER (Certificación) La
aplicación se encuentra desplegada en desarrollo apuntando a los
datos residentes en certificación siendo esta la norma.
- PC Local Cuando la
aplicación se encuentra desplegada en un servidor distinto a
desarrollo
- DES (Desarrollo) Para
pruebas efectuadas de transacciones en desarrollo
- PRE (Preproducción) Para
pruebas efectuadas contra el entorno de preproducción
- MIG (Migración) Para
pruebas efectuadas de migración
El campo “Entrega SW” tendrá un valor único en todas las pruebas relacionadas con una determinada tarea (Gap, envío a cliente, etc.), en todos los ciclos.
Paquete funcional: Se arrastrará el valor registrado en el Test Set
Tipo de Incidencia: Se seleccionará uno de los valores disponibles:
- Error Batch
- Error Contable
- Error de Acceso
- Error de Aplicación
- Error de Idioma
- Error de Impresión
- Error de Log
- Error de Parámetros
- Error de Usabilidad
- Literal
- Otros
- Portal
- Rendimiento
- Seguridad
Código de Expediente: aquí se indica el código de Expediente que se ha abierto desde la herramienta HNE NOTES. Este campo es necesario para el seguimiento del trabajo de factorías de pruebas. Se debe arrastrar del valor que posea el Test Set
ID Incidencias relacionadas: se cumplimenta con el ID de las incidencias mencionadas en caso de que existan.
ID_Remedy: se cumplimentará este campo con el número de Remedy en caso de conocerlo. En este campo Laboratorio introducirá el ID del Remedy que se ha abierto ante una incidencia catalogada como “Externa a la Aplicación”.Origen de la incidencia: podrá ser Batch u Online. Valor “Online” por defecto.
Ruta y sistema: toman valor automáticamente y no son modificables.
Tiempo de resolución: No aplica.
TP Nombre CT: nombre del caso de test del Test Plan (no es modificable)
Grupo Resolutor: se selecciona el grupo o persona que se encargará de solucionar la incidencia. Una vez establecido, al pasar a Open o Reopen las incidencias, se enviará un correo de aviso al usuario seleccionado en este campo como Resolutor. El usuario de factoría que efectúe las pruebas debió ser informado por QA Interno del valor a establecer en este campo
Estado: se podrá optar solamente por el valor New (véase Circuito de incidencias completo).
Motivo de cierre y Ciclo de cierre: no aplican durante la apertura de la incidencia
Externa a la Aplicación: En este campo se indicará si la incidencia es externa a la aplicación. Presentará las opciones SI/NO. En el caso de seleccionar SI (lo que significará que es Externa a la aplicación) se habilita un campo de texto REQUERIDO Datos Aplicación Externa.
Datos Aplicación Externa: campo de texto libre donde indicaremos la aplicación a la que imputar el error
Grupo: grupo que ejecuta la prueba. Es un desplegable con los valores
- Factoría de Construcción
- Factoría de Pruebas
- QA_Interno
- Laboratorio
Se debe arrastrar del valor que posea el Test Set
- Internet
- Contact Center
- Autoservicio
- Oficina
- Movilidad
- Todo Canal
Descripción: debe contener en siguiente orden
- Los datos utilizados
- Los pasos seguidos para reproducir la incidencia
- El detalle del fallo con exactitud
- A continuación se elimina el texto que por defecto aparece a
excepción del nombre del caso de prueba (Test)
Por defecto aparece
Una vez seguidos los pasos mencionados obtendremos el siguiente resultado
También se deberá, en caso de que sea posible, adjuntar una imagen (o varias) que ilustren el error que se ha detectado. Para ello, podremos:
- Botón “Attach Snapshot” (realizar
una captura de la pantalla.
):
- Botón “Attach File” (
): adjuntar un fichero con una
imagen que hayamos adquirido previamente
- Botón “Attach Clipboard Content” (
): adjuntar el
contenido del portapapeles
Una vez completados los campos mencionados y adjuntada la imagen se procede a efectuar el alta de la incidencia pulsando “Submit”. Mercury nos informará de la incidencia creada con un id identificativo único y secuencial.
3.1.4.2.2Vincular una incidencia existente a una ejecución realizada
Desde el módulo de Test Lab
Seleccionar el caso de prueba al que se desea añadir la incidencia existente
Realizar doble clic sobre el para mostrar sus instancias de ejecución
Realizar doble clic sobre la ejecución a la que queremos vincular la incidencia
SE SELECCIONA EL PASO al que realizar la asociación y se pulsa sobre el botón de “Linked Incidents”
En la nueva ventana que aparece, pulsar sobre “Link Existing Incident”
(Este botón permite seleccionar por Id de incidencia (By Id) o listando todas las incidencias, opción “Select”)
Se selecciona la incidencia a vincular (para localizarla se podrá hacer uso de los filtros de la parte superior de las columnas) y se pulsa en “Link”
3.1.5Finalizar una ejecución
La finalización de una ejecución se puede llevar a cabo:
- Pulsando el botón “End Run”
- Pulsando el aspa de Windows que cierra la ventana ante lo que se mostrará un mensaje interrogando al usuario si desea salvar lo ejecutado hasta el momento.
Si se opta por grabar lo ejecutado obtendremos como resultado un caso en estado no completado (“Not Completed”) que se podrá retomar en un momento posterior
Nota: se puede optar por este comportamiento en caso de que queramos vincular una incidencia existente a este caso de prueba
Si se opta por contestar que “No” el caso de prueba permanecerá en el mismo estado que estaba antes de comenzar la ejecución. Por tanto, quedará eliminada la información generada en la ejecución aunque no se eliminan las incidencias que se hayan creado.
3.1.6Continuar una ejecución
Si debido a cualquier motivo no se finalizó la ejecución de un caso de prueba y se desea continuar su ejecución se debe, dentro del módulo de Test Lab.
Seleccionar el caso de prueba que se desea continuar haciendo doble clic
Con la instancia de ejecución seleccionada (en este caso “Reprueba de Ciclo 4) pulsamos sobre el botón “Continue”
Retomando así la ejecución tal y como se finalizó
Un botón con idéntica función se puede localizar directamente en la pantalla de Test Lab pulsando la flecha que despliega las opciones del botón Run
A continuación el detalle de donde localizar la opción
3.1.7Cambio de estado de los casos de prueba
En el módulo de Test Lab se ha de cambiar el estado del caso de prueba si el cambio de estado no es automático. Por tanto, se establecerán los siguientes estados DE FORMA MANUAL CUANDO PROCEDA:
BLOCKED: si el caso de test está bloqueado porque existe otro caso de test fallido (FAILED) que no permite la ejecución del caso.
NOT DELIVERED: si el software que verifica este caso de prueba no ha enviado y por tanto no se encuentra disponible.
PENDING DATA: si el caso de prueba se encuentra pendiente de que laboratorio envíe datos los datos necesarios para ejecutarlo.
Nota: Los estados que se establecen automáticamente son: FAILED, NO RUN, NOT COMPLETED, PASSED
El cambio de estado se realiza en el módulo de Test Lab, dentro del Test Set correspondiente se utiliza el desplegable del estado para evolucionar el estado
3.1.8 Consolidación de incidencias
Una vez finalizada la ejecución de un caso de prueba, y realizadas las consultas que se estimen necesarias sobre las incidencias abiertas en presente ciclo (se encuentran en estado New) se procede a cambiar el estado a Open en caso de considerarse incidencia o a estado False en caso de estimarse que no se trata de incidencia
NOTA PARA LAS INCIDENCIAS CON CATEGORIZACIÓN P1 O P2. LOS USUARIOS DE FACTORÍA HAN DE INFORMAR A QA INTERNO (NORMALMENTE MEDIANTE UN CORREO Y EXCEPCIONALMENTE POR TELÉFONO) DE LA APERTURA DE ESTAS INCIDENCIAS. QA INTERNO UNA VEZ EVALUADAS SERÁ EL ENCARGADO DE EVOLUCIONAR EL ESTADO LAS INCIDENCIAS (A OPEN O FALSE SEGÚN ESTIME CONVENIENTE).
BUZÓN PARA COMUNICACIÓN CON FACTORÍA: pruebasfactorias@isban.es. Es imprescindible en el correo enviado a QA Interno indicar en el asunto: la aplicación, el cliente y el número de incidencia a evaluar
Nota: Las incidencias en estado New no se consideran como tal hasta que no pasan a estado Open. Véase el Circuito de incidencias completo
Buzón de Factoría MTP: softwarefactorymtp@isban.es
Buzón de QA Interno: pruebasfactorias@isban.es
3.1.9 Pruebas en paralelo
Cuando se realicen pruebas de forma paralela por el grupo de Corebanking y Factoría. Se documentarán las incidencias detectadas
Progresivamente, Corebanking probará los casos ya ejecutados en factoría, para ello:
Se extraerá la relación de incidencias abiertas (Open, Reopen o In Test) del caso a probar.
Se realiza el caso de prueba en busca de incidencias no detectadas hasta el momento
Las nuevas incidencias detectadas se documentan mediante la plantilla existente.
Cada vez que se detecte una incidencia que no ha sido detectada en factoría, se debe enviar la plantilla cumplimentada a la factoría para que proceda a darla de alta asociándola al caso correspondiente
3.1.10Informes
Para efectuar un seguimiento diario del estado del proyecto se realizará un cuadro de mandos que QA Interno enviará a los laboratorios para elaborarlo se deben seguir los pasos descritos
Para obtener el cuadro de mandos se necesita información tanto de los casos de test ejecutados como de las incidencias en vigor:
- Filtro para Casos de Test, para obtener información de
número Casos de test probados, fallidos, correctos, etc.
- Entrar en módulo Test Lab
- Obtener el estado de los casos de test.
- Ver epígrafe: Avance
de las pruebas
- Filtro para obtener información de Incidencias:
- Entrar en módulo Incidencias.
- Seleccionar Test Plan por Subject.
- Seleccionar Test Lab de todos los Ciclo.
- Seleccionar Incidencias Open, Reopen,
Rejected o Fixed.
- Ver epígrafe: Incidencias
abiertas por categoría
- Generar Cuadro de Mandos:
- Combinar los datos obtenidos en los dos filtros anteriores
actualizando la hoja Excel que se envía por correo a las
aplicaciones. Ver anexo Plantilla
cuadro de mandos
3.1.10.1Avance de las pruebas
Para conocer el avance de las pruebas se podrá obtener un grafico siguiendo los pasos que a continuación se detallan:
Desde el módulo de Test Lab. Seleccionar <Sumary> - Cross test set
Mediante el botón “Filter”
Se parametriza el filtro cruzado
Mediante el botón de Avanced es posible realizar un filtro cruzado
Utilizaremos el botón de puntos suspensivos de la fila de Test Set
Obteniéndose así el dialogo que permite filtrar por atributos del Test Set con los que están relacionados (esto se realiza así para que solamente se muestren los defectos de los Test Sets de los ciclos que seleccionaremos en un paso posterior)
Cuando se posiciona sobre el campo Test Set Folder aparece una ventana donde seleccionaremos la carpeta del ciclo que incluya todos los Test Set objeto de la prueba
Se pulsa OK permaneciendo así el valor seleccionado como aparece en la siguiente imagen
Se selecciona la pestaña de “Pie Chart”
Se selecciona en el desplegable X-Axis el valor “Resultado prueba”
Se pulsa Refresh obteniendo el gráfico
Esta información debe ser incorporada al actual excel de Cuadro de Mandos (CM) por cada responsable de la aplicación
3.1.10.2Incidencias abiertas por categoría
Para conocer el número de incidencias que se encuentran abiertas se podrá obtener un gráfico siguiendo los pasos que a continuación se detallan:
Desde el módulo de Incidents. Seleccionar <Sumary> - Group by ‘Status’
Mediante el botón “Filter”
Se parametriza el filtro cruzado
Mediante el botón de Avanced es posible realizar un filtro cruzado
Utilizaremos el botón de puntos suspensivos de la fila de Test Set
Obteniéndose así el dialogo que permite filtrar por atributos del Test Set con los que están relacionados (esto se realiza así para que solamente se muestren los defectos de los Test Sets de los ciclos que seleccionaremos en un paso posterior)
Cuando se posiciona sobre el campo Test Set Folder aparece una ventana donde seleccionaremos la carpeta a nivel del CLIENTE que incluya todos los Test Set objeto de la prueba de TODOS LOS CICLOS
Se pulsa OK permaneciendo así el valor seleccionado como aparece en la siguiente imagen
Seguidamente se procede a establecer como filtro el estado de las incidencias, solamente mostrando las “Open”, “Reopen”, “Rejected”, “Fixed” e “In Test””.
Se selecciona la pestaña de “Pie Chart”
Se selecciona en el desplegable X-Axis el valor “Categorización”
Se pulsa Refresh obteniendo el gráfico
Esta información debe ser incorporada al actual excel de Cuadro de Mandos (CM) por cada responsable de la aplicación
3.1.10.3Seguimiento de las pruebas
Como primer paso se establecen como visibles las columnas que se desea incluir en el informe (no se muestra el campo ciclo para evitar confusión a Laboratorio puesto que el valor contenido es el ciclo de apertura de la incidencia)
Se selecciona el módulo de Incidents donde se procederá a establecer un filtro para mostrar exclusivamente las incidencias a reportar a Laboratorio
Mediante el botón
se obtiene el dialogo
Mediante el botón de Avanced es posible realizar un filtro cruzado
Utilizaremos el botón de puntos suspensivos de la fila de Test Set
Obteniéndose así el dialogo que permite filtrar por atributos del Test Set con los que están relacionados (esto se realiza así para que solamente se muestren los defectos de los Test Sets de los ciclos que seleccionaremos en un paso posterior)
Cuando se selecciona el campo Test Set Folder y se pulsa el botón de
Aparece una ventana donde seleccionaremos la carpeta que incluya todos los Test Set objeto de la prueba (es posible que para seleccionar todas las pruebas sea necesario incluir más de una ruta utilizando el operador lógico OR. Esto se daría si se realizan pruebas simultáneas entre distintos grupos de prueba)
Se pulsa OK permaneciendo así el valor seleccionado como aparece en la siguiente imagen
Se pulsa OK para aplicar el filtro
Se pasa a continuación a ocultar las incidencias que no se encuentren abiertas. En la cabecera del listado, en el campo Estado se debe escribir “Open OR Reopen”
Ya se dispone de la información que se desea exportar. Mediante el botón derecho y seleccionado la opción de “Export” “All”
Se introduce el nombre del documento y se selecciona como tipo HTML (posteriormente de debe abrir con el Excel y guardar como xls). También se puede guardar como Excel (xls) y posteriormente maquetar el archivo resultante
NOTA: Se puede guardar la configuración de campos y filtro utilizando el menú Favorites Add to favorites
Obteniendo el siguiente formulario en el que se introduce el nombre que se desee
Una vez pulsado el OK estará disponible en el desplegable de la barra superior
3.1.11Notificación de incidencias
Cuando finaliza la jornada de pruebas se procederá a notificar la situación mediante un cuadro de mandos generado con los datos extraídos de Mercury. Junto al CM se hará llegar el filtro que se debe aplicar en Mercury para acceder a las incidencias relacionadas con la prueba.
La apertura / reapertura de incidencias se comunica al resolutor en el momento (correo automático de Mercury) y están disponibles para consulta en la herramienta.
Cambios de estado de las incidencias provocan un correo automático de Mercury dirigido al resolutor o registrador:
Correos al Resolutor en los casos:
- La incidencia pasa a estado Open o Reopen
- La incidencia pasa a estado Closed
- La incidencia pase a estado AWAIT INFORMATION
- La incidencia pase a estado REJECTED
3.2Ciclo enésimo de pruebas
3.2.1Flujo ciclo enésimo
3.2.2Preparación del Test Set (NO APLICA PARA USUARIOS DE FACTORÍA)
3.2.2.1Nuevo ciclo con alcance distinto de los previos
Cuando se aborda un ciclo de pruebas cuyo alcance difiere demasiado de ciclos ejecutados con anterioridad (y por tanto no procede el copiar otro ciclo), se deberá proceder como si se tratase del primer ciclo de pruebas, es decir, decidir la estructura de carpetas que se estime más apropiada para recoger las baterías de pruebas.
3.2.2.1.1Estructura de carpetas en el Test Lab
Normalmente, está estructura estará versada en la ya generada para el Plan de Pruebas. El árbol de directorios que se defina para acoger las baterías de pruebas debe partir de la ruta:
El árbol de directorios que se defina para acoger las baterías de pruebas debe partir de la ruta:
GRUPO PROPIETARIO DE LOS TESTSETS\CANAL\APLICACIÓN Y/O PAQUETE FUNCIONAL\VERSIÓN/RELEASE PDP\TIPO DE PRUEBA\REQUERIMIENTO ORIGEN\VERSIÓN ENTREGA SW\CLIENTE\CICLO DE PRUEBAS - EXPEDIENTE
La carpeta grupo propietario de los Test Sets podrá ser:
- La de QA_INTERNO: solo accesible por los usuarios del propio
grupo
- La de LABORATORIO: accesible para los usuarios de laboratorio
y los de QA Interno
- La de FACTORÍA_XXX: accesible para los usuarios de la propia
factoría y los pertenecientes a QA_Interno
Canal: Alguno de los definidos como canal marco. Por ejemplo:- Oficina
- Internet
- CIC
- Movilidad
- P. Integración
- P. Sistema
3.2.2.1.2Creación de Baterías
Una vez establecido el árbol de carpetas, se pasará a crear las baterías mediante el botón “New Test Set”
Se muestra la pantalla de petición de nombre y descripción de la batería
Una vez pulsado el “OK”, se solicitan los datos obligatorios del Test Set
Se cumplimentarán todos los campos obligatorios
Nota:
Muchos de los nombre empleados en al estructura de carpetas tienen también reflejo en campos de la bateríaEl campo “Ciclo Prueba” debe recoger un valor numérico. Este número debe ser único en todas las ejecuciones relacionadas con un Ciclo de Pruebas, independientemente de que todas las pruebas las realice QA Interno o Factoría, o entre ambos (en este caso el campo Ciclo Prueba tendrá el mismo valor en ambos.El campo “Entrega SW” tendrá un valor único en todas las pruebas relacionadas con una determinada tarea (Gap, envío a cliente, etc.), en todos los ciclos. El valor que se desea seleccionar debió ser solicitado previamente para que aparezca en el desplegable.
Estos datos del Test Set son almacenados dentro de la pestaña de “Test Set Properties” en el enlace de “Details”
******************Pending to complete this document***************************** - por la categorización que estableceríamos a la nueva
incidencia
No hay comentarios:
Publicar un comentario