O que é teste de aceitação (um guia completo)

what is acceptance testing

Introdução ao Teste de Aceitação (Parte I):

Nesta série de tutoriais, você aprenderá:

1. O que é teste de aceitação
2. Testes de Aceitação e Plano de Teste
3. Status dos testes de aceitação e relatórios resumidos
4. O que é o Teste de Aceitação do Usuário (UAT)

Terminou o Teste do Sistema? A maioria dos seus bugs foram corrigidos? Os bugs são verificados e fechados? Então o que vem depois?

Em seguida na lista vem o Teste de Aceitação, que é a última fase do Processo de Teste de Software . Esta é a fase em que o cliente decide GO / No-GO para o produto e deve ser seguido obrigatoriamente antes de lançar o Produto no mercado. Os esforços conjuntos da equipe de desenvolvimento e teste serão concedidos pelo cliente, aceitando ou rejeitando o Produto desenvolvido.

Este tutorial exclusivo sobre Teste de Aceitação lhe dará uma visão geral completa do significado, tipos, usos e vários outros fatores envolvidos no Teste de Aceitação de uma maneira simples e fácil para seu melhor entendimento.

O que você aprenderá:

• O que é teste de aceitação?
• Por que testes de aceitação?
• Tipos
  • # 1) Teste de aceitação do usuário (UAT)
  • # 2) Teste de Aceitação de Negócios (BAT)
  • # 3) Teste de Aceitação de Contrato (CAT)
  • # 4) Testes de Aceitação de Normas / Conformidade (RAT)
  • # 5) Teste de Aceitação Operacional (OAT)
  • # 6) Teste Alpha
  • # 7) Teste Beta / Teste de Campo
• Quem faz o teste de aceitação?
• Testadores de Qualidades de Aceitação
• Usar
• Diferenças entre teste de sistema, teste de aceitação e teste de aceitação do usuário
• Testes de aptidão
• Bancada de teste de aceitação
• Critérios de entrada e saída para AT
  • Critério de entrada
  • Critério de saída
• Processo de Teste de Aceitação
• Fatores de sucesso para este teste
• Conclusão
• Leitura recomendada

O que é teste de aceitação?

Uma vez o Processo de teste do sistema é concluído pela equipe de teste e é assinado, todo o Produto / aplicativo é entregue ao cliente / poucos usuários de clientes / ambos, para testar sua aceitabilidade, ou seja, o Produto / aplicativo deve ser perfeito para atender tanto ao ponto crítico quanto principais requisitos de negócios. Além disso, os fluxos de negócios de ponta a ponta são verificados de forma semelhante ao cenário em tempo real.

O ambiente de produção será o ambiente de teste para o Teste de Aceitação (normalmente denominado como Staging, Pre-Prod, Fail-Over, UAT environment).

Isto é um técnica de teste caixa preta onde apenas a funcionalidade é verificada para garantir que o produto atende aos critérios de aceitação especificados (sem necessidade de conhecimento de design / implementação).

Por que testes de aceitação?

Embora o teste do sistema tenha sido concluído com sucesso, o teste de aceitação é exigido pelo cliente. Os testes realizados aqui são repetitivos, pois teriam sido abordados em Teste do sistema.

Então, por que esse teste é realizado pelos clientes?

Isto é porque:

• Ganhar confiança no produto que está sendo lançado no mercado.
• Para garantir que o produto está funcionando da maneira que deve.
• Garantir que o produto corresponda aos padrões atuais do mercado e seja competitivo o suficiente com os outros produtos semelhantes no mercado.

Tipos

Existem vários tipos de teste.

Poucos deles estão listados abaixo:

# 1) Teste de aceitação do usuário (UAT)

UAT é avaliar se o Produto está funcionando para o usuário, corretamente para o uso. Requisitos específicos que são freqüentemente usados ​​pelos usuários finais são escolhidos principalmente para fins de teste. Isso também é denominado como Teste do usuário final.

O termo “Usuário” aqui significa os usuários finais aos quais o Produto / aplicativo se destina e, portanto, os testes são realizados da perspectiva dos usuários finais e de seu ponto de vista.

=> Também Leitura: O que é o Teste de Aceitação do Usuário (UAT)?

# 2) Teste de Aceitação de Negócios (BAT)

O objetivo é avaliar se o Produto atende aos objetivos e objetivos do negócio ou não.

A BAT concentra-se principalmente nos benefícios comerciais (finanças), que são bastante desafiadores devido às mudanças nas condições do mercado / tecnologias em avanço, de modo que a implementação atual pode ter que passar por mudanças que resultem em orçamentos extras.

é a chave de segurança de rede igual à senha

Mesmo o Produto que passa nos requisitos técnicos pode falhar na BAT devido a esses motivos.

# 3) Teste de Aceitação de Contrato (CAT)

Este é um contrato que especifica que assim que o Produto entrar no ar, dentro de um período pré-determinado, o teste de aceitação deve ser realizado e deve passar em todos os casos de uso de aceitação.

O contrato firmado aqui é denominado Acordo de Nível de Serviço (SLA), que inclui os termos em que o pagamento será feito somente se os serviços do Produto estiverem em linha com todos os requisitos, o que significa que o contrato foi cumprido.

Às vezes, esse contrato pode acontecer antes de o Produto entrar no ar. De qualquer forma, um contrato deve ser bem definido em termos de período de teste, áreas de teste, condições sobre problemas encontrados em fases posteriores, pagamentos, etc.

# 4) Regulamentos /ConformidadeTeste de Aceitação (RAT)

Isso serve para avaliar se o Produto viola as regras e regulamentações definidas pelo governo do país onde está sendo lançado. Isso pode não ser intencional, mas terá um impacto negativo nos negócios.

Normalmente, o Produto / aplicativo desenvolvido que se destina a ser lançado em todo o mundo, tem que passar por RAT, pois diferentes países / regiões têm diferentes regras e regulamentos definidos por seus órgãos de governo.

Se alguma das regras e regulamentos forem violados em qualquer país, esse país ou região específica naquele país não terá permissão para usar o produto e é considerado uma falha. Os fornecedores do produto serão diretamente responsáveis ​​se o produto for liberado, mesmo que haja uma violação.

# 5) Teste de Aceitação Operacional (OAT)

Isso é para avaliar a prontidão operacional do Produto e é um teste não funcional. Inclui principalmente testes de recuperação, compatibilidade, manutenção, disponibilidade de suporte técnico, confiabilidade, failover, localização, etc.

O OAT garante principalmente a estabilidade do Produto antes de liberá-lo para a produção.

# 6) Teste Alpha

Isso serve para avaliar o Produto no ambiente de desenvolvimento / teste por uma equipe de testadores especializados, geralmente chamados de testadores alfa. Aqui, o feedback dos testadores, sugestões ajudam a melhorar a utilização do Produto e também a corrigir alguns bugs.

Aqui, o teste acontece de maneira controlada.

=> Leia também: O que é o Alpha Testing?

# 7) Teste Beta / Teste de Campo

O objetivo é avaliar o Produto expondo-o aos usuários finais reais, geralmente chamados de testadores beta / usuários beta, em seu ambiente. Feedback contínuo dos usuários é coletado e os problemas corrigidos. Além disso, isso ajuda a aprimorar / aprimorar o Produto para fornecer uma experiência rica ao usuário.

Os testes acontecem de maneira não controlada, o que significa que o usuário não tem restrições sobre a forma como o Produto está sendo usado.

=> Leia também: O que é o teste beta?

Todos esses tipos têm um objetivo comum:

• Certifique-se de ganhar / enriquecer a confiança no produto.
• Certifique-se de que o produto está pronto para ser usado por usuários reais.

Quem faz o teste de aceitação?

Para o tipo Alpha, apenas os membros da organização (que desenvolveram o Produto) realizam o teste. Esses membros não fazem parte diretamente do projeto (gerentes / líderes de projeto, desenvolvedores, testadores). As equipes de gerenciamento, vendas e suporte geralmente realizam os testes e fornecem feedback de acordo.

Além do tipo Alpha, todos os outros tipos de aceitação são geralmente executados por diferentes partes interessadas. Como clientes, clientes de clientes, testadores especializados da organização (nem sempre).

Também é bom envolver analistas de negócios e especialização no assunto ao realizar este teste com base em seu tipo.

Testadores de Qualidades de Aceitação

Os testadores com as qualidades abaixo são qualificados como testadores de aceitação:

• Capacidade de pensar lógica e analiticamente.
• Bom conhecimento de domínio.
• Capaz de estudar os produtos competitivos do mercado e analisar os mesmos no produto desenvolvido.
• Tendo a percepção do usuário final durante o teste.
• Entenda a necessidade de negócios para cada requisito e teste de acordo.

Impacto dos problemas encontrados durante este teste

Quaisquer problemas encontrados na fase de teste de Aceitação devem ser considerados de alta prioridade e corrigidos imediatamente. Isso também requer que a análise da causa raiz seja realizada em cada problema encontrado.

A equipe de teste desempenha um papel importante no fornecimento de RCAs para problemas de aceitação. Isso também ajuda a determinar a eficiência dos testes.

Além disso, problemas válidos no teste de aceitação afetarão os esforços da equipe de teste e de desenvolvimento em termos de impressão, classificações, pesquisas de clientes, etc. Às vezes, se qualquer ignorância da equipe de teste sobre as validações for encontrada, isso também levará a escalonamentos.

Usar

Este teste é útil sob vários aspectos.

Poucos dos quais incluem:

• Para descobrir os problemas perdidos durante a fase de teste funcional.
• O quão bem o produto é desenvolvido.
• Um produto é o que os clientes realmente precisam.
• Feedbacks / pesquisas realizadas ajudam a melhorar o desempenho do produto e a experiência do usuário.
• Melhore o processo seguido tendo RCAs como entrada.
• Minimize ou elimine os problemas decorrentes do Produto de Produção.

Diferenças entre teste de sistema, teste de aceitação e teste de aceitação do usuário

A seguir estão as principais diferenças entre esses 3 tipos de testes de aceitação.

Testes de aptidão

Semelhante aos casos de teste do produto, temos testes de aceitação. Os testes de aceitação são derivados dos critérios de aceitação das histórias do usuário. Normalmente, esses são os cenários escritos no detalhamento de alto nível sobre o que o Produto deve fazer em diferentes condições.

Não dá uma imagem clara de como realizar testes, como nos casos de teste. Os testes de aceitação são escritos por testadores que têm domínio total sobre o produto, geralmente especialização no assunto. Todos os testes escritos são revisados ​​por um cliente e / ou analistas de negócios.

Esses testes são executados durante o teste de aceitação. Junto com os testes de aceitação, um documento detalhado sobre quaisquer configurações a serem feitas deve ser preparado. Deve incluir todos os detalhes de minuto com capturas de tela adequadas, valores de configuração, condições, etc.

Bancada de teste de aceitação

A bancada de teste para este teste é semelhante a uma bancada de teste regular, mas é separada. A plataforma com todo o hardware, software, produtos operacionais, instalação e configurações de rede, instalação e configurações de servidor, instalação e configurações de banco de dados, licenças, plug-ins, etc., devem ser configurados de forma muito semelhante. o ambiente de produção.

Cama de teste de aceitação é uma plataforma / ambiente onde os testes de aceitação projetados serão executados. Antes de entregar o ambiente de teste de Aceitação ao cliente, é uma boa prática verificar se há problemas ambientais e a estabilidade do Produto.

Se não houver um ambiente separado configurado para o teste de aceitação, um ambiente de teste regular pode ser usado para esse propósito. Mas aqui será complicado, pois os dados de teste do System Testing regular e os dados em tempo real do teste de aceitação são mantidos em um único ambiente.

A bancada de teste de aceitação é geralmente configurada no lado do cliente (ou seja, no laboratório) e terá acesso restrito às equipes de desenvolvimento e teste.

As equipes serão obrigadas a acessar este ambiente por meio de VMs / ou URLs especificamente projetados usando credenciais de acesso especiais, e todo o acesso a isso será rastreado. Nada neste ambiente deve ser adicionado / modificado / excluído sem a permissão do cliente, e eles devem ser notificados das alterações feitas.

Critérios de entrada e saída para AT

Assim como qualquer outra fase do STLC, o teste de aceitação tem um conjunto de critérios de entrada e saída que devem ser bem definidos no Plano de teste de aceitação (que é abordado na parte posterior deste tutorial).

Esta é a fase que começa logo após o teste do sistema e termina antes do lançamento da produção. Portanto, os critérios de saída do teste do sistema passam a fazer parte dos critérios de entrada para AT. Da mesma forma, os critérios de saída de AT passam a fazer parte dos critérios de entrada para o lançamento de produção.

Critério de entrada

A seguir estão as condições a serem cumpridas antes de começar:

como abrir arquivos .json

• Os requisitos de negócios devem ser claros e disponíveis.
• A fase de teste de sistema e regressão deve ser concluída.
• Todos os bugs críticos, principais e normais devem ser corrigidos e fechados (bugs menores aceitos são principalmente bugs cosméticos que não perturbam o uso do produto).
• A lista de problemas conhecidos deve ser preparada e compartilhada com as partes interessadas.
• A bancada de teste de aceitação deve ser configurada e uma verificação de alto nível deve ser realizada quanto à ausência de problemas ambientais.
• A fase de teste do sistema deve ser concluída, permitindo que o produto passe para a fase AT (normalmente feito por meio de comunicação por e-mail).

Critério de saída

Existem certas condições a serem cumpridas pela AT para liberar o produto para um lançamento de produção.

Eles são os seguintes:

• Os testes de aceitação devem ser executados e todos os testes devem Passar.
• Nenhum defeito crítico / grave foi deixado em aberto. Todos os defeitos devem ser corrigidos e verificados imediatamente.
• AT deve ser assinado por todas as partes interessadas incluídas com Go / No-Go Decisão sobre o produto.

Processo de Teste de Aceitação

No V-Model , A fase AT é paralela à fase de Requisitos.

O processo AT real ocorre conforme mostrado abaixo:

Análise de Requisitos de Negócios

Os requisitos de negócios são analisados ​​referindo-se a todos os documentos disponíveis dentro do projeto.

Alguns dos quais são:

• Especificações de requisitos do sistema
• Documento de Requisitos de Negócios
• Casos de Uso
• Diagramas de fluxo de trabalho
• Matriz de dados projetada

Plano de Teste de Aceitação de Projeto

Existem certos itens a serem documentados no Plano de Teste de Aceitação.

Vamos dar uma olhada em alguns deles:

• Estratégia e abordagem do Teste de Aceitação.
• Os critérios de entrada e saída devem ser bem definidos.
• O escopo da AT deve ser bem mencionado e deve cobrir apenas os requisitos do negócio.
• A abordagem do projeto de teste de aceitação deve ser detalhada, de modo que qualquer pessoa que esteja escrevendo testes possa entender facilmente a maneira como eles devem ser escritos.
• A configuração da bancada de teste e o cronograma / cronograma de teste real devem ser mencionados.
• Como o teste é conduzido por diferentes partes interessadas, detalhes sobre o bug de registro devem ser mencionados, pois as partes interessadas podem não estar cientes do procedimento seguido.

Projetar e revisar testes de aceitação

Os testes de aceitação devem ser escritos em um nível de cenário, mencionando o que deve ser feito (não detalhadamente para incluir como fazer). Eles devem ser escritos apenas para as áreas identificadas de escopo para requisitos de negócios, e cada teste deve ser mapeado para seu requisito de referência.

Todos os testes de aceitação escritos devem ser revisados ​​para alcançar uma alta cobertura dos requisitos de negócios.

Isso é para garantir que quaisquer outros testes além do escopo mencionado não estejam envolvidos, de forma que os testes fiquem dentro dos prazos programados.

Configuração da cama de teste de aceitação

A base de teste deve ser configurada de maneira semelhante a um ambiente de produção. São necessárias verificações de alto nível para confirmar a estabilidade e o uso do ambiente. Compartilhe as credenciais para usar o ambiente apenas com uma parte interessada que esteja realizando este teste.

Configuração de dados de teste de aceitação

Os dados de produção devem ser preparados / preenchidos como dados de teste nos sistemas. Além disso, deve haver um documento detalhado de forma que os dados sejam usados ​​para teste.

Não tenha os dados de teste como TestName1, TestCity1, etc., em vez disso, tenha Albert, Mexico, etc. Isso oferece uma rica experiência de dados em tempo real e os testes serão atualizados.

Execução do Teste de Aceitação

Os testes de aceitação projetados devem ser executados no ambiente nesta etapa. Idealmente, todos os testes devem passar na primeira tentativa em si. Não deve haver bugs funcionais decorrentes do teste de aceitação, se houver, então eles devem ser relatados com alta prioridade para serem corrigidos.

Novamente, os bugs corrigidos devem ser verificados e fechados como uma tarefa de alta prioridade. O relatório de execução de teste deve ser compartilhado diariamente.

Os bugs registrados nesta fase devem ser discutidos em uma reunião de triagem de bugs e devem passar pelo procedimento de Análise de Causa Raiz. Este é o único ponto onde o teste de aceitação avalia se todos os requisitos de negócios são realmente atendidos pelo produto ou não.

Decisão de Negócios

Sai um Go / No-Go decisão de o produto ser lançado em Produção. Vai decisão levará o produto à frente para ser lançado no mercado. Não vá decisão marca o produto como Falha.

Alguns fatores de decisão proibida:

• Má qualidade do produto.
• Muitos erros funcionais abertos.
• Desvio dos requisitos de negócios.
• Não está à altura dos padrões de mercado e precisa de melhorias para corresponder aos padrões de mercado atuais.

Fatores de sucesso para este teste

Assim que este teste for planejado, prepare uma lista de verificação que aumente a taxa de sucesso do mesmo. Existem alguns itens de ação que devem ser seguidos antes do início do teste de aceitação.

Eles estão:

• Tenha um escopo bem definido e certifique-se de que haja uma necessidade comercial para o escopo identificado para este teste.
• Execute os testes de aceitação na própria fase de teste do sistema pelo menos uma vez.
• Executar extensa teste ad-hoc para cada um dos cenários de teste de aceitação.

Conclusão

Resumindo, o teste de aceitação ajuda a descobrir a eficiência das equipes de desenvolvimento e teste.

Existem várias ferramentas para realizar esta atividade, mas geralmente é preferível que seja feito manualmente, pois há um envolvimento dos usuários reais e diferentes partes interessadas que não têm formação técnica, e pode não ser viável para eles.

Qual é o próximo?

Em nosso próximo tutorial, iremos focalizar os tópicos abaixo:

• Exemplos de critérios de teste de aceitação.
• Como escrever um plano de teste de aceitação.
• Um modelo adequado para a escrita de testes de aceitação.
• Como escrever testes de aceitação com exemplos.
• Identificação de cenários de teste de aceitação.
• Relatórios de teste de aceitação.
• Teste de aceitação em desenvolvimento ágil e baseado em teste.

PRÓXIMO Tutorial nº 2: Plano de Teste de Aceitação

Você realizou o teste de aceitação? Ficaríamos felizes em ouvir suas experiências !!

Leitura recomendada

• Teste Alfa e Teste Beta (um guia completo)
• O que é o teste de aceitação do usuário (UAT): 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)
• Guia de teste de segurança de aplicativos da Web