Uma importante atividade do processo de desenvolvimento de software é o teste de aceitação, que é a última atividade de teste realizada antes da implantação e que verifica se um sistema satisfaz ou não os critérios de aceitação. É nesse momento que os usuários do sistema devem decidir se vão aceitar ou não o sistema. Esta palestra apresenta uma visão geral do teste de aceitação, os principais problemas e desafios desses testes e as abordagens adotadas para solucioná-los.

1. Teste de Aceitação:
Problemas, desafios e
abordagens
Luiz Carlos da Silva Luz
luizluz@dcc.ufmg.br

2. Agenda
 Introdução
 Teste de aceitação
 Teste de aceitação durante o processo de
desenvolvimento de software
 Estratégias de implementação dos testes de aceitação
 Preparação do teste de aceitação
 Execução do teste de aceitação
 Resultados do teste de aceitação
 Testes de aceitação em processos ágeis
 Conclusão
 Bibliografia
2

3. Introdução

4. Introdução
 Antes da implantação…
– Será que o sistema em desenvolvimento está
pronto e já pode ser utilizado pelos usuários
finais para executarem tarefas que serão
apoiadas por ele, como é esperado?
4

5. Introdução
 No recebimento de um produto que foi contratado via
licitação ou por outros meios...…
– Será que o produto atende as especificações
técnicas e de negócio presente no edital ou
na documentação, que serviu de base para a
sua aquisição?
5

6. Introdução
 As estratégias adotadas para responder essas e outras
questões relacionadas à verificação das características
funcionais e não-funcionais de um software, segundo
uma determinada documentação, podem ser
denominadas de Teste de Aceitação
6

7. Teste de Aceitação

8. Teste de Aceitação
 Conceitos
– “(...) começa no fim do teste de integração, quando componentes
individuais já foram exercitados, o software está completamente
montado como um pacote, e os erros de interface foram descobertos e
corrigidos. (...)” O testes focaliza ações visíveis ao usuário e saídas do
sistema reconhecidas pelo usuário. (Pressman)
– É um teste formal relacionado às necessidades dos usuários, requisitos
e processos de negócios. É realizado para estabelecer se um sistema
satisfaz ou não os critérios de aceitação e para possibilitar aos usuários,
aos clientes e às outras entidades autorizadas decidir aceitar ou não
determinado sistema. (Glossário , ISTQB)
– (...) é de responsabilidade do cliente ou do usuário do sistema; os
interessados (stakeholders) também podem ser envolvidos. . (Syllabus ,
ISTQB)
– Garante a satisfação do cliente
• Os clientes não querem se comprometer com sistemas inadequados;

9. Teste de Aceitação
 Objetivos
– confirmar se o sistema está funcionando conforme o
esperado, ou seja, prover a confiabilidade de que
esteja de acordo com o requisito.
– avaliar a qualidade do software, para prover
informações sobre os riscos da implantação do
sistema em um determinado momento aos gestores.
• Procurar defeitos não é o principal foco do teste de aceite.

10. Teste de Aceitação
 Formas de Teste de Aceitação
– Teste de Aceitação de usuário
• Verifica se o sistema está apropriado para o uso por um
usuário com perfil de negócio
– Teste Operacional de Aceite
• O aceite do sistema pelo administrador dos sistemas, que
verifica:
– Atendimento às configurações de ambiente.
– Atendimento às rotinas administrativas: backup, gerenciamento
de usuários, etc

11. Teste de Aceitação
 Formas de Testes de Aceitação
– Teste de aceitação de contrato e regulamento
• Teste de aceitação de contrato: verifica se os critérios de
aceite incluso em contrato na produção de software
encomendado.
– Os critérios de aceite devem ser definidos quando o contrato é
assinado.
• Teste de aceitação de regulamento: verifica a necessidade
de adesão a algum regulamento de acordo com
determinadas normas (ex.: segurança, governamental,
legislação).

12. Teste de Aceitação
 Formas de Testes de Aceitação
– Alfa e Beta Teste (ou teste no campo)
• Teste Alfa: é realizado no ambiente da organização em que o
produto foi desenvolvido. É realizado pelos clientes ou por
uma equipe de teste independente.
• Teste Beta (ou teste no campo): é realizado pelas pessoas ou
pelos clientes em seu próprio ambiente de trabalho.
• O objetivo desses testes é obter um feedback dos clientes ou
usuários do sistema antes do sistema entrar em produção ou
ser disponibilizado para comercialização.

13. Teste de Aceitação durante o
desenvolvimento do software

14. Teste de aceitação durante o desenvolvimento do software
 Níveis de Teste
Teste de Aceite pode ser
realizado em mais de um
único nível:
•Processo de alteração;
•Teste de aceitação de
usabilidade;
•Teste de aceite de uma nova
funcionalidade

15. Estratégia de implementação
do Teste de Aceitação

16. Estratégia de implementação do teste de aceitação
 Teste de Aceitação Formal
– O teste de aceitação formal é um processo altamente
gerenciado e costuma ser uma extensão do teste do
sistema.
– Os testes são planejados e projetados com o mesmo
cuidado e nível de detalhe do teste do sistema.
– Teste de aceitação de contrato ou regulamento
geralmente são implementados como Teste de
Aceitação Formal.

17. Estratégia de implementação do teste de aceitação
 Teste de Aceitação Informal
– No teste de aceitação informal, os procedimentos para executar
o teste e os critérios de aceitação não são definidos com tanto
rigor como no teste de aceitação formal.
– O testador individual determina o que fazer.
• Teste Alfa
– Essa abordagem de teste de aceitação não é tão controlada e é mais
subjetiva.
– As funções e as tarefas de negócios a serem exploradas são
identificadas e documentadas, mas não há casos de teste específicos
para seguir.
• Teste Beta
– Não há nenhum controle, a quantidade de detalhes, os dados e a
abordagem adotada são de inteira responsabilidade do testador
individual
– Cada testador é responsável por criar o próprio ambiente, selecionar os
dados correspondentes e determinar as funções, os recursos ou as
tarefas a serem exploradas.
– Cada um deles é responsável por identificar os próprios critérios que o
levarão a aceitar ou rejeitar o sistema no seu estado atual.

18. Estratégia de implementação do teste de aceitação
– Pode ser implementada mais de uma estratégia de
testes em um mesmo projeto, tendo como benefícios:
• o aumento da possibilidade de identificar defeitos;
• a redução dos riscos, e ;
• o aumento da confiança no sistema e da satisfação do
cliente.

19. Estratégia de implementação do teste de aceitação
– Qual estratégia de implementação de teste de
aceitação eu devo adotar?
• Essa decisão dependerá....
– do compromisso com a qualidade do sistema;
– da disponibilidade dos usuários;
– das restrições de custo ou de prazo;
– das características do processo de desenvolvimento de
Software adotado pela organização.
– da confiança que se tem na equipe independente de testes.

20. Preparação do Teste de
Aceitação

21. Preparação do teste de aceitação
 Teste de Aceitação Formal
– As atividades e os artefatos são os mesmos do teste
do sistema.
– A preparação consiste em escolher um subconjunto
dos testes já realizados e de adaptar a linguagem e as
informações presentes nas especificações de testes
de sistema aos usuários que também participarão
desses testes.
– Exige recursos, planejamento e preparação do
ambiente de testes.

22. Preparação do teste de aceitação
 Teste de Aceitação informal
– Teste Alfa
• Preparação do ambiente de teste;
• Preparação da documentação sobre as partes do sistema
que serão testadas;
• Preparação de roteiros de testes ou descrição de possíveis
cenários que serão testados;
• Exige recursos, planejamento e preparação do ambiente de
testes.
– Teste Beta
• Preparação da documentação sobre as partes do sistema
que serão testadas

23. Execução do Teste de
Aceitação

24. Execução do teste de aceitação
 Teste de Aceitação Formal
– A execução pode ser manual ou os testes podem ser
automatizados, permitindo teste de regressão.
– Durante a execução o progresso dos testes pode ser
medido ou monitorado;

25. Execução do teste de aceitação
 Teste de Aceitação informal
– Teste Alfa
• As funcionalidades e cenários que serão testados são conhecidos.
• O progresso dos testes pode ser medido e monitorado, com base na nos
roteiros ou cenários já exercitados.
• Os recursos do teste de aceitação não estão sob o controle do projeto e
podem ser limitados.
• Não há controle sobre os testes que estão sendo realizados.
• Exige acompanhamento para:
– orientar quanto a execução dos roteiros;
– orientar quanto ao uso do software;
– e para apoiar no registro dos problemas identificados.
– Teste Beta
• É difícil medir o progresso do teste.
• Os recursos do teste de aceitação não estão sob o controle do projeto e
podem ser limitados.
• Em alguns casos pode exigir acompanhamento para apoiar no registro dos
problemas identificados.
– Nos testes informais é importante apresentar os objetivos dos testes
para os usuários

26. Execução do teste de aceitação
 Correção de defeito durante os testes
– É possível que ocorram durante os testes defeitos que
impedem a verificação de determinados critérios de
aceitação.
• Esses defeitos terão que ser corrigidos durante a fase de
teste de aceitação;
• Será necessário garantir, através de teste de sistema ou de
teste de regressão, que a correção desses defeitos não gerou
novos defeitos que inviabilizem a continuidade dos testes de
aceitação;
 O teste de aceitação só é finalizado quando todos os
defeitos críticos forem corrigidos e os critérios de
aceitação forem devidamente verificados.

27. Resultados do Teste de
Aceitação

28. Resultados do teste de aceitação
 Teste de Aceitação Formal
– Os testes podem ser uma nova implementação dos
testes do sistema.
• Geralmente não são identificados novos problemas já que
são procurados apenas os defeitos já esperados.
– Os critérios de aceitação são conhecidos.
• O relatório final consiste em informar se os critérios de
aceitação foram ou não atendidos e qual é o impacto do não
atendimento deles, quando eles falharem ou não puderem ser
verificados.

29. Resultados do teste de aceitação
 Teste de Aceitação informal
– Teste Alfa
• Os usuários finais podem se adaptar à forma como o sistema
funciona e não encontrar defeitos.
• Os usuários finais podem se concentrar na comparação do
novo sistema com um sistema antigo, em vez de procurar
defeitos.
– Identificação de melhorias ou alterações ao invés de defeito.
• São revelados defeitos subjetivos.
• Os critérios de aceitação são conhecidos e estão
relacionados aos roteiros ou cenários exercitados durante os
testes.
– O relatório final consiste em informar se os critérios de aceitação
foram ou não atendidos e qual é o impacto do não atendimento
deles, quando eles falharem ou não puderem ser verificados

30. Resultados do teste de aceitação
 Teste de Aceitação informal
– Teste Beta
• Nem todas as funcionalidades podem ser testadas.
• Os usuários finais podem se adaptar à forma como o sistema
funciona e não encontrar defeitos.
• Os usuários finais podem se concentrar na comparação do
novo sistema com um sistema antigo, em vez de procurar
defeitos.
– Identificação de melhorias ou alterações ao invés de defeito.
• Aumenta a satisfação do cliente para aqueles que participam.
• São revelados defeitos subjetivos.
• Os critérios de aceitação não são conhecidos.
– O relatório final consiste na apresentação dos defeitos
identificados pelos participantes durante os testes e da
declaração deles quanto à satisfação e ao aceite do produto;

31. Teste de Aceitação em
processos ágeis

32. Teste de aceitação em processos ágeis
 São escritos pelo cliente
– Durante a escrita da histórias de usuários o cliente
define pontos de verificação
• O ponto de verificação permite verificar se o sistema atende
determinada funcionalidade associada à história de usuário.
• Os pontos de verificação são utilizados na escrita de testes
de aceitação (ou Story Test, ou Customer Test) que
descrevem cenários (de sucesso ou não) que contemplam a
expectativa do cliente em relação a uma determinada
funcionalidade ou à história de usuário.
– Deve existir pelo menos um teste de aceitação para
cada história de usuário.
– Uma história de usuário só pode ser considerada
acabada quando seus testes de aceitação executarem
completamente.

33. Teste de aceitação em processos ágeis
 Pode ser automatizado
– Permitindo a realização de testes de regressão
durante todo o período de desenvolvimento do
software e garantindo que as histórias de usuários
continuam sendo atendidas apesar das modificações
realizadas no sistema.
 Papel importante no refinamento da análise
– Além de garantir o correto funcionamento do sistema o
teste de aceitação pode ser utilizado para refinar a
análise e garantir que a equipe esteja sempre
trabalhando naquilo que é importante para o cliente.

34. Conclusão

35. Conclusão
 Determinada falhas em
produção podem ser
dramáticas, podem ter
prejuízos irreversíveis e
podem apresentar um
custo muito alto para a
organização.
 Invista na qualidade dos
testes de aceitação!
Falha de paraquedas a 1.500 metros de altura. (Mar/2012)

36. Referências

37. Referências Bibliográficas
 Pressman, R. S. (2006). Engenharia de Software. Mcgraw-Hill, 6 a
edição edição.
 Filho, W. P. P. (2003). Engenharia de Software: Fundamentos,
Métodos e Padrões. LTC, 2 a edição edição.
 Syllabus Fundation, BSTQB, versão 2011br. Disponível em
http://www.bstqb.org.br
 Glossário de termos, BSTQB, versão 2.1.1br. Disponível em
http://www.bstqb.org.br
 RUP,IBM, versão 2002.05.00 Português. Disponível em
http://www.wthreex.com/rup/index.htm

38. ?
Dúvidas

39. Obrigado