Testes de aceitação automatizados evidenciam rastreabilidade, cobertura e desempenho de software

1.756 visualizações

Publicada em

Apresentação realizada por Edmundo Andrade (edworld) no evento Agile Brazil 2012, em São Paulo, no dia 6 de setembro de 2012.
Com a ampla disseminação dos métodos ágeis nos últimos anos, a automação de testes tornou-se popular entre os desenvolvedores de software. O custo da escrita de testes automatizados (de aceitação, de unidade etc.) costuma ser compensado pelo maior grau de confiabilidade e de manutenibilidade do software resultante.
O objetivo da palestra foi demonstrar como os testes de aceitação automatizados podem subsidiar a gestão dos produtos de software, evidenciando características importantes tais como: rastreabilidade com requisitos, rastreabilidade com código-fonte, cobertura de código e desempenho. Durante a demonstração, foram utilizadas soluções de código aberto.

Publicada em: Tecnologia
0 comentários
5 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
1.756
No SlideShare
0
A partir de incorporações
0
Número de incorporações
16
Ações
Compartilhamentos
0
Downloads
30
Comentários
0
Gostaram
5
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Testes de aceitação automatizados evidenciam rastreabilidade, cobertura e desempenho de software

  1. 1. Agenda• Rastreabilidade• Testes de aceitação• Acceptance TDD• Instrumental open-source• Considerações finais
  2. 2. Aprendizado  Estratégia/Políticas
  3. 3. Rastreabilidade negocial Teste de aceitação X.1 Story X Teste de Feature 1 aceitação X.2 Teste de Story Y aceitação Y.1Propósito A Teste de aceitação Z.1 Feature 2 Story Z Teste de aceitação Z.2
  4. 4. Rastreabilidade negocial Teste de aceitação X.1 Story X Teste de Feature 1 aceitação X.2 Teste de Story Y aceitação Y.1Propósito A Teste de aceitação Z.1 Feature 2 Story Z Teste de aceitação Z.2
  5. 5. Rastreabilidade técnica Teste de aceitação Fixture code X.1 X.1 Teste de aceitação Fixture code X.2 X.2Story X Teste de aceitação Fixture code X.3 X.3 Procedimentos de aceitação manuais ou semiautomatizados
  6. 6. Rastreabilidade técnica Teste de aceitação Fixture code X.1 X.1 Teste de aceitação Fixture code X.2 X.2Story X Teste de aceitação Fixture code X.3 X.3 Procedimentos de aceitação manuais ou semiautomatizados
  7. 7. Robert Martin & Grigori Melnik, 2008 IEEE Software Tests and Requirements, Requirements and Tests: A Möbius StripFonte: http://www.gmelnik.com/papers/IEEE_Software_Moebius_GMelnik_RMartin.pdf
  8. 8. Edsger Wybe Dijkstra, 1968Conf. Eng. Soft. OTANAlemanha, 7 a 11/out/1968“The conclusion is that making thepredocumentation at the propermoment, and using it, will improvethe efficiency with which youconstruct your whole thing incredibly.One may wonder, if this is soobvious, why doesn’t it happen? Iwould suggest that the reason whymany programmers experience themaking of predocumentation as anadditional burden, instead of atool, is that whateverpredocumentation he produces cannever be used mechanically. Only ifwe provide him with more profitablemeans, preferably mechanical, forusing predocumentation, only thenwill the spiritual barrier be crossed.” Foto: http://homepages.cs.ncl.ac.uk/brian.randell/NATO/N1968/
  9. 9. Edsger Wybe Dijkstra, 1969Conf. Téc. Eng. Soft. OTANItália, 27 a 31/out/1969“The most basic aspectsare, on the one hand, what aroutine does for you and, onthe other hand, how it works.My point is that on no level ofabstraction are both of theseaspects simultaneously ofrelevance if the routine isnot recursive. These aspectscan therefore be clearlyseparated.” Foto: homepages.cs.ncl.ac.uk/brian.randell/NATO/N1969/
  10. 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. 11. Lasse Koskela, 2008Methods & ToolsAcceptance TDD Explained“Acceptance tests are specificationsfor the desired behavior andfunctionality of a system. They tellus, for a given user story, how thesystem handles certain conditionsand inputs and with what kinds ofoutcomes” Foto: http://twitter.com/lassekoskela
  12. 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. 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. 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. 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. 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. 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. 18. Instrumental Teste de FixtureStory aceitação code JUnit Fit Fitnesse Concordion Cucumber ou crie solução específica
  19. 19. Cucumber
  20. 20. Concordion
  21. 21. Concordion :assertEquals :set :execute :verifyRows
  22. 22. FitNesse
  23. 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

×