The Bug Bang Theory

Onde está o defeito?

11 fev 2010 @ 22:17

(5 votes, average: 9,80 out of 10)

Loading ...

A maioria dos analistas de teste e testadores não sabe onde estão o defeito que eles encontram, ou em outras palavras, não analisam nem acompanham o defeito após encontrá-lo, ou quando fazem, podem fazer de maneira incorreta, o que de certa forma é mais prejudicial do que se não fizessem.

defeito

Na verdade, é quase impossível, até mesmo para um analista de teste experiente dizer com certeza que o defeito que ele encontrou é de software, requisitos, análise, desenho, configuração etc. Os defeitos mentem, e isso é um fato que vamos ter que conviver cada vez mais, já que a cada dia a complexidade dos projetos de software aumenta e com ela a complexidade dos defeitos e da arquitetura do software em desenvolvimento.

A atividade de gerência de defeitos é uma das atividades mais importantes para o projeto e principalmente para a organização. Com uma boa gerência de defeitos, vários indicadores podem ser utilizados para conhecer e melhorar os processos e a capacitação dos profissionais.

Alguns dos indicadores* são:

•TD (Total de Defeitos)
•DD (Detecção de Defeitos)
•DDG (Detecção de Defeitos Graves)
•TDG (Total de Defeitos Graves)
•ETS (Eficiência de Teste de Software)
•ERR (Eficiência de Revisão de Requisitos)

*Em um próximo post vou falar sobre métricas e indicadores.

Apesar de ser uma ferramenta muito importante, a gerência de defeitos muitas vezes é usada de forma incorreta ou não é aproveitado o seu potencial, ficando limitada a um workflow do Bugzilla ou do Mantis.

Como os defeitos não são analisados, as pessoas não se importam com onde eles foram encontrados, nem com quando eles foram encontrados, até o dia que um determinado projeto está com problemas e alguém pede uma métrica de “bugs” por desenvolvedor, normalmente solicitado por uma pessoa que não tem experiência como analista de testes ou está iniciando na carreira de coordenador/gerente de projetos.

Esse é o grande perigo. Como citado no post Bug is Dead!, a idéia de “bug” da uma impressão muito ruim dos desenvolvedores, pois bugs são de software, e software quem faz são os desenvolvedores e programadores. O ideal para evitar esse tipo de mal entendido, é catalogar os defeitos de forma a saber de onde eles vieram e não quem causou o defeito.

Nenhum defeito pode ser atribuído somente a uma pessoa no projeto, mas sempre a um conjunto de eventos, que, de não conseguiram evitar que esse problema fosse inserido em determinado momento do processo.

Agora vou dizer uma coisa que pode te assustar prezado leitor:

A identificação da origem do defeito não é de responsabilidade do profissional que encontrou o defeito.

Muito simples, o profissional de testes ou quem encontrou o defeito, não pode saber claramente a sua origem, não pode dizer com certeza absoluta onde o defeito estava. Se estava no código, se era no ambiente, uma configuração do servidor, um problema de compatibilidade etc.

A única pessoa que tem essa informação é quem corrige o defeito. Ele é o único que sabe com 100% de certeza onde o defeito estava.

A responsabilidade de acompanhar essa informação e de garantir sua integridade sim, é de responsabilidade do gerente de defeitos, que normalmente é uma pessoa da qualidade ou teste de software. Por isso é importante acompanhar o andamento dos defeitos, preferencialmente todos os dias, de forma a manter o controle e rastreabilidade entre o defeito e sua origem.

Outra situação que acontece com frequência com novos testadores, é que assim como a nossa querida Tia Cida que sem querer escreveu “Café com defeito” quando na verdade o defeito estava no repositório de colheres da máquina de café. É um exemplo bobo e divertido, mas muito próximo do que acontece com algumas pessoas. Por vezes, os defeitos são descritos de forma pouco detalhada, com informações insuficientes para sua reprodução, com falta de atenção ou as vezes detalhado demais, dificultando sua interpretação.

Não existe uma forma de garantir que a descrição do defeito esteja perfeita, mas uma técnica que venho usando com sucesso é a substituição do passo a passo pelos procedimentos (passo a passo) do caso de teste que detectou o defeito.

Dessa maneira, a pessoa que corrigiu o defeito executa um teste de regressão e não um teste de confirmação. O mesmo acontece quando o testador recebe o defeito para verificar/validar, ao invés de executar um teste de confirmação, limitado as condições únicas daquele defeito, ele executa um teste de regressão, garantindo que aquela funcionalidade continua funcionando mesmo após a correção daquele defeito.

Caso o teste tenha sido detectado por um teste exploratório, o testador pode criar um Caso de Teste numa suíte especial, para aquele defeito (considerando o resultado esperado), e somente em seguida deve cadastrar o defeito na ferramenta de gestão de defeitos. Essa é uma pratica do XP que também da muito certo.
*O detalhamento dessa e outras práticas pode ser lido no post “Práticas XP ajudando na efetividade do teste de software“.

Bons Testes