QA, o código e o log também são seus
Introdução
Muitas vezes trabalhamos em empresas que não dão abertura e até mesmo não permitem que o QA olhe o código fonte ou o log da aplicação. Onde a diretriz é apenas abrir o bug que o dev analisa o que está acontecendo. Neste tipo de abordagem o QA pode reportar bugs que podem não ser problemas (os famosos falsos positivos), pois temos diversas coisas que podem influenciar em nossos testes: ambiente, banco de dados, autenticação, OAM, sistema terceiro, rede, intermitência (oscilações nos tempos de resposta, falhas de integração temporárias), configuração, versão e etc.
Vamos elucidar um pouco esses dois mundos, o de um analista de testes que tem autonomia para analisar o código fonte a fim de detectar problemas e outro, onde o testador não tem esta autonomia. Isso vai nos ajudar a responder a seguinte pergunta: Quais os benefícios dessa análise mais aprofundada pelo QA?
QA que apenas executa testes
Então, vamos a um contexto em que o QA pode apenas executar seus testes e caso encontre problemas, tem que se limitar a reportá-los, sem nenhuma análise prévia. Estou realizando testes e durante um dos passos é apresentado um erro na tela da aplicação. Como eu apenas testo e não analiso, então vou abrir um defeito para ser corrigido.
Quando o desenvolvedor (dev) vai analisar, vê que apenas a aplicação XX esteve fora do ar por alguns segundos e supõe que o QA não fez o reteste ou mesmo não analisou o log para entender o motivo, então ele retorna o bug para testes. Ele pede para o QA testar novamente, dizendo que o sistema vai funcionar e que ele esteve fora do ar durante os testes. Nessa hora o QA pensa: jurava que era um bug, falhei e o pior é que essa situação está ficando recorrente. Essa semana já foram dois ou três casos parecidos com este…
Este caso acima era apenas mais um dia comum de um QA que apenas reporta bugs sem analisar a causa. No momento que o dev vai analisar um report, já pensa: “Deve ser mais um falso negativo como o de ontem… está ficando complicado, pois a cada cinco bugs abertos, apenas dois são problemas reais. Será que posso acreditar nele? Será que esse QA nunca chegou a se perguntar se os logs da aplicação, ambiente e código podem lhe dar a resposta para saber se o bug realmente ocorre e que também ele pode descobrir a causa do mesmo?”
É então que o DEV decidiu chamar o QA para conversar sobre como as coisas funcionam na empresa. O desenvolvedor já começa falando: — Então amigo, não me leve a mal, porém queremos que seja um QA mais proativo no reporte dos problemas das demandas que atuamos e não apenas um que fale “tenho um defeito na aplicação”. Quando encontrar algo diferente do esperado, você pode fazer uma análise detalhada do log da aplicação, código ou mesmo verificar se a versão está correta no ambiente e, além disso, fazer o teste mais de uma vez para garantir se o erro encontrado é realmente um problema. Temos que ter a certeza de que o que está reportado é realmente um problema e não só mais um falso positivo. Entende que com isso o seu trabalho vai ficar muito melhor? Topa esse desafio comigo? Posso te ajudar no que for preciso? O QA responde: “claro, estamos juntos nessa, vamos acabar com esses meus dias de Klebinho, de apenas reportar bugs duvidosos.”
QA que analisa bugs
Após certo tempo durante a atividade testes, o QA percebe que um dos fluxos do sistema está falhando. Ele abre o modo desenvolvedor do browser para analisar a situação e a aplicação não apresenta erros. Após ele lembrar como aplicação é chamada na ferramenta que mapeia os logs, ele vai analisar os logs para ver o que pode ter acontecido, então ele descobre que a aplicação XX está fora do ar. Ele fala: “Time, a aplicação XX está fora do ar, quem pode me ajudar?”. Prontamente, o dev já sobe novamente a aplicação e pede para ele realizar novamente o teste. Quando o QA efetua novamente o teste, o sistema exibe um erro diferente do anterior, dessa vez com logs que informam: “Exception na linha 50 da aplicação”. Ele descobre que um item não estava sendo tratado e registra o defeito com todos os detalhes. Então o dev corrige esse defeito, sobe a nova versão do sistema, o teste é realizado novamente e o bug é fechado.
Elenco abaixo alguns problemas encontrados em análises, que podem ou não ser um defeito (pode variar de acordo com o contexto):
- Aplicação XXX fora do ar;
- Timeout;
- Exception na linha XX;
- Endpoint que chama uma aplicação terceira escrito incorretamente;
- Testes sendo realizados na versão diferente da qual a correção foi aplicada;
- Configuração incorreta do ambiente.
Quais os benefícios de se ter uma análise mais aprofundada para o time/QA?
Ao realizar as análises o QA vê o quanto esta forma de atuar ajuda o time a realizar um trabalho melhor e mais confiável, diferente do Klebinho, que apenas reporta defeitos sem dar muitos detalhes. Agora, o QA tem mais autonomia para encontrar a origem do problema e prover mais insumos para colocar em anexo quando o defeito for registrado. Abaixo cito alguns dos ganhos que temos:
- Conhecimento;
- Visão de código;
- Entender melhor o negócio / sistema (legado);
- Poder achar algum problema no código que iria originar uma inconsistência;
- Diminuir a ocorrência de falsos positivos.
Parece difícil, como posso começar?
Vou elencar alguns passos que podem te ajudar a dar o início nesta mudança, lembrando que não há algo exato e sim dicas que podem ser seguidas, podendo mudar de acordo com o seu conhecimento e contexto (alinhe com o time antes e vejam se dão abertura para tal).
- Analise os logs da aplicação e se sentir dificuldade peça ajuda ao dev para verificarem juntos o problema. Lembre de perguntar onde ficam os logs e o que se analisa, quais pontos ele costuma verificar (lembre de anotar). Na segunda vez tente sozinho, porém não tenha receio em pedir ajuda se não conseguir avançar muito na análise.
- Com o tempo, quando tiver mais domínio da linguagem e prática, baixe o código na sua máquina, na branch correta, e tente analisar o erro. O código do desenvolvedor se tornará mais amigável, você poderá parear com o dev para observar e aprender como funciona a correção do problema e no futuro poderá até corrigir inconsistências e testá-las em sua máquina, subindo também a correção.
Conclusão
Agindo desse modo, vemos o quanto podemos evoluir como QA ao sermos mais assertivos no report de problemas através de uma análise mais aprofundada da aplicação. Além disso, ganhamos a confiança dos desenvolvedores, do time e às vezes podemos até mesmo efetuar a correção de inconsistências, mediante aprovação/review do time.
Às vezes temos que sair um pouco da nossa zona de conforto e fazer algo para que possamos ser ainda melhores na área que atuamos e por isso é tão importante agirmos como no post, para desempenhar um papel melhor junto ao nosso time.
Agradecimentos
Antonio Montanha, Júlio de Lima, Gabriel Santos
Referências
- Quem aplica o conhecimento citado no post e entende do código, consegue ocupar uma fatia muito grande das vagas de teste de software no mercado contemporâneo: link
- Além de realizar a análise do código durante os bugs, podemos fazer o review com intuito de antecipar problemas e melhorar a qualidade do código: link
- Cursos:
