Você encontra falha e tenta identificar o erro?

Gostaria de abordar aqui um tema que as vezes acabamos deixando de lado na área de qualidade. Quando você encontra uma falha, você tenta identificar o erro?

Introdução

Geralmente quando temos que realizar testes em algum sistema, ao encontrarmos uma falha reportamos alguns dados como:

• Prioridade.
• Versão do sistema.
• Passos para reproduzir.
• Resultado esperado.
• Resultado obtido.

E com esses dados que informamos, normalmente quem for corrigir a falha pode seguir um desses caminhos:

• Procurar nos logs qual erro apresentou essa falha.
• Acompanhar novamente os passos para assim ver os logs.
• Falar com o QA para ajudar a acompanhar a falha e assim ver os logs.

Nesse caso não seria melhor já passarmos todas as informações possíveis contemplando logs e informações da base de dados?

O que quero dizer com isso?

Vamos pensar no cenário que temos que testar o pagamento de um produto e ao informar os dados necessários e clicar em confirmar o front-end apresente a seguinte mensagem: Não foi possível completar sua solicitação. Apenas lendo essa mensagem, não temos idéia de qual foi o erro que ocasionou essa falha. Nesse caso poderíamos verificar diversas opções entre elas os logs e o banco de dados.

Olhando os logs temos como verificar qual a exception que foi lançada ao clicar no confirmar após informar os dados. Nesse caso vamos imaginar que a aplicação que esta sendo testada foi escrita em Java e olhando os logs vimos algo como: java.lang.NullPointerException: name can’t be null. Com essa linha extraída do log já podemos verificar que o atributo name tem o valor null e o sistema não permite isso.

Olhando o banco de dados, podemos realizar uma consulta dos dados que temos do usuário que apresentou a falha e verificar se o campo name esta null também. Se o campo estiver null já sabemos que existe uma falha na hora de gravar os dados na tabela.

Viram como apenas olhando os logs e banco de dados podemos informar dados mais precisos do que ocasionou o erro? Rastreabilidade de uma falha também faz parte da qualidade de um projeto.

Reforçando que tudo depende do contexto e da empresa onde esta sendo aplicado, não sendo uma regra. Já tive experiência de trabalhar em empresa onde o acesso a logs e banco de dados é restrito.

Quais os ganhos?

• Mais cenários de teste: Olhando os logs e dados do banco temos um melhor entendimento da caixa branca do sistema, podendo assim ver um cenário não coberto e assim podemos pensar em mais testes desde o baixo nível(unitário) tanto de alto nível(E2E).
• Rastreabilidade do erro: Se for difícil encontrar a causa raiz da falha, provavelmente os logs estão apresentando informações faltantes ou inconclusivas para o usuário e devem ser alterados para ser de fácil rastreamento.
• Correção mais rápida: Encontrando a causa raiz do bug, podemos informar ao time não só a falha que recebemos mas exatamente onde o erro esta no sistema, dessa forma levando a uma correção mais rápida.

Conclusão

Algumas pessoas tem a idéia que simplesmente achar o bug e reportar já é o suficiente, mas quanto mais informações temos sobre o bug e mais vamos atrás de identificar a causa raiz, mais qualidade o projeto ganha. A qualidade de um projeto vai muito além disso que falamos, mas como vimos aqui, tentar identificar a causa raiz de um bug ajuda não só na qualidade do projeto mas na evolução do QA para se aproximar mais da caixa branca do sistema.