Você já se viu sendo cobrado por todo e qualquer detalhe? Tem pedidos constantes dos seus superiores para que relate as suas tarefas? Acredita que o seu time não confia em você? Pois bem, eu tenho uma razão para isso: Falta de visibilidade.

Quando se trabalha como QA, você é o defensor da qualidade do produto perante aos membros do time. Como tal, espera-se que você preze pela qualidade mais que todos os outros. Então por que, tendo esse papel, muitas vezes sua voz não é ouvida? Por que questionam insistentemente se você validou corretamente as funcionalidades? É simples, não confiam no seu trabalho.

E se seu próprio time não confia no trabalho que está apresentando, e questionam se você é a pessoa certa para identificar os problemas e disseminar a cultura de qualidade dentro do projeto...

Caro parceiro de profissão, você está em apuros.

Mas então, como criar laços e convencê-los de que seus esforços estão direcionados para o bem do produto? Como convencer meus superiores e colegas que meu trabalho é digno de confiança? Que bugs precisam realmente ser consertados e que a qualidade do produto pode sempre melhorar? Eis aqui um caminho que indico: visibilidade.

Como gerar impactos positivos através da visibilidade

Durante a minha carreira, ouvi uma frase que me marcou muito:

"Faça antes que te peçam para fazer."

Quando você executa seu trabalho corretamente e em seguida foca em mostrar os resultados de forma clara e objetiva, os questionamentos são minimizados e a confiança é conquistada. 

Imagine a seguinte situação: Durante uma semana inteira você executou, por exemplo, cinco baterias de teste, abriu doze bugs ao todo e cadastrou todos esses os bugs na ferramenta existente na sua empresa. Ao final do processo, enviou uma mensagem ao seu chefe dizendo que as tarefas foram finalizadas.

Você até pode achar que está mostrando seu trabalho, certo? Mas essa não é a melhor maneira de fazer isso, afinal, não houve qualquer destaque ou real satisfação do status do projeto. Como os bugs encontrados podem impactar o sistema? São graves? Podemos publicar o que foi testado?

Dizer que abriu doze bugs não é a mesma coisa que dizer que foram abertos um bug bloqueador, dois bugs críticos, três bugs de prioridade alta, quatro bugs de prioridade média e dois bugs de prioridade baixa.

Ainda nesse exemplo, eu poderia informar que dentre os doze bugs abertos, cinco deles são funcionais (pois impactam a funcionalidade a ser testada), mas que também foram identificados quatro bugs de integração e três bugs de layout... Nesse cenário, fica claro que há um bug que precisa ser urgentemente consertado.

Uma maneira ainda melhor de visibilizar o que foi testado é tornar todas essas informações visuais – seja em um desenho, um gráfico, uma planilha ou um dashboard. Destrinchar essas informações, organizando e as ordenando de forma gráfica faz com que os interessados na qualidade do produto tenham uma visão clara do real status em que a qualidade se encontra. Por mais bobo que pareça, essa organização permite que os gestores e demais membros do time tenham uma base compreensível para tomada de decisões para o produto.

Para ilustrar, pense que uma nova funcionalidade foi testada e foram encontrados exatos quinze bugs - todos de prioridade baixa. Desses quinze, doze são de layout.

Ao final do expediente, o gestor do projeto pretende disponibilizar uma versão atualizada para todos os clientes e para tomar essa decisão, ele checa o dashboard dos bugs. Por serem todos bugs de prioridade baixa, o gestor decide que a funcionalidade pode ser publicada em produção. Contudo, revendo os bugs, ele percebe que os desenvolvedores não consultaram o material de definição de layout da funcionalidade. Por isso, reúne todos no dia seguinte para discutir mudanças no processo de desenvolvimento do layout.

Resultados

Quando se desenvolve uma visibilidade fácil e bem ordenada do trabalho que fazemos, os questionamentos cessam e a confiança é construída. Quando você ordena e classifica, demonstra que sabe o que é realmente crítico, que entende e que está verdadeiramente antenado no que acontece com o produto para o qual trabalha.

A visibilidade pode ser ainda maior e ilimitada. Quantos bugs foram abertos? Quantos bugs foram consertados pelo time? Qual o volume de bugs na semana, ao mês ou ao ano? A quantidade de bugs caiu depois do ajuste do processo de desenvolvimento?

Você pode fazer um trabalho incrível atrás do palco, mas precisa sim, evitar a falta de visibilidade. É fundamental mostrar, de maneira clara e objetiva, quais foram os problemas identificados, e consequentemente, qual foi a sua contribuição e relevância para o produto.

Os resultados devem ser disponibilizados para todos aqueles que tiverem o interesse em qualidade – podendo ser gerentes de projetos, pessoas de produto, desenvolvedores e até mesmo outros QAs.

O seu trabalho tem importância, ele impacta as pessoas e os sistemas com os quais você trabalha. Demonstre isso.