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

what is user acceptance testing

Aprenda o que é 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 será relevante e principalmente um significado literal (no contexto técnico).

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

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

como imprimir uma matriz em ordem reversa

Vamos testar esse conceito.

=> Leia todos os tutoriais em nossa série de testes de aceitação.

O que você aprenderá:

• O que é o teste de aceitação do usuário?
  • Quando é realizado?
  • Quem executa o UAT?
  • Necessidade de teste de aceitação do usuário
  • Processo de Teste de Aceitação do Usuário
  • Governança UAT
  • Planejamento de teste UAT
  • Projeto de Teste de Aceitação do Usuário
  • Execução de Teste
  • Ferramentas e Metodologias
  • UAT em ambiente ágil
  • Equipe UAT - Funções e responsabilidades
• 7 desafios do UAT e plano de mitigação
• Teste do sistema versus teste de aceitação do usuário
• Conclusão
  • Leitura recomendada

O que é o teste de aceitação do usuário?

Nós 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 sua construção para ele (cliente).

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

O 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 executado quando os testes funcional, de sistema e de regressão são concluídos.

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

UAT, testes alfa e beta são diferentes tipos 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 esta é a última chance para o cliente testar o software e medir se ele é adequado para o propósito.

Quando é realizado?

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

Quem executa o 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 o usuário final, se o software for disponibilizado para eles antes do tempo e quando seu feedback for solicitado.

A equipe pode ser composta de 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 contra o Especificações funcionais . Eles interpretam os requisitos de acordo com seus conhecimentos 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 e 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 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 a liberação é muitas vezes maior do que consertar antes.

O UAT é realmente necessário?

Depois de realizar muitos testes de sistema, integração e regressão, alguém pode se perguntar sobre a necessidade desse 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 validarão o sistema para sua adequação.

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

Na verdade, seria muito útil para as equipes de negócios, se estivessem envolvidas no projeto bem cedo, para que pudessem fornecer suas visões e contribuições que ajudariam no uso eficaz do sistema no mundo real.

Processo de Teste de Aceitação do Usuário

A maneira mais fácil de entender esse processo é pensar nisso como um projeto de teste autônomo - ou seja, terá as fases de planejamento, design e execução.

A seguir estão os pré-requisitos antes do início da fase de planejamento:

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

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

Podem ser de 2 tipos:

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

Idealmente, todas as principais funcionalidades de negócios devem ser validadas, mas devido a vários motivos, 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) Definir o escopo do envolvimento de QA.

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

(i) Sem Envolvimento - Isso é muito raro.

(ii) Auxiliar neste teste - Mais comum. Nesse caso, nosso envolvimento poderia ser treinar os usuários do UAT sobre como usar o aplicativo e ficar em espera durante este teste para ter certeza de que podemos ajudar os usuários em caso de qualquer dificuldade. Ou em alguns casos, além de estar em espera e ajudando, 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 - Nesse caso, os usuários apontam 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 empresarial, que pode ser o proprietário ou o cliente de um sistema em teste. Semelhante à fase de teste do sistema, a fase UAT também abrange fases religiosas antes de ser encerrada.

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

Governança 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.

Planejamento de teste UAT

O processo é quase o mesmo que com 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 uma amostra, verifique as seções do UAT do documento do plano de teste em anexo.

Plano de Teste de Aceitação do Usuário

(Este é o mesmo que você encontrará em nosso site para 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 e saída - tudo isso e tudo o mais que seja relevante será encontrado no plano de teste UAT.

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

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

Projeto de 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 aparência mostrada abaixo.

(Estes são trechos de 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 disso, os dados, modelos para registrar os resultados dos testes, procedimentos administrativos, mecanismo de registro de defeitos, etc., devem estar disponíveis antes de passarmos para a próxima fase.

Execução de Teste

Normalmente, quando possível, esse teste acontece em uma conferência ou sala de guerra, onde os usuários, PM e representantes da equipe de QA 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, executamos os casos de teste no AUT.

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

Chegar à decisão de aceitação é normalmente o fim desta fase.

Ferramentas e Metodologias

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

Ferramentas:

Como essa 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 de sistema, os usuários também usariam o gerenciamento de teste e uma ferramenta de gerenciamento de defeitos, como QC, JIRA, etc. Essas ferramentas podem ser configuradas para acumular dados para a fase de aceitação do usuário.

Metodologias:

dfs e bfs c ++

Embora as metodologias convencionais, como usuários de negócios específicos realizando UAT do produto, ainda sejam relevantes, em um mundo verdadeiramente global como o de hoje, o Teste de Aceitação do Usuário às vezes precisa envolver clientes variados entre 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 teste de multidão seria a melhor opção viável.

Teste de multidão é uma metodologia onde pessoas de todo o mundo podem participar e validar a utilização do produto e dar sugestões e recomendações.

Plataformas de teste de multidão 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 será 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 os requisitos, atualizando assim a lista de pendências 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 do 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 product backlog, 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 para sua utilização com mais frequência ao contrário dos projetos tradicionais em cascata.

Equipe UAT - Funções e 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 entregar um software de sucesso para o usuário final.

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

Realizar esse 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 .

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

Depois 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 é perdido 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) Planejamento de Teste:

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

No planejamento da 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.

Este 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, no pior dos 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 e scripts de teste e criando um ambiente UAT.

# 3) Lidar com 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 na liberação.

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

Quando não há equipe permanente, a empresa seleciona funcionários da 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 estão sendo desenvolvidos, eles não podem executar 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, a atribuição de 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 equipe 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 uniformemente a carga de trabalho e evitar relatar problemas duplicados.

# 6) Pedir à equipe de teste funcional para realizar este teste:

Não há situação pior do que pedir à equipe de teste funcional 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 esse teste a testadores dedicados e qualificados 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 tais 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, comunicação, execução e equipe motivada são as chaves para o teste de aceitação do usuário bem-sucedido.

Teste do sistema versus teste de aceitação do usuário

O envolvimento da equipe de teste começa bem no início do projeto, desde a fase de análise de requisitos.

Durante 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, teste de ponta a ponta ou teste de regressão. Isso nos permite entender melhor sobre o teste executado na fase do UAT e como ele é diferente dos outros testes executados anteriormente.

Embora vejamos as diferenças no SIT e no UAT, é importante que aproveitemos as sinergias, mas ainda mantenhamos a independência entre as duas fases, o que possibilitaria um tempo de lançamento mais rápido no mercado.

Conclusão

# 1) UAT não é sobre páginas, campos ou botões. O subjacente suposição mesmo antes de este teste começar é que todo aquele material básico foi testado e está funcionando bem. Deus me livre, os usuários encontram um bug tão básico quanto isso - é uma notícia muito ruim para a equipe de QA. :(

#dois) Esse teste é sobre a entidade que é o elemento principal do negócio.

Deixe-me lhe dar um exemplo: Se o AUT é um sistema de bilhetagem, o UAT não vai ser sobre, procurar o menu que abre uma página, etc. É sobre os bilhetes e sua reserva, os estados que pode tomar, seu percurso pelo sistema, etc.

Outro Exemplo, se o site for de uma concessionária de automóveis, o foco estará no “carro e suas vendas” e não realmente no site. Portanto, o core business é o que é verificado e validado e quem é melhor para fazer isso do que os proprietários do negócio. É por isso que este teste faz mais sentido quando o cliente está muito envolvido.

# 3) UAT também é uma forma de teste em seu núcleo, o que significa que há uma boa chance de identificar alguns bugs nesta fase também . Às vezes acontece. Além do fato de que é um grande escalonamento na equipe de QA, os bugs do UAT geralmente significam uma reunião para sentar e discutir como lidar com eles, pois após esse teste, geralmente não há tempo para corrigir e testar novamente.

A decisão seria:

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

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

• Teste alfa é quando o UAT é realizado no ambiente do criador de software e é mais significativo no contexto de software comercial pronto para uso.
• 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 regular de desenvolvimento de software, o UAT é realizado no Ambiente de controle de qualidade se não houver teste ou ambiente UAT.

Em resumo, a melhor maneira de descobrir se o seu produto é aceitável e adequado para o propósito é 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. Feito isso, a fase de Aceitação do Usuário é considerada a porta de entrada para a implementação e produção.

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

como usar a extensão github para visual studio

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

=> Visite aqui para obter a série de tutoriais do plano de teste completo

Leitura recomendada

• Teste Alfa e Teste Beta (um guia completo)
• O que é teste de aceitação (um guia completo)
• Guia completo de teste de verificação de compilação (teste BVT)
• Teste Funcional Vs Teste Não Funcional
• Melhores ferramentas de teste de software 2021 [QA Test Automation Tools]
• Tipos de teste de software: diferentes tipos de teste com detalhes
• Teste ETL Tutorial de teste de data warehouse (um guia completo)
• Tutorial de teste de GUI: um guia completo de teste de interface de usuário (IU)