O documento discute a importância de se ter uma estratégia de teste de qualidade (QA) para projetos de desenvolvimento de software. Ele explica que a falta de planejamento e execução adequados de testes pode levar a atrasos, custos extras e problemas para o cliente. Além disso, apresenta diversas ferramentas e técnicas para se realizar testes funcionais, de regressão, de fumaça, análise estática de código, testes em navegadores, de layout, de velocidade e sob carga, entre outros.

1. Porque você precisa de
uma estratégia de QA e
precisa disso AGORA!
PHP Conference Brasil 2016 – São Paulo, Brasil
10 de Dezembro de 2016
Daniel Carvalhinho
daniel@dscl.com.br

2. Quem sou eu?
Software Engineer @ Council on Foreign Relations
Contribuidor, Tradutor e Revisor @ Drupal.org
Colaborador @ Associação Drupal do Brasil
17 anos de experiência com PHP
7 anos focando em Drupal
Morei 2 anos na China, comi gafanhoto sim, mas não cachorro.
Mas Chinês não come nenhum dos dois. :)
Viciado em viajar, já estive em 19 países (acho).

3. Senta que lá vem a história
(bem conhecida de muitos, creio)

4. RFP

5. Contrato

6. Análise e planejamento

7. Alocação de time?
1 Desenvolvedor / Backend
1 Webdev / Frontend
Scurm Master e Líder técnico/Arquiteto?
Compartilhados entre 10 projetos

8. Quem testa?
Dev!
Webdev!
SM!

9. Code review? Oi?
UAT? Pff…
Site entregue! o/

10. Cliente diz…
… que layout tem erros gritantes.
… que as principais áreas do site não funcionam.
… que o site está muito lento.

11. Ultimato!
Site corrigido e em produção em 4 dias…
… ou atitudes serão tomadas

12. Abasteça

13. TASK FORCE (!!!)

14. Principais razões para falha:
● Estimativas equivocadas
● Falta de planejamento de QA
● Alocação insuficiente
● Mudanças além do aceitável
Principais razões para falha:
● Estimativas equivocadas
● Falta de planejamento de QA
● Alocação insuficiente
● Mudanças além do aceitável

16. Planejamento de QA
(ou testes)

17. Três coisas que levam a clientes infelizes:
atraso na entrega, custos e bugs.

18. “O custo para corrigir um erro encontrado depois do lançamento
do produto é de quatro a cinco vezes maior que um erro
encontrado na fase de especificação, e até 100 vezes mais
quando encontrado na fase de manutenção.
Systems Sciences Institute at IBM

19. Cultura Variável: a gestão não entende que qualidade é uma questão de
gerenciamento. Problemas são resolvidos com grandes esforços pessoais, e não em
uma abordagem sistemática.
Cultura da Rotina: a gestão concorda que qualidade pode ser importante, mas não
existe dinheiro ou time alocado para fazer com que ela aconteça. Times geralmente
corrigem problemas depois que um problema grave aconteceu.
Cultura da Gestão: a gestão reconhece que qualidade é uma questão sistemática, e
que auxilia os gerentes a gerenciar melhor. Problemas são trazidos à tona, discutidos e
resolvidos de maneira ordenada.
Weinberg, Gerald M., Quality Software Management, Volume 1, Systems Thinking, Dorset House, New York. 1992.
Abordagem dos problemas

20. Conformidade:
● Custos de prevenção - investimento feito em treinamento, levantamento de
requisitos, code reviews, etc.
● Custos de avaliação - investimento gasto em planejamento de testes,
desenvolvimento de casos de teste e execução dos testes.
Não-conformidade:
● Falhas internas - gastos criados por testes que falham na primeira execução.
● Falhas externas - gastos criados como consequência de falhas encontradas pelo
cliente. Geralmente serão custos maiores que para falhas internas. Pode chegar
ao nível judicial.
Conformidade vs. Não-conformidade (custos)

21. Análise de Requisitos
Custo = tempo que se leva para se reeescrever o requisito.
Codificação/Desenvolvimento
Custo = horas adicionais de desenvolvimento.
Integração de Sistema:
Custo = horas adicionais de desenvolvimento e de integração.
Testes
Custos = horas adicionais de desenvolvimento, de integração, do PM e de QA.
User Acceptance Testing (UAT)
Custo = additional required developer, system engineer, PM, customer, and QA hours.
Produção
Custo = horas adicionais de desenvolvimento, suporte, integração, PM, cliente e QA.
Custo do bug vs. Fase de desenvolvimento

22. Tenha uma pessoa (ou time)
dedicada aos testes

23. Mas quando envolver o tester?
RFP?
Geralmente muito cedo. Mas dependendo da complexidade do projeto, pode ser
necessária a consulta.
Análise e Planejamento?
Com certeza. Antes mesmo do resto do time.
O Tester precisa conhecer o projeto melhor que todos.
Idealmente, tanto quanto o cliente para atuar como um PO interno.

24. Planning
Tester
… deve atuar como um braço direito do Líder técnico e do ScrumMaster
… será decisivo na definição dos critérios de aceitação das User Stories
… será responsável pela criação dos Test Cases relacionados a cada Story,
ajudando assim o desenvolvedor a testar o seu trabalho de uma forma
não-viciada.
Desenvolvedores
… devem usar o Test Case como complemento de seus testes.
… devem sempre informar caminho ou URLs relacionados a seus tickets.
… devem garantir que as boas práticas estão sendo aplicadas

25. Test early. Test Often.
(teste cedo, teste sempre)

26. Functional testing

27. Regression testing
Garantir que partes do produto que já foram terminadas e testadas continuem
funcionando depois que outras mudanças foram feitas ao sistema.

28. Smoke testing
Garantir que as funcionalidades críticas ao negócio
estão devidamente implementadas e funcionais.

29. Algumas ferramentas
(várias)

30. PHP Static Analysis Tools - https://github.com/exakat/php-static-analysis-tools
Lista com diversas ferramentas de extrema utilidade para garantir a qualidade do código.
Alguns destaques:
● PHPCPD - Encontra trechos de código que foram copiados e colados. DRY
● PHP Mess Detector - Encontra potenciais problemas no código..
● PHP Code Sniffer - PHPCS checa o padrão do código.
Escolha um padrão de código, ou use o padrão do framework (ou ferramenta/CMS) que
você usa.
Siga a risca, use o PHPCS (talvez até um pré-commit hook)
Qualidade de Código

31. Links quebrados (e mais)
robots.txt , sitemap.xml ,listas de URLs, etc
http://home.snafu.de/tilman/xenulink.html https://www.screamingfrog.co.uk/seo-spider

32. Browser Testing
Testing sites on real mobile and desktop browsers
https://www.browserstack.com https://saucelabs.com
http://appium.io

33. E-mail testing
Testar visualização de e-mails em diversos clientes
https://litmus.com/email-testing

34. Teste de Layout
Comparando versões em busca de alterações
https://github.com/everright/erSiteComparehttp://backtrac.io

35. BDD
Behavior Driven Development
http://behat.org
StoryBDD
http://www.phpspec.net
SpecBDD

36. Análise de velocidade
encontrando gargalos e analisando boas práticas
https://tools.pingdom.comhttp://www.webpagetest.org
https://developers.google.com/speed/pagespeedhttp://yslow.org

37. Load test
Testando a performance do seu site sob estresse
http://jmeter.apache.org https://www.blazemeter.com
Apache Benchmarking (ab)
https://httpd.apache.org/docs/2.4/programs/ab.html

38. Enfim...
Você precisa de uma boa estratégia de teste!

39. Obrigado!

40. Perguntas?
Daniel Carvalhinho
daniel@dscl.com.br
http://www.linkedin.com/in/danielscl
http://twitter.com/dscl
http://dgo.to/@dscl