Gestão de bugs: como rastrear, organizar e priorizar no seu jogo

Gestão de bugs é a parte menos glamourosa de fazer um jogo e, ao mesmo tempo, uma das que mais separa o projeto que sai do projeto que apodrece no seu HD. Rastrear bugs de forma organizada não é sobre saber consertar código: é sobre ter um sistema para saber quais bugs existem, quais importam e em que ordem atacá-los. Este texto é sobre o fluxo de produção em volta dos bugs (anotar, classificar, priorizar e fechar), não sobre a técnica de debugar em si nem sobre montar seu processo de teste. É o meio de campo que faz o resto funcionar.

Por que a cabeça e o papel não escalam

Todo mundo começa igual: você joga, encontra um problema, pensa "depois eu arrumo isso" e segue. No começo funciona, porque você tem três bugs e lembra dos três. O problema aparece quando o jogo cresce. De repente são quarenta problemas conhecidos, você lembra de uns doze, arruma um sem querer criando outro, e aquele bug crítico que você viu semana passada sumiu da memória até um jogador reclamar dele no lançamento.

Anotação na cabeça não tem histórico, não tem prioridade e não sobrevive a uma noite de sono. Papel e bloco de notas soltos são um pouco melhores, mas viram uma lista morta que ninguém relê e que não diz o que já foi resolvido. O ponto central da gestão de bugs é simples: existe um lugar único onde todo bug vive, e esse lugar é a fonte da verdade. Se não está lá, não existe. Se está lá, não vai ser esquecido.

Esse lugar único é o bug tracker. Não precisa ser sofisticado. As opções mais comuns:

• Trello ou similar (quadro Kanban): cada bug é um cartão, cada coluna é um estado. Visual, rápido, ótimo para solo e times pequenos.
• GitHub Issues (ou GitLab): perfeito se seu código já está lá. Você linka o commit que corrige o bug à issue e fecha automaticamente. Labels servem para severidade.
• Notion ou planilha: uma tabela com colunas de título, severidade, estado e ambiente já resolve muita coisa. Filtro e ordenação vêm de graça.
• Ferramentas dedicadas (Jira, Linear, YouTrack): poderosas, mas geralmente pesadas demais para um indie solo. Só valem a pena quando o time cresce.

Não gaste uma semana escolhendo. Pegue a ferramenta que você já usa para o resto do projeto e comece hoje. A pior ferramenta usada com disciplina vence a melhor ferramenta abandonada.

Como escrever um bom relatório de bug

Um bug mal descrito é quase pior que nenhum bug anotado, porque ele ocupa espaço na fila sem ser acionável. "Tá bugado o menu" não é um relatório, é um lamento. Quando você (ou um testador, ou um jogador) abre um bug, o objetivo é que qualquer pessoa consiga reproduzir e entender o problema sem precisar te perguntar nada.

Os campos que todo relatório de bug precisa ter:

• Título: curto e específico. "Save corrompe ao sair no meio da fase 3" e não "problema no save".
• Passos para reproduzir: a parte mais importante. Uma lista numerada do que fazer para o bug aparecer.
• Resultado esperado: o que deveria acontecer.
• Resultado obtido: o que de fato aconteceu.
• Ambiente e versão: plataforma, sistema operacional e a versão/build do jogo. Um bug que só acontece no build 0.4.2 no Linux é uma pista enorme.
• Severidade: o quanto isso machuca (falo disso na próxima seção).
• Evidência: um print ou, melhor ainda, um vídeo curto. Bug visual sem imagem é o dobro do trabalho.

Um bug que reproduz sempre com passos claros costuma ser rápido de resolver. Um bug sem passos vira caça ao tesouro e volta pra fila intocado. Se você não consegue reproduzir, anote isso também: "intermitente, aconteceu 1 em 5 tentativas" já orienta quem for investigar.

Aqui vai um template que você pode colar direto na descrição de cada cartão ou issue:

TÍTULO: [resumo curto e específico do problema]

SEVERIDADE: [crítico / alto / médio / baixo]

AMBIENTE:
- Plataforma: [PC / Android / Switch / ...]
- SO: [Windows 11 / Ubuntu 22.04 / ...]
- Build/versão: [0.4.2]

PASSOS PARA REPRODUZIR:
1. [primeiro passo]
2. [segundo passo]
3. [terceiro passo]

RESULTADO ESPERADO:
[o que deveria acontecer]

RESULTADO OBTIDO:
[o que realmente aconteceu]

FREQUÊNCIA: [sempre / às vezes / 1 em X tentativas]

EVIDÊNCIA: [link do print ou vídeo]

OBSERVAÇÕES: [logs, teoria de causa, contexto extra]

Note que não tem uma linha de código de programação nesse template. Ele é texto puro de propósito: quem preenche pode ser um jogador da sua comunidade, não só você. Quanto mais fácil for reportar, mais bugs você descobre antes do lançamento em vez de depois.

Níveis de severidade e como classificar

Severidade responde a uma pergunta só: o quanto esse bug atrapalha o jogador? Não é o quanto ele te irrita nem o quão feio ele é no seu código. Um crash tem severidade alta mesmo se a correção for trivial; um texto desalinhado tem severidade baixa mesmo se te dá vontade de arrancar o cabelo. Separar essas duas coisas é o que mantém a fila honesta.

Uma escala de quatro níveis dá conta da maioria dos projetos:

• Crítico / bloqueador: o jogo trava, fecha sozinho, corrompe o save ou impede o jogador de progredir. Não dá pra lançar com isso em aberto. Um softlock onde a única saída é reiniciar entra aqui.
• Alto: uma função importante quebra, mas existe contorno. A loja não abre pelo botão, porém abre por um atalho. Machuca a experiência de verdade.
• Médio: incômodo perceptível que não impede jogar. Um inimigo que às vezes atravessa uma parede, um som que não toca em uma situação específica.
• Baixo / cosmético: puramente estético ou raríssimo. Uma sombra levemente errada, um typo, um pixel fora do lugar num canto que ninguém olha.

O erro clássico é classificar pela emoção. O bug que você acabou de introduzir e te deixou frustrado parece o fim do mundo, mas se ele só muda a cor de um botão por meio segundo, é baixo. Classifique olhando o jogador, não o espelho. Se estiver em dúvida entre dois níveis, pense: "um streamer jogando isso ao vivo teria a sessão arruinada?" Se sim, sobe de nível.