The Bug Bang Theory

(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.

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

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

(2 votes, average: 9,00 out of 10)

 Loading ...

Estou escrevendo esse post para passar para frente um pensamento que tenho ha algum tempo sobre o nosso popular termo “BUG”.

Acredito que todo mundo já conhece essa história e nunca cansa de contar para todas as pessoas que perguntam o porquê desse termo, levando em consideração a conotação de defeito de software que é atribuído a esse termo.

O que quero perguntar é: Esse termo ainda é adequado?

Meu ponto de vista é que o nosso tradicional bug, ainda é o bug de 1945, atribuído a construção e a engenharia. Se pensarmos nas fases do RUP, o bug é identificado em um código fonte ou em um produto de trabalho derivado da fase de construção ou identificado em um produto já em testes, homologação ou produção.

O problema é que ao longo de vários anos estamos aprendendo que o bug, aquele que está no código fonte, não é o único problema proveniente da engenharia de software, na verdade, muitas das vezes ele é somente uma consequência de um defeito em outra atividade ou em outro produto de trabalho.

O que quero deixar bem claro é que não considero a nomenclatura errada, apenas acredito que o termo não é o mais adequado no cenário atual, levando em consideração a conotação de defeito de software que é atribuído a esse termo.

Acredito que existam tantos defeitos quanto papeis dentro de um processo de fabricação de software. Logo o Gerente de Projetos erra e gera defeitos de planejamento, o analista de negócios/requisitos erra e gera defeitos de requisitos e assim por diante.

Todos os papeis ou até mesmo atividades de um processo podem gerar problemas no software ou sistema desenvolvido, o problema é que muitas vezes chamamos isso de não conformidade e não fazemos a coleta adequada desses números. Mas os defeitos sempre estão gerenciados pelo Bugzilla, pelo Mantis ou por uma ferramenta “bugtracker” qualquer.

Quando acontece algum problema em um projeto, os primeiros dados medidos e comparados são os bugs, sim os que cadastramos para os desenvolvedores. Esses bugs sempre tem origem no software e sempre são de responsabilidade dos programadores.

Mas e os defeitos de requisitos? E as mudanças de cronograma? E os defeitos que podiam ser identificados antes e agora estão mais caros porque os analistas de teste não identificaram no momento mais adequado?

Bom, esses são meus argumentos para justificar o título desse post. Acho que o BUG está morto, e é tempo para pensarmos em defeitos como produtos de trabalho, exceções das atividades de todos envolvidos no processo. É tempo de aliviar um pouco os nossos desenvolvedores e fazer a equipe assumir os problemas como devem ser assumidos.

Importante, não quero dizer para apontarmos responsáveis por defeitos, ou para ficar medindo o índice de defeitos de cada colaborador, mas sim para dentro dos nossos processos termos como argumentar a entrada da equipe de teste e qualidade o mais cedo. Mostrar que podemos verificar os requisitos e identificar defeitos que mais tarde iriam virar bugs de software, mostrar que às vezes nos não conhecemos tão bem os nossos próprios processos ou pior, às vezes achamos que conhecemos bem e tomamos decisões ineficazes para resolver problemas com base nas suas conseqüências e não na sua raiz.

Sugiro uma reflexão sobre as métricas que usamos para gerir nossos defeitos, conscientização de que todos nós falhamos e aos poucos vamos conseguindo identificar onde devemos melhorar a equipe, onde podemos melhorar os processos, quem precisa de mais capacitação e investimento, etc.


This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.