Onde começa a Qualidade!?

Ao ler a indagação acima acredito que a maioria dos leitores entenderam que eu iria responder sobre onde a qualidade se inicia no processo de desenvolvimento, porém a intenção é apenas refletir um pouco sobre a perspectiva de qualidade, e como o (QA) pode ajudar dentro do processo de desenvolvimento em diferentes etapas.

Abaixo para argumentar um pouco foi traçado 3 tipos de profissionais.

Exemplo 1: Marcos vem trabalhando com (QA) por 3 anos e considera que o (QA) deva fazer apenas testes manuais e escrever planos de teste.

Exemplo 2: José vem atuando na área por 4 anos, já passou por times ágeis e em seu time atual, tem um papel estratégico na construção dos produtos durante as etapas de desenvolvimento.

Exemplo 3: Nando começou na área de qualidade faz 5 anos, possui conhecimento em diferentes metodologias e possui uma visão estratégica do produto. Atua diretamente com os desenvolvedores em práticas que aumentam a cobertura na qualidade das features que serão entregues.

Antigamente era mais comum ter profissionais preocupados em apenas entregar o projeto “codar, codar e codar” , entretanto hoje os profissionais tendem a ser mais dinâmicos. Abaixo uma ilustração mostrando a comparação entre gerações;

Brincadeiras a parte, cada vez mais as empresas estão deixando de ter uma ‘célula’ de qualidade e procurando por profissionais com um mindset mais voltado em entregar features com qualidade em todo processo.

“E você? Onde se encaixaria nos exemplos citados acima? Ou o que você realmente acha que um profissional que trabalha como um (QA) pode fazer para mudar a visão atual do mercado pensando um passo a frente?”

“Com base no que foi falado, então quando posso começar a ajudar na qualidade!?”

Listarei 5 coisas, e não levem como uma verdade absoluta, mas comigo sempre funcionou muito bem.

1) Alinhe expectativas

“Sou (QA) mas não sou o único responsável pela qualidade”

O interessante é reunir a equipe e discutir qual é o seu papel dentro do time e o que seria benéfico desenvolver a curto/médio prazo pra assegurar um produto com mais qualidade. Tive a oportunidade na empresa que trabalho atualmente de ingressar em um time sem nenhum desenvolvimento, chamei os Devs do time para conversar e apresentar minhas ideias, quando expliquei que queria participar de todo processo, para minha surpresa, um deles me convidou para parear no desenvolvimento e consequentemente aprendi muito em coisas que não tinha experiência como testes de unidade, testes de componentes, mock de componentes, injeção de dependência entre muitas outras coisas.

2) Exija maior atenção sobre as definições de pronto nas histórias

Nas definições de pronto podem incluir não apenas requisitos, mas também cenários de testes unitários, componentes e integrados como entregáveis. E apesar de na maioria das vezes a história ser responsabilidade do Product Owner/Manager, todos do time tem autonomia e liberdade para ajudar a construir as definições de pronto, assim como apontar os riscos do entregável.

3) Seja curioso peça para parear com os Devs nos testes ou desenvolvimento

Quanto mais familiar com a implementação mais fácil de encontrar problemas e agregar valor para o time, conseguirá mais autonomia para mensurar possíveis impactos em novas implementações, correções ou features. Digamos que você encontre um Bug na aplicação, como um time sua responsabilidade não acaba nessa etapa, sendo proativo você pode debugar a aplicação e enxergar o ponto de falha do projeto, e quando conversar com o Dev já ter insumos do ponto onde o problema se originou, possibilidades, ou melhor você mesmo pode corrigir.

4) Participe do Code Review

Code Review — Revisão de código é uma atividade de garantia de qualidade de software na qual um ou várias pessoas verificam o código criado.

Pre Review — E uma etapa que permite que pessoas comentem as alterações, propostas de mudanças, aprove as alterações ou solicite mais alterações antes de mergear o conteúdo, a etapa de code review na maioria das vezes se encontra dentro desse processo.

Quem disse que (QA) não pode revisar PR!?… “ mais eu não tenho familiaridade com o código não sei o que tem lá!!”. Bom nesse caso pergunte, mesmo que não entenda direito, isso é gradativo e acumulativo, comece por coisas simples no PR.

• Comece pelos testes, se não existir entenda o por quê.
• Se existir leia o descritivo e veja se esta claro e entendível a finalidade do teste.
• Nesses testes anote o que não entende ou não faz sentido e questione.
• Se houver alguma mudança no código veja se os atributos dos testes foram atualizados, bem descritos, se cumpre com sua finalidade e se não há testes duplicados.
• Exija descrição na abertura do PR para entendimento das mudanças e implementações.
• Procure saber se existe alguma ferramenta de análise estática.
• Procure saber se existe alguma ferramenta para mensurar cobertura de código.
• Procure entender se estas ferramentas estão configuradas corretamente.
• Através dos testes e possível enxergar design de código, ou seja se a implementação do código não estiver bacana será muito mais difícil de criar testes limpos .

5) Crie oportunidades

Participe de coisas fora do seu universo de automação, crie e desenvolva ferramentas que auxiliem nos testes de maneira que ajudem no processo como um todo. Uma situação que vivenciei e quero dar os parabéns foi que um dos (QAs) que trabalho criou um mock para melhorar o ambiente de desenvolvimento. Foi levantado o problema pela equipe e com o passar da semana o (QA) junto com algumas outras pessoas conseguiram implementar a solução a fim de eliminar a instabilidade da plataforma que consumia. Querendo ou não, isso é um ponto de qualidade.

• Pense em testes não funcionais ex; performance, carga etc…
• Testes como monitoração.
• Testes de contrato.
• Implementar analise estática.
• Bloqueio de build por % cobertura código (Branch ou Instrumentação).
• Melhorar a organização da pirâmide de testes.
• Criar mocks embedded para testes de componentes ou integrados.
• Criar mock server para diminuir o acoplamento em determinados ambientes que façam sentido.
• Pense em continuous integration .
• Testes de performance para monitorar degradação do código em CI/CD.
• Vulnerabilidade, testar acesso a Buckets do S3, verificar se existe formas de acessar dados sem autenticação.

Por fim se você trabalha em algum lugar que não tenha nada disso essa e a oportunidade de arriscar, se você trabalha em algum lugar que já tenha tudo isso aproveite para aprender mais sobre cada um.

Chego no fim desse meu primeiro post!!. A minha intenção foi apenas mostrar que existe muitas coisas além de automação de testes, e que qualidade nunca vai se resumir em garantir que algo apenas não quebre, mas sim, que todo o processo de desenvolvimento seja feito com preocupação, comprometimento e apreço de todas as partes envolvidas.

Muito obrigado!!

Dicas de leitura

teste de software -aborda alguns testes dentro do desenvolvimento de software.

how google tests software - livro antigo mas ainda com informações atuais.

A extinção do profissional de QA - artigo bacana e reflexivo do Walmyr.