UAT para Dynamics 365: um guia prático

Quando precisa de um UAT no Dynamics 365

Um teste de aceitação responde a uma pergunta: o negócio consegue fazer o seu trabalho nesta versão do Dynamics 365? Quem faz o trabalho testa-o, com as suas próprias palavras, antes de chegar à produção. Precisa de um nestes momentos.

• Um go-live. O primeiro Dynamics 365 Sales ou Customer Service, ou a migração a partir de outro CRM.
• Uma nova aplicação ou um novo módulo. O Customer Service ao lado do Sales, uma nova aplicação baseada em modelo para uma equipa, um portal de clientes, ou funcionalidades do Copilot que ativa.
• Uma grande alteração. Uma nova integração com o ERP, ou uma nova forma de encaminhar casos.
• As atualizações da Microsoft. A Microsoft já não agrupa as alterações do Dynamics 365 em duas ondas de lançamento por ano. Novas funcionalidades e alterações chegam ao longo de todo o ano. Os planos de lançamento foram arquivados em outubro de 2026; o que vem a seguir está agora no roadmap da Microsoft em aka.ms/AIatWorkRoadmap. Qualquer atualização pode mudar o funcionamento do seu sistema, mesmo que não tenha alterado nada.

Um go-live precisa de um UAT completo. As atualizações precisam de um teste de regressão mais curto dos processos mais importantes, a um ritmo fixo. Mais sobre isso em Depois do go-live.

Ambientes

Nunca teste em produção. No centro de administração do Power Platform, cada ambiente tem um tipo. Para um UAT, precisa de uma sandbox.

Uma cópia da produção

O mais próximo da realidade que consegue é uma cópia da produção num ambiente sandbox. Quando copia um ambiente, escolhe o que vem com ele:

• Tudo: as personalizações, o esquema e todos os dados. O mais próximo da produção, mas contém dados reais de clientes e todos os itens que os seus utilizadores criaram.
• Apenas personalizações e esquemas: a configuração sem os dados. Carrega depois os seus próprios dados de teste.

Uma cópia substitui o que está no ambiente de destino, por isso faça-a antes do UAT, nunca durante. Depois, aponte as integrações e os fluxos do Power Automate para sistemas de teste, não para a produção, verifique as caixas de correio, e retire o ambiente do modo de administração quando estiver pronto.

Soluções e a build

As alterações do projeto chegam ao ambiente de UAT como soluções. Importe-as como soluções geridas, através de um pipeline se tiver um, para que o ambiente de UAT receba exatamente o que a produção vai receber mais tarde.

• Acorde quando as soluções são importadas enquanto os testes decorrem, por exemplo uma vez por dia depois da triagem. Uma importação a meio de um teste pode mudar o ecrã debaixo de um tester.
• Anote que soluções e que versões estão no ambiente de UAT. O número de versão de uma solução é a build que testa, e cada ocorrência e cada reteste pertencem a uma.

Dados de teste

Os testers perdem horas quando os dados não estão prontos. Prepare-os antes do primeiro dia de testes:

• Contas e contactos para cada tipo de cliente que testa, com o proprietário e a unidade de negócio certos.
• Produtos e listas de preços. Um produto precisa de um item da lista de preços antes de poder ser adicionado ao preço certo, e tem de ser publicado antes de os comerciais o poderem usar. Verifique se a lista de preços de cada equipa de vendas existe.
• Filas, SLAs e artigos de conhecimento para o Customer Service: as filas para onde os casos são encaminhados, SLAs ativos e artigos publicados para encontrar.
• Itens em aberto para trabalhar: leads, oportunidades em diferentes fases e casos em aberto.
• Sem dados pessoais reais sempre que o possa evitar. Uma cópia com Tudo contém-nos todos, por isso mascare ou anonimize o que os testers não precisam de ver.

Funções de segurança, unidades de negócio e utilizadores por função

Um UAT prova que cada função consegue fazer o seu trabalho, e só o seu trabalho. No Dynamics 365, isso depende das funções de segurança, da unidade de negócio e das equipas de um utilizador. As aplicações também são partilhadas através de funções de segurança: sem a função certa, um utilizador nem sequer vê a aplicação.

• Liste as funções que testa, como um comercial, um diretor comercial, um agente de suporte e um supervisor de suporte, com a sua unidade de negócio.
• Dê a cada tester um utilizador com exatamente essa função no ambiente de UAT. Cada utilizador precisa de uma licença, também numa sandbox.
• Quando uma pessoa testa várias funções, use um utilizador de teste separado por função, ou mude a função entre testes e anote qual foi usada.
• Nunca teste com a função Administrador de Sistema. Vê e pode fazer tudo, por isso esconde exatamente os problemas que um UAT deve encontrar.

O que dizer aos testers sobre o ambiente

• O endereço do ambiente de UAT. O marcador habitual abre a produção.
• Que aplicação abrir, como o Sales Hub ou o Customer Service workspace, e com que conta entrar.
• Que os dados são dados de teste: nada do que fazem chega a um cliente real, e nada do que veem está atualizado.
• A quem ligar quando não conseguem entrar ou não veem a aplicação.

No UAT StudioCada tester recebe um Test role, como a função de segurança, e um Test account, mostrados no topo dos seus testes como Log in as …. As Notes for testers contêm o endereço do ambiente, as caixas de correio de teste e quem contactar. Os testers entram no UAT Studio com um código por email, ou com Sign in with Microsoft.

Casos de teste a partir de user stories e processos

Comece pelos processos do negócio, não pelas tabelas do Dataverse. Dois processos cobrem a maior parte de um UAT de Dynamics 365:

• Do lead à oportunidade e à proposta. Um lead entra e é qualificado numa conta, num contacto e numa oportunidade. A oportunidade segue o fluxo de processo de negócio, recebe produtos da lista de preços, é feita uma proposta, aprovada e ativada, e o negócio é ganho e passa para a equipa ou o sistema seguinte.
• Gestão de casos. Um caso entra por email ou pelo portal, é encaminhado para a fila ou o agente certo, segue o seu SLA, é resolvido com um artigo de conhecimento, escalado quando necessário, e fechado.

Divida cada processo em casos de teste com um cenário de negócio cada, como Qualificar um lead com uma conta existente. Depois verifique se cada user story no âmbito tem pelo menos um caso de teste.

Fluxos de processo de negócio

Um fluxo de processo de negócio guia os utilizadores por fases, com passos que podem ser obrigatórios antes da fase seguinte. Teste-o como um utilizador o faz:

• Cada fase, e o que acontece quando um passo obrigatório está vazio.
• Cada ramo, e cada função: um fluxo pode estar ativado apenas para algumas funções de segurança.

Encaminhamento, SLAs e conhecimento

No Customer Service, grande parte do trabalho acontece sem um clique. Teste o que o sistema deve fazer sozinho: um email torna-se um caso para a conta certa, o caso chega à fila certa, o SLA mostra o tempo certo e avisa antes de expirar, e o agente encontra o artigo de conhecimento certo.

Passos que os testers de negócio entendem

Escreva cada passo como uma ação e um resultado esperado, nas palavras do tester. Acrescente dados de teste quando importa. Um tester nunca deve ter de adivinhar se um passo passou.

Prioridade e risco

Nem todos os casos de teste são igualmente importantes. Marque cada um como Must, Should ou Could: Must é o que tem de funcionar no primeiro dia, como criar uma proposta ou encaminhar um caso. Acrescente o risco: quanto custa se isto falhar depois do go-live. Os testers começam por Must e risco alto, para que os testes importantes fiquem feitos mesmo quando o tempo acaba.

Acrescente também os unhappy paths: um campo obrigatório deixado vazio, um desconto acima do limite, um utilizador de outra unidade de negócio que não deveria ver um item.

No UAT StudioImporte os seus casos de teste do Excel com as colunas Priority e Risk, leia-os do Azure DevOps Test Plans, ou comece pelos scripts de Dynamics 365 da biblioteca de modelos, um módulo para todos os planos pagos. Com AI test design, a IA propõe casos de teste a partir das suas user stories no Azure DevOps, também no modelo da sua própria empresa, como Microsoft Foundry / Azure OpenAI. Nada se torna um caso de teste até o aprovar.

Testers

Escolha pessoas que fazem o trabalho todos os dias: gestores de conta, agentes de suporte, e os seus gestores para aprovações, filas e dashboards. Inclua testers de cada equipa e de cada país que usa o Dynamics 365, porque os seus processos, unidades de negócio e listas de preços são diferentes.

Quanto tempo

Acorde o tempo por tester com o respetivo gestor, e reserve tempo para retestes. Testers que continuam a atender chamadas ou a visitar clientes não vão terminar.

Uma reunião de kick-off

Comece com um kick-off curto: porque é que o teste deles importa, como abrir o ambiente de UAT, como registar um resultado e como registar uma ocorrência. Deixe cada tester entrar uma vez durante o kick-off e abrir a aplicação. A maioria dos problemas com licenças, funções e o ambiente errado aparece aí, não no dia de testes.

Um dia de testes ou uma semana

Um dia de testes dá foco e respostas rápidas, e adequa-se a um âmbito pequeno. Uma semana em blocos de algumas horas deixa espaço para novas builds e retestes, e adequa-se a um go-live com muitos processos. Em qualquer dos casos, marque uma hora para a triagem todos os dias.

Durante o UAT

Abrir ocorrências

Uma boa ocorrência pode ser corrigida sem reunião. Peça aos testers:

• O passo, o que esperavam e o que aconteceu em vez disso.
• Uma captura de ecrã da página, com a mensagem de erro, se houver.
• O link para o item. Está na barra de endereço do navegador e leva o consultor diretamente à oportunidade ou ao caso onde algo falhou.
• O utilizador e a função de segurança com que testaram.

No UAT StudioA extensão do navegador para Chrome e Edge mostra os testes num painel lateral ao lado do Dynamics 365. Um passo falhado leva consigo a captura de ecrã, o link para o item e as mensagens de erro da página. A função do tester aparece ao lado do seu nome na ocorrência.

Triagem

Analise as novas ocorrências todos os dias, com o negócio e a equipa de Dynamics 365 em conjunto. Dê a cada uma uma gravidade e alguém que a corrija, e decida:

• Corrigir: um problema real, corrigido nesta release.
• Rejeitar: o Dynamics 365 funciona como foi concebido, ou o teste estava errado.
• Pedido de alteração: um desejo, não um defeito. Vai para o backlog, não para esta release.

Envie as ocorrências a corrigir aos programadores, muitas vezes no Azure DevOps, com a captura de ecrã e o link para o item.

Reteste

Quando a correção está numa nova build no ambiente de UAT, o tester que encontrou a ocorrência testa o passo de novo. Anote em que build foi feito cada reteste. Depois de uma correção grande, teste também de novo os processos à volta.

Estado diário

Envie todos os dias à direção do projeto um estado curto: o progresso face ao plano, as ocorrências abertas por gravidade, e o que bloqueia. Sem surpresas na reunião de go/no-go.

No UAT StudioA triagem decorre num ecrã partilhado com Fix, Reject e Change request. Uma ocorrência torna-se um work item Bug no Azure DevOps; quando está concluído aí, a ocorrência passa a Ready for retest e o tester recebe um email. Cada ciclo guarda a sua release, build e ambiente. O Microsoft Teams recebe as novas ocorrências, ciclos e sign-offs num canal.

Sign-off e go/no-go

O UAT termina com uma decisão do negócio. Acorde os critérios de saída antes do primeiro dia de testes, para que ninguém discuta sobre eles no fim:

• Nenhuma ocorrência Critical está aberta.
• Todos os casos de teste Must passaram.
• Cada ocorrência High aberta tem uma solução de contorno ou uma data de correção que o negócio aceita.
• Cada caso de teste do âmbito tem um resultado.

Quem assina

O responsável de cada processo faz o sign-off, como o diretor comercial para o processo do lead à proposta e o responsável do apoio ao cliente para a gestão de casos. Escolhem: aceite, aceite com condições, ou rejeitado. Anote cada condição, com quem a cumpre e até quando. A direção do projeto decide então sobre o go-live.

O que entra no relatório

• O que estava no âmbito, e o que não foi testado.
• Os resultados por processo ou equipa, e por prioridade.
• O ambiente, as soluções e a build que foram testados.
• As ocorrências abertas por gravidade, com a decisão sobre cada uma.
• Os sign-offs, com as suas condições, e os riscos conhecidos para as primeiras semanas.

No UAT StudioSign-off por grupo: Accepted, Accepted with conditions ou Rejected. Por defeito, ninguém pode aceitar enquanto houver uma ocorrência Critical aberta. O relatório de go/no-go fica pronto em PDF ou em slides quando chega o último resultado.

Ciclos de regressão a um ritmo fixo

Depois do go-live, as atualizações continuam a chegar, ao longo de todo o ano, e cada uma pode mudar um formulário, um fluxo ou uma permissão. Os seus casos de teste do UAT são o melhor teste de regressão que tem: descrevem exatamente o que o negócio aceitou.

• Escolha um ritmo, por exemplo um ciclo de regressão por mês ou por trimestre, e ponha já as datas no calendário dos testers.
• Antes de cada ciclo, leia o roadmap da Microsoft e as mensagens para os seus administradores, e anote que alterações tocam nos seus processos.
• Experimente primeiro as funcionalidades em pré-visualização ou acesso antecipado num ambiente sandbox, antes de chegarem aos seus utilizadores.
• Teste de novo os casos de teste Must, e Should se houver tempo, com alguns testers do negócio.
• Registe as ocorrências como no UAT, e corrija-as antes de a alteração chegar aos seus utilizadores.

No UAT StudioEscolha Dynamics 365 como CRM do projeto. Start a regression round copia os casos de teste que escolher de um UAT anterior, com os seus passos, dados de teste e resultados esperados: Must and Should, Only Must ou All test cases in scope.

De uso gratuito

Para tudo o que há a preparar antes, durante e depois do UAT, veja a checklist de UAT para um go-live de CRM, também como Excel gratuito. Para o que o UAT Studio faz num UAT de Dynamics 365, veja UAT para Dynamics 365.

Microsoft, Dynamics 365, Power Platform, Azure DevOps e Microsoft Teams são marcas comerciais do grupo de empresas Microsoft. O UAT Studio não está associado à Microsoft nem é endossado por ela.