Veja primeiro
O que é preciso
- Azure DevOps Services: um endereço como
dev.azure.com/yourcompany. (O Azure DevOps Server nos seus próprios servidores não é suportado.) - Uma conta que possa criar work items no projeto para onde os bugs devem ir.
- Direitos de administrador no seu workspace do UAT Studio.
Conecte o seu projeto Azure DevOps
Encontre a sua organization, o projeto e o processo
Abra o seu projeto no Azure DevOps e veja a barra de endereço: dev.azure.com/acme/Customer Portal. A primeira parte é a organization (acme), a segunda o projeto (Customer Portal), exatamente como aí está escrito, incluindo espaços.
Depois verifique o processo do projeto: Project settings › Overview › Process.
| Processo | Tipo de work item a usar |
|---|---|
| Agile, Scrum ou CMMI | Bug: com Repro Steps, Severity, Priority e tags. |
| Basic | Issue: o Basic não tem o tipo Bug. O work item recebe o título e a descrição; o Basic não tem campos para gravidade e prioridade. |
Crie um personal access token
- No Azure DevOps, clique no ícone User settings no canto superior direito (a pessoa com uma engrenagem, junto às suas iniciais) e escolha Personal access tokens.
- Clique em + New Token.
- Name: UAT Studio. Organization: a sua organization. Expiration: escolha Custom defined, até um ano.
- Scopes: escolha Custom defined e marque Work Items › Read & write. Para ler também casos de teste do Test Plans, marque ainda Test Management › Read.
- Clique em Create e copie o token. O Azure DevOps só o mostra uma vez: mantenha a janela aberta até o ter colado no passo 4.
Adicione o Azure DevOps no UAT Studio
Entre em app.uat.studio, abra o seu workspace e clique em Connections. Em Add a connection, escolha Azure DevOps e clique em Add.
| Campo | O que preencher |
|---|---|
| Name | O texto do botão: Send to Azure DevOps. Altere-o se conectar mais de um projeto. |
| Organization | A parte depois de dev.azure.com/, como acme. |
| Project | O nome do projeto exatamente como no Azure DevOps, como Customer Portal. |
| Work item type | Bug, ou Issue num projeto Basic (ver passo 1). |
| Area path | Opcional: para onde vão os work items, como Customer Portal\UAT. Vazio: a área predefinida do projeto. |
Clique em Save settings.
Guarde o token
Cole o token do passo 2 no campo Personal access token e clique em Store token. O campo passa a mostrar apenas os últimos 4 caracteres.
Teste a integração
Clique em Test connection. O UAT Studio verifica o token, o projeto e se o tipo de work item existe. Se estiver tudo bem, vê Connected to project … in …; work items of type Bug can be created e OK junto ao último teste. Se o tipo não existir, a mensagem indica os tipos que o projeto tem.
Enviar ocorrências para o Azure DevOps
Uma ocorrência
Abra a ocorrência. Em Ticket in the development team's system, clique em Send to Azure DevOps.
O número do work item e um link aparecem na ocorrência, e o histórico mostra quando foi enviada e por quem. Uma ocorrência já associada não pode ser enviada duas vezes por engano.
Todas as ocorrências depois da reunião de triagem
Em Issues › Triage, tome uma decisão para cada nova ocorrência. No fim, clique em Send 3 to Azure DevOps (ou o número que houver) para criar todos os work items de uma vez.
O que contém o work item
- Título: o número e o título da ocorrência, como ISS-012: Quote PDF shows the wrong VAT rate.
- Repro Steps e Description: o que o tester escreveu, o caso de teste com o passo que falhou e o resultado esperado, e quem a encontrou, com um link de volta para o UAT Studio.
- Severity, Priority e as tags
UATe o número da ocorrência (não num projeto Basic). - Attachments: os screenshots e arquivos da ocorrência, até 10 arquivos de no máximo 10 MB cada.
Fundir duplicados
Quando funde duas ocorrências que têm ambas um work item, o work item duplicado recebe um comentário, o link Duplicate Of para o outro, e é fechado (Closed, Done ou Resolved, conforme o processo permitir). Quando só a duplicada tinha work item, a ocorrência que fica assume-o.
Quando a correção está feita no Azure DevOps
Quando o programador põe o work item em Resolved, Done ou Closed, a ocorrência no UAT Studio passa a Ready for retest e o tester recebe um email. Active, Committed ou Doing põem a ocorrência em In progress. O estado no Azure DevOps aparece junto ao link.
Um reteste falhado nunca é desfeito: quando o tester reabre a ocorrência enquanto o work item ainda está Resolved, o UAT Studio mantém a ocorrência aberta. Uma ocorrência fechada continua fechada.
Automaticamente, ou de imediato
Sem fazer nada, o UAT Studio consulta o estado sempre que um administrador abre as ocorrências, e com o botão Update ticket status.
De imediato: deixe o Azure DevOps avisar o UAT Studio quando um work item muda, com um service hook. Tem de ser administrador do projeto no Azure DevOps.
- No UAT Studio, em Connections, na integração com o Azure DevOps, clique em Create webhook address e copie o endereço. Só é mostrado uma vez.
- No Azure DevOps, abra o projeto e vá a Project settings › Service hooks. Clique em Create subscription.
- Desça na lista de serviços, escolha Web Hooks e clique em Next.
- Trigger on this type of event: Work item updated. Em Filters, defina Field como State, para que só sejam enviadas mudanças de estado. Area path e Work item type podem ficar em [Any], ou restrinja-os à área e ao tipo do seu projeto. Clique em Next.
- URL: cole o endereço do passo 1. Deixe os outros campos (username, password, headers) vazios. Clique em Test para verificar e depois em Finish.
Quem pode fazer o quê
Se algo falhar
| Vê | O que fazer |
|---|---|
| O token é recusado, ou não tem acesso a esta organization | Verifique o nome da organization (a parte depois de dev.azure.com/), se o token foi criado para essa organization e se tem o scope Work Items (Read & write). Ou crie um novo token e guarde-o de novo. |
| O projeto não tem o tipo de work item "Bug" | O projeto provavelmente usa o processo Basic: preencha Issue em Work item type. A mensagem indica os tipos existentes. |
| Não encontrado (404) | Verifique o nome do projeto: exatamente como na barra de endereço, incluindo espaços. |
| Antes funcionava, agora não | O token provavelmente expirou ou foi revogado. Crie um novo e guarde-o; o resto fica como está. |
| O estado não regressa | Abra as ocorrências como administrador, ou clique em Update ticket status. Com um service hook: no Azure DevOps, Project settings › Service hooks mostra se foi executado e o que voltou; em Connections no UAT Studio vê quando chegou a última mensagem. |
| Sem botão Send to Azure DevOps | Só os administradores o veem, e apenas quando a integração está On e tem um token guardado. |
| As integrações não fazem parte do seu plano | As integrações estão incluídas no Team, Business, Partner e Enterprise, e como módulo para o Project. O seu administrador pode mudar de plano em Plan & billing. |
Continua com dificuldades? Escreva para [email protected] com a mensagem que vê. Nunca nos envie o próprio token.
Usa o Jira? Veja Conectar o UAT Studio ao Jira. Todos os guias: Ajuda do UAT Studio.
Como tratamos o seu token
- O token vai do seu navegador para o nosso servidor uma única vez, por um canal cifrado.
- É guardado cifrado (AES-256). A chave para o decifrar fica separada da base de dados, por isso uma cópia da base de dados, sozinha, não serve para nada.
- Ninguém pode voltar a ler o token: nem na app, nem através do suporte.
- O UAT Studio usa o token apenas para testar a integração, criar os work items que envia (com os seus arquivos), ler o estado desses work items e fechar um duplicado depois de uma fusão. Só precisa do scope Work Items.
- Remova a integração ou revogue o token no Azure DevOps, e o acesso termina de imediato.