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:
- 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;
- A produtividade da equipe diminui;
- A cultura da culpa começa a se instalar;
- A equipe tende a se tornar menos enxuta ao longo do tempo;
- Os desenvolvedores começam a prestar menos atenção ao detalhes;
- Remove a responsabilidade de entregar tarefas com qualidade dos desenvolvedores;
- Não é escalável;
- A agilidade sofre com isso;
- Fazer uma gestão da sprint torna-se bastante complexa;
Soluçã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.