A história abaixo é fictícia e qualquer semelhança com a realidade da área de QA das empresas é mera coincidência.
Sexta-feira, 16h55. Momento final de validação daquele Release cabeludo, com mais de 70 chamados envolvidos e que contém a liberação de novas funcionalidades para 12 clientes.
Faltam apenas 20 casos de teste para a validação total dos testes de regressão e liberação do Release, fora a liberdade para um final de semana sem stress e sem horas extras.
Eis que neste momento o inesperado resolve acontecer. Um dos casos de teste resolve falhar, e bem em um ponto que bloqueia os demais e que ainda por cima é crítico para o operacional dos clientes.
O que fazer neste momento? Gritar?? Sair correndo??? Se desesperar?!?
Bom, a coordenação e gerência de equipe nestes últimos três anos me trouxe grandes ensinamentos, como o fato de se manter calmo e sereno nestes momentos.
Algumas perguntas que devem ser feitas nesta situação:
- Será que a falha no caso de teste é realmente bug? Se é um bug, é de simples correção, ou de baixo impacto para o operacional do cliente, podendo ser corrigido posteriormente? A falha não seria por conta de alguma configuração no ambiente?
Quase sempre que isso ocorre, é uma situação diferente. O final da história do começo deste post tinha relação com o ambiente que estava com problemas, e por isso o caso de teste falhava. Ao mudar de ambiente (de QA para STG), o erro não foi reproduzido (ambos os ambientes estavam com o mesmo código-fonte aplicado) e assim o final de semana tranquilo foi garantido. Porém nem sempre é assim, a chance do bug ser realmente bug e ainda por cima crítico para o cliente é gigantesca.
Muitos gestores e líderes insistem em orientar suas equipes para que qualquer falha seja aberta como erro, sem qualquer tipo de análise. Eu mesmo as vezes peço para a minha equipe se comportar como a ROTA, ou seja, atirar ao invés de perguntar se a falha é bug ou comportamento do sistema. Mas isto deve ser feito com cautela. A diferença entre ambientes de teste é muito grande em diversas empresas, e dependendo do tipo de aplicação que está sendo testada, o ambiente de teste é a própria máquina do testador, então uma simples diferença entre versão do sistema operacional ou navegador já é o suficiente para alterar o resultado do teste.
E na área de QA de vocês, a história relatada acima já aconteceu? Qual foi o final dela? Com bug ou sem bug?
Abraços
Custom JUnit 5 Extensions for Testing
Há 9 meses
