O que é teste de aceitação do usuário (UAT): um guia completo

Saiba o que é o teste de aceitação do usuário (UAT) , Junto com sua definição, tipos, etapas e exemplos:

Minha regra número um ao tentar entender um novo conceito é que: o nome sempre vai ser relevante e principalmente um significado literal (no contexto técnico).

Descobrir o que é isso dará uma compreensão inicial e me ajudará a começar.

= > Clique aqui para obter a série completa de tutoriais do plano de teste

Deixe-nos colocar este conceito à prova.

= > Leia todos os tutoriais de nossa série de Teste de Aceitação.

O que é Teste de Aceitação do Usuário?

Sabemos o que é teste, aceitação significa aprovação ou acordo. O usuário no contexto de um produto de software é o consumidor do software ou a pessoa que solicitou que fosse construído para ele (cliente).

Então, seguindo minha regra – a definição será :

Teste de aceitação do usuário (UAT), também conhecido como beta ou teste do usuário final, é definido como o teste do software pelo usuário ou cliente para determinar se ele pode ser aceito ou não. Este é o teste final realizado quando os testes funcional, de sistema e de regressão são concluídos.

O objetivo principal deste teste é validar o software em relação aos requisitos de negócios. Essa validação é realizada pelos usuários finais que estão familiarizados com os requisitos do negócio.

Os testes UAT, alfa e beta são tipos diferentes de teste de aceitação.

Como o teste de aceitação do usuário é o último teste realizado antes de o software entrar no ar, obviamente este é o última chance para o cliente testar o software e medir se ele é adequado para a finalidade.

Quando é executado?

Normalmente, essa é a última etapa antes de o produto entrar no ar ou antes que a entrega do produto seja aceita. Isso é realizado depois que o produto em si é completamente testado (ou seja, após o teste do sistema).

Quem realiza UAT?

Usuários ou cliente – pode ser alguém que está comprando um produto ( no caso de software comercial) ou alguém que teve um software customizado por meio de um provedor de serviços de software ou do usuário final, se o software for disponibilizado a eles antes do tempo e quando seu feedback for solicitado.

A equipe pode ser composta por testadores beta ou o cliente deve selecionar membros UAT internamente de cada grupo da organização para que cada função de usuário possa ser testada de acordo.

Necessidade de teste de aceitação do usuário

Desenvolvedores e testadores funcionais são pessoas técnicas que validam o software em relação às especificações funcionais. Eles interpretam os requisitos de acordo com seu conhecimento e desenvolvem / testam o software (aqui está a importância do conhecimento do domínio).

Este software é completo de acordo com as especificações funcionais, mas existem alguns requisitos e processos de negócios que são conhecidos apenas pelos usuários finais, não conseguem se comunicar ou são mal interpretados.

Esse teste desempenha um papel importante na validação se todos os requisitos de negócios são atendidos ou não antes de liberar o software para uso no mercado. O uso de dados ativos e casos de uso reais tornam esse teste uma parte importante do ciclo de lançamento.

Muitas empresas que sofreram grandes perdas devido a problemas de pós-lançamento sabem da importância de um Teste de Aceitação do Usuário bem-sucedido. O custo de consertar os defeitos após o lançamento é muitas vezes maior do que consertá-lo antes.

O UAT é realmente necessário?

Depois de realizar vários testes de sistema, integração e regressão, seria de se perguntar a necessidade deste teste. Na verdade, esta é a fase mais importante do projeto, pois é o momento em que os usuários que realmente vão usar o sistema validariam o sistema para sua adequação.

UAT é um teste fase que depende muito da perspectiva dos usuários finais e do conhecimento do domínio de um departamento que os representa.

Na verdade, seria realmente útil para as equipes de negócios, se eles estiveram envolvidos no projeto muito cedo, para que pudessem fornecer suas opiniões e contribuições que ajudariam no uso eficaz do sistema no mundo real.

Processo de teste de aceitação do usuário

O A maneira mais fácil de entender este processo é pensar nisso como um projeto de teste autônomo – o que significa que terá as fases de planejamento, design e execução.

A seguir estão os pré-requisitos antes da fase de planejamento começa:

# 1) Reúna os principais critérios de aceitação

Em termos simples, os critérios de aceitação são uma lista destes ngs que serão avaliados antes de aceitar o produto.

Estes podem ser de 2 tipos:

(i) Funcionalidade do aplicativo ou relacionado ao negócio

Idealmente, todas as principais funcionalidades do negócio devem ser validadas, mas devido a várias razões, incluindo o tempo, não é prático fazer tudo. Portanto, uma reunião ou duas com o cliente ou os usuários que estarão envolvidos neste teste podem nos dar uma ideia de quanto teste estará envolvido e quais aspectos serão testados.

(ii) Contratual – Não vamos entrar nisso e o envolvimento da equipe de QA em tudo isso é quase nada. O contrato inicial que é elaborado antes mesmo do SDLC começar é revisado e um acordo é alcançado sobre se todos os aspectos do contrato foram entregues ou não.

Vamos nos concentrar apenas na funcionalidade do aplicativo .

# 2) Defina o escopo do envolvimento de QA.

A função da equipe de controle de qualidade é uma das seguintes:

(i) Sem envolvimento – isso é muito raro.

(ii) Auxiliar neste teste – a maioria comum. Nesse caso, nosso envolvimento poderia ser treinar os usuários do UAT sobre como usar o aplicativo e ficar em espera durante esse teste para ter certeza de que podemos ajudar os usuários em caso de alguma dificuldade. Ou, em alguns casos, além de estar em espera e ajudar, podemos compartilhar suas respostas e registrar os resultados ou registrar bugs etc., enquanto os usuários realizam o teste real.

(iii) Realizar UAT e Apresentar Resultados – Se for o caso, os usuários apontarão as áreas do AUT que desejam avaliar e a avaliação em si é realizada pela equipe de QA. Feito isso, os resultados são apresentados aos clientes / usuários e eles vão decidir se os resultados que têm em mãos são suficientes ou não e de acordo com suas expectativas para aceitar o AUT. A decisão nunca é da equipe de QA.

Dependendo do caso em questão, decidimos qual abordagem é a melhor.

Os principais objetivos e expectativas:

Normalmente, o UAT é realizado por um Especialista no Assunto (SME) e / ou um usuário comercial, que pode ser o proprietário ou o cliente de um sistema em teste. Semelhante à fase de teste do sistema, a fase do UAT também abrange fases religiosas antes de ser encerrada.

As principais atividades de cada fase do UAT são definidas a seguir:

Governança do UAT

Semelhante ao teste do sistema, a governança eficaz é aplicada ao UAT para garantir que os portões de alta qualidade, juntamente com os critérios de entrada e saída definidos (fornecidos abaixo **).

** Observe que é apenas uma orientação. Isso pode ser modificado com base nas necessidades e requisitos do projeto.

UAT Test Planning

O processo é quase o mesmo que o plano de teste regular na fase do sistema.

A abordagem mais comum seguida na maioria dos projetos é planejar as fases de teste do sistema e do UAT juntas. Para obter mais informações sobre o plano de teste do UAT junto com um exemplo, verifique as seções do UAT do documento do plano de teste em anexo.

Plano de teste de aceitação do usuário

(é o mesmo que você faria encontre em nosso site a série de treinamento de controle de qualidade também).

Clique na imagem abaixo e role para baixo para encontrar o exemplo de documento do plano de teste em vários formatos. Nesse modelo, verifique a seção UAT.

As datas, ambiente, atores (quem), protocolos de comunicação, funções e responsabilidades, modelos, resultados e seu processo de análise, critérios de entrada-saída – todos isso e tudo o mais que for relevante será encontrado no plano de teste do UAT.

Esteja a equipe de QA participando, parcialmente ou não participando deste teste, é nosso trabalho planejar esta fase e certifique-se de que tudo seja levado em consideração.

= > Aqui está um documento de amostra do plano de teste de aceitação do usuário

Design do teste de aceitação do usuário

Os critérios de aceitação coletados dos usuários são usados nesta etapa. As amostras podem ter a seguinte aparência.

(Esses são trechos do CSTE CBOK. Esta é uma das melhores referências disponíveis sobre este teste.)

Modelo de teste de aceitação do usuário:

Com base nos critérios, nós (equipe de QA) fornecemos aos usuários uma lista de casos de teste do UAT. Esses casos de teste não são diferentes de nossos casos de teste regulares do sistema. Eles são apenas um subconjunto, pois testamos todos os aplicativos em oposição, apenas às principais áreas funcionais.

Além desses, os dados, modelos para registrar resultados de teste, procedimentos administrativos, mecanismo de registro de defeitos, etc., deve ser implementado antes de passarmos para a próxima fase.

Execução do teste

Normalmente, quando possível, esse teste acontece em uma conferência ou sala de guerra, configurar onde os usuários, PM, representantes da equipe de QA todos se sentam juntos por um ou dois dias e trabalham em todos os casos de teste de aceitação.

Ou no caso da equipe de QA realizando os testes, nós executamos o teste casos no AUT.

Assim que todos os testes forem executados e os resultados em mãos, a Decisão de Aceitação é feita. Isso também é chamado de decisão Go / No-Go. Se os usuários estiverem satisfeitos, é um Go ou então é um No-go.

Alcançar a decisão de aceitação é normalmente o fim desta fase.

Ferramentas & Metodologias

Normalmente, o tipo de ferramentas de software usadas durante esta fase de teste é semelhante às ferramentas usadas durante a execução de testes funcionais.

Ferramentas:

Como esta fase envolve a validação de todos os fluxos de ponta a ponta do aplicativo, pode ser difícil ter uma ferramenta para automatizar essa validação completamente. No entanto, até certo ponto, poderíamos alavancar os scripts automatizados desenvolvidos durante o teste do sistema.

Semelhante ao teste do sistema, os usuários também usariam o gerenciamento de teste e ferramentas de gerenciamento de defeitos como QC, JIRA, etc. ferramentas podem ser configuradas para acumular dados para a fase de aceitação do usuário.

Metodologias:

Embora as metodologias convencionais, como usuários de negócios específicos realizando UAT do produto, ainda sejam relevantes, de uma forma verdadeiramente global Em todo o mundo como hoje, o Teste de Aceitação do Usuário às vezes precisa envolver diversos clientes em vários países com base no produto.

Por exemplo, um site de comércio eletrônico seria usado por clientes em todo o mundo. Em cenários como este, o crowd test seria a melhor opção viável.

O crowd test é uma metodologia onde pessoas de todo o mundo podem participar e validar o uso do produto e dar sugestões e recomendações.

Plataformas de Crowd testing são construídas e estão sendo usadas por muitas organizações agora. Um site ou produto que precisa ser testado coletivamente é hospedado na plataforma e os clientes podem se inscrever para fazer a validação. Os feedbacks fornecidos são então analisados e priorizados.

A metodologia de Crowd Testing está provando ser mais eficaz, pois o pulso do cliente em todo o mundo pode ser facilmente compreendido.

UAT em ambiente ágil

O ambiente ágil é mais dinâmico por natureza. Em um mundo ágil, os usuários de negócios estarão envolvidos em todos os sprints do projeto e o projeto seria aprimorado com base nos ciclos de feedback deles.

No início do projeto, os usuários de negócios seriam os principais interessados para fornecer requisitos, atualizando assim o backlog do produto. Durante o final de cada sprint, os usuários de negócios participariam da demonstração do sprint e estariam disponíveis para fornecer qualquer feedback.

Além disso, uma fase de UAT seria planejada antes da conclusão do sprint, onde os usuários de negócios fariam suas validações.

Os feedbacks que são recebidos durante o sprint demo e o UAT do sprint, são agrupados e adicionados de volta ao backlog do produto, que é constantemente revisado e priorizado. Assim, em um mundo ágil, os usuários de negócios estão mais próximos do projeto e avaliam o mesmo quanto ao seu uso com mais frequência, ao contrário dos projetos tradicionais em cascata.

Equipe UAT – Funções & Responsabilidades

Uma organização UAT típica teria as seguintes funções e responsabilidades. A equipe UAT seria apoiada pelo gerente de projeto, equipes de desenvolvimento e teste com base em suas necessidades.

7 desafios do UAT E plano de mitigação

Não importa se você faz parte de um lançamento de um bilhão de dólares ou de uma equipe de inicialização, você deve superar todos esses desafios para fornecer software de sucesso para o usuário final.

# 1) Configuração do ambiente e processo de implantação:

Realizar este teste no mesmo ambiente usado pela equipe de teste funcional certamente acabará negligenciando os casos de uso do mundo real. Além disso, atividades de teste cruciais, como teste de desempenho, não podem ser realizadas em um ambiente de teste com dados de teste incompletos.

Um ambiente de produção separado deve ser configurado para este teste.

Uma vez que o ambiente UAT é separado do ambiente de teste, você precisa controlar o ciclo de lançamento de forma eficaz. O ciclo de lançamento não controlado pode levar a diferentes versões de software no ambiente de teste e UAT. Valioso tempo de teste de aceitação é desperdiçado quando o software não é testado na versão mais recente.

Enquanto isso, o tempo necessário para o rastreamento de problemas na versão incorreta do software é alto.

# 2) Teste Planejamento:

Este teste deve ser planejado com um plano de teste de aceitação claro na análise de requisitos e fase de design.

No planejamento de estratégia, o conjunto de casos de uso do mundo real deve ser identificado para execução. É muito importante definir os objetivos do teste para este teste, pois uma execução completa do teste não é possível para grandes aplicativos nesta fase de teste. O teste deve ser realizado priorizando os objetivos críticos de negócios primeiro.

Esse teste é realizado no final do ciclo de teste. Obviamente, é o período mais crítico para o lançamento do software. O atraso em qualquer um dos estágios anteriores de desenvolvimento e teste consumirá o tempo do UAT.

O planejamento de teste impróprio, nos piores casos, leva a uma sobreposição entre o teste do sistema e o UAT. Devido ao menor tempo e pressão para cumprir prazos, o software é implantado neste ambiente mesmo que o teste funcional não seja concluído. Os objetivos principais deste teste não podem ser alcançados em tais situações.

O plano de teste UAT deve ser preparado e comunicado à equipe bem antes de começar este teste. Isso os ajudará no planejamento de teste, escrevendo casos de teste & scripts de teste e criando um ambiente UAT.

# 3) Tratamento de novos requisitos de negócios como incidentes / defeitos:

Ambiguidades nos requisitos são detectadas na fase do UAT. Os testadores UAT encontram problemas decorrentes de requisitos ambíguos (observando a IU completa que não estava disponível durante a fase de coleta de requisitos) e registram como um defeito.

O cliente espera que isso seja corrigido na versão atual sem considerar o tempo para as solicitações de mudança. Se uma decisão oportuna não for tomada pelo gerenciamento do projeto sobre essas mudanças de última hora, isso pode levar à falha no lançamento.

# 4) Testadores não qualificados ou testadores sem conhecimento de negócios:

Quando não há equipe permanente, a empresa seleciona equipe UAT de vários departamentos internos.

Mesmo se a equipe estiver bem familiarizada com as necessidades do negócio, ou se não forem treinados para os novos requisitos que são sendo desenvolvidos, eles não podem realizar UAT eficaz. Além disso, uma equipe de negócios não técnica pode enfrentar muitas dificuldades técnicas na execução dos casos de teste.

Enquanto isso, designar testadores no final do ciclo do UAT não adiciona nenhum valor ao projeto. Pouco tempo para treinar a equipe do UAT pode aumentar significativamente as chances de sucesso do UAT.

# 5) Canal de comunicação impróprio:

A comunicação entre o desenvolvimento remoto, teste e a equipe do UAT é mais difícil . A comunicação por e-mail costuma ser muito difícil quando você tem uma equipe de tecnologia offshore. Uma pequena ambigüidade nos relatórios de incidentes pode atrasar sua correção por um dia.

O planejamento adequado e a comunicação eficaz são essenciais para a colaboração eficaz da equipe. As equipes de projeto devem usar uma ferramenta baseada na web para registrar defeitos e dúvidas. Isso ajudará a distribuir a carga de trabalho de maneira uniforme e evitar relatar problemas duplicados.

# 6) Solicitando que a equipe de teste funcional realize este teste:

Não há pior situação do que solicitar o teste funcional equipe para realizar o UAT.

Os clientes transferem sua responsabilidade para a equipe de teste devido à falta de recursos. Todo o propósito deste teste fica comprometido em tais casos. Assim que o software entrar no ar, os usuários finais identificarão rapidamente os problemas que não são considerados cenários do mundo real pelos testadores funcionais.

Uma solução para isso é atribuir este teste a pessoas dedicadas e qualificadas testadores com conhecimento de negócios.

# 7) O jogo da culpa

Às vezes, os usuários de negócios apenas tentam encontrar motivos para rejeitar o software. Pode ser sua autoconfiança mostrar o quão superior eles são ou culpar a equipe de desenvolvimento e teste para obter respeito na equipe de negócios. Isso é muito raro, mas acontece em equipes com política interna.

É muito difícil lidar com essas situações. No entanto, construir um relacionamento positivo com a equipe de negócios definitivamente ajudaria a evitar o jogo da culpa.

Espero que essas diretrizes certamente ajudem você a executar um plano de aceitação do usuário bem-sucedido, superando vários desafios. O planejamento adequado, a comunicação, a execução e a equipe motivada são as chaves para um teste de aceitação do usuário bem-sucedido.

Teste do sistema vs. Teste de aceitação do usuário

O envolvimento da equipe de teste começa bem cedo no projeto desde a fase de análise de requisitos.

Ao longo de todo o ciclo de vida do projeto, algum tipo de validação é realizada para o projeto, ou seja, teste estático, teste de unidade, teste de sistema, teste de integração, um teste de ponta a ponta ou teste de regressão. Isso nos permite entender melhor sobre o teste realizado na fase do UAT e como ele é diferente dos outros testes realizados anteriormente.

Embora vejamos as diferenças no SIT e no UAT, é importante que aproveitemos as sinergias mas ainda manter a independência entre as duas fases, o que permitiria um tempo de comercialização mais rápido.

Conclusão

# 1) UAT não é sobre as páginas, campos ou botões. A suposição subjacente, mesmo antes do início do teste, é que todas as coisas básicas foram testadas e estão funcionando bem. Deus me livre, os usuários encontram um bug tão básico quanto esse – é uma notícia muito ruim para a equipe de controle de qualidade. 🙁

# 2) Este teste é sobre a entidade que é o elemento principal no negócio.

Deixe-me dar um exemplo: Se o AUT for um sistema de tíquetes, o O UAT não vai ser sobre, procurar o menu que abre uma página, etc. Trata-se dos ingressos e sua reserva, os estados que podem tomar, sua jornada pelo sistema, etc.

Outro exemplo, se o site é um site de concessionária de automóveis, o foco está no “carro e suas vendas” e não realmente no site. Portanto, o negócio principal é o que é verificado e validado e quem é melhor para fazer isso do que o proprietários de empresas. É por isso que esse teste faz mais sentido quando o cliente está muito envolvido.

# 3) O UAT também é uma forma de teste em sua essência, o que significa que há uma boa chance de identificar alguns bugs também nesta fase. Às vezes acontece. Além do fato de ser uma grande escalada na equipe de controle de qualidade, os bugs do UAT geralmente significam uma reunião para discutir como lidar com eles. Para fazer esse teste, geralmente não há tempo para consertar e testar novamente.

A decisão seria:

• Adiar a data de ativação, corrigir o problema primeiro e depois siga em frente.
• Deixe o bug como está.
• Considere-o como parte da solicitação de mudança para versões futuras.

# 4) UAT é classificado como teste Alfa e Beta, mas essa classificação não é tão importante no contexto de projetos típicos de desenvolvimento de software em uma indústria baseada em serviços.

• O teste alfa é quando o UAT é realizado no ambiente do criador de software e é mais significativo no contexto comercial de prateleira software.
• O teste beta é quando o UAT é realizado no ambiente de produção ou no ambiente do cliente. Isso é mais comum para aplicativos voltados para o cliente. Os usuários aqui são os clientes reais como você e eu neste contexto.

# 5) Na maioria das vezes em um projeto de desenvolvimento de software regular, o UAT é realizado no ambiente de controle de qualidade, se houver não é um ambiente de teste ou UAT.

Resumindo, a melhor maneira de descobrir se o seu produto é aceitável e adequado para a finalidade é colocá-lo na frente dos usuários.

As organizações estão adotando a maneira ágil de entrega, os usuários de negócios estão se envolvendo mais e os projetos estão sendo aprimorados e entregues por meio de ciclos de feedback. Tudo feito, a fase de aceitação do usuário é considerada como o portão para entrar na implementação e produção.

Qual foi a sua experiência com o UAT? Você estava em espera ou testou para seus usuários? Os usuários encontraram algum problema? Se sim, como você lidou com eles?

= > Leia também TODOS os tutoriais desta série aqui

= > Visite aqui para ver a série completa de tutoriais do plano de teste