Teste de aceitação: o quê e por quê

Teste de Aceitação: O Que e Por Que + Tipos a Conhecer

O teste de aceitação é onde você descobre que o software criado não é o que o cliente e os usuários esperavam. Certo?

Software Testing

Há algumas décadas, isso acontecia com bastante frequência devido ao longo tempo desde que os requisitos foram especificados.

As práticas Agile têm feito muito para fechar esta lacuna. Mas mesmo quando sua adoção ao Agile é de alto nível, ainda é crucial ter testes de aceitação em seu arsenal porque isso envolve mais do que a verificação de requisitos.

Este artigo o informará sobre o que você precisa saber para colocá-lo para trabalhar de forma eficaz e garantir que você entregue software que seus clientes e usuários finais terão prazer em usar.

O que é Teste de Aceitação, e Por que é Importante?

Historicamente, como usuário, você só veria um novo produto de software muito depois que a maioria dos desenvolvedores e testadores tivessem passado adiante.

Devido a essa longa lacuna, os testes de aceitação foram cruciais para determinar se o software satisfazia as expectativas e era funcional para seus usuários, em outras palavras: se ele era aceitável e apto para entrar em funcionamento. Somente se ele fosse adicionado a um ambiente de produção e utilizado no curso normal dos negócios.

No desenvolvimento ágil, os testes de aceitação são parte do processo e não uma reflexão posterior. Entretanto, a intenção ainda é a mesma: verificar se o software atende às expectativas do ponto de vista do cliente e dos usuários finais.

Quando você trabalha com uma equipe ágil e madura, você não verá nenhuma diferença entre as especificações e a verificação. Você colabora com a equipe para criar histórias de usuários e seus critérios de aceitação. E você ou eles escrevem esses critérios de aceitação em uma notação que as ferramentas podem se transformar em testes de aceitação automatizados.

O tremendo benefício é que o produto em desenvolvimento está sempre em um estado aceitável — sem mais surpresas desagradáveis.

Como Isso é Diferente dos Testes Funcionais e dos Testes de Sistema?

Acceptance testing

Teste funcional é o antigo nome do teste de aceitação. O nome mudou para refletir melhor a intenção dos testes.

Agora você usa o termo teste funcional para distingui-lo dos testes não-funcionais — verificação de requisitos não-funcionais (mais sobre isso na próxima seção).

A diferença entre aceitação e teste de sistema está no ponto de vista de quem você considera. Com os testes de sistema, você verifica o comportamento do software de acordo com a forma como os desenvolvedores interpretaram e entenderam os requisitos.

Tipos de Critérios de Aceitação

Para fazer um teste de aceitação e decidir se você vai aceitar o software, você precisa de critérios claros. Estes são conhecidos como critérios de aceitação.

Os critérios de aceitação funcional dizem como o software precisa se comportar para ajudar seus usuários a fazer seu trabalho. Eles são sobre as funções, ou recursos, que seu software oferece.

Os critérios de aceitação não-funcionais especificam os requisitos para tudo mais. Eles são sobre como seu software faz o que faz: aspectos como acessibilidade, facilidade de uso, segurança e privacidade, velocidade, confiabilidade e muito, muito mais.

Tipos de Testes de Aceitação

O Teste de Aceitação do Usuário é o que você geralmente pensa quando ouve o termo “teste de aceitação”. Mas há muito mais nos testes de aceitação do que verificá-los de acordo com as expectativas dos usuários.

Teste de Aceitação do Usuário (UAT)

UAT

Durante o UAT, você executará um produto de software através de seus passos para garantir que ele atenda às suas expectativas como usuário e que seja viável para você. Em outras palavras, que ele o ajude a fazer seu trabalho e lhe proporcione os benefícios que você se propôs a obter.

Em equipes ágeis maduras e equipes que utilizam CI/CD, o teste de aceitação (automatizado) combina tanto o teste de aceitação do usuário quanto o teste de sistema.

Você mantém a centralidade do UAT no usuário através da estreita colaboração entre os usuários finais e a equipe de desenvolvimento, especificando os critérios de aceitação para cada história de usuário desenvolvida. A equipe de desenvolvimento então os utiliza para criar casos de testes automatizados que são executados sempre que uma integração é construída.

Teste de Aceitação Operacional (OAT)

Você usa o teste de aceitação operacional para avaliar se pode executar e administrar corretamente um sistema de software. OAT também é chamado de Teste de Funcionamento de Prontidão (ORT) ou Teste de Prontidão e Garantia de Operações (OR&A).

Durante o OAT, você vai observar tudo o que precisa para manter um sistema de software funcionando sem problemas: sua segurança, sua escalabilidade, sua velocidade e desempenho, degradação graciosa sob picos de carregamento, etc. Você também observará sua capacidade de recuperação de falhas, seus procedimentos de backup e restauração, balanceamento de carregamento e muito mais.

Em resumo, a OAT é o principal tipo de teste de aceitação para todos os requisitos não-funcionais. Os únicos testes funcionais que você realizaria lidam com as funções necessárias para executar e verificar esses requisitos não-funcionais.

Governança e Conformidade, ou Teste Regulamentar de Aceitação

Software-projects-lifecycle

Você realiza testes regulamentares de aceitação quando o campo para o qual seu software é usado é regulado de qualquer forma.

Software para fins médicos talvez venha primeiro à mente. Você encontrará outros exemplos nas áreas aviação, automotiva, petróleo e gás, navegação, agricultura, pesca, etc. Dificilmente restará uma indústria onde você não tenha que lidar com regras e regulamentos.

Quando você faz testes de conformidade ou de regulamentação, você verifica se o software está em conformidade com as regras e regulamentações aplicáveis. Estes podem ser requisitos funcionais, mas muitas vezes não são funcionais. Pense, por exemplo, nas trilhas de auditoria necessárias para saber quem atualizou o quê e quando.

Teste de Aceitação Alpha e Beta

Testes de Aceitação Alpha e Beta são práticas para obter feedback antecipado de um número limitado de usuários finais e clientes, ou mesmo dos clientes dos clientes.

O objetivo é coletar feedback do uso real para corrigir quaisquer defeitos, tais como comportamento incorreto ou complicado antes de liberar seu software para o público em geral.

O teste de aceitação Alpha também é conhecido como Teste de Aceitação Interna. E o teste de aceitação Beta também é conhecido como Teste de Aceitação de Campo ou Teste de Aceitação Externo.

Ambos são formas informais de teste de aceitação do usuário. Os testes Alpha ou Beta obtêm acesso antecipado a novos recursos em troca de seu feedback. Eles não têm direito a voto na decisão de entrar no ar e não executam nenhum dos seus casos de teste.

Os testadores Alpha são geralmente usuários internos e talvez alguns clientes (potenciais) selecionados. Às vezes, equipes de teste independentes dedicadas realizam os testes Alpha.

Os testes Beta sucedem a fase Alpha. A diferença é que você permite a entrada de (muito) mais usuários finais externos.

Teste de Aceitação Contratual ou de Contrato

Um contrato de software geralmente tem cláusulas sobre quanto tempo um cliente tem após a entrega para notificar uma empresa de software sobre problemas que deve resolver como parte do contrato. Um cliente terá que pagar separadamente para resolver problemas que não tenha relatado durante o “período de aceitação”.

Como tal, é mais uma razão para fazer testes de aceitação do que um tipo de teste. Entretanto, um contrato pode incluir critérios de aceitação que o cliente definiu ao negociar seu acordo com um fornecedor de software. Se estes não se tornassem uma história de usuário ou critérios de aceitação não funcionais, você faria testes de contrato específicos para verificá-los.

Quando Você Realiza os Testes de Aceitação?

Types UAT Testing
Src: Usersnap

Você executa testes formais de aceitação como o teste final antes que o novo software entre em funcionamento.

Entretanto, quando você pratica CI/CD ou trunk-based development com feature toggles, “go live” é quando você aciona o interruptor (a feature toggle) para tornar um recurso disponível a todos.

Portanto, mesmo assim, a ideia ainda é a mesma. Todos os testes de aceitação devem ser bem sucedidos antes do lançamento.

Como Realizar Testes de Aceitação do Usuário em 5 Passos Fáceis

acceptance testing

O teste de aceitação informa a decisão de entrar em funcionamento com um produto ou funcionalidade. Requer um plano de teste minucioso e execução diligente.

Os passos para realizar um teste de aceitação como uma atividade separada são:

  • Coletar os Critérios de Aceitação a partir das histórias dos usuários que estão prontos para entrar em ação.
    • Se suas histórias de usuários ainda não possuem critérios de aceitação, crie-as. Faça isso em colaboração com profissionais de negócios, testadores e desenvolvedores. Confira a seção “Três Amigos como a Ideia Central do Behavior Driven Development” em Behavior Driven Development para descobrir o porquê.
  • Tomando os Critérios de Aceitação como entrada, criar pelo menos um caso de teste para cada um.
    • Descreva os dados factuais e a situação que você precisa como ponto de partida.
    • Descreva as ações precisas que um usuário deve tomar a partir desse ponto de partida, incluindo os dados que ele/ela deve inserir.
    • Descreva o comportamento esperado do software, incluindo os dados factuais que ele deve exibir em resposta às ações do usuário.
  • Preparar um ambiente de teste instalando o software e coletando os dados necessários para todos os casos de teste.
  • Executar os casos de teste.
    • Diagnosticar falhas: determinar se é um problema com o caso de teste ou com o software. Consertar problemas em casos de teste e reexecutar. Relatar problemas com o software e reexecutar quando corrigidos.
  • Quando todos os casos de teste forem bem-sucedidos, assinar o teste de aceitação.

Mesmo que não seja mais uma atividade separada, você precisará passar por estas etapas. Elas serão apenas parte de outras atividades de desenvolvimento. Por exemplo, você criaria critérios de aceitação como parte da coleta de requisitos ou da definição de histórias de usuários.

Feche a Lacuna Entre o que Você Pretende e o que Você Recebe

Parabéns a você. Você aprendeu o que é o teste de aceitação. Na verdade, você aprendeu muito mais que isso.

Portanto, tenho certeza que você me entende quando digo que o teste de aceitação é uma parte essencial de qualquer processo de desenvolvimento de software.

Você também sabe agora que pode evitar as interpretações errôneas que levam a obter o que você não pretendia, adotando uma abordagem de test-first como o BDD. Ou pelo menos criando os critérios de aceitação para as histórias de usuários primeiro e deixando-os informar tanto o desenvolvimento quanto os testes de QA.

Portanto, dê o primeiro passo — crie critérios de aceitação para cada história de usuário que você pretende desenvolver — e cresça a partir daí.

Teste de Aceitação: O Que e Por Que + Tipos a Conhecer

A vida é boa quando suas equipes Agile estão sincronizadas!

Contate-Nos hoje para uma demonstração personalizada do SwiftEnterprise! Ou inscreva-se para atualizações abaixo.

Solicitar Demonstração