As Cinco Melhores Razões (Erradas) Para Você Não Ter Testadores

From The Joel on Software Translation Project

Revision as of 17:17, 23 May 2009 by Setatakahashi (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Por Joel Spolsky da Fog Creek Software
Segunda-feira, 30 de Abril de 2000
Artigo original: Top Five (Wrong) Reasons You Don't Have Testers
Traduzido por: Yakultsan

Teaser

A traduzir...

Artigo

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, distorcendo a equipe do Word por não responder aos pedidos dos clientes, e entregado 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 deveira trabalhar próximo a um testador, lançando a ele builds particulares tão frequentes 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 tem. Mas um número surpreendente não tem testadores. Na verdade, um monte de times de software sequer acreditam 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 desleixads e escrever códigos defeituosos. Evitando testadore, 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, altamente superqualificado testador tinha hábitos ligeiramnete 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 relamente me contava que a interface categoricamente não funcinava, 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 num 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 defetuosas e não terminadas. Nos primeros anos, quase todo mundo que utilizava Netscape estava usando um tipo de pre-release ou versão beta. Como resultado, a maioria das pessoas pensam 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 defeitor 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 intruções extatamente 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 e 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 convecionais”: 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 exorciso e a maioria das pessoas não reconhece.

Personal tools