Míralo primero
Lo que necesitas
- Azure DevOps Services: una dirección como
dev.azure.com/tuempresa. (Azure DevOps Server en tus propios servidores no es compatible.) - Una cuenta que pueda crear work items en el proyecto al que deben ir los bugs.
- Derechos de administrador en tu espacio de trabajo de UAT Studio.
Conecta tu proyecto de Azure DevOps
Busca tu organización, proyecto y proceso
Abre tu proyecto en Azure DevOps y mira la barra de direcciones: dev.azure.com/acme/Customer Portal. La primera parte es la organización (acme), la segunda el proyecto (Customer Portal), exactamente como aparece ahí, con los espacios.
Después comprueba el proceso del proyecto: Project settings › Overview › Process.
| Proceso | Tipo de work item que usar |
|---|---|
| Agile, Scrum o CMMI | Bug: con Repro Steps, Severity, Priority y etiquetas. |
| Basic | Issue: Basic no tiene el tipo Bug. El work item recibe el título y la descripción; Basic no tiene campos para la gravedad ni la prioridad. |
Crea un personal access token
- En Azure DevOps, haz clic en el icono User settings arriba a la derecha (la figura con un engranaje, junto a tus iniciales) y elige Personal access tokens.
- Haz clic en + New Token.
- Name: UAT Studio. Organization: tu organización. Expiration: elige Custom defined, hasta un año.
- Scopes: elige Custom defined y marca Work Items › Read & write. Para leer también casos de prueba de Test Plans, marca además Test Management › Read.
- Haz clic en Create y copia el token. Azure DevOps solo lo muestra una vez: deja la ventana abierta hasta que lo hayas pegado en el paso 4.
Añade Azure DevOps en UAT Studio
Inicia sesión en app.uat.studio, abre tu espacio de trabajo y haz clic en Connections. En Add a connection, elige Azure DevOps y haz clic en Add.
| Campo | Qué rellenar |
|---|---|
| Name | El texto del botón: Send to Azure DevOps. Cámbialo si conectas más de un proyecto. |
| Organization | La parte que va después de dev.azure.com/, como acme. |
| Project | El nombre del proyecto exactamente como en Azure DevOps, como Customer Portal. |
| Work item type | Bug, o Issue en un proyecto Basic (consulta el paso 1). |
| Area path | Opcional: adónde van los work items, como Customer Portal\UAT. Vacío: el área predeterminada del proyecto. |
Haz clic en Save settings.
Guarda el token
Pega el token del paso 2 en el campo Personal access token y haz clic en Store token. Después el campo solo muestra los 4 últimos caracteres.
Prueba la conexión
Haz clic en Test connection. UAT Studio comprueba el token, el proyecto y que el tipo de work item existe. Si todo va bien, ves Connected to project … in …; work items of type Bug can be created, y OK junto a la última prueba. Si el tipo no existe, el mensaje enumera los tipos que tiene el proyecto.
Enviar incidencias a Azure DevOps
Una incidencia
Abre la incidencia. En Ticket in the development team's system, haz clic en Send to Azure DevOps.
El número del work item y un enlace aparecen en la incidencia, y su historial muestra cuándo se envió y quién lo hizo. Una incidencia ya vinculada no se puede enviar dos veces por error.
Todas las incidencias después del triaje
En Issues › Triage, toma una decisión sobre cada incidencia nueva. Cuando termines, haz clic en Send 3 to Azure DevOps (o las que sean) para crear todos los work items de una vez.
Qué contiene el work item
- Título: el número y el título de la incidencia, como ISS-012: Quote PDF shows the wrong VAT rate.
- Repro Steps y Description: lo que escribió el tester, el caso de prueba con el paso que falló y el resultado esperado, y quién la encontró, con un enlace de vuelta a UAT Studio.
- Severity, Priority y las etiquetas
UATy el número de incidencia (no en un proyecto Basic). - Attachments: las capturas de pantalla y los archivos de la incidencia, hasta 10 archivos de 10 MB como máximo cada uno.
Fusionar duplicados
Cuando fusionas dos incidencias que tienen work item, el work item duplicado recibe un comentario, el vínculo Duplicate Of con el otro y se cierra (Closed, Done o Resolved, según lo que permita el proceso). Si solo el duplicado tenía work item, la incidencia que se queda lo hereda.
Cuando la corrección está lista en Azure DevOps
Cuando el desarrollador pasa el work item a Resolved, Done o Closed, la incidencia en UAT Studio pasa a Ready for retest y el tester recibe un correo. Active, Committed o Doing pasan la incidencia a In progress. El estado en Azure DevOps se muestra junto al enlace.
Una nueva prueba fallida nunca se deshace: si el tester reabre la incidencia mientras el work item sigue en Resolved, UAT Studio la deja abierta. Una incidencia cerrada sigue cerrada.
Solo, o al instante
Sin hacer nada, UAT Studio consulta el estado cada vez que un administrador abre las incidencias, y con el botón Update ticket status.
Al instante: deja que Azure DevOps avise a UAT Studio cuando cambia un work item, con un service hook. Necesitas ser administrador del proyecto en Azure DevOps.
- En UAT Studio, en Connections, dentro de la conexión con Azure DevOps, haz clic en Create webhook address y copia la dirección. Solo se muestra una vez.
- En Azure DevOps, abre el proyecto y ve a Project settings › Service hooks. Haz clic en Create subscription.
- Desplázate por la lista de servicios, elige Web Hooks y haz clic en Next.
- Trigger on this type of event: Work item updated. En Filters, pon Field en State, para que solo se envíen los cambios de estado. Area path y Work item type pueden quedarse en [Any], o limitarse al área y el tipo de tu proyecto. Haz clic en Next.
- URL: pega la dirección del paso 1. Deja vacíos los demás campos (usuario, contraseña, cabeceras). Haz clic en Test para comprobarlo y después en Finish.
Quién puede hacer qué
Si algo sale mal
| Ves | Qué hacer |
|---|---|
| No se acepta el token, o no tiene acceso a esta organización | Comprueba el nombre de la organización (la parte que va después de dev.azure.com/), que el token se creó para esa organización y que tiene el scope Work Items (Read & write). O crea un token nuevo y guárdalo otra vez. |
| El proyecto no tiene el tipo de work item "Bug" | Probablemente el proyecto usa el proceso Basic: rellena Issue en Work item type. El mensaje enumera los tipos que hay. |
| No encontrado (404) | Comprueba el nombre del proyecto: exactamente como en la barra de direcciones, con los espacios. |
| Antes funcionaba, ahora no | Probablemente el token ha caducado o se ha revocado. Crea uno nuevo y guárdalo; lo demás sigue igual. |
| El estado no vuelve | Abre las incidencias como administrador o haz clic en Update ticket status. Con un service hook: en Azure DevOps, Project settings › Service hooks muestra si se ejecutó y qué devolvió; en Connections de UAT Studio ves cuándo llegó el último mensaje. |
| No aparece el botón Send to Azure DevOps | Solo lo ven los administradores, y solo cuando la conexión está en On y tiene un token guardado. |
| Las conexiones no forman parte de tu plan | Las conexiones se incluyen en Team, Business, Partner y Enterprise, y como complemento en Project. Tu administrador puede cambiar de plan en Plan & billing. |
¿Sigues atascado? Escribe a [email protected] con el mensaje que ves. Nunca nos envíes el token.
¿Usas Jira? Consulta Conectar UAT Studio con Jira. Todas las guías: Ayuda de UAT Studio.
Cómo tratamos tu token
- El token va una sola vez de tu navegador a nuestro servidor, por una conexión cifrada.
- Se guarda cifrado (AES-256). La clave para descifrarlo se guarda aparte de la base de datos, así que una copia de la base de datos por sí sola no sirve de nada.
- Nadie puede volver a leer el token: ni en la app ni a través del soporte.
- UAT Studio usa el token solo para probar la conexión, crear los work items que envías (con sus archivos), leer el estado de esos work items y cerrar un duplicado después de una fusión. Solo necesita el scope Work Items.
- Elimina la conexión o revoca el token en Azure DevOps y el acceso termina al instante.