Reproduzir um problema¶
Não pode consertar um problema se não tiver o problema em primeiro lugar.Assim, reproduzir o problema é um pré-requisito para corrigi-lo. Em software, as situações irregulares são normalmente chamadas de "bugs", e os problemas são geralmente chamados de "relatórios de bugs".
Alguém forneceu um relatório de bug. Você precisa de validar se os passos descritas pelo relator estão a resultar no bug relatado. Pode reproduzir o mesmo resultado fazendo exatamente o que foi descrito no relatório? Se não conseguir, precisa descobrir o motivo.
Para começar a reprodução dum problema, vai precisar de configurar um [ambiente de desenvolvimento] .
Bugs no código¶
Numa situação ideal, terá a mesma configuração que a pessoa que relatou o bug, vai seguir os passos e conseguir reproduzir o bug conforme descrito. Em muitos casos, porém, isto não será tão simples. Muitos relatórios de bugs incluem apenas explicações vagas e um conjunto vago de condições. O problema é que muitos bugs variam de acordo com o conjunto de condições envolvidas, incluindo a forma de interação, várias condições prévias, sistema operativo, versão do sistema operativo, arquitetura da CPU ou se a máquina do utilizador é antiga e lenta ou nova e rápida. Quanto mais informações tivermos sobre a situação que envolve o bug, melhor. Tente reproduzir o conjunto de condições que o relator forneceu. Se não conseguir fazer isso, no seu próximo passo talvez precise de solicitar mais informações à pessoa que relatou o bug.
A melhor maneira de reproduzir um bug é com o menor exemplo possível que ainda exiba o problema. Na maioria das vezes, os relatores não fornecem um exemplo mínimo viável; se fornecerem algum exemplo, ele será copiado diretamente da sua aplicação do "mundo real". O seu objetivo será reduzir o relatório à forma mais simples possível que exiba o problema. O melhor caso de reprodução é o menor programa possível. Essa redução é útil porque determina qual é o problema real. Qualquer pessoa pode pegar no exemplo mínimo, executa-lo e observar o bug descrito.
Bugs na documentação¶
Os bugs na documentação podem se manifestar de diferentes maneiras. Há problemas de formatação que resultam em problemas de renderização. Às vezes, não se trata nem mesmo de um bug; a pessoa pode ter lido mal a documentação ou cometido um erro genuíno. Isso não significa necessariamente que não haja um problema com a documentação. O conteúdo pode ser pouco claro ou impreciso, dando margem a confusão ou má interpretação. É possível que um conceito que deveria ser discutido não o seja, porque não está completamente documentado.
Quando um bug é preenchido para um problema de documentação, vai querer verificar se o problema relatado ainda existe. No caso de problemas de renderização, vai precisar de criar a documentação para ver se consegue reproduzir o problema. Os problemas de conteúdo são uma questão de leitura para verificar se ninguém enviou uma atualização.
Atualizar o problema¶
O passo final do processo de triagem é documentar as suas descobertas deixando um comentário sobre o problema.
Se conseguir reproduzir o problema exatamente como descrito, isso é tudo o que precisa dizer. Deixe um comentário dizendo que confirmou que está a ver o mesmo problema, exatamente da maneira descrita pelo relator original.
Se puder fornecer algum contexto adicional, inclua os detalhes desse contexto. Isto pode incluir a possibilidade de reproduzir o problema num sistema operativo diferente, ou com uma versão diferente de algum dos softwares envolvidos, ou qualquer outra coisa que varie do relatório original.
Se o relatório original não continha detalhes necessários para reproduzi-lo, inclua esses detalhes. Isso pode incluir o fornecimento de detalhes do sistema operativo ou da versão que o relatório original não forneceu, relatórios ou rastreios de pilha mais completos ou instruções mais claras sobre a sequência exata de operações necessárias para reproduzir o problema. Se desenvolveu uma maneira mais simples de reproduzir o problema (ou se o relator original não forneceu um caso de reprodução), pode incluir detalhes desse método de reprodução.
Se não conseguir reproduzir o problema, deixe também um comentário detalhando o que tentou fazer. Saber onde um problema não existe é quase tão importante quanto saber onde ele existe, pois isso ajuda a restringir uma possível causa. Se tiver alguma teoria sobre porque não consegue reproduzir o problema — por exemplo, se acha que é um erro de utilização ou que o problema foi resolvido por uma atualização recente do sistema operativo — inclua essa especulação como parte do seu comentário.
Por fim, pode fazer recomendações para a equipa principal. Se acha que o relatório original está errado, sugira que o problema seja encerrado; se tiver uma teoria sobre a causa do problema, também pode sugerir isso. Os seus comentários vão ajudar a equipa principal a descobrir como passar o problema para o próximo passo.
Neste ponto, pode optar por tentar corrigir o problema que acabou de reproduzir; em alternativa, pode anotar suas descobertas e tentar reproduzir outro problema.