Classificar um problema

BeeWare recebe regularmente relatórios de problemas de usuários que estão enfrentando problemas. Quando um novo problema é relatado, esse relatório precisa ser triado, ou seja, precisamos que alguém leia o relatório, pegue as informações fornecidas pelo relator e tente reproduzir o problema que está sendo descrito.

Infelizmente, embora os relatórios de problemas sejam geralmente bem-intencionados, eles costumam ser incompletos ou confusos. O objetivo do processo de triagem é preencher as lacunas do relatório original. Isso significa gerar detalhes suficientes para que possamos confirmar como o problema pode ser reproduzido ou confirmar que o relator original estava enganado em seu relatório.

Fazer a triagem de um problema não significa que se espera que você o corrija. Dependendo do problema, a triagem pode nem mesmo envolver a escrita de código. Você pode fazer a triagem de um problema com muito pouco conhecimento de BeeWare, pois deve ser capaz de seguir as etapas incluídas no relatório e reproduzir o problema que foi descrito.

Contribuição para a triagem de problemas

Reproduza o problema

Você não pode consertar um problema se não tiver o problema em primeiro lugar. Portanto, reproduzir o problema é um pré-requisito para corrigi-lo. Em software, os problemas são comumente chamados de "bugs", e os problemas são geralmente chamados de "relatórios de bugs".

Alguém forneceu um relatório de bug. Você precisa validar se as etapas descritas pelo relator estão resultando no bug relatado. Você pode reproduzir o mesmo resultado fazendo exatamente o que foi descrito no relatório? Se não conseguir, você precisa descobrir o motivo.

Bugs no código

Em uma situação ideal, você terá a mesma configuração que a pessoa que relatou o bug, seguirá as etapas e conseguirá reproduzir o bug conforme descrito. Em muitos casos, porém, isso 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 operacional, versão do sistema operacional, arquitetura da CPU ou se a máquina do usuário é 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, sua próxima etapa talvez precise 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 fornecerão um exemplo mínimo viável; se fornecerem algum exemplo, ele será copiado diretamente de seu aplicativo do "mundo real". 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 o exemplo mínimo, executá-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 é registrado para um problema de documentação, você deve verificar se o problema relatado ainda existe. No caso de problemas de renderização, você precisará 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

A etapa final do processo de triagem é documentar suas descobertas deixando um comentário sobre o problema.

Se você conseguir reproduzir o problema exatamente como descrito, isso é tudo o que você precisa dizer. Deixe um comentário dizendo que você confirmou que está vendo o mesmo problema, exatamente da maneira descrita pelo relator original.

Se você puder fornecer algum contexto adicional, inclua os detalhes desse contexto. Isso pode incluir a possibilidade de reproduzir o problema em um sistema operacional 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 operacional ou da versão que o relatório original não forneceu, logs ou rastreamentos de pilha mais completos ou instruções mais claras sobre a sequência exata de operações necessárias para reproduzir o problema. Se você desenvolveu uma maneira mais simples de reproduzir o problema (ou se o relator original não forneceu um caso de reprodução), você pode incluir detalhes dessa metodologia de reprodução.

Se você não conseguir reproduzir o problema, deixe também um comentário detalhando o que você 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 você tiver alguma teoria sobre por que não consegue reproduzir o problema — por exemplo, se você acha que é um erro de uso ou que o problema foi resolvido por uma atualização recente do sistema operacional — inclua essa especulação como parte do seu comentário.

Por fim, você pode fazer recomendações para a equipe principal. Se você acha que o relatório original está errado, sugira que o problema seja encerrado; se você tiver uma teoria sobre a causa do problema, também pode sugerir isso. Seus comentários ajudarão a equipe principal a descobrir como passar o problema para a próxima etapa.