O que é teste de aceitação?

O teste de aceitação verifica se o software atende aos seus requisitos de negócio e está pronto para ser aceito por usuários ou stakeholders.

Enquanto os testes unitários e de integração perguntam "o código funciona", o teste de aceitação pergunta "construímos a coisa certa". Ele verifica o sistema em relação aos requisitos que um cliente ou product owner realmente valoriza, normalmente de fora para dentro, em termos de comportamento visível ao usuário. Passar nos testes de aceitação é o sinal de que uma funcionalidade está concluída.

A pergunta que ele responde

O teste de aceitação valida em relação aos requisitos, não à implementação. Ele confirma que o comportamento acordado está presente e correto sob a perspectiva do usuário. Uma funcionalidade pode passar em todos os testes unitários e ainda assim falhar na aceitação se resolver o problema errado.

Aceitação por usuário versus automatizada

O teste de aceitação vem em dois formatos. O teste de aceitação do usuário (UAT) é realizado por usuários reais ou stakeholders, muitas vezes de forma manual. Os testes de aceitação automatizados codificam os mesmos requisitos como cenários executáveis, frequentemente escritos no estilo BDD Given-When-Then, de modo que servem também como documentação viva.

Um exemplo rápido

Um teste de aceitação automatizado descreve um requisito em termos do usuário e, em seguida, conduz o sistema para confirmar que ele foi atendido.

Scenario: New user sees onboarding
  Given a brand-new account
  When the user signs in for the first time
  Then the onboarding wizard is shown

Onde ele se encaixa

• Depois que os testes unitários e de integração passam.
• Na fronteira entre a engenharia e o negócio.
• Frequentemente expresso como cenários BDD para entendimento compartilhado.
• Como o portão que declara uma funcionalidade verdadeiramente concluída.

Teste de aceitação no CI

Os testes de aceitação automatizados rodam no pipeline como outros testes ponta a ponta, exercitando o sistema inteiro, portanto são mais lentos e ocasionalmente instáveis. Executá-los em paralelo em runners rápidos e isolados e refazer falhas transitórias os mantém confiáveis o suficiente para servir de portão a um release.

Principais conclusões

• O teste de aceitação verifica se o software atende aos requisitos de negócio.
• Ele valida que a coisa certa foi construída, sob a perspectiva do usuário.
• Testes de aceitação automatizados rodam no CI, muitas vezes como cenários BDD.

Guias relacionados