Gerador de bugs para Jira

Escreva um resumo que cite a área e o sintoma, como “Checkout: botão Finalizar pedido continua desabilitado após cupom”. Na descrição, informe o ambiente, os passos numerados para reproduzir, o resultado esperado, o resultado obtido e evidências como screenshots, logs ou um arquivo HAR. Defina severidade, prioridade, componente e versão afetada e vincule a história relacionada. Mantenha um bug por ticket. Este gerador oferece essa estrutura e a formata como Markdown ou wiki markup do Jira.

Um relatório de bug completo tem um título específico; o ambiente (build ou versão, navegador, SO, dispositivo, conta de teste); pré-condições; passos numerados para reproduzir; o resultado esperado; o resultado obtido; severidade e prioridade; e anexos como screenshots, vídeo, logs do console ou respostas de API. Informe também com que frequência reproduz e se há algum contorno. O objetivo é que um desenvolvedor consiga reproduzir o bug sem precisar perguntar nada a você. Veja como escrever um relatório de bug que é corrigido.

A severidade mede o impacto do bug no sistema; a prioridade mede a urgência com que o negócio quer a correção. Normalmente andam juntas, mas nem sempre. Um crash em um relatório administrativo pouco usado tem severidade alta, mas prioridade baixa, enquanto o nome da empresa escrito errado na home tem severidade baixa, mas prioridade alta. Em geral, testers propõem a severidade e os product owners definem a prioridade. Use o guia de severidade e prioridade de bugs para classificar de forma consistente.

Comece de um estado conhecido, como deslogado, uma conta nova ou uma URL específica, e escreva cada ação como um passo numerado com dados exatos: “3. Digite SAVE10 em Cupom e clique em Aplicar.” Inclua só os passos necessários para disparar o bug e siga-os mais uma vez antes de registrar. Se o bug for intermitente, informe a taxa de reprodução, por exemplo 3 em 5 tentativas. Coloque os resultados esperado e obtido depois dos passos, não dentro deles.

Na prática significam a mesma coisa, e o glossário do ISTQB trata “bug” como sinônimo de “defeito”: uma falha em um produto de trabalho, como código ou um requisito, que faz com que ele não atenda aos seus requisitos. Alguns times usam “bug” para problemas encontrados nos testes e “defeito” para problemas encontrados após o release, mas isso é uma convenção local. Termos relacionados: um erro (engano) é a ação humana que causa o defeito, e uma falha é o que os usuários veem quando o defeito é acionado.

Em parte. Este gerador transforma suas anotações em um ticket com estrutura consistente, formatado para Jira Cloud (Markdown) ou Jira Server e Data Center (wiki markup), que você mesmo cola no Jira. Ele não cria a issue, porque o SDETRole não tem acesso à sua instância do Jira. A criação totalmente automática exige a API REST do Jira ou uma integração, por exemplo um job de CI que abre um ticket quando um teste noturno falha. Revise os tickets criados automaticamente para evitar duplicatas.

Seja factual, específico e neutro. Use um título preciso, passos reproduzíveis com dados reais, comportamento esperado versus obtido e evidências. Evite culpar alguém (“o dev quebrou o login”) e opiniões; descreva o comportamento observado e o impacto para os usuários. Mantenha a formatação consistente para agilizar a triagem e anexe os logs em vez de colar milhares de linhas. O gerador de relatório de bug e este gerador de tickets do Jira aplicam um modelo profissional com checklist de completude.

Use Markdown. O editor atual do Jira Cloud converte títulos, listas e blocos de código em Markdown colados. Wiki markup é para Jira Server/Data Center e para campos ou apps do Cloud que ainda usam o renderizador legado.

No wiki markup do Jira, { inicia uma macro e [ inicia um link, então um trecho JSON como {"error": [1]} em texto normal pode quebrar a renderização. O gerador os escapa com barra invertida. O texto dentro de blocos {noformat} ou {code} fica exatamente como você colou.