Joel on Software

Joel on Software   Joel sobre Software

 

Outros artigos de "Joel on Software" em Português

Outros artigos de "Joel on Software" em Inglês

Envie email para o autor (apenas em Inglês)

 

Acompanhamento de Bugs Indolor


Por Joel Spolsky
Traduzido por Carlos Duarte do Nascimento
Editado por Rafael Sabbagh Armony
8 de Novembro de 2000

O BASIC do TRS-80 Level-I só armazenava duas variáveis string, A$ e B$. Da mesma forma, eu também nasci com apenas dois slots para armazenar bugs no meu cérebro. Em qualquer momento, eu só consigo me lembrar de dois bugs. Se você me pedir para lembrar de três, um deles cairá no chão e será varrido para debaixo da cama junto com os montinhos de poeira, que irão engoli-lo.

Manter um banco de dados de bugs é uma das características imprescindíveis de qualquer boa equipe de software. Eu não canso de me espantar com a quantidade mínima de equipes que efetivamente fazem isto. Um dos fatos mais errados em que os programadores parecem consistentemente acreditar é que eles podem lembrar de todos os seus bugs, ou mantê-los em post-its.

Se eu puder alugar seu ouvido por um instante, gostaria de lhe explicar uma forma bastante indolor de se fazer o acompanhamento de bugs, no mesmo espírito dos meus artigos anteriores sobre cronogramas indolores e especificações indolores.

Em primeiro lugar, você precisa de um banco de dados de verdade. Em equipes de duas pessoas escrevendo um pouco de código durante um longo fim-de-semana, é provavelmente aceitável utilizar um arquivo-texto como o banco de dados. Para qualquer coisa maior do que isso, você precisará de um banco de dados para acompanhamento de bugs de verdade. Há zilhões de sistemas de acompanhamento de bugs que você pode comprar. (Propaganda descarada: o sistema que criamos na Fog Creek Software, chamado FogBUGZ, roda na web, é muito fácil de usar, e bastante poderoso, se é que eu posso dizer isto.)

Vamos acompanhar um bug, para fins ilustrativos, do momento em que ele nasce até o em que alguém finalmente dá um fim a seu sofrimento. Acompanharemos o famoso Bug 1203. Veja o que o banco de dados de bugs diz a respeito dele:
ID
1203
Projeto
Bee Flogger 2.0
Área
Cliente de FTP
Título
Enviar um arquivo faz o servidor de FTP dar um "core dump"
Atribuído a
FECHADO
Status
FECHADO (RESOLVIDO - CORRIGIDO)
Prioridade
2 - Deve ser corrigido
Corrigir Para
2.0 Alfa
Versão
Build 2019
Computador
iMac da Jill, Mac OS 9.0, 128MB de RAM, 1024x768 com milhões de cores
Descrição
1/11/2000 Aberto por Jill, a Testadora Muito, Muito Boa
* Inicie o Bee Flogger
* Crie um documento sem título, contendo apenas a letra "a"
* Clique no botão FTP da barra de ferramentas
* Tente fazer um ftp para o seu servidor

BUG: Observe; o servidor ftp não responde mais. De fato, um ps -augx mostra que ele nem está mais rodando e há um core dump em /.

RESULTADO ESPERADO: Não travar

1/11/2000 Atribuído a Willie, o Desenvolvedor-Chefe por Jill, a Testadora Muito, Muito boa

2/11/2000 (Ontem) RESOLVIDO - NÃO SERÁ CORRIGIDO por Willie, o Desenvolvedor-Chefe

Não é no nosso código, Jill, é apenas o proftpd que vem com o Linux.

2/11/2000 (Ontem) Reativado (atribuído a Willie, o Desenvolvedor-Chefe) por Jill, a Testadora Muito, Muito boa

Isso não me parece certo. Eu nunca consegui fazer o proftpd travar quando eu conectava com um cliente de ftp normal. Nosso código faz ele travar todas as vezes. Servidores de ftp não simplesmente "travam".

3/11/2000 (Hoje) Atribuído a Mikey, o Programador por Willie, o Desenvolvedor-Chefe

Mikey, você pode dar uma olhada nisso? Talvez nosso código na parte cliente esteja fazendo algo errado.

3/11/2000 (Hoje) RESOLVIDO - CORRIGIDO por Mikey, o Programador

Acho que eu estava passando o nome do usuário no lugar da senha, ou algo assim...

3/11/2000 (Hoje) Reativado (atribuído a Mikey, o programador) por Jill, a Testadora Muito, Muito boa

Ainda acontece no Build 2021.

3/11/2000 (Hoje) Editado por Mikey, o Programador

Opa. Isso é estranho. Deixa eu debugar isso.

3/11/2000 (Hoje) Editado por Mikey, o Programador

Estou achando que pode ser a MikeyStrCpy()...

3/11/2000 (Hoje) RESOLVIDO - CORRIGIDO por Mikey, o Programador

Ahhh!
CORRIGIDO!

3/11/2000 (Hoje) Fechado por Jill, a Testadora Muito, Muito boa

Está corrigido no Build 2022, vou seguir em frente e fechar isto.

Vejamos o que aconteceu.

Mikey, o Programador está explorando o código da nova funcionalidade do cliente de FTP do seu bom software para Macintosh. Em algum momento, ele se empolga e escreve sua própria função de cópia de strings. Isso vai lhes dar uma lição, sua irritante patrulha da reusabilidade! Ha ha ha!

Coisas ruins acontecem quando você não reutiliza código, Mikey. E hoje, o que aconteceu de ruim foi que Mikey esqueceu de terminar com null a string copiada. Mas ele nunca percebeu o problema porque, na maioria das vezes, ele por acaso estava copiando strings em áreas de memória pré-zeradas.

Mais tarde naquela mesma semana, Jill, a Testadora Muito, Muito Boa está castigando bastante código, passando sua testa de um lado ao outro do teclado, ou fazendo algum outro teste igualmente cruel. (Por acaso a maioria das boas testadoras chama-se Jill ou alguma variante, como Gillian.) De repente, algo muito estranho acontece: o daemon de FTP que ela estava testando travou. É, eu sei que é uma máquina Linux, e que máquinas Linux nunca travam (sem manifestações ruidosas da turma do slashdot, por favor), mas o maldito travou. E ela nem tocou no servidor, ela só estava enviando arquivos via FTP para ele usando o código de Mac do Mikey.

Bem, Jill é uma testadora muito, muito boa, então ela manteve um histórico muito detalhado do que estava fazendo (as medidas e o ângulo preciso de sua cabeça enquanto ela a rolava pelo teclado estão em suas anotações, por exemplo). Ela reinicia tudo, recomeça com uma máquina zerada, repete os passos, e -- veja só -- acontece de novo! O daemon de ftp do Linux travou de novo! Agora foram duas vezes num mesmo dia! Tome essa, Linus.

Jill dá uma olhada na lista de passos para reproduzir o bug. São cerca de 20 passos. Alguns deles não parecem relacionados entre si. Depois de experimentar um pouco, Jill consegue reduzir o problema a quatro passos que sempre causam o mesmo comportamento. Agora ela está pronta para cadastrar um bug.

Jill entra com o novo bug no banco de dados de acompanhamento de bugs. Bem, o simples ato de cadastrar um bug requer alguma disciplina: existem relatórios de bugs bons e relatórios de bugs ruins.

Três Elementos para Todo bom Relatório de Bugs

E o senhor proclamou, dizendo: "Primeiro, tu deves tirar o Santo Pino. Então conta até três, nem mais, nem menos. Três deverá ser o número a que contarás, e o número a que contarás deverá ser três. A quatro não contarás, nem mesmo contarás até dois, exceto se procederes então até o três. O cinco está fora. Uma vez que o número três, sendo o terceiro número, seja alcançado, atira então a Santa Granada de Mão de Antioch em direção ao inimigo, que, sendo mau aos meus olhos, deverá engoli-la."

-- Monty Python e A Busca do Cálice Sagrado


É bem fácil memorizar a regra básica para um bom relatório de bugs. Todo bom relatório de bugs necessita de exatamente três coisas.
  1. Passos para reproduzir o bug,
  2. O que você esperava ver, e
  3. O que você viu, ao invés disso.

Parece fácil, certo? Talvez não seja. Como programador, as pessoas regularmente atribuem a mim bugs esquecendo-se de um ou de outro item.

Se você não me disser como reproduzir o bug, eu provavelmente não vou fazer a menor idéia de sobre o que você está falando. "O programa travou e deixou um objeto malcheiroso parecido com esterco na mesa". Tudo bem, querido. Não posso fazer nada a respeito a não ser que você me diga o que você estava fazendo. Claro, admito que há dois casos em que é difícil obter os passos exatos para se reproduzir o bug. Às vezes você simplesmente não se lembra, ou está apenas transcrevendo um bug obtido "em campo." (Por falar nisso, por que as pessoas dizem "em campo"? É como um campo de centeio, ou algo do gênero? Deixa pra lá...) A outra situação em que é tolerável não haver os passos é quando o bug acontece de vez em quando mas não sempre, mas ainda assim deve-se fornecer passos para a reprodução, com um pequeno comentário dizendo que ele não acontece com muita freqüência. Nestes casos, será realmente bem difícil encontrar o bug, mas podemos tentar.

Se você não especificar o que você esperava ver, eu posso não entender por que isso é um bug. A tela de abertura tem uma mancha de sangue. E daí? Cortei os dedos quando eu a estava programando. O que você esperava? Ah, você me diz que a especificação pedia nada de sangue! Agora eu entendo porque você considera isso um bug.

Parte três. O que você viu no lugar do que deveria ter visto. Se você não me diz isso, eu não sei o que é o bug. Essa é meio óbvia.

De Volta à Nossa História

De qualquer forma, Jill cadastra o bug. Em um bom sistema de acompanhamento de bugs, ele é automaticamente atribuído ao desenvolvedor-chefe para aquele projeto. E é aí que surge o segundo conceito: cada bug deve estar designado a exatamente uma pessoa em qualquer momento, até o seu fechamento. Um bug é como uma batata quente: quando ele é passado a você, você é responsável por resolvê-lo de alguma forma, ou passá-lo para outra pessoa.

Willie, o desenvolvedor-chefe, dá uma olhada no bug, decide que provavelmente tem algo a ver com o servidor de ftp, e o resolve como "não corrigir". Afinal de contas, eles não escreveram o servidor de ftp.

Quando um bug é resolvido, ele é atribuído de volta à pessoa que o abriu. Isso é um ponto crucial. Ele não desaparece simplesmente porque um programador acha que ele deve desaparecer. A regra de ouro é que apenas a pessoa que abriu o bug pode fechá-lo. O programador pode resolver o bug, o que significa: "ei, eu acho que está pronto", mas para realmente fechar o bug e retirá-lo dos registros, a pessoa que originalmente o abriu precisa confirmar que ele realmente foi corrigido ou concordar que ele não deve ser corrigido por algum motivo.

Jill recebe um e-mail lhe dizendo que o bug caiu novamente em seu colo. Ela o examina e lê os comentários de Willie, o desenvolvedor-chefe. Algo não soa bem. As pessoas vêm usando este servidor de ftp por anos e ele nunca trava. Ele só trava quando se usa o código do Mikey. Então Jill reativa o bug explicando sua posição, e o bug volta para Willie. Desta vez, Willie atribui o bug a Mikey para que ele o corrija.

Mikey estuda o bug, pensa bastante por um bom tempo, e faz um diagnóstico totalmente errado do bug. Ele conserta um outro bug que não tinha nada a ver, e então resolve o bug que Jill tinha aberto.

O bug volta para Jill, desta vez marcado como "RESOLVIDO-CORRIGIDO". Jill tenta os seu passos de reprodução no último build, e, vejam só, o servidor Linux trava. Ela reativa o bug novamente e o atribui diretamente ao Mikey.

Mikey está perplexo, mas ele segue até descobrir a origem do bug. (Já sabe o que é? Eu vou deixar como um exercício para o leitor. Já dei pistas suficientes!). Ele o conserta, testa e -- Eureca! Os passos de reprodução não travam mais o servidor. Mais uma vez, ele o resolve como "CORRIGIDO". Jill tenta também os passos, descobre que o bug é coisa do passado, e o fecha.

As dez Melhores Dicas para se Encontrar Bugs

  1. Um bom testador sempre tentará reduzir os passos de reprodução ao menor número possível; isso é de grande ajuda para o programador que tem que encontrar o bug.
  2. Lembre-se que a única pessoa que pode fechar um bug é a pessoa que o abriu. Qualquer um pode resolvê-lo, mas apenas a pessoa que o viu pode realmente ter certeza de que o que ela viu foi corrigido.
  3. Há muitas maneiras de se resolver um bug. O FogBUGZ permite que se resolva um bug como corrigido, não será corrigido, postergado, não reproduzível, duplicado ou por projeto.
  4. Não Reproduzível significa que ninguém jamais conseguiu reproduzir o bug. Programadores usam isso com freqüência quando estão faltando os passos de reprodução no relatório do bugs.
  5. Você irá querer manter um controle cuidadoso das versões. Cada build do software entregue aos testadores deve ter um número de identificação para que o pobre testador não tenha venha a testar novamente o bug em uma versão do software na qual nem era esperado que ele estivesse consertado.
  6. Se você é um programador, e está difícil convencer os testadores a usarem o banco de dados de bugs, simplesmente não aceite relatórios de bugs por qualquer outro método. Se seus testadores estão acostumados a te mandar um e-mail com relatórios de bugs, apenas responda o e-mail com um texto breve: "por favor, coloque isto no banco de dados de bugs. Eu não posso acompanhar os e-mails."
  7. Se você é um testador, e está difícil convencer os programadores a usarem o banco de dados de bugs, apenas não fale com eles sobre bugs - cadastre-os no banco de dados e deixe que o sistema lhes envie os e-mails.
  8. Se você é um programador, e apenas alguns dos seus colegas usam o banco de dados de bugs, basta começar a atribuir bugs a eles no banco de dados. Com o tempo, eles vão entender o recado.
  9. Se você é um gerente, e ninguém parece estar usando o banco de dados de bugs que lhe custou uma fortuna para instalar, comece a atribuir novas funcionalidades para as pessoas implementarem utilizando os bugs. Um banco de dados de bugs também é um excelente banco de dados de "funcionalidades não-implementadas".
  10. Evite a tentação de adicionar novos campos no banco de dados de bugs. De mês em mês, alguém virá com uma grande idéia de um novo campo para adicionar ao banco. Você recebe todo o tipo de idéias engenhosas, como por exemplo, controlar em que arquivo o bug foi encontrado; controlar o percentual das vezes em que o bug é reproduzível; controlar quantas vezes o bug aconteceu; controlar quais versões exatas de quais DLLs estavam instaladas na máquina onde o bug aconteceu. É importante não ceder a estas idéias. Se você fizer isso, sua nova tela de entrada de bugs vai acabar com mil campos a serem preenchidos e ninguém mais vai querer cadastrar relatórios de bugs. Para o banco de dados de bugs funcionar, todos deverão usá-lo, e se entrar bugs "formalmente" der muito trabalho, as pessoas irão burlar o banco de dados de bugs.

Se você desenvolve código, mesmo em um grupo de uma só pessoa, sem um banco de dados organizado listando todos os bugs conhecidos no programa, você simplesmente irá entregar código de baixa qualidade. Em boas equipes de desenvolvimento de software, não apenas se utiliza o cadastro de bugs universalmente, mas as pessoas têm o hábito de usar o cadastro de bugs para fazer suas próprias listas de itens "a fazer", elas mudam a página default do browser para a lista de bugs designada a eles, e elas começam a desejar que pudessem atribuir bugs ao gerente do escritório para que ele aumentasse o estoque de Gatorade.


A Fog Creek Software oferece um pacote de gerenciamento de bugs de fácil uso chamado FogBUGZ.


Esse artigo apareceu originalmente em Inglês com o título Painless Bug Tracking  

Joel Spolsky é o fundador da Fog Creek Software, uma pequena empresa de software na cidade de Nova York. Formou-se na Universidade de Yale, e trabalhou como programador e gerente na Microsoft, na Viacom e no Juno.


O conteúdo dessas páginas reflete exclusivamente a opinião do autor.
Todo o conteúdo Copyright ©1999-2005 Joel Spolsky. Todos os direitos reservados.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky