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, mas o cliente só via os bugs. 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. Até então, quem fazia o QA era o próprio cliente.
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. 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 horas em feature, que era o que o contrato pagava.
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.
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!