O documento discute técnicas de teste de aceitação como Acceptance Test-Driven Development (ATDD) e rastreabilidade, e menciona ferramentas como JUnit, Fit, FitNesse, Concordion e Cucumber. Ele também discute estilos de teste como ponta-a-ponta, acesso subcutâneo e exercitando os internos.

2. Agenda
• Rastreabilidade
• Testes de aceitação
• Acceptance TDD
• Instrumental open-source
• Considerações finais

3. Rastreabilidade negocial
Propósito A
Feature 1
Story X
Teste de
aceitação X.1
Teste de
aceitação X.2
Story Y
Teste de
aceitação Y.1
Feature 2 Story Z
Teste de
aceitação Z.1
Teste de
aceitação Z.2

4. Rastreabilidade negocial
Propósito A
Feature 1
Story X
Teste de
aceitação X.1
Teste de
aceitação X.2
Story Y
Teste de
aceitação Y.1
Feature 2 Story Z
Teste de
aceitação Z.1
Teste de
aceitação Z.2

5. Rastreabilidade técnica
Story X
Teste de aceitação
X.1
Fixture code X.1
Teste de aceitação
X.2
Fixture code X.2
Teste de aceitação
X.3
Fixture code X.3
Procedimentos de
aceitação manuais
ou
semiautomatizados

6. Rastreabilidade técnica
Story X
Teste de aceitação
X.1
Fixture code X.1
Teste de aceitação
X.2
Fixture code X.2
Teste de aceitação
X.3
Fixture code X.3
Procedimentos de
aceitação manuais
ou
semiautomatizados

7. Robert Martin & Grigori Melnik, 2008
IEEE Software
Tests and Requirements, Requirements and Tests: A Möbius Strip
Fonte: http://www.gmelnik.com/papers/IEEE_Software_Moebius_GMelnik_RMartin.pdf

8. Edsger Wybe Dijkstra, 1968
Conf. Eng. Soft. OTAN
Alemanha, 7 a 11/out/1968
“The conclusion is that making the
predocumentation at the proper
moment, and using it, will improve
the efficiency with which you
construct your whole thing incredibly.
One may wonder, if this is so
obvious, why doesn’t it happen? I
would suggest that the reason why
many programmers experience the
making of predocumentation as an
additional burden, instead of a tool,
is that whatever predocumentation
he produces can never be used
mechanically. Only if we provide him
with more profitable means,
preferably mechanical, for using
predocumentation, only then will the
spiritual barrier be crossed.”
Foto: http://homepages.cs.ncl.ac.uk/brian.randell/NATO/N1968/

9. Edsger Wybe Dijkstra, 1969
Conf. Téc. Eng. Soft. OTAN
Itália, 27 a 31/out/1969
“The most basic aspects are,
on the one hand, what a
routine does for you and, on
the other hand, how it works.
My point is that on no level of
abstraction are both of these
aspects simultaneously of
relevance if the routine is
not recursive. These aspects
can therefore be clearly
separated.”
Foto: homepages.cs.ncl.ac.uk/brian.randell/NATO/N1969/

10. Teste de aceitação - nomes
• Especificação por exemplos
• Requisito executável
• Story test
• Teste funcional do sistema
• Teste de cliente
• Teste de aceitação

11. Lasse Koskela, 2008
Methods & Tools
Acceptance TDD Explained
“Acceptance tests are specifications
for the desired behavior and
functionality of a system. They tell
us, for a given user story, how the
system handles certain conditions
and inputs and with what kinds of
outcomes”
Foto: http://twitter.com/lassekoskela

12. Teste de aceitação - características
• Deve ser propriedade do cliente
• Deve ser escrito conjuntamente pelo cliente,
desenvolvedor e testador
• Deve tratar “O QUÊ”, não “COMO”
• Deve ser expresso na linguagem do domínio do
problema
• Deve ser concisa, precisa e não ambígua
• Pode ser escrita em linguagem diferente da
utilizada pelos programadores
• TDD diferente de ATDD

13. Teste de aceitação - exemplos
• [Story] Técnico de suporte visualiza histórico
do cliente na tela ao receber ligação.
– [Test] Número de assinante válido
– [Test] Número de assinante inexistente
– [Test] Número de assinante não fornecido

14. Acceptance TDD – Ciclo robusto
• Pegar próxima story do backlog da iteração corrente
• Conversar com o cliente sobre a story e seus testes de aceitação
• Escrever teste de aceitação (requisito)
• Automatizar teste de aceitação (escrever código fixture)
• Executar teste de aceitação (resultado esperado: falha)
• Escrever código de implementação, aplicando ciclos TDD
• Executar teste de aceitação (resultado esperado: sucesso)
• Refatorar e reexecutar teste de aceitação (resultado esperado: sucesso)
• Tratar impacto nos demais testes (conflito ou mudança de requisitos)
• Inserir teste de aceitação no processo de testes de regressão
• Validar story com cliente, que poderá aceitá-la como completada
• Coletar informações de gestão do software
– rastreabilidade story-teste
– rastreabilidade teste-design
– cobertura do código de implementação
– desempenho da execução dos testes
• Repetir tudo

15. Automatizar teste de aceitação
• Não adequado para avaliar usabilidade e
atratividade da solução.
• Adequado para tarefas ordinárias repetitivas.
• Não substitui um bom testador, mas o apóia.
• Momento em que a especificação surge
antes da implementação (algumas vezes,
ocorre em paralelo)
• VERMELHO  VERDE  VERDE …

16. Automatizar teste de aceitação
• Teste ponta-a-ponta (caixa preta) é bom,
mas não deve ser o único estilo.
• Escolha depende dos seguintes fatores:
– Story (lógica de domínio ou de apresentação)
– Turbulência (impacto de mudanças na interface)
– Tecnologia (facilidades e atalhos para testes)

17. Automatizar teste de aceitação
• Principais estilos:
– Ponta-a-ponta (interface externa real)
• Realista, lenta e instável.
• Instrumental: Junit, Fit, FitNesse, Concordion, JWebUnit
– Acesso subcutâneo (interface abstrata ou API)
• Semiartificial, rápida e estável.
• Instrumental: Junit, Fit, FitNesse, Concordion
– Exercitando os internos (classes de negócio)
• Pontual, rápida e estável.
• Instrumental: Junit, Fit , FitNesse, Concordion
– Contornando o irrelevante (stub de recurso externo)
• Artificial, rápida e estável.
• Instrumental: Junit, Fit , FitNesse, Concordion
– Portas dos fundos (manipulação de recurso externo)
• Instrumental: Junit, Fit , FitNesse, Concordion

18. Instrumental
Story
Teste de
aceitação
Fixture
code
JUnit
Fit
Fitnesse
Concordion
Cucumber
ou crie solução específica

19. Cucumber

20. Concordion

21. Concordion
:assertEquals
:set
:execute
:verifyRows

22. FitNesse

23. Considerações finais
• Testes não garantem ausência de defeitos.
• Sistemas muito críticos podem exigir métodos
formais de especificação e prova da corretude do
software.
• TDD contribui para qualidade interna e reduz custo e
tempo de manutenção do produto.
• ATDD contribui para qualidade externa e reduz custo
e tempo de verificação das funcionalidades produto.
• A partir das informações de cobertura coletadas pelo
software COBERTURA, pode se gerar:
– Matriz de rastreabilidade teste-design
– Relatório de desempenho dos testes