Vinculação entre Histórias, Testes e Bugs no Jira para Rastreabilidade

O que é rastreabilidade e por que os vínculos importam

Rastreabilidade, em gestão de testes, é a capacidade de navegar e comprovar a cadeia completa entre o que foi pedido (requisito), o que foi verificado (testes), o que falhou (defeitos) e o que foi revalidado (re-teste). No Jira, essa cadeia é construída com links entre issues (relacionamentos) e com disciplina na atualização de comentários, evidências e status.

Uma cadeia bem mantida permite responder rapidamente perguntas como: “Quais histórias foram testadas?”, “Quais testes falharam por causa deste bug?”, “O bug já foi re-testado e com qual evidência?”.

Tipos de vínculo mais usados e quando aplicar

Abaixo estão os relacionamentos mais comuns para rastreabilidade entre História, Teste e Bug. Os nomes podem variar conforme idioma/configuração, mas a intenção é a mesma.

Vínculo de bug com história (requisito afetado)

Além de ligar o bug ao teste que falhou, é essencial ligar o bug à história/requisito impactado. Isso facilita medir qualidade por requisito e evita “bugs soltos” sem contexto.

• Bug ↔ História: use relates to quando o bug afeta a história, mas não necessariamente bloqueia a entrega (ex.: problema cosmético aceito).
• Bug bloqueando entrega: use blocks/is blocked by quando a correção é condição para concluir a história.

Como manter a cadeia requisito → testes → defeitos → validação

Modelo de cadeia recomendada

• História (Requisito) is tested by Teste(s)
• Teste relates to ou referência no próprio bug (e vice-versa)
• Bug relates to ou blocks História (dependendo do impacto)
• Re-teste: evidência e comentário de validação no Bug e/ou no item de execução do teste, com referência cruzada

Exemplo completo (com IDs fictícios)

• História: PROJ-120 “Como usuário, quero redefinir senha por e-mail”.
• Teste: QA-55 “Redefinição de senha - fluxo feliz e erros”.
• Bug: BUG-77 “Token expira imediatamente ao abrir link”.

Vínculos esperados:

Continue em nosso aplicativo e ...

• Ouça o áudio com a tela desligada
• Ganhe Certificado após a conclusão
• + de 5000 cursos para você explorar!

ou continue lendo abaixo...

Baixar o aplicativo

• Em PROJ-120: adicionar link is tested by → QA-55.
• Em BUG-77: adicionar link relates to → PROJ-120 (ou blocks se impedir a entrega).
• Em BUG-77: adicionar link relates to → QA-55 (para mostrar qual teste revelou o problema).

Passo a passo prático: criando e revisando vínculos no Jira

1) Vincular História a Testes (is tested by / tests)

1. Abra a História (ex.: PROJ-120).
2. Localize a seção de links (geralmente “Issue links”/“Links”).
3. Clique em Link issue.
4. Selecione o tipo de vínculo: is tested by (ou tests, conforme a direção disponível).
5. Digite a chave do Teste (ex.: QA-55) e confirme.
6. Valide se o link apareceu também do outro lado (no Teste), garantindo navegação bidirecional.

Dica prática: se a história tem critérios de aceite múltiplos, prefira mais de um teste vinculado (um por cenário relevante) em vez de um teste genérico.

2) Criar Bug a partir de falha e vincular corretamente

1. Ao identificar uma falha durante a execução do teste, crie o Bug (ou use “Create linked issue”, se disponível).
2. No Bug, preencha campos essenciais: ambiente, versão/build, passos, resultado esperado/obtido e evidência (anexo/link).
3. Crie os vínculos mínimos:

• Bug ↔ História: relates to (ou blocks se impedir a entrega).
• Bug ↔ Teste: relates to (para indicar origem da detecção).

Regra de ouro: todo bug deve estar ligado a pelo menos um requisito afetado (história) e uma fonte de detecção (teste/execução).

3) Usar blocks / is blocked by para dependências reais

Use blocks quando uma issue impede outra de avançar. Exemplos típicos:

• Bug crítico impede concluir a história: História is blocked by Bug.
• Teste automatizado depende de endpoint ainda não entregue: Teste is blocked by História/Tarefa técnica.

Boa prática: se a história está “pronta” do ponto de vista de desenvolvimento, mas não pode ser validada, o vínculo is blocked by ajuda a explicar por que a entrega não deve ser encerrada.

4) Marcar duplicidade com duplicates (higiene do backlog de bugs)

1. Ao encontrar um bug semelhante, compare: passos, ambiente, logs e evidências.
2. Se for o mesmo problema, no bug mais novo aplique duplicates apontando para o bug original.
3. No bug original, mantenha a referência ao requisito/teste; no duplicado, registre um comentário curto explicando o motivo da duplicidade e a chave do bug principal.

Evite: fechar como duplicado sem link. O link é o que preserva rastreabilidade e evita retrabalho.

Comentários de validação: como registrar decisão e evidência (re-teste)

O comentário de validação é a peça que conecta a correção à confirmação. Ele deve permitir auditoria rápida: o que foi re-testado, em qual versão, com qual evidência, e qual foi a decisão.

Estrutura recomendada de comentário de validação

[RETESTE] Data/Hora: AAAA-MM-DD HH:MM (fuso) | Ambiente: Homolog | Build: 1.8.3-rc2  
Escopo do re-teste: (cenários executados e limites)  
Referências: História PROJ-120 | Teste QA-55 | Execução RUN-310 (se aplicável)  
Evidências: anexo(s) / link(s) (ex.: screenshot, vídeo, log)  
Resultado: PASSOU / FALHOU  
Decisão: (ex.: validar correção e liberar história / manter bug aberto / abrir bug novo relacionado)  
Observações: (riscos, comportamento residual, passos adicionais)

Exemplo preenchido (PASSOU)

[RETESTE] Data/Hora: 2026-01-26 10:40 BRT | Ambiente: Staging | Build: 2.3.0+451  
Escopo do re-teste: fluxo de redefinição via e-mail (token válido), token expirado, reuso de token  
Referências: História PROJ-120 | Teste QA-55 | Execução RUN-310  
Evidências: anexo video_reteste_bug77.mp4; screenshot_token_valido.png  
Resultado: PASSOU  
Decisão: correção validada; história pode seguir para pronto após execução completa do conjunto de testes vinculado  
Observações: sem regressões no login; tempo de expiração confirmado em 15 min

Exemplo preenchido (FALHOU com decisão clara)

[RETESTE] Data/Hora: 2026-01-26 11:15 BRT | Ambiente: Staging | Build: 2.3.0+451  
Escopo do re-teste: abertura do link em navegador mobile + desktop  
Referências: História PROJ-120 | Teste QA-55 | Execução RUN-311  
Evidências: anexo screenshot_mobile_erro.png; log_console_mobile.txt  
Resultado: FALHOU  
Decisão: manter BUG-77 aberto; impacto ainda bloqueia conclusão da PROJ-120 (mantido vínculo is blocked by)  
Observações: falha ocorre apenas no Safari iOS; sugerido investigar encoding do parâmetro token

Checklist de rastreabilidade para não concluir histórias sem teste vinculado

Roteiro de verificação (use antes de mover a história para “Done/Concluída”)

• Vínculo obrigatório: a história possui pelo menos 1 link is tested by/tests
• Cobertura mínima: os testes vinculados cobrem os critérios de aceite principais (não apenas “fluxo feliz”).
• Evidências: há evidência registrada na execução/itens de teste (ou anexos/links) para os cenários críticos.
• Bugs associados: todo bug encontrado durante os testes está vinculado à história (relates to ou blocks).
• Bloqueios resolvidos: se existe is blocked by ativo, a história não deve ser concluída sem decisão explícita (ex.: aceitação de risco aprovada e registrada).
• Duplicidades tratadas: bugs duplicados foram marcados com duplicates e apontam para o bug principal.
• Re-teste documentado: para cada bug corrigido, existe comentário de validação com build/ambiente e evidências.
• Decisão rastreável: se algum bug foi “não corrigir”/“aceito”, o comentário registra quem decidiu, por quê e qual impacto (e o vínculo com a história permanece).

Mini-auditoria rápida (perguntas que você deve conseguir responder em 30 segundos)

• Quais testes validam esta história? (abrir links is tested by)
• Quais bugs afetaram esta história? (ver links relates to/blocks)
• Qual foi a última evidência de re-teste e em qual build? (ler comentário [RETESTE] no bug)