As Cinco Melhores Razões (Erradas)

Para Você Não Ter Testadores

From The Joel on Software Translation Project

Por Joel Spolsky da Fog Creek Software - Artigo original: Top Five (Wrong) Reasons
You Don't Have Testers - Traduzido por: Yakultsan

Em 1992, James Gleick estava tendo um monte de problemas com software defeituoso.
Uma nova versão do Microsoft Word para Windows tinha sido lançado, na qual Gleick,
um escritor científico, considerou ser terrível. Ele escreveu um artigo extenso na edição
dominical da New York Times Magazine que pode ser descrito como inflamável,
criticando a equipe do Word por não responder aos pedidos dos clientes e, por ter
liberado um produto altamente defeituoso.

Depois, como cliente do provedor local de internet Panix (que também é o meu provedor
de acesso), ele queria uma forma de automaticamente organizar e filtrar seu correio. A
ferramenta UNIX para fazer isso é chamado procmail, que é realmente arcaico e é do
tipo de interface que mesmo o mais fanático usuário UNIX admitiria que é obscuro.

De qualquer forma, Sr. Gleick acidentalmente rodou algum comando no procmail que
apagou todos os seus emails. Num acesso de raiva, ele decidiu que ele iria criar sua
própria empresa de acesso a internet. Contratando Uday Ivatury, um programador, ele
criou Pipeline, que era realmente um pouco avançada para sua época: foi o primeiro
provedor comercial de acesso a internet com algum tipo de interface gráfica.

Agora, Pipeline tem seus problemas, é claro. A primeira versão não usava nenhum tipo de
protocolo de correção de erro, então ele tinha a tendência de se atrapalhar com as coisas
ou travar. Como todo software, ele tinha defeitos. Eu me candidatei a um trabalho na
Pipeline em 1993. Durante a entrevista, eu perguntei ao Sr. Gleick sobre o artigo que ele
escreveu. “Agora que você está do outro lado da força,” eu perguntei, “você compreende
melhor a dificuldade de se criar bom software ?”

Gleick não estava arrependido. Ele negou que a Pipeline tinha algum defeito. Ele negou
que havia algo tão ruim quanto Word. Ele me disse: “Um dia, Joel, você também virá a
odiar a Microsoft.” Eu estava um pouco chocado que seu ano de experiência como
criador de software, e não como usuário, não tenha dado a ele uma gota de valorização
sobre como é difícil ter um software sem defeitos e fácil de usar. Então eu desisti,
descartando a oferta de emprego. (Pipeline foi comprada, pela PSI, a mais bizarra
provedora de Internet do planeta, e então encerrada sem cerimônias.)

Softwares tem defeitos. CPU’s são escandalosamente mimados. Eles se recusam

absolutamente a lidar com coisas que eles não foram ensinados a lidar de forma explícita,
e eles tendem a recusar na forma mais infantil possível. Quando meu laptop não está em
casa, ele tende a travar bastante porque ele não pode encontrar a impressora de rede que
ele costuma encontrar. Que criança! Provavelmente existe uma única linha de código em
algum lugar com um minúsculo e insignificante defeito nele.
E é por isso que você certamente, absolutamente, precisa de um departamento de QA
(Quality Assurance, Garantia de Qualidade). Você vai precisar de um testador para cada 2
programadores (mais se seu software precisa funcionar sob várias configurações
complicadas ou sistemas operacionais). Cada programador deveria trabalhar próximo a
um testador, lançando a ele builds particulares tão freqüentes quanto necessário.

O departamento de QA deveria ser independente e poderoso, ele não deve se reportar

para a equipe de desenvolvimento, na verdade, o chefe do QA deveria ter poder de veto
sobre entrega de qualquer software que não atenda a inspeção.

Meu primeiro emprego de verdade foi na Microsoft; uma empresa que não é exatamente
famosa pelo seu código de alta qualidade, mas na qual apesar de tudo contrata um grande
número de testadores de software. Então eu mais ou menos espero que qualquer operação
de software tenha testadores.

Muitos têm. Mas um número surpreendente não tem testadores. Na verdade, um monte de
times de software sequer acredita em testar.

Você pode pensar que depois de toda aquela mania de qualidade dos anos 80, com todos
os tipos de certificações internacionais de “qualidade” sem sentido como ISO-9000 e
palavras-chaves como “seis sigma”, gerentes hoje deveriam entender que ter produtos de
alta qualidade fazem um bom senso de negócio. Na verdade, eles fazem. A maioria tem
obtido sucesso com isso na cabeça. Mas eles continuam a vir com muitas razões de não
ter testadores de software, todas elas erradas.

Eu espero poder explicar a você porque essas idéias estão erradas. Se você está com
pressa, pule o resto deste artigo, e saia e contrate um testador de tempo integral para cada
dois programadores de tempo integral do seu time.

Aqui estão as principais desculpas esfarrapadas que eu já ouvi por não contratar
testadores:

1. Defeitos vem de programadores preguiçosos

“Se nós contratarmos testadores”, esta fantasia continua, “os programadores vão se tornar
desleixados e escrever códigos defeituosos. Evitando testadores, nós podemos forçar os
programadores a escrever códigos corretor em primeiro lugar.”

Sheesh. Se você pensa assim, você ou nunca escreveu código, ou você está sendo
desonesto sobre como escrever código. Defeitos, por definição, escapam porque
programadores não vêem defeito no seu próprio código. Muitas vezes basta um segundo
par de olhos para encontrar um defeito.

Quando eu estava escrevendo código na Juno, eu sempre exercitava meu código da

mesma maneira toda as vezes... eu usava meus hábitos, dependendo bastante do mouse.
Nosso maravilho e, altamente super qualificado testador tinha hábitos ligeiramente
diferentes: ele fazia mais coisas com o teclado (e realmente testava rigorosamente a
interface usando todas as combinações possíveis de entradas). Isto revelava rapidamente
um monte de defeito. De fato às vezes ele realmente me contava que a interface
categoricamente não funcionava, 100% não funcionava, mesmo pensando que sempre
funcionava comigo. Quando eu assistia ele reproduzir o defeito eu tinha um daqueles
momentos de tapa na testa. Alt! Você está segurando a tecla Alt! Por que eu não testei
isso antes?

2. Meu software está na web. Eu posso corrigir defeitos em um segundo.

Hahahaha! Ok, é verdade, distribuições via web permitem a você entregar correções de
defeito muito mais rápido que nos antigos dias de empacotamento de software. Mas não
subestime o custo de correção de defeitos, mesmo em um web site, depois que seu projeto
já foi congelado. Por exemplo, você pode incluir mais defeitos enquanto você corrige o
primeiro. Mas um problema pior é quando você dá uma olhada no processo que você tem
no lugar de entregar novas versões, você se toca que pode ser um problema caro entregar
correções via web. Junto com a má impressão que você vai causar, o que leva a:

3. Meus clientes vão testar o software por mim

Ah, a temível “Defesa Netscape”. Esta pobre compania fez uma quantia quase
sobrenatural de danos para sua reputação através da sua metodologia de teste:

1.Quando os programadores estão quase na metade, entregam o software na internet sem

qualquer teste. 2.Quando os programadores dizem que terminaram, entregam o software
na internet sem qualquer teste. 3.Repita de 6 a 7 vezes. 4.Chame uma dessas versões de
“versão final” 5.Entregue .01, .02, .03 versões cada vez que um defeito cabuloso é
mencionado na C|net.

Esta empresa foi pioneira na idéia dos “wide betas”. Literalmente milhões de pessoas
poderiam baixar essas versões defeituosas e não terminadas. Nos primeiros anos, quase
todo mundo que utilizava Netscape estava usando um tipo de pre-release ou versão beta.
Como resultado, a maioria das pessoas pensa que o software da Netscape é realmente
defeituoso. Mesmo se a versão final seja normalmente e razoavelmente sem defeitos,
Netscape tem maltratado tantas pessoas utilizando versões defeituosas que a impressão
média que a maioria das pessoas tem sobre o software é bastante baixa.

Além do mais, o principal ponto de deixar “seus clientes” fazer o teste é que eles vão
encontrar os defeitos, e você os corrigirá. Infelizmente, nem a Netscape, nem qualquer
empresa do planeta, tem o potencial humano para inspecionar relatórios de defeitos de
2.000.000 clientes e decidir o que é realmente importante. Quando eu encontrava defeitos
no Netscape 2.0, o website para informar defeitos repeditamente travava e simplesmente
não me deixava informar um defeito (o defeito, é claro, poderia ter ido para um buraco
negro de qualquer forma). Mas Netscape não aprende. Testadores da atual versão
“preview”, 6.0, tem reclamada em newsgroups que o website para informar defeitos
continua não permitindo submissões. Anos depois! Mesmo problema!

Desses zilhões de defeitos informados, eu poderia apostar que quase todos eles são sobre
o mesmo conjunto de 5 ou 10 defeitos extremamente óbvios, de qualquer forma.
Enterrado nesse palheiro deve ter um ou dois defeitos interessantes, difíceis de se
encontrar que alguém teve a dificuldade de informar, mas ninguém está olhando para
nenhum desses informativos de defeito de qualquer maneira, então ele está perdido.
A pior coisa sobre essa forma de testar é a considerável má impressão que você vai fazer
da sua empresa. Quando Userland liberou a primeira versão do Windows com a sua
bandeira de produtos Frontier, eu baixei e comecei a trabalhar seguindo o tutorial.
Infelizmente, Frontier travou diversas vezes. Eu estava literalmente seguindo as
instruções exatamente como elas estavam impressas no tutorial, e eu simplesmente não
consegui usar 2 minutos do programa. Eu me senti como se ninguém na Userlando tinha
ao menos feito um mínimo de teste, para ter certeza que o tutorial funciona. A baixa
qualidade do produto me fez desistir da Frontier por um bom tempo.

4. Qualquer um qualificado para ser um bom testador não quer trabalhar como um
testador.

Esta é dolorosa. É muito difícil contratar bons testadores. Com testadores, assim como
programadores, os melhores são uma ordem de magnitude melhor que os médios. Na
Juno, nós temos um testador, Jill McFarlane, que encontrou três vezes mais defeitos que
todos os outros quatro testadores, combinados. Eu não estou exagerando, eu realmente
medi isso. Ela era mais do que vinte vezes mais produtiva do que o testador médio.
Quando ela se demitiu, eu enviei um email ao CEO dizendo “Eu preferia ter Jill nas
Segundas e Terças do que o resto do time de QA junto”.

Infelizmente, a maioria das pessoas que são espertas tendem a se cansar com o teste dia-
a-dia, então os melhores testadores tendem a ficar aproximadamente 3 ou 4 meses e então
seguem viajem.

A única coisa a fazer a respeito desse problema é reconhecer que ele existe, e lidar com
isso. Aqui estão algumas sugestões:

. Use teste como uma etapa da carreira para o suporte técnico. Por mais entediante que
teste pode ser, com certeza com certeza é melhor do que lidar com usuários irritados no
telefone, e isso pode ser um caminho para eliminar alguns problemas do lado do suporte
técnico.

. Permita que testadores desenvolvam sua carreira tendo aulas de programação, e encoraja
os melhores para desenvolver testes automatizados usando ferramentas de programação e
linguagens de script. Isso é muito melhor do que ficar testando a mesma janela de
mensagem várias vezes.

. Reconheça que você terá bastante rotatividade entre os seus melhores testadores.
Contrate agressivamente para manter um fluxo constante de pessoas. Não pare de
contratar apenas porque você temporariamente tem uma lista completa, porque os “anos
dourados” não vão durar.

. Procure trabalhadores “não convencionais”: adolescentes espertos, estagiários, e

aposentados, trabalhando em período parcial. Você pode criar de forma impressionante
um departamento de testes com dois ou três experientes em tempo integral e um exército
de jovens da Bronx Science (uma excelente escola secundária de Nova York) trabalhando
durante o verão em troca de dinheiro para faculdade.
. Contrate temporários. Se você contratar em torno de 10 temporários para vir e trabalhar
no seu software por alguns dias, você vai encontrar um grande número de defeitos. Dois
ou três desses temporários provavelmente devem ser bons testadores, e nesse caso vale a
pena contratá-los por tempo integral. Reconheça antecipadamente que alguns temporários
são inúteis como testadores; mande-os para casa e siga em frente. É para isso que existem
agências de trabalhadores temporários.

Aqui está um jeito de como não fazer isso:

. Não pense em dizer aos universitários de computação que vão trabalhar para você mas
“todo mundo tem que ficar um tempo em QA antes de ir para programação”. Eu tenho
visto muito disso . Programadores não são bons testadores, e você vai perder um bom
programador, o que é muito mais difícil de repor.

E finalmente. A mais estúpida razão do por que as pessoas não contratam testadores:

5. Eu não posso pagar testadores!

Esta é a mais estúpida e a mais fácil de derrubar.

Não importa o quão difícil é encontrar testadores, eles continuarão sendo mais baratos
que programadores. Muito mais baratos. E se você não contratar testadores, você estará
fazendo os programadores testarem. E se você pensa que é ruim tendo testadores
descontentes, apenas espere até você ver o quão caro será substituir aquele ótimo
programador, a $100.000 por ano, que ficou cansado de ouvir para “ficar algumas
semanas no teste antes de nós entregarmos” e se transferiu para uma empresa mais
profissional. Você pode contratar três testadores por ano apenas para cobrir os custos de
contratação de um programador de reposição.

Mesquinhar em testadores é uma escandalosa falsa economia que eu exorcizo e a maioria

das pessoas não reconhece.

_____________________________________________________________________________ 

A Olympya Software - www.olympya.com.br - é também a representante exclusiva

no Brasil e Portugal da FogCreek, http://www.fogcreek.com.br empresa fundada pelo
Joel Spolsky 

Você pode usar gratuitamente por 45 dias o produto FogBugz, totalmente web, para
gerencia de projetos e outras funcionalidades, visitando o link http://try.fogbugz.com

Para treinamento em como fazer melhores softwares você pode aprender mais
sobre, um outro produto da FogCreek, já lançado em Português:

 http://www.scribd.com/doc/29112680/Make‐Better‐Software‐V1