As Doze Melhores Dicas Para Se Realizar

Um Beta Test
Por Joel Spolsky da Fog Creek Software
Artigo original: Top Twelve Tips for Running a Beta Test

Artigo
Aqui estão algumas dicas para se realizar beta test de um software produzido para
grandes audiências - o que eu chamo de "shirinkwrap". Essas dicas se aplicam para
projetos comerciais ou opensouce; eu não ligo se você for pago em dinheiro, doces ou
reconhecimento, mas eu estou me focando em produtos para muitos usuários, não
projetos internos de TI.

1. Betas abertos ao público não funcionam. Você consegue testadores de mais (pense
sobre o Netscape) nos quais você não consegue uma boa quantidade de testadores, ou
poucas respostas por parte deles.

2. O melhor jeito de um beta tester mandar um relatório é apelar para o aspecto

psicológico necessário para ser consistente. Você precisa fazer com que eles digam que
vão enviar um relatório, ou, melhor ainda, ser cadastrado para participar dos betas.
Uma vez que eles se comprometam com alguma ação positiva como preencher um
relatório marcando as caixas que dizem "Eu concordo em mandar um relatório e bug
reports imediatamente", muito mais pessoas irão fazê-lo para ser consistente.

3. Não pense que você conseguiria fazer um beta completo em menos de oito a dez
semanas. Eu tentei e deus me ajude, simplesmente não pode ser feito.

4. Não espere lançar novas compilações para os beta testers mais do que uma vez a cada
duas semanas. Eu tentei e deus me ajude, simplesmente não pode ser feito.

5. Não planeje um beta com menos de quatro distribuições. Eu não tentei pois
obviamente não funcionaria!

6. Se você adicionar uma ferramenta nova, mesmo uma pequena, durante o processo de
beta, o relógio volta para o começo das oito semanas e você precisará outras 3-4
distribuições. Um dos maiores erros que eu já cometi foi ter adicionado um código
whitespace-preserving no CityDesk 2.0 no final do ciclo beta e esse código tinha,
podemos dizer, alguns efeitos colaterais que um beta test mais longo iria eliminar.

7. Mesmo que você tenha um método de reportar bugs pelo programa, apenas uma em
cada cinco pessoas vai mandar um relatório de qualquer maneira.

8. Nós temos uma política de dar uma cópia do software gratuitamente para qualquer
um que mande qualquer resposta, positiva, negativa, qualquer uma. Mas pessoas que
não mandam nada para nós não ganham uma cópia ao fim do beta.
 9. O mínimo número de testadores sérios que você precisa (pessoas que mandam para
você três páginas de sua experiência com o software) é provavelmente por volta de 100.
Se você é um desenvolvedor sozinho, isso é o que você consegue agüentar. Se você tem
um time de testadores, ou beta managers, tente ter 100 testadores sérios para cada
empregado que estiver disponível para relatórios.

10. Mesmo se você tenha um método de reportar bugs pelo programa, somente um de
cinco testadores vai realmente testar o produto e mandar alguma resposta. Então, por
exemplo, se você tem um departamento com 3 testadores, você deve aprovar 1500
cadastros de betas para conseguir 300 testadores sérios. Menos do que isso e você não
ouvirá respostas. Mais do que isso e você ficará atolado de relatórios repetidos.

11. A maioria dos beta testers vai testar o programa assim que ele conseguir e depois
perder o interesse. Eles não vão ficar interessados em re-testar ele a cada vez que você
fizer outra compilação a não ser que eles usem o programa diariamente, o que é
improvável. Portanto divida seus betas em quatro grupos e a cada nova distribuição,
adicione outro grupo para conseguir o software, então haverão novos betas a cada
lançamento.

12. Não confunda um beta técnico com um beta de marketing. Eu tenho falado sobre
betas técnicos, aqui eles têm por objetivo achar bugs e conseguir relatórios de último
minuto. Marketing betas são pré-versões do produto final que são dadas para a mídia,
para grandes consumidores, e para o cara que irá escrever o livro dos Cones de Estrada
que precisa aparecer no mesmo dia que o produto final. Com os betas de marketing você
não precisa esperar respostas (apesar de pessoas que escrevem livros geralmente tentam
dar para você relatórios não importando o que você faça, e se você os ignorar, eles vão
ser copiados e colocados para dentro do livro).

Nota: A FogCreek,  tem hoje como seu representante, para língua portuguesa, Brasil e 
Portugal, a www.olympya.com.br . 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 

A Olympya também é representante de um novo produto da FogCreek, para treinamento em 
engenharia de software. Este novo produto foi lançado desde o inicio em Português veja
mais detalhes em:

http://training.fogcreek.com.br – venda sem instrutor. 
 
Para ver a nossa oferta  que inclui assistência com nossos instrutores na Avenida Paulista, em 
Copacabana ou na sua empresa, veja:  
 
     http://www.scribd.com/doc/29112680/Make‐Better‐Software‐V1