Bom dia pessoal vou descrever aqui um pequeno manual para tentar melhorar nossa forma de reportar bugs. O propósito de um *bug report* é informar que um erro ocorre dar o maior número de informações possíveis para que este possa ser corrigido.
Pra isso nós sempre precisamos saber:
*1- Passos para reproduzir o problema*: descrever o que você fez para que o bug aconteça. Exemplo: No formulário de criação de contas (http://example.com/register/) preencher os campos e clicar no botão enviar.
*2- Qual o resultado esperado*: descrever o deveria ter acontecido. Exemplo: Ser redirecionado para página de sucesso e receber e-mail de validação de conta.
*3- Qual o resultado obtido: *descrever o que aconteceu e porque isso parece errado. Exemplo: A mensagem de erro "Something Went wrong" foi exibida na página http://example.com/success. O e-mail de confirmação foi recebido.
Notem que no passo 3 se a última parte sobre o recebimento do e-mail não fosse descrito essa provavelmente seria a próxima pergunta do programador que vai revisar o bug (saber se o e-mail chegou ou não neste caso é um bom indicador de onde o código falhou).
O report pode ser escrito tanto de maneira contínua – sem explicitar os 3 passos – ou demarcando cada um deles como no exemplo acima. O formato não é tão importante, o que importa é fornecer as informações necessárias para que possamos atacar os bugs da maneira mais pragmática e eficiente possível.
Marisa e Nayanne, fica a dica pra usarem também =).
att Arthur
Em 19 de maio de 2015 11:15, Sergio Oliveira escreveu:
> Bom dia pessoal vou descrever aqui um pequeno manual para tentar melhorar > nossa forma de reportar bugs. O propósito de um *bug report* é informar > que um erro ocorre dar o maior número de informações possíveis para que > este possa ser corrigido. > > > Pra isso nós sempre precisamos saber: > > *1- Passos para reproduzir o problema*: descrever o que você fez para que > o bug aconteça. > Exemplo: No formulário de criação de contas (http://example.com/register/) > preencher os campos e clicar no botão enviar. > > *2- Qual o resultado esperado*: descrever o deveria ter acontecido. > Exemplo: Ser redirecionado para página de sucesso e receber e-mail de > validação de conta. > > *3- Qual o resultado obtido: *descrever o que aconteceu e porque isso > parece errado. > Exemplo: A mensagem de erro "Something Went wrong" foi exibida na página >http://example.com/success. O e-mail de confirmação foi recebido. > > Notem que no passo 3 se a última parte sobre o recebimento do e-mail não > fosse descrito essa provavelmente seria a próxima pergunta do programador > que vai revisar o bug (saber se o e-mail chegou ou não neste caso é um bom > indicador de onde o código falhou). > > O report pode ser escrito tanto de maneira contínua – sem explicitar os 3 > passos – ou > demarcando cada um deles como no exemplo acima. O formato não é tão > importante, o que importa é fornecer as informações necessárias para que > possamos atacar os bugs da maneira mais pragmática e eficiente possível. > > > Abraços, > > Sergio Oliveira > > _______________________________________________ > spb-dev mailing list > spb-dev@listas.softwarepublico.gov.br >http://listas.softwarepublico.gov.br/mailman/cgi-bin/listinfo/spb-dev > >
Sergio Oliveira
Arthur Esposte