Gerenciamento de Defeitos com TMap Next - Parte 5

Muitas pessoas vêem como a descoberta de defeitos um dos propósitos do teste. No entanto, teste de software é muito mais do que isso.

por Fábio Martinho Campos

Muitas pessoas vêem como a descoberta de defeitos um dos propósitos do teste. No entanto, teste de software é muito mais do que isso como já vimos e podemos complementar esta definição com a provisão de informação e conselhos em relação aos riscos e qualidade.

Confusões são feitas com os vários termos como erro, defeito e falha:

- Erro(Error): Erro humano! Esta ação tem lugar antes de todas as faltas e / ou falhas.

- Falta(Fault): O resultado de um erro que residem no código ou documento.Falha é a visão de dentro do sistema.Falha é o estado onde qualquer erro existe.Desenvolvedores verão as faltas.

- Falha(Failure): O resultado ou manifestação de uma ou mais falhas.Quando o sistema está funcionando de maneira diferente do comportamento exigido, do ponto de vista fora do sistema.Os usuários verão a falha.

“O defeito(Fault, Bug) é o resultado de um erro que residem no código ou documento.”

                                      

O ciclo de vida de um defeito é constituído de:

Encontra defeito

Defeitos podem ser encontrados em várias fases do processo de testes. Seja nas fases iniciais como Preparação e Especificação(test basis) como também na Execução(test object).

Os passos que um testador deve realizar quando um defeito for encontrado são:

1) Coletar evidências

Em determinado ponto, o objeto de teste produz uma resposta que o testador não espera ou a base de testes(test basis) contém ambigüidades, inconsistências ou omissões, ou seja, um defeito.

O primeiro passo é estabelecer uma evidência da anomalia encontrada. Isso pode ser feito através, por exemplo, com screenshots mostrando o problema encontrado, extração de registros em banco de dados, registros de logs, etc.

Se um defeito for encontrado na base de testes(test basis), outras partes da base de testes devem ser examinadas

2) Reprodução do defeito

Quando um defeito é encontrado durante a execução do teste, o próximo passo é verificar se o defeito é passível de ser reproduzido.

Se o defeito pode ser reproduzido, o testador continua com os passos subseqüentes.

Se o defeito não pode ser reproduzido e não for um erro de execução do teste, o testador executa o teste novamente e indica de forma clara no relatório de defeitos que o defeito ocorre duas vezes a cada três execuções.

Geralmente, desenvolvedores não perdem muito tempo em defeitos não reproduzíveis.

No entanto, o testador poderá registrar o defeito como forma de manter um histórico caso este defeito venha acontecer novamente no futuro ou até mesmo em produção.

Se um defeito não reproduzível acontece com freqüência, provavelmente acontecerá em produção.

3) Checar pelos seus próprios erros

Os testadores procuram por possíveis causas de um defeito, primeiramente procurando por uma possível causa interna.

Causas internas podem ser:

- A especificação do teste ou ponto de início(central).

- O ambiente de teste ou ferramentas de teste.

- A execução de teste.

- A avaliação dos resultados de teste.

4) Determinar a causa suspeita externa

Se a causa não for do teste em si, a busca deverá ser externa. Alguns exemplos são:

- Base de testes(test basis).

- Objeto de teste(test object).

- Ambientes de teste e ferramentas de teste.

Defeitos externos sempre são gerenciados formalmente e devem estar no formato de relatório de defeitos.

5) Isolar a causa(opcional)

Enquanto a causa suspeita é freqüentemente aparente, no caso de um defeito no objeto de teste ou ambiente de teste, não é normalmente claro para quem vai resolver o defeito(defect solver).

Este passo é opcional, uma vez que representa a fronteira do quanto o testador deveria ir a respeito do desenvolvimento na procura pelas causas do defeito

É muito importante fazer acordos com o desenvolvedor previamente.

Isso pode evitar discussões sobre o trabalho de análises extras, quando a execução do teste encontrar-se no caminho crítico do projeto.

6) Generalizar o defeito

Se a causa está suficientemente clara, o testador considera também se o defeito poderia acontecer em outros lugares.

O testador pode executar casos de teste simulares em outros lugares do objeto de teste(test object).

Defeitos relacionados à base de testes(test basis), o testador procura em lugares similares na documentação do projeto em busca de outros defeitos(Ex: defeitos na especificação técnica funcional gera defeitos na arquitetura).

A meta do testador não é a visão completa, mas ser capaz de prover uma impressão do tamanho e severidade do defeito.

Este passo tem por objetivo construir uma imagem do possível estrago que o defeito causaria em produção.

7) Comparar com outros defeitos

Antes dos testadores escreverem o relatório de defeito, eles investigam se o defeito já foi encontrado previamente.

Existem várias possibilidades como:

- O defeito foi encontrado na mesma parte da release atual.

- Um defeito similar já foi encontrado em outra parte da release atual.

- O defeito já foi encontrado na mesma parte da release anterior.

8) Escrever um relatório de defeitos

O testador documenta o defeito na forma de um relatório de defeito, descrevendo o defeito e completando os campos necessários.

A descrição do defeito deve ser clara, sem ambigüidades e objetiva. Além disso, o tom do relatório deve ser neutro e imparcial, sendo consciente que está entregando “más noticias”. Sarcasmos, cinismos e exageros obviamente devem ser evitados.

Idealmente, os testadores devem deixar claro quais as conseqüências envolvidas em não solucionar um defeito ou qual o estrago em produção.

9) Revisar

Antes do defeito formalmente entrar no procedimento de defeitos, o testador tem o relatório revisado para garantir a completude, exatidão e tom.

A revisão pode ser feita por outro testador, o gerente de testes ou administrador de defeitos.

Após os comentários, o defeito é formalmente submetido.

Reportar defeito

Um relatório de defeitos é muito mais que uma descrição do defeito, sendo que outros campos precisam ser estabelecidos como versão do objeto de teste e nome do testador.

Para fazer isso de uma maneira estruturada, um relatório de defeitos é freqüentemente dividido em vários campos, nos quais detalhes podem ser inseridos que são necessários para o gerenciamento do defeito e obtenção de informações relevantes.

A uniformidade e consistência de um relatório de defeitos pode ser melhorada restringindo possíveis valores de entrada para os campos, ao invés de usar uma caixa de texto.

Um relatório de defeitos contém no mínimo os seguintes campos, conforme o livro TMap Next, for result-driven testing:

- Nome do projeto ou sistema.

- Identificação única do defeito.

- Breve caracterização.

- Testador(Submitter).

- Identificação da fase / nível de teste.

- Severidade(Cosmético, rompimento(disruptive), severo e produção-obstrutiva).

- Prioridade(Re-trabalho eventual, retrabalho dentro da release atual e re-trabalho imediato).

- Causa(TB – Test Basis, S – Software, DOC-Documentation, TIS – Technical Infrastructure).

- Identificação do objeto de teste.

- Especificação do teste.

- Descrição do defeito.

- Apêndices.

- Solucionador do defeito.

- Notas na resolução.

- Resolvido no produto(Nº da versão).

- Status + Data(Novo, em processo, postergado, rejeitado, resolvido, re-teste e finalizado).

Além dos campos já citados, outros podem ser adicionados ao relatório de defeito.

As vantagens de se adicionar mais campos são melhores gerenciamentos de visão da qualidade e tendências. Já as desvantagens são administração extra de mais informações e maior complexidade.

Possíveis extensões de campos para serem adicionados ao relatório de defeitos são:

- Identificação do ambiente de teste.

- Identificação da base de testes(test basis).

- Categoria de severidade provisória.

- Prioridade provisória.

- Causa provisória.

- Característica da Qualidade.

Podemos citar campos do relatório de defeitos em conexão com o teste:

- Re-testador.

- Identificação do ambiente de teste.

- Identificação da base de testes(test basis).

- Identificação do objeto de teste(test object).

Ainda com relação às extensões de campos, podemos citar em conexão com a solução:

- Severidade definitiva.

- Prioridade definitiva.

- Causa definitiva.

- Prazo ou release para a solução requerida.

Procedimento de defeitos

Quando um defeito é levado para ser administrado, ele entra no procedimento de defeitos.

O progresso da resolução de defeitos é discutida em uma consulta(consultation) periódica de defeitos.

Participantes na consulta são representantes das partes que submeteram e/ou lidam com os defeitos:

- Representantes do teste: gerentes de teste, administrador de defeitos e intermediários.

-Outros representantes: usuários, gerência funcional/desenvolvimento/sistemas.

A consulta de defeitos é também algumas vezes combinada com as propostas de mudanças, conhecidos como o CCB(Change Control Board).

Em ordem de prioridade, os participantes discutem cada novo defeito e decidem se o defeito deve ser resolvido e se for o caso, por quem.

Nesta consulta, a correção, causa, prioridade e severidade dos defeitos, bem como os custos de solucioná-los, são discutidos.

Os participantes na consulta determinam, após realizar as discussões necessárias, os valores definitivos para causa, prioridade e severidade do defeito.

Se a consulta de defeitos concordar que é um defeito válido e os custos de resolução são aceitáveis, o defeito é designado para um solucionador.

Caso a consulta de defeitos concordar que não é um defeito válido, ou que os custos, prazo e riscos de teste de regressão para resolver o defeito forem muito altos, o defeito é rejeitado.

Um defeito válido que é rejeitado é também conhecido como “erros conhecidos”(known errors).

Se a consulta não concorda com o defeito, então o defeito é escalado para um fórum de decisões.

Representantes das partes com poderes de decisão participam do fórum como o cliente e gerente do projeto, os quais decidem se o defeito deverá ser resolvido ou não, e quando.

O fórum de decisão não é necessariamente uma consulta independente, mas é freqüentemente a reunião da gerencia do projeto ou reunião do conselho do projeto.

Uma vez aprovado, é iniciado o ciclo de vida do defeito. Os textos nos retângulos mostram os status do defeito. Os balões representam os atores.

A linha pontilhada de “Postponed”(Adiado) para “Allocated”(Alocado) significa que o defeito é postergado na release atual, mas deveria ser resolvido em uma release futura.

Referências e Links:

- Livros utilizados para a base deste artigo e materiais de apoio

1. TMap Next, for result-driven testing

2. Software Testing: A guide to the TMap Approach

3. End-to-end testing with TMap Next

- Links

     - Site TMap Next: http://eng.tmap.net/Home/

-TMap Next Downloads: http://eng.tmap.net/Home/TMap/Downloads/index.jsp

          - Glossário TMap Next: http://eng.tmap.net/Home/TMap/Glossary.jsp