Como escrever um relatório de bug Android

Comece com um ambiente reproduzível

Registre a versão e compilação do aplicativo, versão Android, modelo do dispositivo ou emulador e configurações relevantes. Observe o estado da conta e os dados de teste sem incluir senhas ou informações pessoais. Um relatório sobre uma construção antiga deveria dizer isso.

• Identifique a versão exata que você testou.
• Grave a tela, o estado da conta e as condições de rede necessárias para iniciar.
• Descreva quaisquer configurações que afetem o problema, como texto grande ou um idioma diferente.

Escreva uma ação por etapa

Comece de um estado que outro testador possa alcançar. Use uma sequência numerada curta com controles visíveis e informações concretas. Mantenha os problemas não relacionados em relatórios separados.

• Abra o aplicativo e navegue até a tela afetada.
• Insira o valor de teste ou execute a ação que aciona o problema.
• Descreva o resultado visível e com que frequência você o observou.

Separe o resultado esperado do real

O resultado esperado explica o que deveria acontecer e por que isso é razoável. O resultado real registra o que você viu. Evite assumir uma causa raiz, a menos que tenha sido verificada. A gravidade descreve o impacto; a equipe ainda decide a prioridade da correção.

Exemplo resolvido: uma ação de formulário oculta

Cenário ilustrativo, não um resultado medido pelo cliente: após aumentar o tamanho do texto, uma ação do formulário fica abaixo de um painel fixo e não pode ser alcançada. Um relatório útil identifica a construção, o tamanho da janela, a configuração do texto, as etapas de navegação e o comportamento de rolagem esperado. Anexe uma referência de captura de tela editada, se tiver uma.

Torne as evidências úteis e seguras para compartilhar

Uma captura de tela ou gravação curta deve mostrar o estado relevante. Faça referência a um arquivo ou anexo com acesso controlado em seu rastreador de problemas. Remova credenciais e dados pessoais de capturas e registros antes de compartilhar. Este site não carrega evidências.

Feche o ciclo com um novo teste

Após uma correção, execute novamente as etapas originais na nova compilação e o registro foi aprovado, falhou ou não foi possível verificar. Incluir fluxos adjacentes nas verificações de regressão. Não marque um problema como corrigido simplesmente porque uma alteração foi feita.

É o mesmo que um relatório de bug do sistema Android?

Não. Esta é uma descrição estruturada do problema para uma pessoa ou rastreador de problemas. Os relatórios de erros do sistema Android contêm logs de diagnóstico e são coletados separadamente com as ferramentas Android.

O gerador testa meu aplicativo?

Não. Você insere observações de seus próprios testes. O gerador os formata; ele não inspeciona um APK, não coleta registros do dispositivo nem verifica um defeito.

Quanto detalhe é suficiente?

Inclua contexto suficiente para que outra pessoa alcance o mesmo estado, siga as etapas e compare os resultados. Mantenha o relatório focado em um problema.