menu

O dia em que matamos o QA

Por

Recentemente a empresa em que trabalho passou por uma série de cortes e reestruturações para fazer frente às mudanças que o mercado vem impondo a seus negócios e com isso a diretoria introduziu uma nova estratégia para a área de TI. Esta mudança, em conjunto com o mercado de TI aquecido, provocou a debandada de boa parte dos desenvolvedores.

Como é normal na maioria das empresas, o número de desenvolvedores era maior que o de analistas de qualidade (QAs) e a saída de desenvolvedores, embora preocupante, era uma questão de ajuste da capacidade de entrega, até que um belo dia os QAs começaram a deixar a empresa e o processo de desenvolvimento praticamente quebrou.

Nosso pequeno experimento começa quando um dos meus times ficou sem um analista de qualidade:

Para simplificar a história é suficiente saber que o processo de desenvolvimento segue o adotado pela maioria das empresas: “Desenvolvedor escreve código e testes unitários e o QA realiza os testes funcionais.” O processo, embora funcione bem, não é 100% confiável, eventualmente um defeito escapa para produção.

A primeira reação foi correr desesperadamente atrás de um substituto, mas até conseguir alguém, treiná-lo e ele se familiarizar com os sistemas ficaríamos descobertos. Foi quando uma série de investimentos em automatização e boas práticas adotadas no passado começou a dar retorno.

A equipe que ficou sem QA cuidava de sistemas de borda, que pela definição usada pela empresa significa sistemas dos quais nenhum outro depende, como por exemplo um site.

Meses antes, para colocar uma funcionalidade em produção era necessário abertura de chamado, reserva de janela, alocação de um membro da equipe de operações, algum desenvolvedor para acompanhar etc etc etc. Com este arranjo, uma funcionalidade, depois de aceita pelo PO, levava de 3 a 7 dias para ser colocada em produção. Nesta época começamos uma iniciativa para implementar integração e entrega contínua nos projetos da área.

Com automatização, empacotamento e virtualização conseguimos reduzir o tempo entre o aceite da funcionalidade até ela chegar em produção para 21 minutos ou seja ficou muito barato implantar mudanças. Neste cenário o plano para sobreviver sem um QA surgiu meio que naturalmente.

A primeira mudança foi de cunho psicológico/cultural, antes havia alguém na “esteira de desenvolvimento” dando uma última olhada no que os desenvolvedores faziam, sem esta pessoa a responsabilidade por entregar algo sem defeitos foi dividida pelo resto da equipe (eu incluso), começamos um a fazer testes funcionais no entregável do outro, ou seja, todos se tornaram responsáveis pelo trabalho de todos.

A outra mudança foi estratégica, aumentamos a tolerância a defeitos em produção e meio como um contra-senso isso ajudou a aumentar a velocidade do equipe, pois com o barateamento do processo de implantação em produção, encontrar um defeito e corrigir tornou-se mais barato do que investir em uma pessoa dedicada exclusivamente para verificar a qualidade ou automatização de testes funcionais, histórias ficaram mais baratas e o número de funcionalidades entregues aumentou.

O papel de QA continua existindo no time, mas tem outras responsabilidades. Hoje ele é o responsável por garantir a confiabilidade do conjunto de aparatos de testes. História nenhuma espera uma olhada um QA.

Até a próxima

H2

Leave your reply

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Go to top