Copyright © 2025. UPEX Quality LLC. TODOS LOS DERECHOS RESERVADOS.
RETESTING (RTX) PASO A PASO con XRAY
ANTES DEL RE-TESTING
Después de Reportar un BUG o DEFECT,
Dicha incidencia creada debe estar TRANSITADA y ASIGNADA al Dev responsable del Triage.
Véase en la imagen el ejemplo de cómo queda (suponiendo que Yo soy Dev también)
Nota: Normalmente luego de reportar una incidencia, se le asigna a un Lead (puede ser al QA Lead o al Tech Lead del componente correspondiente afectado), cuya persona será encargada del hacer el “Triage” de la incidencia reportada.
(Véase el video de Bug Life Cycle en Youtube en el siguiente link para saber qué es Triage)
https://youtu.be/6T9r21zpgfMNota 2: Si ya conoces por experiencia quién es el responsable de dicha incidencia, asigna el bug a tal persona.
Cuando el Dev responsable realiza el Fix del BUG o DEFECT reportado,
Procede a notificar al Tester reportador (y si existe una TRANSICIÓN de la incidencia, lo cambia de estado a “Fixed” o “Resolved” o “Retest”, dependiendo de cómo se maneje el proyecto).
Cuando el Tester reportador es notificado y tiene el BUG o DEFECT reportado asignado al mismo,
Debe proceder con el RE-TESTING de tal funcionalidad fixeada.
Ahora se visualiza así la incidencia (supongamos que yo, Elyer, también soy el Tester reportador jaja)
EN EL RE-TESTING de un DEFECTO (PASO A PASO)
Crea una tarea para el RE-TEST EXECUTION.
En Jira, haz click aquí (Subtask) para crear tareas autolinkeadas a la incidencia:
Selecciona “Re-Test Execution” como opción de tarea:
Crea la Tarea agregando un nombre a la tarea primero,
Cumpliendo con buenas prácticas, intenta nombrarlo así:
RTX | <Nombre del Bug>
Ejemplo:
Después de crear la Tarea RTX,
Lo primero es ESTIMAR y LOGUEAR las horas de Trabajo a realizar con esta tarea (tal como se hace en el resto de tareas asignadas):
NOTA: Recuerda estar asignado al RTX si eres tú el que va a retestearlo. También completar los campos que sean importantes como el Componente y Etiquetas, pero ésto último no es obligatorio en todos los proyectos; depende.
ASOCIAR UN TC A LA INCIDENCIA (Hay dos formas):
SI la incidencia reportada FUESE un BUG,
Entonces NO tiene un TEST CASE (TC) asociado (porque se descubrió el BUG por testing exploratorio)
En este caso:
DEBES CREAR UN NUEVO TEST CASE PARA EL BUG:COMO BUENA PRÁCTICA,
Puedes copiar y pegar el MISMO TÍTULO DEL BUG REPORTADO y agregarle el ID del BUG:También NO olvides tener buena Trazabilidad y seguimiento del Bug rellenando estos campos:
Así se visualizará en el RTX una vez creado el TC asociado:
DENTRO DEL TC asociado, AHORA, Y MÁS IMPORTANTE,
DEBES COLOCAR LOS MISMOS REPRO STEPS DEL BUG.
(Recuerda: esto pasa cuando reportamos un BUG que no tiene TC asociado)
Ejemplo:
SI la incidencia reportada FUESE un DEFECTO (como lo es en la incidencia reportada),
Entonces YA HAY y EXISTE el SET DE PRUEBAS asociados (porque se descubrió el DEFECTO por Testing de Historia de Usuario)En este caso:
DEBES ASOCIAR EL TEST CASE QUE CREÓ EL DEFECTO (O LOS TEST CASES si son varios):Como recomendación para ENCONTRAR las incidencias relacionadas a una US,
BUSCA POR ID DE LA HISTORIA DE USUARIO:Así se visualizará en el RTX con los TCS seleccionados y asociados:
—PARA UN DEFECT: ES IMPORTANTE SOBREESCRIBIR LA PREVIA EJECUCIÓN DE PRUEBAS—
(Esto ocurre solo cuando se reporta un DEFECT, como en este caso, el cual se asocia a una US)SE DEBE CONFIGURAR EL AMBIENTE DE PRUEBAS IGUAL A LA US afectada!
Rellenar la siguiente información dentro de la incidencia RTX:
Ahora que tiene la configuración igual a la PRIMERA EJECUCIÓN (la que falló), se podrá sobreescribir el resultado final y actualizarse en la US que el Defecto ataca.
—LUEGO DE ASOCIAR EL TC PARA HACER EL RE-TESTING— (Ya sea del BUG o del DEFECTO)
SE PROCEDE CON LA EJECUCIÓN
(igual de normal como cualquier otra siguiendo los stepsdel TC)Puedes abrir el Test Runner haciendo click en:
Como bien se sabe, se puede ejecutar un Test Run por:
OR: una APP de Ejecución
→ para más info véas: https://upexdocu.atlassian.net/wiki/spaces/UPEX/pages/361550OR: el mismo Test Runner marcando las casillas de estados del Test (como en la img).
DESPUÉS del RE-TESTING de un DEFECTO (PASO A PASO)
DESPUÉS DE LA EJECUCIÓN, EN CASO DE:
TODOS LOS STEPS de los TC asociados al RTX, PASARON LAS PRUEBAS (PASS).
SI SE TRATA DE UN DEFECTO:
Automáticamente se actualizará en la US asociada.
Se deberá TRANSITAR el Defecto al estado CLOSED, e informar al Dev responsable.
SI SE TRATA DE UN BUG:
Simplemente se deberá TRANSITAR el BUG al estado CLOSED, e informar al Dev responsable.
MÍNIMO 1 STEP de TC asociado al RTX, NO PASÓ LAS PRUEBAS (FAIL).
SI SE TRATA DE UN DEFECTO:
Automáticamente se actualizará en la US asociada.
Se deberá TRANSITAR el Defecto al estado OPEN, e informar al Dev responsable.
SI SE TRATA DE UN BUG:
Simplemente se deberá TRANSITAR el BUG al estado OPEN, e informar al Dev responsable.
Así se visualiza en la incidencia reportada para realizar la transición según el status mencionado:
OJO: TRANSITA el RTX al estado CLOSED si todo salió bien, y CARGA el tiempo de la tarea:
(Así se cumple con un buen seguimiento de la actividad)Así debe estar la incidencia reportada (ejemplo en esta caso):
EN CASO DE UN DEFECTO,
SI LA “COBERTURA DE PRUEBAS” EN LA “US” NO SE ACTUALIZA (Sobreescribirse).
CHEQUEAR BIEN LA CONFIGURACIÓN DEL “Analysis & Scope”.ASÍ SE VISUALIZABA ANTES LA “COBERTURA DE PRUEBAS”:
ACTUALIZA BIEN LA CONFIGURACIÓN DEL “Analysis & Scope”.
Ésta debe coincidir con el TX y ahora con el RTX para que la ejecución se haya dado en la misma línea de Ambiente (Esto es simplemente para poder hacer múltiples Coberturas en diferentes Ambientes):Ahora la “COBERTURA DE PRUEBAS” se visualiza actualizado correctamente:
(Esto se realiza en dado caso no se actualiza por sí solo)
✅ LISTO!! RE-TESTING COMPLETADO!