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)

 

As Cinco Principais Razões (Erradas) Para Não Se Utilizar Testadores


Por Joel Spolsky
Traduzido por Carlos Duarte do Nascimento
Editado por Rafael Sabbagh Armony
30 de Abril de 2000

Em 1992, James Gleick teve uma série de problemas com softwares cheios de bugs. Uma nova versão do Microsoft Word para Windows havia sido lançada e Gleick, um divulgador científico, considerou-a péssima. Ele escreveu um longo artigo na revista de domingo do New York Times que só pode ser descrito como um ataque direto, dando um sermão na equipe do Word por não atenderem aos pedidos dos usuários, e por entregarem um produto com tantos bugs.

Mais tarde, como cliente do provedor de Internet Panix (que por acaso também é meu provedor), ele queria uma maneira de ordenar e filtrar automaticamente seus e-mails. A ferramenta UNIX para se fazer isso se chama procmail, que é bastante misteriosa e tem o tipo de interface que mesmo os tietes mais radicais do UNIX admitem ser obscura.

De qualquer forma, utilizando o procmail, Gleick inadvertidamente cometeu algum erro de digitação inocente que apagou todos os seus e-mails. Enfurecido, ele decidiu criar sua própria empresa de acesso à Internet. Ao contratar o programador Uday Ivatury, ele criou a Pipeline, que estava realmente bem à frente do seu tempo: era o primeiro provedor comercial de acesso à Internet com algum tipo de interface gráfica.

Agora, é claro que a Pipeline teve seus problemas. A primeira de todas as versões não usava nenhum tipo de protocolo de correção de erros, o que a fazia ter uma tendência a bagunçar as coisas ou travar. Como todo software, este tinha seus bugs. Eu concorri a um emprego na Pipeline em 1993. Durante a entrevista, perguntei ao Sr. Gleick sobre o artigo que ele escrevera. "Agora que está do outro lado", perguntei, "você entende um pouco melhor a dificuldade de se criar um bom software?"

Gleick não tinha arrependimentos. Negou que o software da Pipeline tivesse quaisquer bugs. Ele não o considerava nem de longe tão ruim quanto o Word. Ele me disse: "um dia, Joel, você também passará a odiar a Microsoft". Fiquei um pouco chocado com o fato de que um ano de experiência como criador de software, e não apenas como usuário, não lhe dera um mínimo de sensibilidade sobre a dificuldade que existe em se obter software sem bugs e fácil de usar. Então eu recuei, recusando a oferta de emprego. (A Pipeline foi comprada pela PSI, o provedor de Internet mais bizarro do planeta, e depois, sem qualquer cerimônia, foi levada para fora e abatida a tiros).

Programas de computador possuem bugs. CPUs são incrivelmente frescas. Elas se recusam absolutamente a lidar com coisas com que não foram explicitamente ensinadas a lidar, e tendem a fazer isso da maneira mais infantil. Quando meu laptop está longe de casa, ele costuma travar um bocado porque não encontra a impressora de rede que está acostumado a encontrar. Que bebê chorão. Isso provavelmente não passa de uma única linha de código em algum lugar com um bugzinho minúsculo, quase insignificante.

E é por isso que você certamente, absolutamente, precisa de ter um departamento de Controle de Qualidade. Você vai precisar de 1 testador para cada 2 programadores (ou mais se seu software tiver que funcionar em várias configurações complicadas ou diversos sistemas operacionais). Cada programador deveria trabalhar em sintonia com um único testador, gerando para ele builds particulares sempre que necessário.

O departamento de Controle de Qualidade deve ser independente e poderoso, não deve responder à equipe de desenvolvimento; na verdade, seu responsável deve ter poder de veto sobre o lançamento de qualquer software que não for aprovado nos testes.

Meu primeiro emprego de verdade na indústria de software foi na Microsoft, uma empresa que não é exatamente reconhecida por seu código de alta qualidade, mas que de qualquer forma emprega um grande número de testadores de software. Assim eu tinha meio que assumido que toda operação que envolvesse software teria testadores.

Muitas os têm. Mas um número surpreendente não tem testadores. De fato, muitas equipes de software sequer acreditam em testes.

Seria de se pensar que, depois de toda aquela mania de Qualidade dos anos 80, com todos os tipos de certificação de "qualidade" sem qualquer significado como a ISO-9000 e expressões de efeito como "Seis-Sigma", os gerentes de hoje em dia deveriam entender que ter produtos de alta qualidade faz sentido em termos de negócios. De fato, eles entendem isso. Muitos conseguiram colocar isso em suas cabeças. Mas eles ainda propõem uma série de razões para não se utilizar testadores de software, todas elas erradas.

Eu espero ser capaz de lhe explicar porque estas idéias estão erradas. Se você estiver com pressa, pule o resto do artigo e vá contratar um testador em tempo integral para cada dois programadores em tempo integral de sua equipe.

Aqui estão as reprováveis desculpas mais comuns que eu já ouvi para não se contratar testadores:

1. Os erros surgem devido a programadores preguiçosos.

"Se contratarmos testadores", e segue a fantasia, "os programadores vão ficar descuidados e escreverão código com bugs. Evitando os testadores, podemos forçar os programadores a escrever código correto logo de primeira."

Tá, tá. Se você pensa assim, ou você jamais escreveu código, ou você é incrivelmente desonesto sobre como é o processo de se escrever código. Bugs, por definição, proliferam porque os programadores não os viram em seu próprio código. Muitas vezes basta um outro par de olhos para ver o bug.

Quando eu escrevia código no Juno, eu costumava exercitar o meu código do mesmo jeito todas as vezes... eu usava meus próprios hábitos, trabalhando bastante com o mouse. Nossa maravilhosa e extremamente superqualificada testadora tinha hábitos ligeiramente diferentes: ela fazia mais coisas com o teclado (e na verdade testava rigorosamente a interface usando todas as combinações de entradas possíveis). Isso rapidamente revelava uma tonelada de erros. De fato, das vezes em que ela me disse que a interface simplesmente não funcionava, em 100% ela não funcionava, mesmo tendo sempre funcionado comigo. Quando eu a via reproduzir o bug eu sempre acabava me dando um tapa na testa. Alt! Você está segurando a tecla Alt! Por que eu não testei isso?

2. Meu software está na web. Eu posso consertar os erros em um segundo.
Hua ha ha ha ha! Ok, é verdade, a distribuição da web permite que você distribua as correções de erros muito mais rápido do que nos velhos tempos de software empacotado. Mas não subestime o custo de consertar um bug, mesmo num site na web, depois que o projeto foi finalizado. Em primeiro lugar, você pode introduzir ainda mais bugs ao consertar o primeiro. Mas o maior problema é que se você analisar todo o processo que é acionado para se colocarem novas versões no ar, você vai perceber que pode sair bem caro publicar correções na web. Além da má impressão que você deixa, o que nos leva a:
3. Meus clientes testarão o software para mim.
Ah, a temida "Defesa Netscape". Esta pobre empresa causou danos quase sobrenaturais em sua reputação devido a sua metodologia de "testes":
  1. quando os programadores estiverem na metade do trabalho, disponibilize o software na web sem qualquer tipo de teste.
  2. quando os programadores disserem que acabaram, disponibilize o software na web sem qualquer tipo de teste.
  3. repita seis ou sete vezes.
  4. dê a uma dessas versões o nome de "versão final".
  5. disponibilize as versões .01, .02, .03 cada vez que um bug embaraçoso for mencionado na c|net.
Esta empresa foi a pioneira na idéia de "betas em larga escala". Literalmente milhões de pessoas faziam o download dessas versões incompletas e cheias de bugs. Nos primeiros anos, quase todos os usuários de Netscape estavam utilizando algum tipo de pré-lançamento ou versão beta. Como resultado, muitos pensam que softwares da Netscape são realmente cheios de bugs. Mesmo que a versão final costumasse ter poucos bugs, a Netscape tinha condenado tantas pessoas a usarem versões com bugs que a impressão média que a maioria das pessoas tinha do software era bastante ruim.

Além disso, toda a idéia de deixar "seus clientes" fazerem os testes é que eles encontrem os erros, e você então os conserte. Infelizmente, nem a Netscape nem qualquer outra empresa no mundo tem recursos humanos suficientes para peneirar relatórios de erros de 2.000.000 de clientes e decidir o que é realmente importante. Quando eu relatava erros no Netscape 2.0, o site para se informar erros travava com freqüência e simplesmente não me deixava reportar um erro (o qual, é claro, teria ido parar no buraco negro de qualquer forma). Mas a Netscape não aprende. Testadores da versão "preview", 6.0, têm reclamado em newsgroups que o site de para informar erros simplesmente ainda não possibilita o envio dos relatórios. Anos depois! O mesmo problema!

Desses zilhões de relatórios de erros, eu apostaria que quase todos eram sobre os mesmos 5 ou 10 erros mais óbvios, de todo jeito. Enterrado neste palheiro deve haver um ou dois erros interessantes, difíceis de se encontrar, que alguém teve o trabalho de relatar, mas ninguém vai ler estes relatórios de qualquer forma, então é trabalho perdido.

O pior desta forma de se testar é a impressão notadamente ruim que você acaba criando para sua empresa. Quando a Userland lançou a primeira versão para Windows do seu carro-chefe, o Frontier, eu fiz o download e comecei a usá-lo pelo tutorial. Infelizmente, o Frontier travou várias vezes. Eu estava seguindo literalmente as instruções, exatamente como estavam impressas no tutorial, e eu não conseguia ficar mais de 2 minutos no programa. Eu senti como se ninguém na Userland tivesse feito uma quantidade mínima de testes, para ter certeza que o tutorial funcionaria. A baixa qualidade percebida no produto me afastou do Frontier por muito, muito tempo.
4. Ninguém qualificado como um bom testador vai querer trabalhar como testador.
Essa é dolorosa. É bastante difícil se contratar bons testadores.

Com os testadores, como acontece com os programadores, os melhores são uma ordem de grandeza melhores que os medianos. Na Juno, nós tínhamos uma testadora, Jill McFarlane, que encontrava três vezes mais erros que todos os outros testadores juntos. Não estou exagerando, eu realmente medi isso. Ela era mais de doze vezes mais produtiva que um testador mediano. Quando ela pediu demissão, eu mandei um e-mail ao CEO dizendo: "Eu preferiria ter Jill somente nas segundas e terças do que todo o resto do grupo de Controle de Qualidade".

Infelizmente, a maioria das pessoas inteligentes tende a se entediar com o dia-a-dia de testes, o que leva os melhores testadores a durarem cerca de 3 ou 4 meses e depois irem embora.

A única coisa a fazer a respeito deste problema é reconhecer que ele existe, e lidar com ele. Seguem algumas sugestões:
  • Apresente o trabalho de testador como um degrau acima na carreira do suporte técnico. Por mais tedioso que testar seja, certamente é melhor do que lidar com usuários furiosos ao telefone, e isso pode ser uma forma de eliminar um pouco da rotatividade no lado do suporte técnico.
  • Permita aos testadores desenvolverem suas carreiras com aulas de programação, e encoraje os mais inteligentes a desenvolverem sistemas automáticos de teste usando ferramentas de programação e linguagens script. Isso é um bocado mais interessante do que testar a mesma caixa de diálogo muitas e muitas e muitas vezes.
  • Reconheça que você terá muita rotatividade dentre seus melhores testadores. Contrate de forma agressiva para manter um fluxo constante de entrada de pessoal. Não pare com as contratações somente porque você temporariamente está com a casa cheia, porque estes bons tempos não irão durar.
  • Procure trabalhadores "não tradicionais": adolescentes espertos, estudantes da faculdade e aposentados, trabalhando em meio-período. Você poderia criar um departamento de testes impressionantemente bom com duas ou três estrelas em período integral e um exército de garotos do Bronx Science (uma escola de segundo grau de primeiro nível em Nova Iorque), trabalhando em suas férias para pagarem suas faculdades.
  • Contrate trabalhadores temporários. Se você chamar 10 trabalhadores temporários para chegarem e castigarem o seu software por alguns dias, você vai encontrar um número enorme de bugs. Dois ou três desses temporários devem ter habilidade para testes, e neste caso vale a pena comprar os seus passes para tê-los em período integral. Reconheça antecipadamente que alguns dos temporários se tornarão péssimos testadores; mande-os para casa e siga em frente. É para isso que as agências de empregos temporários servem.
Aqui vai um jeito de não lidar com a questão:
  • Nem sonhe em dizer a recém-formados de Ciência da Computação que eles podem vir trabalhar para você, mas "todos aqui têm que passar um tempo no Controle de Qualidade antes de irem para a programação". Eu já vi um bocado disso. Programadores o são bons testadores, e você irá perder um bom programador, que é muito mais difícil de se substituir.

E finalmente. A razão estúpida número um pela qual as pessoas não contratam testadores:

5. Não tenho verba para ter testadores!
Essa é a mais idiota, e a mais fácil de desbancar.

Não importa o quão difícil seja encontrar testadores, eles ainda são mais baratos que os programadores. Bem mais baratos. E se você não contratar testadores, você terá programadores fazendo os testes. E se você acha ruim quando seus testadores vão embora, espere só para ver quanto sai para substituir aquele programador, a $100.000 por ano, que cansou de receber ordens para "passar algumas semanas testando até o lançamento", e foi para uma empresa mais profissional. Você poderia contratar três testadores por um ano inteiro só para cobrir o custo de recrutamento do programador substituto.

Ser mesquinho com testadores é uma economia tão descaradamente falsa que eu simplesmente não consigo entender como mais pessoas não reconhecem o fato.



Esse artigo apareceu originalmente em Inglês com o título Top Five (Wrong) Reasons You Don't Have Testers  

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