Por que o título importa mais que o resto do relatório
Um bom título de bug = onde aconteceu + o que você fez + o que deu errado + em que condição se reproduz. Se esses quatro pontos cabem em uma linha, o desenvolvedor reproduz o problema sem te perguntar nada. É exatamente essa a diferença entre um bom título e um ruim. Abaixo estão 40 exemplos lado a lado, divididos em sete cenários — login, cadastro, pagamento, mobile, APIs, desempenho e interface — para você reescrever seus próprios bugs.
Desenvolvedores leem o título primeiro, sempre. Um título vago significa ou uma rodada extra de perguntas, ou o ticket fica parado. Pior: um título ruim não se salva com um bloco de ambiente bem preenchido — ninguém abre um ticket chamado «o botão está quebrado».
Um título passa ou falha em quatro pontos: é específico (nomeia o componente ou a página), é observável (traz fatos, não «não funciona»), carrega condições (navegador, dispositivo, tipo de conta, momento) e permite avaliar o alcance (queda total ou caso de borda).
A fórmula de 4 partes para títulos de bug
[Componente/Página] + [Ação] + [Resultado inesperado] + [Condição]
Como preencher cada parte:
- Componente: página de checkout / modal de login / lista de pedidos /
POST /api/orders - Ação: clicar, enviar, fazer upload, trocar de aba, escanear
- Resultado inesperado: nada acontece, retorna 500, valor com um dígito a mais, status fora de sincronia, texto sobreposto
- Condição: Chrome 120, iOS 17.2, largura <390px, apenas contas enterprise, após um timeout de rede
Sentence case, componente primeiro, sem marcadores de prioridade. É a convenção que a maioria dos times adota — e consistência importa mais do que a convenção escolhida.
1. Login e contas (7 exemplos)
| Título fraco | Título forte |
|---|---|
| O botão de login não funciona | Clicar em «Entrar» no Chrome 120 não faz nada; o console lança TypeError: login is not a function |
| O e-mail de redefinição não chega | Nenhum e-mail após clicar em «Esqueci minha senha» com um endereço Gmail (spam verificado após 30 minutos) |
| Redirecionamento errado após login | Usuário padrão cai em /admin em vez de /dashboard após entrar; reproduzível desde a v5.3 |
| O captcha falha sempre | Captcha válido continua recusado com «Código inválido» — só em janelas anônimas |
| A conta é bloqueada | Três senhas erradas bloqueiam a conta permanentemente, mas a mensagem diz «tente novamente em 24 horas» |
| A sessão não é invalidada | Entrar em um segundo dispositivo não invalida a primeira sessão, que continua totalmente utilizável |
| O login via SSO falha | O callback de SSO retorna «Invalid signature» desde a rotação do certificado do IdP |
Conclusão: em bugs de login, a condição (navegador, tipo de conta, janela anônima) decide se alguém consegue reproduzir. Não omita.
2. Cadastro e formulários (7 exemplos)
| Título fraco | Título forte |
|---|---|
| Não consigo me cadastrar | O cadastro recusa e-mails com «+» (ex. user+test@x.com) com «Formato de e-mail inválido» |
| A validação de telefone não funciona | Um número completo de 11 dígitos ainda mostra «Informe um número de 11 dígitos» |
| O indicador de força está errado | Uma senha de 8 caracteres que já contém dígitos ainda mostra «precisa incluir um número» |
| A lista suspensa não responde | A lista «País» não pode ser selecionada pelas setas após filtrar digitando 3 caracteres |
| O formulário envia duas vezes | Pressionar Enter no formulário de cadastro envia duas vezes e cria duas contas duplicadas |
| Campo obrigatório não validado | O cadastro é concluído sem marcar «Aceito os termos» e a conta é criada mesmo assim |
| Fuso horário padrão errado | O fuso aparece como UTC+0; usuários em UTC+8 precisam alterar manualmente a cada cadastro |
Conclusão: troque a descrição por valores de entrada concretos. Uma string real vale mais que dez frases de «a entrada não funciona».
3. Pagamento e checkout (7 exemplos)
| Título fraco | Título forte |
|---|---|
| O pagamento falha | Um total de R$ 129,99 aparece como R$ 1.299,99 (um dígito a mais) no checkout, e a página de pagamento herda o valor errado |
| O cupom não funciona | Cupom expirado ainda aparece como «válido»; ao aplicar, retorna 500 e esvazia o carrinho |
| O contador do carrinho não atualiza | O contador no cabeçalho continua mostrando «1» após remover o último item, até recarregar a página |
| Cobrança em duplicidade | Repetir o pagamento após um timeout de rede cobra duas vezes o mesmo pedido (pedido n.º 10231) |
| Dados de nota fiscal não são salvos | Os dados de faturamento da empresa são apagados ao voltar uma etapa e retornar ao checkout |
| Status de reembolso dessincronizado | O pedido continua mostrando «Pago» na visão do cliente mesmo após o reembolso (pedido n.º 10388) |
| Falta uma forma de pagamento | A opção de cartão não aparece no checkout — só em contas no modelo de cobrança antigo |
Conclusão: quando envolve dinheiro ou número de pedido, coloque o número no título. Isso corta a triagem pela metade.
4. Mobile e responsivo (6 exemplos)
| Título fraco | Título forte |
|---|---|
| O layout quebra no celular | O botão «Adicionar ao carrinho» sobrepõe o preço no iPhone 14 (iOS 17.2) abaixo de 390px de largura |
| A página não rola | Abrir um modal trava a rolagem no celular e ela continua travada depois de fechar |
| O teclado cobre o campo | O teclado do Android Chrome cobre o botão «Enviar», que fica impossível de tocar |
| Layout em paisagem quebrado | A barra de navegação quebra no iPad em paisagem (1024×768) e o logo sobrepõe o menu |
| As imagens não carregam | A imagem principal do produto some no Safari iOS 16; o console retorna 403 (assinatura do CDN expirada) |
| Área de toque pequena demais | Os botões de paginação no celular têm área de toque de 12×12px, abaixo do mínimo de acessibilidade de 44px |
Conclusão: no mobile, «mobile» não é uma condição. Escreva o modelo exato, a versão do sistema e a largura do viewport.
5. Dados, APIs e permissões (6 exemplos)
| Título fraco | Título forte |
|---|---|
| A exportação falha | Exportar mais de 10.000 pedidos retorna 504; exportar em lotes funciona |
| Carimbos de data e hora errados | Os horários do relatório ficam 8 horas atrasados — só para usuários no fuso Asia/Shanghai |
| A busca não retorna nada | Buscar «iPhone» retorna 0 resultados, embora existam 12 registros correspondentes no banco |
| Linhas duplicadas ao paginar | A lista de pedidos repete as últimas 3 linhas da página 1 no início da página 2 |
| Erro no upload | Upload de PNG acima de 5MB retorna 413, mas a interface mostra «Upload concluído» com o arquivo vazio |
| Elevação de privilégio | Um perfil somente leitura consegue chamar DELETE /api/projects/12 e excluir um projeto com sucesso |
Conclusão: em bugs de API, coloque o código HTTP, o caminho do endpoint ou o limite no título. É metade do trabalho de depuração feito de antemão.
6. Desempenho e carregamento (3 exemplos)
| Título fraco | Título forte |
|---|---|
| A página está lenta | O LCP da home é 8,2s em 4G, causado por 2,1MB de JavaScript sem compressão |
| Vazamento de memória | A memória sobe de 120MB para 900MB após trocar de aba 20 vezes, e a aba acaba travando |
| A API está lenta | O P95 do endpoint de listagem de produtos é 4,8s (base 300ms), só em picos de promoção |
Conclusão: bug de desempenho precisa de número e de referência, senão ninguém consegue julgar se é mesmo um defeito.
7. Textos e detalhes de interface (4 exemplos)
| Título fraco | Título forte |
|---|---|
| Erro de digitação na página | «Confirmacao» deveria ser «Confirmação» na página de confirmação do pedido |
| Ícones inconsistentes | Dois dos quatro ícones da página de configurações são em estilo linha e dois em estilo preenchido |
| Modo escuro ilegível | No modo escuro, o texto do campo é #333 sobre fundo escuro, praticamente invisível |
| Mensagem de erro inútil | Um upload falho mostra apenas «Operação falhou», sem causa e sem orientação de nova tentativa |
Conclusão: em bugs de texto e interface, escreva «o que está escrito → o que deveria estar». É o tipo de bug com menor custo de revisão.
7 hábitos que pioram os títulos
Como escrever em cada função
| Função | Como fazer |
|---|---|
| QA / testador | Fórmula completa de 4 partes, com todas as condições (navegador, dispositivo, conta, rede) |
| Suporte ou operações escalando | Sintoma visível ao usuário + caminho reproduzível + print; omita a causa se não souber e marque «aguardando confirmação técnica» |
| Revisor de UAT | Ancore no critério de aceite: «Falha no AC-3: status do pedido não atualizado em 5 segundos» |
| Product manager | Descreva o impacto visível para priorizar, mas não substitua o sintoma técnico |
Quando um título é traduzido
| Título no idioma original | Título em português |
|---|---|
| 结算页删除最后一件商品后购物车角标未更新 | O contador do carrinho não é atualizado após remover o último item no checkout |
| Android Chrome 键盘遮挡提交按钮，无法点击 | Android Chrome: o teclado cobre o botão Enviar e ele não pode ser tocado |
| 只读角色可删除项目（越权） | Perfil somente leitura pode excluir projetos (elevação de privilégio) |
Três regras quando um título muda de idioma: mantenha nomes de componentes no idioma original quando forem nomes próprios, traduza literalmente o resultado observável e nunca traduza mensagens de log nem códigos de erro. Um stack trace traduzido é um bug irreproduzível.
FAQ
Qual deve ser o tamanho de um título de bug? Cerca de 60 caracteres ou 10 palavras no máximo, para não ser cortado nas listagens. Se não couber, ou o sintoma principal não foi isolado, ou são dois bugs.
O título deve incluir prioridade ou severidade? Não. Prioridade é um campo separado que muda com o planejamento. Quando muda, o título fica errado — e polui a busca.
Posso escrever uma suposição se não sei a causa? «Possivelmente causado por X» é aceitável, mas nunca como conclusão fechada. Justifique no corpo do ticket, ou você desviará a triagem.
Um bug em vários navegadores são vários tickets? Titule com o sintoma principal e coloque as diferenças de ambiente no campo de ambiente ou observações. Separe apenas se os caminhos de correção forem realmente distintos, por exemplo iOS e Android em trechos de código diferentes.
Title Case ou sentence case? Os dois funcionam, mas mantenha a consistência com o backlog existente. Sem legado, sentence case lê melhor e é mais rápido de escanear.
O título continua sendo seu; o resto pode ser automático
Deixando claro: o BugCapturer não escreve o seu título — isso exige o seu julgamento sobre o que você viu. Mas os campos tediosos e fáceis de esquecer podem se preencher sozinhos:
- Contexto técnico automático: URL, navegador, sistema operacional, resolução de tela e tamanho do viewport são capturados para você, então as condições do título nunca precisam ser copiadas à mão.
- Dados de diagnóstico: logs de console em nível de erro e requisições de rede que falharam (HTTP ≥ 400) são coletados, com anonimização automática de parâmetros sensíveis (tokens, senhas, chaves de API).
- Prints anotados: arraste para selecionar a área do problema e adicione setas, quadros e texto, fixando «onde está errado» na imagem.
- Gravação de tela: grave a aba atual e corte o trecho, para o desenvolvedor receber um vídeo de 12 segundos que ele pode verificar.
- Compartilhar ou sincronizar em um clique: gere um link que colaboradores externos abrem sem se cadastrar, ou envie o relatório para o Feishu Bitable ou um webhook genérico.
Assim, você só precisa acertar aquela única linha de título, e a ferramenta preenche o resto.
Checklist para download
Cole ao lado do monitor e revise antes de enviar:
- Nomeia o componente ou a página?
- Traz um fato observável em vez de «não funciona»?
- Inclui condições (navegador / dispositivo / conta / rede / largura)?
- Carrega um dado verificável (código de status, n.º do pedido, valor, duração, limite)?
- Descreve exatamente um sintoma?
- Prioridade e qualquer suposição não verificada foram removidas?
- Fica abaixo de 60 caracteres ou 10 palavras?
Passando nos sete, seus títulos serão triados antes de 90% do backlog.
Leia também: modelo de relatório de bug (lista completa de campos e modelo para copiar) · como reportar bugs com eficácia · modelo de caso de teste com exemplos · Formato de relatório de bug · Como escrever os passos para reproduzir