Teste de Software e Utilidades…

Gestão de Defeitos e o Papel do Testador neste Processo

Posted in Teste de Software by jppercy on 30/03/2011

Olá Pessoal,

 

Depois de um bom tempo ausente de novos posts, venho agora com um que anda me chamando muito a atenção.

Quando testamos, procuramos nos empenhar ao máximo na procura de defeitos, ou seja, todos nossos esforços se centralizam nesse contexto. Mas há um detalhe que aumenta a influência dos Testadores nos Projetos. A atenção não parte apenas para a Matriz GUT (vide ótimo post sobre: http://qualidadeeteste.blogspot.com/2011/01/como-priorizar-problemas-defeitos.html – por Anderson Tavares), mas também para a descrição e aprofundamento do problema detectado.

Em minha experiência em Teste de Software, vi diversos cenários, desde o cadastramento de um simples bug sendo destruído por uma descrição impossível de se entender até um cadastramento perfeito, aprofundado, embasado em tentativas e experiências. Esse é o fator que eleva o conhecimento do profissional e o faz entender completamente o processo da empresa onde trabalha.

Ok. Vamos mais devagar. O que estou querendo mostrar?

Os profissionais de Teste possuem um poder imensurável em suas mãos, mas que muitos desperdiçam. Por quê?

Vamos a um exemplo:

Um defeito simples: Temos um botão de um programa qualquer que, ao receber o clique, deveria enviar o usuário a uma próxima tela específica, mas não o faz. O Testador, ao perceber tal situação, reproduz o problema e o reporta.

Pronto. No relatório temos o seguinte problema reportado: Ao clicar no Botão “XX” o sistema não envia o usuário à próxima tela.

Testador feliz e Desenvolvedor indignado por esquecer algo tão simples no código.

 

Agora vamos dificultar um pouco com um novo exemplo:

Temos um Trojan, que no caso deveria ter sido morto pelo Anti Vírus, mas não foi. O Testador ao perceber tal situação, reproduz o problema e o reporta.

No relatório temos o seguinte problema reportado: Ao executar o Trojan “XX”, o Anti Vírus não o matou.

Testador feliz e Desenvolvedor indignado, porque agora os problemas podem ser vários.

 

Agora vamos ao ponto principal. E é aqui que definimos os perfis profissionais.

No primeiro exemplo temos um caso simples onde o problema foi um erro básico, fácil de ser detectado e não necessário de ser explorado.

No segundo exemplo temos todo um mundo a ser explorado. Quando percebemos que um trojan não foi morto, quais medidas deveríamos tomar? Quais tipos de testes poderíamos submeter a aplicação pra passar as informações ao desenvolvedor completamente limpas? O trojan possuía sua assinatura na “Base de Assinaturas” do Anti Vírus? Quais proteções do Anti Vírus estavam ativas no momento em que não matou o trojan? Houve algum conflito entre as proteções? … e por aí vai…

 

Mas esbarramos em um problema… quando se trata de prazos, temos a responsabilidade de entregar o produto no tempo acordado. Então nem sempre temos a disponibilidade imediata de pensar nessas possibilidades. E aqui se destacam as pessoas de visão. Gerentes, Líderes, e claro… Testadores.

Quanto mais informações transferirmos ao desenvolvedor, mais rápido ele irá conseguir detectar o problema, e menos risco o Projeto terá.

Trabalhei com diversos tipos de profissionais de Teste e percebi que o maior prazer deles está na busca do problema. Quanto mais envolvido o profissional estiver com a empresa, maior o conhecimento adquirido e maior a disposição dele na detecção do problema.

Tenha sempre em mente: O nível de aprofundamento da informação está totalmente ligado à resolução do problema. Se o Desenvolvedor possuir todas as informações dos tipos de testes que o Testador realizou, ele pode descartar qualquer redundância do processo e detectar o problema tão cedo quanto imaginar.

Nesse aspecto, temos mais um item que pode ser agregado a esta análise. Retirado do Livro: Testes Funcionais de Software, Leonardo Molinari, pág. 86/87: “O herói, na qualidade de software, é alguém que para o bem geral, toma uma iniciativa para resolver um problema ou para atingir uma meta de forma clara e precisa. Um herói não é alguém louco, mas um ser consciente de suas limitações e que age até onde é possível para superá-las de forma consciente e lógica. (…) A sua atitude pode torná-lo um herói. A atitude mais simples pode fazer o seu vizinho ver qualidade sob um novo aspecto, melhor e mais positivo.

Em linhas gerais, podemos dizer que nossas atitudes podem sim mudar tudo a nossa volta, até mesmo a visão dos nossos superiores com relação ao nosso trabalho.

 

 

O que mais impede um defeito ser considerado realmente como um, é a má descrição. Com isso temos uma interpretação errada do Desenvolvedor e consequentemente, o tempo perdido nesse processo.

Geralmente é preciso se atentar a alguns aspectos importantes, que são eles:

Escrita – Uso do Português adequado: Atenção a este item. Parece simples, mas o que mais temos são frases ambíguas e o mau uso das palavras;

Uso de Títulos intuitivos: Saber especificar um problema é essencial e se o Título for intuitivo e descrito de forma correta, muita informação desnecessária pode ser evitada;

Passo a Passo organizado: Não basta apenas saber o que fez, é preciso organizar as informações de modo que um passo não seja excluído ou que não haja falta de informação;

Evite redundâncias: Quanto mais complexo o defeito, mais atenção é preciso na hora da descrição. Seja objetivo;

Neutralidade: Evitar manifestação de humor ou emoção;

Isolamento do Problema: O que foi feito para isolar o problema? Quais tipos de ações foram feitas para reproduzir o problema de modo consistente.

 

Dica: Utilize sempre vídeos para demonstrar os defeitos. Testes feitos utilizando Máquinas Virtuais têm essa vantagem, e isso agrega um valor imenso à descrição do problema. Quando existe a possibilidade de visualizar o problema, surgem novos pontos a serem questionados e isso cria confiança entre as partes.

 

Seguindo esta linha de raciocínio, é possível melhorar de forma exponencial a descrição de defeitos e ainda agilizar o processo de correção.

Trabalhando ao lado de desenvolvedores fica fácil perceber o grau de reconhecimento e satisfação ao lerem itens tão bem descritos e embasados. Não há perda entre os lados. Com isso, a Empresa ganha em agilidade, e os Desenvolvedores e Testadores ganham em competência.

 

 

Concluindo…

 

Como Gerentes, temos que ter a visão macro, entender o que é mais importante e direcionar os esforços para a conclusão dos testes e entrega do produto, não esquecendo de dar foco à problemas mais complexos;

Como Líderes de uma Equipe de Testes, temos que ter uma visão um pouco mais minuciosa, direcionando esforços ao cumprimento das metas estipuladas pelo Gerente e além disso, direcionar os profissionais de Teste no cumprimento de suas tarefas;

Como Testadores, temos que ser críticos, possuir iniciativa, ser explorador e claro, ser organizado. O sucesso, tanto da Empresa como dos Gerentes e Líderes está no empenho e preocupação dos Testadores com o produto. E então entramos novamente no assunto anterior: Quanto mais envolvido estiver com a empresa e motivado com o trabalho, melhor será o desempenho do Testador.

Na Gestão de Defeitos é preciso se “viciar” nas melhores práticas de descrição e relato de defeitos. O uso da Documentação é imprescindível, devendo esta ser de total apoio ao Testador.

Para frisar a importância da gestão de defeitos, tanto em sua descrição como cumprimento de suas etapas, encerro este post com um trecho do livro “Base de Conhecimento em Teste de Software” – Aderson Bastos, Emerson Rios, Ricardo Cristalli, Trayahú Moreira – pág. 195: “(…) A demora em reconhecer defeitos pode ser muito custosa. Uma das principais causas dessa demora é a dificuldade, a incapacidade ou impossibilidade de reproduzir o defeito. Quando isso acontece, o desenvolvedor tende a ver o defeito como inválido ou adiar o reconhecimento para uma próxima ocorrência do mesmo defeito.

 

… … …

 

Espero que este post o ajude a buscar mais dentro do seu ambiente de trabalho e que seja a fonte de inspiração para novas idéias.

 

Qualquer elogio ou crítica construtiva fique à vontade.

 

 

Deixe uma Resposta

Preencha os seus detalhes abaixo ou clique num ícone para iniciar sessão:

Logótipo da WordPress.com

Está a comentar usando a sua conta WordPress.com Terminar Sessão / Alterar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Terminar Sessão / Alterar )

Facebook photo

Está a comentar usando a sua conta Facebook Terminar Sessão / Alterar )

Google+ photo

Está a comentar usando a sua conta Google+ Terminar Sessão / Alterar )

Connecting to %s

%d bloggers like this: