TESTE DE ACEITAÇÃO

Paulyne Jucá (paulyne@ufc.br)

PROCESSO EM V
FASES DO TESTE
 Teste unitário ou de unidade
 Teste de integração

 Teste de sistema

 Teste de aceitação

 Teste de regressão
TESTE DE UNIDADE, INTEGRAÇÃO E
SISTEMA
Teste de unidade Teste de Teste de Sistema
Integração
Casos de teste Especificações dos Especificações da Especificações dos
derivados das componentes arquitetura e requisitos
projeto
Visibilidade Todos os detalhes Alguns detalhes do Nenhum detalhes
necessária do código código e de código
principalmente das
interfaces entre
componentes
Testes de apoio Simuladores de Stubs, mocks. Oráculos de teste e
ambiente de Dependem da simulação de
ativação (drivers), arquitetura usada e ambiente (exemplo
módulos de teste da ordem de de sistemas
(stubs e mocks) e integração embarcados)
oráculos de teste
Foco no(a) Comportamento Integração e Funcionalidades do
individual dos interação entre sistema
módulos módulos
TESTE DE SISTEMA, ACEITAÇÃO E
REGRESSÃO
Teste de sistema Teste de aceitação Teste de regressão
Verifica os requisitos Verifica a adequação às Verifica novamente os
especificados necessidades do usuário casos de teste aprovados
em versões prévias
Executado por grupos de Executado pelo grupo de Executado pelo grupo de
desenvolvimento de teste com o envolvimento desenvolvimento de
testes do usuário testes
Verifica a correção e Valida a utilidade e Protege contra alterações
completude do produto satisfação com o produto indesejadas
TESTE DE REGRESSÃO
 Quando uma nova versão de um software não
prove mais corretamente uma funcionalidade que
deveria ter sido preservada, diz-se que a nova
versão regrediu.
 O teste de regressão verifica se a nova versão não
regrediu
 Abordagem simples:
 Testar tudo de novo
 Problemas:
 Custos
 Existem testes redundantes que podem ser removidos?
 Mudanças podem fazer com que antigos testes não sejam
mais válidos
 Atualizar testes (manutenção)
 Remover testes obsoletos
EXERCÍCIO
 Fazer a maior
quantidade de balões
que puderem
 Entre olhos: 1,5 cm
 Olhos: 5 cm
 Altura nariz: 3,5 cm
 Boca: 11,5 cm
 Largura total: 22,5 cm
O QUE APRENDEMOS?
 Os critérios de aceitação não devem ser usados
apenas para testar o resultado final. Eles
também servem como meta para os
desenvolvedores
 Automatizar os testes de aceitação pode ser
muito útil, pois permite verificar os critérios de
aceitação durante a produção
TESTE DE ACEITAÇÃO
 O propósito do teste de aceitação é orientar a
decisão de quando o produto em seu estado atual
deveria ser liberado
 Por que fazer?
 O produto não está pronto até que ele passe no
critério de aceitação
 Ótima ferramenta de colaboração
 Prove feedback
 Fornece meios para medir a evolução do
desenvolvimento
TESTE DE ACEITAÇÃO
TESTE DE ACEITAÇÃO
 Quem participa da escolha dos critérios de
aceitação:
 Cliente
 Usuário
 Analista de negócio
 Responsável pela garantia da qualidade (SQA e
Testadores)
 Desenvolvedores
TESTE DE ACEITAÇÃO
 Testes podem ser muito técnicos
 O cliente pode precisar de ajuda para escrever
 Desenvolvedores e testadores são técnicos
 Escrita em pares pode ajudar. Revisão também.

 Regras de negócio podem ser complicadas

 Os desenvolvedores podem precisar de ajuda para
escrever seus testes
 Clientes conhecem o negócio
 Implementação dos testes em pares pode ajudar
TESTE DE ACEITAÇÃO
 Teste alfa
 realizados por um grupo de usuários no ambiente de
desenvolvimento
 seu objetivo é determinar se o sistema pode ser
liberado
 Testes beta
 realizados por um grupo de usuários em ambiente de
operação

 Teste de aceitação devem ser automatizados

 Usar ferramentas
 Ex: JBehave, RSpec
EXERCÍCIO
 Escreva as regras de negócio para o login
 Aplicação web

 As credenciais do usuário são

armazenadas em um banco de dados
 Login correto redireciona o usuário para a
tela “welcome”
POSSIBILIDADE DE TESTE
 Digite a URL de login no browser
 Digite o usuário “wallace”

 Problema?
POSSIBILIDADE DE TESTE
 Digite a URL de login no browser
 Digite o usuário “wallace”

 Problema?
 Construa um ambiente testável primeiro
POSSIBILIDADE DE TESTE
 Adiciona alguns usuários ao sistema
 Digite um valor no campo username

 Problema?
POSSIBILIDADE DE TESTE
 Adiciona alguns usuários ao sistema
 Digite um valor no campo username

 Problema?
 Seja específico
 Testes são exemplos
 Use exemplos concretos
 Especifique comportamento

 Não seja ambíguo

POSSIBILIDADE DE TESTE
 Adiciona o valor (’wallace’,‘ilikecheeze’) na tabela
Usuário
 Digite a URL http://localhost/myappum

 Problema?
POSSIBILIDADE DE TESTE
 Adiciona o valor (’wallace’,‘ilikecheeze’) na tabela
Usuário
 Digite a URL http://localhost/myappum

 Problema?
 Evite definir detalhes de implementação
BONS CRITÉRIOS DE ACEITAÇÃO SÃO
 Específicos
 Mensuráveis

 Alcançáveis

 Relevantes (em relação às necessidades do

usuário)
 Contidos no tempo (definir quando vão acontecer)
TESTE DE ACEITAÇÃO
 São:
 Critérios de aceitação +
 Exemplos (dados + cenários)
SOLUÇÃO DO EXERCÍCIO
 Adicione o usuário ao sistema: (‘wallace’,
‘ilikecheeze’)
 Execute o login com o usuário ‘wallace’ e a senha
‘blah’
 Verifique se o login falhou

 Execute o login com o usuário ‘wallace’ e a senha

‘ilikecheeze’
 Verifique se o login foi bem sucedido e se a
página welcome apareceu
REFERÊNCIAS
 Eliane Martins – INF321 : Fases de Teste –
unicamp
 http://www.slideshare.net/nashjain/acceptance-
test-driven-development-350264
 http://tastycupcakes.org/2009/06/99-test-balloons/