Boas práticas de qualidade de software

Quality is everyone's responsibility

A maior responsabilidade de qualquer organização é entregar aos seus clientes um produto que: resolva seus problemas, seja estável e livre de bugs, ou seja, um produto com qualidade.

Em muitas empresas, em setores de tecnologia, temos pessoas que exercem o papel de QA (Quality Assurance Engineer), um papel que costuma gerar expectativas diferentes, muitas vezes associando o papel de QA como a de um Tester responsável por testar as releases, ou um automatizador de testes responsável por criar automações que validam o contrato ou feature na visão do cliente final, ou de um Software Engineer in Test com habilidades de desenvolvimento mas especialista em teste, ou de alguém responsável por analisar e acompanhar horizontalmente todo o desenvolvimento da empresa em termos de qualidade de software e plataformas.

Não existe certo ou errado, existe o que da certo pra você e pra sua empresa. Mas uma coisa que se enquadra em qualquer um dos cenários acima é que somente um papel se responsabilizando por qualidade na empresa, não escala, a responsabilidade disso é de todos da empresa.

O intuito deste artigo é listar algumas boas práticas de qualidade que todos que participam do desenvolvimento de produtos, independente de qual papel exercem dentro da tecnologia, possam pensar e ajudar a cobrar para entregarmos um produto de qualidade.

Separando em alguns estágios:

Planejamento de um produto

Neste momento, quando planejamos um produto ou uma nova funcionalidade, podemos ter muitas coisas em mente: Fazer um código limpo, entregar o mais rápido possível para garantir uma vantagem de mercado, performance e inclusive qualidade. Algumas coisas relacionadas a qualidade podem ser pensadas por quem participa desse planejamento, principalmente focando em duas coisas: Necessidades do cliente e escalabilidade.

Alguns exemplos de questões que podem ser levantadas:

• A idéia do produto/funcionalidade faz sentido para nossos clientes?
• Quantos clientes e quais especificamente atingiremos com essa mudança?
• Faz sentido entregarmos essa funcionalidade de forma faseada?Quais os milestones que temos expectativa?
• Tem alguma forma de desativarmos rapidamente essa funcionalidade caso por algum motivo ela impacte o cliente?Ex: Feature toggle, rollback
• Essa funcionalidade vai precisar de integração ou vai gerar dados que vão precisar ser integrados com algum outro sistema? Se sim, como garantir a integridade desses dados ou mesmo que a estabilidade dessa integração não impacte o cliente final.
• Precisamos monitorar essa funcionalidade?Se sim como e até quanto de esforço gostaríamos de investir nisso.
• Tem algum impacto de segurança para os dados do cliente ou para a empresa?
• Que tipos de testes adicionais talvez ela precise? Testes automatizados de aceitação, Performance, segurança ou outros.
• No que eu posso contribuir com o time antes do produto ser desenvolvido?

Pronto para testes?

Antes de submeter aquela funcionalidade a uma bateria de testes, devemos validar como ela foi desenvolvida:

• A funcionalidade está clara? Sabemos o que é ela?o seu valor e seus critérios de aceite condizem com o que acreditamos que a empresa e nossos clientes precisam?
• Analisando o código que foi criado, ele possui testes suficientes e que fazem sentido? Consigo sugerir alguma melhoria?
• Conheço os dados que vão ser afetados, variáveis de ambiente, scripts que serão executados e o impacto dessas mudanças?

Testando

Esse é um momento que se a empresa tiver um bom processo de continuous integration, cobre boa parte das preocupações, mas existem várias questões interessante que levantadas por diferentes pessoas durante o processo de validação.

• Tenho claro o fluxo principal dessa funcionalidade?
• Quais cenários que podem fugir deste fluxo principal?
• Existem variáveis de ambiente ou configuração que podem afetar a funcionalidade?
• Tenho acesso aos logs da aplicação ou dos testes?
• Estou monitorando as tabelas e seus dados que serão alterados?
• O que esta sendo validado manualmente que terei grandes benefícios se automatizar?
• Tem algo que seria bem importante de ser documentado?
• A performance está adequada para nossos clientes e para a empresa?
• Existe algum risco de segurança para a aplicação ou para os dados?
• A experiência do usuário parece ser boa, ou seja, está fácil e agradável de usar, visando os diferentes perfis de usuários que temos?

Pronto para produção?

Antes de colocarmos no ar nossa funcionalidade e todo mundo ter acesso aquilo que criamos:

• Estamos satisfeitos com o produto entregue?
• O deploy pode ser feito a qualquer hora do dia?
• Tem algum possível impacto em outros projetos?
• Terá downtime ou scripts demorados que podem afetar nossos usuários?
• Devemos preparar algum stakeholder ou mesmo nossos clientes sobre o a mudança que a funcionalidade deve causar?
• Quais riscos temos?
• Quem lida com atendimento, ou diretamente com os clientes está ciente desta atualização, dos impactos ou possíveis problemas?

Em produção.

Após a entrega:

• Temos acesso as estastiticas de uso da funcionalidade?
• Como estão as métricas de utilização de recursos de infraestrutura após o deploy dessa funcionalidade?
• O custo da minha aplicação aumentou?Esse custo compensa pelo ganho que tive em outros aspectos e valores para a empresa?
• Temos acessos aos logs?Como estão as exceptions da aplicação?
• Recebemos feedbacks dos clientes?
• Conseguimos medir o NPS da feature ou do projeto após essa alteração?
• Qual o throughput da funcionalidade e temos expectativa do crescimento que teremos ao longo prazo?

Conclusão

Qualidade é um conceito importante, nem sempre o principal a ser seguido dependendo do momento em que sua empresa ou projeto esta. Muitas vezes velocidade de entrega é o que seu projeto precisa naquele momento e isso vai contra muitos conceitos de qualidade. E novamente, não existe o que é certo e errado e sim o que funciona pra você e pra sua empresa, por isso é importante encontrar o equilíbrio necessário para o momento.

Um fato é que algo construído com boas práticas de qualidades, tem um potencial de escalar muito melhor do que algo focado apenas na velocidade de entrega. Qualidade leva a escalabilidade, e isso é a base se sua empresa busca crescer.

Qualidade no ambiente de desenvolvimento de tecnologias só escala quando todos em algum momento, vestem o chapel de QA buscando o melhor para nossos clientes e o futuro.