“A quantidade está bugada.”
Imagine receber apenas esta mensagem no fim do dia.
Quem vai corrigir precisa perguntar: em qual produto? qual quantidade? em qual versão? o que apareceu? o que deveria ter acontecido?
A frase comunica que existe um problema, mas ainda não ajuda a reproduzi-lo.
Reproduzir vem antes de corrigir
Vamos usar um caso que já conhecemos da Cantina Horizonte.
Cenário observado
Produto: Salgado
Quantidade informada: 0
Esperado: rejeitar a operação e explicar que a quantidade deve estar entre 1 e 10.
Obtido: o item é aceito.
Agora outra pessoa consegue repetir exatamente o cenário.
Um registro útil conta a história do problema
Não existe um único formato obrigatório para toda empresa. O importante é guardar informações suficientes para que o problema possa ser compreendido.
| Campo | O que registrar |
|---|---|
| Título | Uma frase curta que identifica o comportamento incorreto. |
| Ambiente | Versão, navegador, sistema ou condição relevante para repetir o cenário. |
| Pré-condição | O que precisa existir antes de começar. |
| Passos | A sequência realizada até o problema aparecer. |
| Resultado esperado | O comportamento definido pela regra ou requisito. |
| Resultado obtido | O que realmente aconteceu. |
| Evidência | Informação que ajuda a confirmar e investigar o problema. |
Um exemplo da Cantina Horizonte
BUG-01 · Quantidade zero é aceita no pedido
Ambiente: Cantina Horizonte v1, navegador atual.
Pré-condição: Salgado disponível em estoque.
Passos: abrir o sistema → escolher Salgado → informar 0 → adicionar ao pedido.
Esperado: rejeitar a quantidade e informar a faixa permitida.
Obtido: o produto é adicionado com quantidade zero.
Requisito relacionado: RF-03.
BUG é uma palavra muito usada no mercado como sinônimo informal de defeito. Aqui o prefixo serve apenas para identificar o registro.
Severidade e prioridade voltam a aparecer
Na Etapa 8 vimos que essas palavras não significam a mesma coisa.
Severidade ajuda a expressar o impacto do defeito. Prioridade ajuda a decidir quando ele deve ser tratado.
Um erro visual pequeno pode ter baixa severidade e alta prioridade se uma apresentação importante acontecer hoje. Já outro defeito pode ter impacto alto, mas depender de uma condição rara e entrar em outra ordem de correção.
Agora precisamos acompanhar o problema ao longo do trabalho
Um registro em um documento já ajuda, mas a equipe também precisa saber se o problema continua aberto, quem está cuidando dele e quando a correção chegou.
Git, GitHub e repositório
Git é uma ferramenta de controle de versões: registra alterações e permite acompanhar o histórico do projeto. GitHub é um serviço que hospeda projetos controlados por Git e oferece recursos de colaboração.
Um repositório é o espaço em que ficam os arquivos do projeto e seu histórico de versões.
Como a Cantina Horizonte está em um repositório no GitHub, podemos usar um recurso do próprio serviço para acompanhar o defeito.
GitHub Issues
Issue significa questão, item ou ocorrência a acompanhar. No GitHub, uma Issue pode registrar defeitos, melhorias, tarefas e outras necessidades do projeto.
Em QTS vamos usá-la principalmente para registrar defeitos de forma rastreável.
Faça a prática no repositório de exercício
Não abra Issues de aula no repositório oficial do Mundo bit Byte. Use o repositório da sua própria cópia do projeto ou o repositório indicado pelo professor.
- Abra a aba Issues desse repositório.
- Clique em New issue.
- Use um título curto e específico.
- No texto da Issue, registre ambiente, pré-condição, passos, esperado, obtido e evidência.
- Crie a Issue e guarde o número dela para relacioná-la aos testes e à correção.
Um registro pode receber etiquetas como bug, alta prioridade ou estoque. As etiquetas ajudam a organizar, mas não substituem uma descrição clara.
O defeito foi corrigido. Terminou?
Suponha que alguém altere a validação para respeitar a regra:
def validar_quantidade(qtd):
return 1 <= qtd <= 10Agora precisamos voltar ao cenário original e perguntar:
Quantidade 0 continua sendo aceita?
Se repetimos o caso que revelou o problema para verificar a correção, fazemos um teste de confirmação.
Teste de confirmação
Repete o cenário que falhou para verificar se o defeito corrigido deixou de ocorrer.
Mas uma correção pode quebrar outra coisa
Imagine que, ao corrigir quantidade zero, alguém escreva:
def validar_quantidade(qtd):
return 1 <= qtd < 10Quantidade 0 agora é rejeitada. A correção parece funcionar.
Mas quantidade 10, que deveria ser válida, passou a ser rejeitada.
Por isso não basta olhar somente para o caso corrigido.
Teste de regressão
Reexecuta testes relevantes para verificar se uma alteração introduziu problemas em comportamentos que antes funcionavam.
Confirmação e regressão respondem perguntas diferentes
| Teste | Pergunta | Exemplo |
|---|---|---|
| Confirmação | O defeito original foi realmente corrigido? | Quantidade 0 agora é rejeitada? |
| Regressão | A mudança que fizemos estragou algo que deveria continuar funcionando? | 1, 5 e 10 continuam aceitos? 11 continua rejeitado? |
O ciclo do defeito fica mais claro
Encerrar um defeito significa que a equipe possui evidências suficientes para considerar aquele registro resolvido dentro do processo adotado.
Abra o modelo de registro
Documento de apoio
Abrir modelo de registro de defeito →
Use o modelo primeiro em documento simples. Depois replique a mesma estrutura em uma Issue do GitHub.
Prática · transforme uma falha em informação útil
- Escolha um caso que falhou na Cantina Horizonte.
- Escreva um título curto e específico.
- Registre ambiente, pré-condição, passos, esperado e obtido.
- Relacione o defeito ao requisito ou caso de teste quando houver.
- Depois da correção, repita o cenário original.
- Execute também casos próximos para verificar regressão.
Agora aparece outro problema
Imagine repetir manualmente os mesmos testes de quantidade em cada nova versão:
0, 1, 5, 10, 11... corrigiu... testa tudo de novo... outra alteração... testa tudo outra vez.
Com poucos casos ainda é possível. Com dezenas ou centenas, o trabalho se torna demorado e sujeito a esquecimento.
Se os mesmos testes precisam ser repetidos muitas vezes, o computador pode executar parte desse trabalho para nós?
Antes de seguir
Você deve conseguir explicar:
- por que um bom registro de defeito precisa ser reproduzível;
- o que são Git, GitHub e repositório neste contexto;
- o papel de uma Issue no GitHub;
- a diferença entre severidade e prioridade;
- a diferença entre teste de confirmação e teste de regressão.