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 Carvalhinhodaniel@dscl.com.br

http://www.linkedin.com/in/danielsclhttp://twitter.com/dsclhttp://dgo.to/@dscl