drupal e a qualidade de software
TRANSCRIPT
Drupal e a Qualidade de Software
Daniel CarvalhinhoLead DeveloperTrellon, LLC
Mas quem é você?
Daniel Carvalhinho[AKA Carval(h)inho, dscl, diesel, dlopes, CaramelHippos]
Desenvolvedor PHP há 16+ anosDesenvolvedor Drupal há 6+ anosLead Developer na Trellon, LLC
DrupalTradutor e Revisor no time Brazilian PortugueseCo-autor do módulo Entity ScaffoldMentor do Core Sprint (DrupalCon)Organizador de eventos e Global Training Days
http://drupal.org/u/dsclIRC: dscl
RFP
Contrato
Análise e planejamento
Alocação de time?1 Desenvolvedor / Backend1 Webdev / Frontend
Scurm Master e Líder técnico/Arquiteto?Compartilhados entre 10 projetos
Quem testa?Dev!
Webdev!SM!
Code review? Oi?UAT? Pff…
Site entregue! \o/
Cliente diz…… que layout tem erros gritantes.… que as principais áreas do site não funcionam.… que o site está muito lento.
Ultimato!Site corrigido e em produção em 4 dias…
… ou atitudes serão tomadas
Abasteça
TASK FORCE (!!!)
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
Planejamento de QA(ou testes)
Tenha uma pessoa (ou time) dedicada aos testes
E 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.
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
Drupal e boas práticas
Never hack core (https://www.drupal.org/best-practices/do-not-hack-core)
Evite hardcoding (https://www.drupal.org/node/1052556)
Boas práticas em uso e configuração (https://www.drupal.org/best-practices)
Padrões de código (https://www.drupal.org/coding-standards)
Documente seu projeto (https://www.drupal.org/node/632262)
Escreva código seguro (https://www.drupal.org/writing-secure-code)
Boas práticas de Acessibilidade (https://www.drupal.org/node/1637990)
Drupal e boas práticas
PHP_CodeSniffer - https://github.com/squizlabs/PHP_CodeSniffer Scripts PHP que realizam checagens em código PHP baseados em certo padrões
Coder - https://www.drupal.org/project/coder Definições para validação de padrões de código e boas práticas Drupal para ser usado pelo PHP_CodeSniffer
DrupalPractice - https://www.drupal.org/project/drupalpractice (merged into Coder)Definições para validação de boas práticas Drupal para ser usado pelo PHP_CodeSniffer
DrupalSecure - https://www.drupal.org/sandbox/coltrane/1921926 Definições sobre código seguro para ser usado pelo PHP_CodeSniffer
Codespell - https://github.com/lucasdemarchi/codespell Verifica erros de grafia comuns em inglês.
PAReview.sh - http://pareview.sh Project Application Review. Usado para revisão de módulos completos.
Drupal e boas práticas
Menção honrosa
Coder Tough Love - https://www.drupal.org/project/coder_tough_love
“Coder Tough Love is a companion to the existing Coder module by Doug Green. Unlike Coder, which strives to follow the documented style guidelines of Drupal core, Coder Tough Love takes the tougher tactic of applying finely aged and obsessively anal wisdom from years of Drupal development and persnickety quality control.”
Criado por Morbus Iff
Drupal e boas práticas
Crie um atalho para executar o PHPCS com as definições do Coder sobre qualquer código que deseje.
Todo desenvolvedor deve executar essas verificações antes de seus commits (preferencialmente automaticamente pela IDE)
O Tester consegue executar a mesma validações com as mesmas ferramentas.A diferença é que o Tester apenas reportará os possíveis erros para os desenvolvedores que são os responsáveis pela correção ou justificativa plausível para falso positivos.
Test early. Test Often.(teste cedo, teste sempre)
Functional testing
Regression testing
Garantir que partes do produto que já foram terminadas e testadas continuem funcionando depois que outras mudanças foram feitas ao sistema.
Smoke testing
Garantir que as funcionalidades críticas ao negócio estão devidamente implementadas e funcionais.
Outras ferramentas(várias)
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
Browser TestingTesting sites on real mobile and desktop browsers
https://www.browserstack.com https://saucelabs.com
http://appium.io
Teste de LayoutComparando versões em busca de alterações
https://github.com/everright/erSiteComparehttp://backtrac.io
BDDBehavior Driven Development
http://behat.org
StoryBDD
http://www.phpspec.net
SpecBDD
Análise de velocidadeencontrando gargalos e analisando boas práticas
https://tools.pingdom.comhttp://www.webpagetest.org
https://developers.google.com/speed/pagespeedhttp://yslow.org
Load testTestando 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
Enfim...Você precisa de uma boa estratégia de teste!
Obrigado!
Perguntas?
Daniel [email protected]
http://www.linkedin.com/in/danielsclhttp://twitter.com/dsclhttp://dgo.to/@dscl