O documento descreve a estratégia de "Snapshot Tests" adotada por um instituto de P&D para melhorar a qualidade de código e reduzir falhas. A estratégia envolve a realização contínua de testes à medida que novas funcionalidades são desenvolvidas, permitindo identificar problemas de imediato. Isso reduz significativamente o tempo gasto na detecção e correção de erros quando comparado ao modelo anterior de testes apenas após releases.

2. Instituto de P&D localizado
em Manaus (hardware e
software)

3. Treinamentos Constantes

4. Ambiente Descontraído

5. Criatividade e melhoria
contínua de nossos
processos

6. Surgiu a ideia de melhorar
nosso processo de
desenvolvimento com
Snapshot Tests

7. Mas como é nosso processo
de desenvolvimento?

8. Scrum

9. Temos 30 times que
utilizam Scrum

10. Definition of Done (DoD)

11. Todo Sprint Backlog deve ter sido desenvolvido e testado.
Todas as falhas identificadas durante o Sprint devem ter sido
corrigidas e verificadas. E todas as metas de qualidade de
código devem ter sido atingidas.

12. Qualidade
de Código
Codificação
Verificação Testes

14. Após a conclusão de um conjunto
de funcionalidades, o time gera
uma versão para testes

15. Testes de Release

17. Lições aprendidas: não dava
tempo de corrigir e verificar
as falhas

18. Time tinha a sensação de “nadar, nadar e morrer na praia”

19. Esse tipo de problema faz parte da realidade dos times de
vocês?

20. Snapshot Tests

21. Não precisar aguardar uma release para iniciar os testes

22. Estratégia batizada de “Snapshot Tests”

23. O termo “Snapshot” remete ao Maven

24. Mas não é uma ideia atrelada a uma ferramenta

25. Tem mais a ver com
integração do time
Do que com
ferramentas

26. Snapshot Tests

27. Falhas encontradas são imediatamente comunicadas

28. O que é preciso para que
essa estratégia funcione?

29. Todo time fisicamente
próximo

31. Time deve compreender a
importância da estratégia

32. Boa comunicação do time
é fundamental

33. Releases não deixam de existir

34. Mas então qual a
vantagem?

35. Antecipação de falhas

36. Problema detectado o quanto antes

37. Redução de Falhas nos Testes de Release

38. Redução do Tempo de Registro das Falhas

39. Redução do Tempo de Registro das Falhas

40. Redução do Tempo de Registro das Falhas

41. Redução no Tempo de Reporte de Falhas
61 falhas * 8 min = 488 min = >8 horas

42. Redução no Tempo de Reporte de Falhas
48 falhas * 2 min = 96 min = >1.5 horas
13 falhas * 8 min = 104 min = < 2 horas

43. Se convertermos esse
tempo em dinheiro…

44. 220h -> R$ 5.000,00
8 h -> ?
Se convertermos esse
tempo em dinheiro…
220h -> R$ 5.000,00
3,5 h -> ?

45. Se convertermos esse
tempo em dinheiro…
220h -> R$ 5.000,00
8 h -> R$ 181,82
220h -> R$ 5.000,00
3,5 h -> R$ 79,55

46. E para 30 testadores…
R$ 5454,60
R$ 2386,50

47. Automação de testes
Especificação de
novos cenários
“Educação” do
desenvolvedor
para testar

49. Muito Obrigada!
Carla Oran
coran@fpf.br