Alguns anos atrás peguei um projeto difícil: escopo complexo, cliente exigente, e um time de desenvolvimento talentoso posto à prova de verdade pela primeira vez. Tudo bem até chegar a época de entrega e os testes do cliente. Entre idas e vindas, fizemos o go-live alguns meses além do prazo. Culpa nossa, mas também das mudanças que o cliente foi pedindo no caminho. E aí o projeto deixou de ser projeto e virou sustentação contínua.
Tínhamos um pipeline de CI/CD e uma cobertura razoável de testes. O contrato é que era peculiar: na manutenção, as horas de desenvolvimento de feature nova eram pagas; o tempo gasto corrigindo bug, não. E não havia QA dedicado. O próprio time que escrevia o código testava o que escrevia, na mão e no automático.
E como tinha bug. Só de lembrar é de arrepiar. Nada grave, mas bug que vai se acumulando arranha a credibilidade com o cliente. A gota d'água foi um deploy de sexta-feira. Subimos, fomos pra casa. O estrago só apareceu quando abrimos o e-mail na segunda, com o cliente furioso, e com toda a razão. Uma rota de API tinha quebrado, os testes não pegaram o caso, e a integração ficou fora do ar o fim de semana inteiro. Correção de uma linha. Mas deixamos o cliente na mão, e isso era inadmissível.
QA era tratado como luxo
Até ali, QA era luxo. Quando eu tocava no assunto com o tech lead, a leitura era que não fazia falta um time dedicado. A liderança também não via necessidade. O fim de semana mudou essa mentalidade de uma vez. Na mesma semana houve reunião, e eu ouvi toda a frustração: que nosso time não prestava, que devíamos ter vergonha do nosso código, que o contrato estava em risco. Escutei, engoli seco. Quando chegou a minha vez de falar, dei razão, assumi a responsabilidade e pedi uma coisa: "Me dê uma chance. Em um mês a gente coloca esse projeto nos trilhos."
O time era bom, o código não era ruim. Mas o que pesa é a percepção do cliente. Tínhamos um produto inovador nas mãos, dava um trabalho enorme pôr no ar as features que ele pedia, e faltava gente de dentro pra validar tudo. Todo projeto tem um QA. O nosso problema é que, até então, o QA era o próprio cliente. Isso tinha que mudar.
Nasce uma área de QA
Saí da reunião com carta branca pra contratar e arrumar a casa. Trazer duas pessoas de QA virou prioridade. Feita a contratação, mãos à obra. Aloquei mais um dev: enquanto um tocava features novas, o outro corrigia os bugs que as QAs encontravam. Só esse ajuste já equilibrou o projeto financeiramente. E aqui caiu uma ficha importante: lembra do contrato, em que feature nova era paga e correção de bug não? Com as QAs filtrando os problemas antes de chegarem no cliente, o time parava menos pra apagar incêndio e passava mais tempo no que de fato gerava receita. QA não era custo. Era receita.
Deploy também deixou de acontecer a qualquer hora. Passamos a ter um dia fixo na semana, bem combinado com o cliente. Essa previsibilidade fez uma diferença enorme na comunicação, ainda mais quando algum deploy precisava de rollback. Vez ou outra ainda quebrava algo em produção, cenários impossíveis de cobrir em homologação, e tudo bem. O primeiro mês foi pesado. No segundo, o app já estava mais estável. Do terceiro em diante, rodando redondo. A área de QA provou seu valor, dobrou de tamanho e abraçou outras frentes, novos produtos e ferramentas.
Olhando pra trás, vejo o tamanho do desafio e fico feliz que tenha dado certo: a confiança do cliente se manteve e, onde tinha arranhado, foi reconstruída. Criar uma cultura de QA leva tempo. Mas cada pequena vitória, cada cliente satisfeito, cada elogio constrói um tijolo dela. O time que não tinha QA passou a ser um time que não vive sem.
Obrigado a todas as QAs com quem tive a sorte de trabalhar, e ao Cantinho das QAs por manter uma comunidade de gente talentosa e motivada. Vocês são demais!