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:

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.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>