Dez dicas para acompanhamento de “bugs”e Outros
Artigo original em inglês escrito por Joel Spolsky - http://www.fogcreek.c...
Dez dicas para acompanhamento de “bugs”e Outros
primeiros três mil bugs, você deixará de se sentir deprimido e começará a ...
Dez dicas para acompanhamento de “bugs”e Outros
O FogBugz é um sistema integrado que inclui:
• Um wiki, onde se pode criar...
Dez dicas para acompanhamento de “bugs”e Outros
tecnologia de código livre Mercurial (http://mercurial.selenic.com/). O Ki...
Upcoming SlideShare
Loading in …5
×

Dez dicas para_acompanhamento_de_bugs

130 views
97 views

Published on

Aprenda mais como evitar bugs e no link da ultima página veja quanto custa isto para sua empresa e algumas ferramentas

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
130
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
2
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Dez dicas para_acompanhamento_de_bugs

  1. 1. Dez dicas para acompanhamento de “bugs”e Outros Artigo original em inglês escrito por Joel Spolsky - http://www.fogcreek.com Os dez pontos que devem ser considerados pelo programador 1. Um bom testador se preocupa em reduzir, ao mínimo, o número de passos para reproduzir bugs; isto é muito útil para o programador que tiver que encontrar o defeito. 2. Lembrete: a única pessoa que pode atribuir status de resolvido a um bug é aquela que o reportou primeiro. Qualquer um pode solucioná-lo mas só quem o descobriu pode ter a certeza de que foi realmente resolvido. 3. Não reprodutível informa que o programador não conseguiu recriar o bug. Este status é normalmente usado pelos programadores quando enviam de volta o bug ao testador com a informação de que o relatório não contém algum passo crítico para reproduzi-lo. Bons testadores encaram isto como um desafio, não uma desculpa para encerrar o caso. 4. Acompanhe cuidadosamente as versões. Cada versão do software que você passa aos testadores deve carregar um identificador de versão que pode ser colocado no campo de Versão do FogBugz. Quando um programador resolve o bug ele deve indicar em que versão a correção se aplica para que o pobre testador não reteste o bug numa versão do software em que a correção não se aplica. 5. Se você é um programador e está enfrentando problemas para conseguir que os testadores usem o FogBugz, não aceite nenhum bug reportado por qualquer outro meio. Assim se os testadores lhe enviam e-mails com os relatórios de bugs, mande de volta os e-mails com a mensagem: “Por favor coloque isto no banco de dados de bugs. Eu não consigo dar conta dos meus e-mails”. 6. Se você é um testador e está enfrentando problemas para conseguir que os programadores usem o FogBugz, não os informe sobre qualquer bug - coloque-os no FogBugz e deixe que o FogBugz os informe. 7. Se você é um programador e somente alguns dos seus colegas usam o FogBugz, comece a lhes designar bugs. Cedo ou tarde eles entenderão. 8. Se você é um gerente, designe bugs à sua equipe no FogBugz. Cedo ou tarde eles entenderão que em vez de chegar em seu escritório de vez em quando dizendo “que devo fazer agora?” eles simplesmente vão ver o que lhes foi designado no FogBugz. 9. Crie o hábito de escrever todos seus relatórios de bug com três seções: passos para a reprodução, o bug em si, e o que era esperado. 10. Fuja da tentação de adicionar novos campos ao FogBugz. De tempos em tempos, alguém virá com a maravilhosa idéia de um novo campo, por exemplo, um para acompanhar o arquivo onde o bug foi encontrado, ou quão freqüentemente o bug é reprodutível, ou quais as exatas versões de cada DLL estavam instaladas quando o bug aconteceu. Não adicione campos. Se o fizer, sua nova tela de entrada de bugs terá uma centena de campos que deverão ser preenchidos. De repente, usar o FogBugz será algo tão cerimonioso que ninguém irá querer fazê-lo pelo trabalho que será preencher todos os campos. Para o FogBugz funcionar, todos precisam usá-lo. E se a formalidade de registrar um bug der muito trabalho, as pessoas vão começar a trocar e-mails, e os casos vão se perder. 11. (Bônus grátis) Não tenha raiva dos bugs! Se um bug lhe for designado, não significa uma crítica pessoal, é apenas uma forma de melhorar o software. Depois que você passar pelos
  2. 2. Dez dicas para acompanhamento de “bugs”e Outros primeiros três mil bugs, você deixará de se sentir deprimido e começará a apreciar o gosto dos quebra-cabeças que lhe trarão os bugs. Algumas pessoas pagam por livros de quebra- cabeças e os resolvem na praia ou na rede. Você vai solucioná-los no trabalho e será pago para isto. O que pode ser mais divertido? Veja também, aqui no scribd 1 - Make Better Software : Visite http://goo.gl/Bc8zU Make Better Software é um programa de seis semanas para o treinamento abrangente de equipes de software de qualquer tamanho. Você vai aprender alguns conceitos chave de desenvolvimento de software, os mesmos que Joel prega em seu site, Joel on Software, e vê-lo em ação na Fog Creek Software, a empresa que ele criou em New York. O curso é dividido em seis módulos e, cada módulo inclui: • material impresso que deve ser lido com antecedência • um DVD de uma hora para toda assistir junta (com legendas em Português) • material de leitura adicional para as áreas em que se deseje um maior aprofundamento • sugestões de tópicos para discussão com a equipe É uma excelente forma para equipes de desenvolvimento dominarem as técnicas que fizeram a Fog Creek obter sucesso. A Olympya também é representante deste produto da FogCreek. Este novo produto foi lançado desde o inicio em Português 2 - Gerencia de Projetos e outras Funcionallidades - FogBugz 8.0 Visite e use gratuitamente por 45 dias http://goo.gl/7tklj O FogBugz é um sistema completo de gerência de projeto e da vida do produto concebido para auxiliar a comunicação nas equipes de software. Este sistema ajuda as equipes a trabalharem juntas controlando, priorizando e coordenando milhares de pequenas tarefas que realizam no dia-a-dia e propicia a produção de softwares melhores. É um produto web e, por isso, toda equipe tem sempre a perspectiva global do projeto. Solicitações de novas funcionalidades, email para clientes e bugs são facilmente registradas e acompanhadas. O FogBugz é uma criação de Joel Spolsky, do famoso blog Joel on Software. Pode ser instalado num servidor Web dedicado ou pode ser usado sob assinatura diretamente dos servidores da Fogcreek.
  3. 3. Dez dicas para acompanhamento de “bugs”e Outros O FogBugz é um sistema integrado que inclui: • Um wiki, onde se pode criar e compartilhar documentos e especificações técnicas; • Um sistema de gerenciamento de projetos, em que se pode acompanhar o progresso do trabalho, inclusive os bugs e o desenvolvimento de novas funcionalidades; • O premiado sistema de acompanhamento de bugs, incluindo geração automática de inúmeros relatórios para acompanhamento de projeto. • Planejamento baseado em evidências, um sistema sofisticado para gerar um cronograma e estimar a probabilidade de cumprí-lo no parágrafo XIII incluímos um gráfico de probabilidades da etapa 1 extraído do sistema; • Grupos de discussão e email, para se comunicar com clientes. • Completa integração com o Kiln, cujas funcionalidades serão descritas a seguir. Estes recursos funcionam de modo a manter toda equipe atualizada e permitir que os projetos sejam, literalmente, autogerenciados. A recém-lançada versão 8.0 do FogBugz representa uma revisão completa do produto para melhorar ainda mais Seu desempenho e facilidade de uso. Sugestões de clientes resultaram em centenas de aprimoramentos nesta Última versão. O sistema Kiln (http://fogcreek.com/kiln/) fornece uma solução integrada para controle de versão baseado na
  4. 4. Dez dicas para acompanhamento de “bugs”e Outros tecnologia de código livre Mercurial (http://mercurial.selenic.com/). O Kiln adota o novo paradigma de controle deversão distribuído, permitindo uma colaboração mais flexível e robusta entre os diversos analistas/ programadores envolvidos no projeto. A alta integração do Kiln com o FogBugz permite também um processo estruturado (porém simples) de revisão de código — prática essencial para o controle contínuo de qualidade ao longo de todo o processo de desenvolvimento. Joel Spolsky é autor de vários livros sobre desenvolvimento de software, gerência, negócios e Internet. Tem uma reputação internacional de guru na área de usabilidade. Sua empresa Fog Creek Software publica, alémdo FogBugz, o Fog Creek Copilot e o Kiln. No Brasil e em Portugal, a Olympya Software é a parceira exclusiva da Fog Creek Software (http://www.fogcreek.com.br) e provê suporte aos seus produtos para os clientes brasileiros e portugueses. Você pode usar gratuitamente por 45 dias o produto FogBugz, totalmente web, para gerencia de projetos e outras funcionalidades, clicando aqui Aprenda mais sobre a Olympya Software, empresa que representa a Fogcreek no Brasil, clicando aqui A nossa empresa também desenvolve games e, se você se interessa por esta área visite o site do FutWeb: MMO game de futebol que estamos desenvolvendo – www.futweb.com.br Veja aqui também no slideshare informações sobre produtividade segurança e bugs clicando aqui Sobre o Tradutor: Paulo André de Andrade é Engenheiro Eletrônico e Diretor da OLYMPYA TI, responsável, no Brasil, pela comercialização dos softwares da Fog Creek - www.fogcreek.com.br Paulo André atua em Informática desde 1971 em setores que vão de Engenharia de Qualificação de Componentes para Hardware, Engenharia de Produtos de Hardware, Desenvolvimento de Hardware e Software, Desenvolvimento de Negócios, Marketing e Vendas de Software e Consultoria em Gerência de Projetos e em Serviços de Informática.

×