O seu QA está trabalhando?

Garantir entregas com qualidade em empresas de tecnologia é definitivamente uma das áreas, que as empresas em geral, têm mais dificuldade em fazer direito. Normalmente quando se cria uma área de QA os custos aumentam e a produtividade e velocidade da área de TI inteira cai.

Eu tentei muitas vezes ter um QA nas minhas equipes. Só que isso acabou sempre sendo um desastre. E os motivos eram:

1 — Os desenvolvedores tendem a entregar tarefas que nunca foram testadas para o QA e isso aumenta muito a iteração de feedback entre os dois. Por consequência aumenta o tempo e a complexidade do processo;

2 — A produtividade da equipe diminui;

3 — A cultura da culpa começa a se instalar;

4 — A equipe tende a se tornar menos enxuta ao longo do tempo;

5 — Os desenvolvedores começam a prestar menos atenção ao detalhes;

6 — Remove a responsabilidade de entregar tarefas com qualidade dos desenvolvedores;

7 — Não é escalável;

8 — A agilidade sofre com isso;

9 — Fazer uma gestão da sprint torna-se bastante complexa;

Solução:

1 — Dividir a equipe em pequenos squads de 3–8 pessoas;

2 — Cada equipe é responsável por testar o seu próprio trabalho;

3 — Cada desenvolvedor precisa ter certeza de que as tarefas finalizadas estão funcionando;

4 — Forçar uma fase de testes durante a sprint e se necessário adicionar tarefas explícitas para testar cada funcionalidade que for entregue;

5 — Reforçar para todos os membros da equipe a necessidade de ter atenção aos detalhes;

6 — Ter alguém fazendo testes em todos os ambientes para dar um feedback para os desenvolvedores. O Gerente de Projeto, CTO, Gerente de Produto e todas as partes interessadas podem fazer isso;

7 — Sempre dar um contexto para cada user story e tarefa. Dessa forma o desenvolvedor pode perceber os diferentes ângulos de uma forma que facilite a construção dos testes;

8 — Não pontue bugs. O objetivo final deve ser sempre não ter bugs;

9 — Concentre-se em testes automatizados e adicione isso durante nas sprints, na entrega contínua e no processo de integração;

Na minha visão o que determina um bom programador não é só a qualidade do código, estrutura e capacidade de encontrar soluções para os problemas. O que é mais importante é a qualidade da entrega. Isso é algo que eu sempre tento trabalhar e é onde a maioria dos desenvolvedores tem dificuldade.

A maioria dos desenvolvedores tendem a olhar para as tarefas com apenas algumas perspectivas. E às vezes eles perdem a perspectiva de que estão fazendo e qual é o objetivo em questão. Um desenvolvedor não deve só se preocupar em escrever código, na verdade, no último caso, eles devem estar focados na entrega e na qualidade dela. Se um bom desenvolvedor entrega com qualidade geralmente o código por trás tem padrões elevados.

A maioria dos desenvolvedores não gostam dessa abordagem, afinal, eles preferem escrever código sem ter que testar as coisas — especialmente aqueles desenvolvedores que se divertem muito em desenvolver software. Eles são os que não querem testar e costumam reclamar sobre a falta de um QA. Isso é um pouco difícil de aplicar em equipes de tecnologia, mas com persistência a equipe vai começar a perceber que é muito em importante testar em cada entrega e isso se torna natural pra todo mundo.

No final das contas, se o processo de QA for adotado pela equipe de desenvolvimento o número de bugs adicionados em cada sprint pode ser reduzido de 60% a 80% depois de algumas sprints. Isso aumenta a disponibilidade da equipe de desenvolvimento em implementar coisas importantes que levam a empresa pra frente.

Artigo originalmente publicado em inglês no Pulse pelo Ricardo Parro