BUG EM PRODUÇÃO, E AGORA?!
Usuários sem conseguir acessar o sistema, contador de tickets subindo vertiginosamente…
Sim, amigo QA, por mais que você tenha lido livros, feito todos os cursos, assistido os vídeos do Julio de Lima e desenvolvido suas técnicas de testes, um dia esta situação acontece na vida de qualquer profissional. Esses, na verdade, são momentos cruciais para medir a sua maturidade e a do seu time.
Ao invés de descobrir o culpado pela falha é o momento do time se unir e coletar as lições aprendidas para que o processo de desenvolvimento seja melhorado. Pode parecer óbvio, mas acredite em mim, já vi uma pessoa dizer “eu fiz o meu trabalho e passei para o QA, se foi bug para produção a culpa é dele”.
Geralmente, depois que o bug é identificado e tudo volta ao normal, se faz uma reunião chamada de post mortem, nela o time faz um relato cronológico sobre o que aconteceu, identifica a causa raiz da falha e cada integrante aponta o que poderia ser feito diferente para que o problema não tivesse acontecido.
Quando passei por um momento como esse fiz as seguintes reflexões:
- Que perguntas eu não fiz?
- Para quem eu deixei de perguntar?
- O que preciso aprender sobre o produto?
Sim, esse é o cerne do nosso trabalho enquanto profissionais de Qualidade de Software, fazer as perguntas certas para as pessoas certas. Nós somos pagos para fazer perguntas e chegar às respostas. Mas para isso precisamos explorar o nosso produto, saber quais pessoas podem nos ajudar a pensar em casos de testes e entender como o software deve funcionar.
Em cima de tudo isso, tenha um processo de documentação dos seus testes cada vez mais aprimorado, que evidencie seu entendimento sobre o problema, impacto sobre os usuários, perguntas feitas (ao desenvolvedor, à equipe de produto, aos líderes técnicos, aos seus colegas de time de qualidade), o que o desenvolvedor encontrou como falho no código, qual a solução adotada e como você testou essa solução.
Para isso, indico fortemente o uso de mapas mentais, pois eles dão um painel de fácil acesso para a identificação destas questões.
Por fim, deixo as seguintes sugestões para diminuir as chances de um bug em produção ocorrer:
- Identifique as pessoas que têm mais conhecimento sobre o software e faça quantas perguntas julgar necessário;
- Leia os Pull Requests enviados pelos desenvolvedores e se tiver dúvidas do que foi feito, converse com eles para esclarecê-las;
- Avalie o que pode ser melhorado nas suítes de testes automatizados para evitar que bugs encontrados em produção se repitam;
- Comece os testes das novas features o mais cedo possível e teste os cenários de maior risco primeiro;
- Nos casos de features complexas e correções de bugs que causem grandes mudanças no código podemos importar as boas práticas dos desenvolvedores e fazermos revisão e testes em pares;
- Documente seu processo de testes como se algum colega fosse pegar o seu trabalho e dar continuidade sem nem precisar perguntar algo a você;
- Registre o máximo de informações sobre os bugs que escaparam para produção, a fim de servir de insumos para testes exploratórios futuros, auxiliando na detecção de problemas parecidos antes que eles cheguem em produção.
Com estas estratégias, quando algo acontecer, você e seu time terão muito mais insumos para encontrar e resolver o problema de maneira mais assertiva.
Mas lembre-se: quando um bug escapa para produção, o foco deve ser em buscar por soluções e não por culpados, afinal o desenvolvimento de software é um trabalho em equipe. Além disso, existe uma grande oportunidade de aprendizado nessa situação, que sempre deve ser aproveitada para que possa ocorrer uma melhoria real no processo de desenvolvimento.
