TestExpert A sua comunidade de teste e qualidade de software

Resultados dos Testes 

Depois de um tempo sem escrever, retorno com um assunto que me preocupou muito quando estava iniciando em testes, eu não tinha a idéia de quais os resultados que gostaria de obter com os testes e quais resultados poderiam me ajudar.

Deveria identificar isso para ter claro o que registrar de forma que não fosse apenas mais um trabalho “penoso” para a equipe de teste. 

Com isso cheguei à seguinte conclusão, são pelo menos quatro resultados básicos para o meu caso inicialmente: quantos defeitos foram encontrados e em qual situação estão; qual o tipo de defeito identificado; qual o impacto do defeito para o negócio do sistema. Além é claro do ERD e o EDD que mostrará a qualidade da equipe de testes e da correção de defeitos.

ERD e EDD 

Sobre o ERD e o EDD não vou detalhar aqui, mas pode ser lido no link abaixo:

http://www.testexpert.com.br/?q=node/1084

Defeitos Identificados e Situação dos Defeitos 

Todas as ocorrências identificadas se tornam um registro. Qualquer situação suspeita que se encontre durante os testes deve ser registrada. E com a aprovação do desenvolvedor e auditoria dos líderes (de testes e desenvolvimento), elas podem ou não se tornar um defeito (pois a ocorrência pode ser apenas uma configuração que não esteja correta e não um defeito do software).

Assim deve-se criar uma situação para o defeito. Descrevo algumas situações que são interessantes ter:

Ocorrência: toda situação diferente do previsto que foi identificado pelo analista de teste/testador

Defeito: Toda ocorrência que já foi reconhecida pelo desenvolvedor ou alguém que tenha esta responsabilidade que realmente é um defeito.

Reteste: Quando o defeito já foi corrigido pelo desenvolvedor e retornou para teste.

Corrigido: Quando o defeito já foi corrigido pelo desenvolvedor, já foi testado e validado pela equipe de teste.

Ps.: Estas situações são somente exemplos, podem-se ter mais situações dependendo do processo de cada empresa, ou ter situações com outros nomes.
 
Com estas informações durante o processo de testes podemos ter o seguinte gráfico como resultado:

Com o gráfico podemos identificar um resumo de quanto já foi corrigido e quanto está pendente ainda para teste e/ou desenvolvimento. Além de ter uma visão de quantos defeitos foram identificados.

Tipo de Defeito por Impacto 

Para realizar uma classificação de defeitos, utilizei as características da qualidade. Uma listagem básica seria:

- Defeito de Funcionalidade
- Defeito de Usabilidade
- Defeito de Portabilidade
- Defeito de Performance
- Defeito de Manutenibilidade
- Defeito de Confiabilidade

Claro, podemos ter mais classificações de defeitos, isso depende do que a empresa deseja. Um exemplo que eu criei foi o tipo de Defeito de Script, onde indicaria ocorrências/defeitos identificados durante a execução de atualização do banco de dados através de scripts.

Também defini um Impacto, em relação ao negócio, para os defeitos identificados. Claro isso no inicio foi um feeling do analista de teste sobre o defeito, onde o mesmo pode ser reavaliado por um Analista de Negócios antes do encerramento do projeto.

Abaixo um gráfico final por tipo de defeito / Impacto:

Com o gráfico acima podemos identificar onde deverá ser nosso foco para melhorar o processo de desenvolvimento como um todo.
 

Como podemos visualizar, o principal tipo de defeito é sobre a funcionalidade, com isso podemos identificar que a falha possa estar sendo no vínculo da análise com o desenvolvimento, então temos que estar atentos as situações que façam com que o defeito aconteça neste momento.

Algumas perguntas para refelexão:

- Será que está sendo mau feita a análise de como desenvolver a funcionalidade?
- Será que falta treinamento para o desenvolvedor sobre as ferramentas utilizadas?
- Será que falta conhecimento do desenvolvedor nas linguagens utilizadas?

São questionamentos que devemos fazer para que possamos tomar uma ação e melhorar a qualidade de nosso sistema e nosso processo.

Vamos deixar claro que estes resultados não tem foco em identificar culpados e sim melhorar processos e treinamentos que possam ajudar na qualidade do produto como um todo. 

Espero ter ajudado há clarear um pouco o (às vezes) nebuloso mundo do resultado dos testes. Com o tempo colocarei mais situações que podem nos ajudar a tomar decisões importantes, não somente para os testes em si, mas para a empresa como um todo. 

Robson Agapito Corrêa
Coordenador de Testes - Mega Sistemas
Professor de Testes - Iterasys