Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Porque você precisa de uma estratégia de QA e precisa disso AGORA!

294 views

Published on

Veremos como uma pessoa ou time dedicado ao controle de qualidade pode trabalhar com o gerente do projeto e/ou líder técnico/arquiteto para garantir uma melhor cobertura de casos de usos e testes em múltiplos projetos, e como isso impactará a entrega final. Além disso, também precisamos ensinar os clientes que essa estratégia é importante e devemos investir dinheiro nisso cedo para evitar grandes perdas depois Já passou o momento de levarmos controle de qualidade mais a sério.

Published in: Software

Porque você precisa de uma estratégia de QA e precisa disso AGORA!

  1. 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. 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. 3. Senta que lá vem a história (bem conhecida de muitos, creio)
  4. 4. RFP
  5. 5. Contrato
  6. 6. Análise e planejamento
  7. 7. Alocação de time? 1 Desenvolvedor / Backend 1 Webdev / Frontend Scurm Master e Líder técnico/Arquiteto? Compartilhados entre 10 projetos
  8. 8. Quem testa? Dev! Webdev! SM!
  9. 9. Code review? Oi? UAT? Pff… Site entregue! o/
  10. 10. Cliente diz… … que layout tem erros gritantes. … que as principais áreas do site não funcionam. … que o site está muito lento.
  11. 11. Ultimato! Site corrigido e em produção em 4 dias… … ou atitudes serão tomadas
  12. 12. Abasteça
  13. 13. TASK FORCE (!!!)
  14. 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
  15. 15. Planejamento de QA (ou testes)
  16. 16. Três coisas que levam a clientes infelizes: atraso na entrega, custos e bugs.
  17. 17. “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
  18. 18. 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
  19. 19. 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)
  20. 20. 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
  21. 21. Tenha uma pessoa (ou time) dedicada aos testes
  22. 22. 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.
  23. 23. 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
  24. 24. Test early. Test Often. (teste cedo, teste sempre)
  25. 25. Functional testing
  26. 26. Regression testing Garantir que partes do produto que já foram terminadas e testadas continuem funcionando depois que outras mudanças foram feitas ao sistema.
  27. 27. Smoke testing Garantir que as funcionalidades críticas ao negócio estão devidamente implementadas e funcionais.
  28. 28. Algumas ferramentas (várias)
  29. 29. 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
  30. 30. 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
  31. 31. Browser Testing Testing sites on real mobile and desktop browsers https://www.browserstack.com https://saucelabs.com http://appium.io
  32. 32. E-mail testing Testar visualização de e-mails em diversos clientes https://litmus.com/email-testing
  33. 33. Teste de Layout Comparando versões em busca de alterações https://github.com/everright/erSiteComparehttp://backtrac.io
  34. 34. BDD Behavior Driven Development http://behat.org StoryBDD http://www.phpspec.net SpecBDD
  35. 35. 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
  36. 36. 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
  37. 37. Enfim... Você precisa de uma boa estratégia de teste!
  38. 38. Obrigado!
  39. 39. Perguntas? Daniel Carvalhinho daniel@dscl.com.br http://www.linkedin.com/in/danielscl http://twitter.com/dscl http://dgo.to/@dscl

×