# Boas práticas

URL: /reportar/boas-praticas

Como escrever um report que o time consegue entender, reproduzir e corrigir sem perguntar nada.

Um bom report diz o que aconteceu, o que era esperado e como chegar lá.

## Escolha o tipo certo [#escolha-o-tipo-certo]

| Tipo | Exemplo |
| --- | --- |
| **Bug** | O cupom some ao voltar do pagamento |
| **Melhoria** | O filtro funciona, mas leva 8 segundos para carregar |
| **Sugestão** | Permitir salvar o carrinho para depois |

Passe o cursor sobre um tipo no formulário para ver quando usá-lo.

## Escreva um título que se encontra depois [#escreva-um-título-que-se-encontra-depois]

O título aparece na lista, nas buscas e nas issues. Descreva o sintoma, não a suspeita de causa.

| Evite | Prefira |
| --- | --- |
| "Erro no carrinho" | "Cupom some ao voltar do pagamento" |
| "Não funciona" | "Botão Pagar não responde após trocar de cartão" |
| "Bug na tela de login" | "Login com email em maiúsculas retorna 'usuário não encontrado'" |

Enquanto você digita, o painel mostra **É algum destes?** com reports abertos parecidos. Abra os itens antes de enviar. Se o problema já foi registrado, comente nele em vez de criar outro.

## Descreva o comportamento atual e o esperado [#descreva-o-comportamento-atual-e-o-esperado]

Na **Descrição**, conte o que aconteceu e o que você esperava, com a tela, os dados usados e a mensagem de erro. Se o projeto tem [templates](/administrar/templates), os títulos do template ajudam a não esquecer nada.

| Fraco | Forte |
| --- | --- |
| "O cupom não funciona." | "Depois de pagar e voltar ao carrinho, o cupom OUTONO10 não aparece mais." |

## Liste passos que alguém repete [#liste-passos-que-alguém-repete]

A descrição aceita Markdown. Numere os passos, do estado inicial até o problema. Inclua o usuário ou o perfil, os dados usados e o que você clicou.

```text
1. Entre como cliente com carrinho de R$ 120.
2. Aplique o cupom OUTONO10.
3. Clique em Pagar e volte pelo botão do navegador.
4. O carrinho abre sem o cupom.
```

Use a aba **Visualizar** para conferir como o texto fica antes de enviar. Se o projeto tem [templates](/administrar/templates), a descrição já sugere os títulos que a equipe espera.

## Sugira a prioridade só quando souber [#sugira-a-prioridade-só-quando-souber]

**Prioridade** é opcional. Deixe **Sem prioridade** quando não tiver certeza: a triagem decide a ordem de atendimento.

| Prioridade | Quando sugerir |
| --- | --- |
| **Urgente** | Impede continuar e não tem contorno |
| **Alta** | Afeta bastante o uso |
| **Média** | Tem contorno |
| **Baixa** | Detalhe visual ou de texto |

## Capture a evidência certa [#capture-a-evidência-certa]

- Prefira recortar uma área a capturar a tela toda, para a imagem mostrar só o problema.
- Cubra dados pessoais com a **tarja** do editor.
- Mantenha console, erros e rede marcados.
- Para um componente específico, use **Elemento**.
- Se o problema só acontece depois de uma sequência de ações, use o [replay](/reportar/evidencias#replay) quando o projeto tiver.

## Um problema por report [#um-problema-por-report]

Se você achou três problemas na mesma tela, abra três reports. Cada um tem seu status, responsável e histórico, e pode ser corrigido em outro momento.

## Antes de enviar [#antes-de-enviar]

- [ ] O título descreve o sintoma
- [ ] A descrição traz passos que permitem repetir o problema
- [ ] Há uma imagem mostrando o problema
- [ ] Dados pessoais estão cobertos
- [ ] Conferi **É algum destes?**

## Próximos passos [#próximos-passos]

- [Evidências](/reportar/evidencias)
- [Triar e acompanhar](/triar)