Gestão de Evidências no Jira: Anexos, Comentários e Histórico de Validações

O que são evidências confiáveis no Jira

Evidência confiável é qualquer registro dentro do Jira que permita reproduzir e verificar o resultado de uma execução de teste sem depender da memória de quem testou. Para ser auditável, a evidência precisa estar: (1) no próprio Jira (anexo, comentário, campos, links rastreáveis), (2) contextualizada (ambiente, build, dados, passos, resultado esperado vs. obtido), e (3) imutável ou historicamente rastreável (com histórico de mudanças e autoria).

Na prática, você combina três camadas: anexos (provas “visuais/técnicas”), comentários padronizados (narrativa e contexto) e histórico de mudanças (auditoria de quem alterou o quê e quando).

Quando anexar evidências: prints, vídeos, HAR/logs e console

Prints (capturas de tela)

• Quando usar: validações visuais, mensagens de erro, estados de tela, dados exibidos incorretamente, diferenças de layout, confirmações de sucesso.
• Boas práticas: capture a tela inteira quando o contexto for importante (URL, usuário, data/hora do sistema, ambiente). Se o foco for um componente específico, use zoom/recorte, mas mantenha ao menos um print “contexto”.
• Evite: prints repetidos sem valor (ex.: 10 imagens do mesmo erro). Prefira 1–2 prints bem escolhidos.

Vídeos curtos (screen recording)

• Quando usar: problemas intermitentes, passos longos, animações, falhas de usabilidade, timing/latência, comportamento dependente de sequência.
• Duração recomendada: 15–60 segundos, focado no cenário. Se precisar de mais, divida em partes (Parte 1, Parte 2).
• Boas práticas: inicie mostrando o estado inicial (URL/ambiente), execute o fluxo sem cortes e finalize mostrando o resultado (erro/estado final).

HAR (HTTP Archive) e logs de rede

• Quando usar: erros de API, falhas de autenticação, CORS, timeouts, respostas 4xx/5xx, discrepâncias entre front e back, problemas de cache.
• O que precisa constar no comentário junto do HAR: endpoint principal afetado, horário aproximado da captura, ação executada no momento do erro, status code observado.
• Cuidados: HAR pode conter tokens, cookies e dados pessoais. Faça redaction antes de anexar (ver seção de dados sensíveis).

Arquivos de console (logs do navegador/app)

• Quando usar: erros JavaScript, warnings relevantes, stack traces, falhas de carregamento de recursos, erros de feature flag.
• Formato: prefira exportar como arquivo .txt ou .log quando houver muitas linhas; para poucas linhas, cole em bloco de código no comentário.
• Boas práticas: inclua o trecho que mostra o erro e algumas linhas antes/depois (contexto), e informe o navegador/versão.

Outros anexos úteis

• Arquivos de configuração (ex.: JSON de payload, coleção de requests) quando necessário para reproduzir.
• Relatórios de execução (ex.: export do runner/CI) quando o teste for automatizado e o log for a evidência principal.
• Dados de entrada (ex.: CSV) quando o cenário depende de massa específica, desde que não contenha dados sensíveis.

Padrão de nomenclatura de arquivos (data, build e cenário)

Um padrão de nome evita anexos “print1.png” e facilita auditoria e busca. Recomenda-se um formato consistente, legível e ordenável.

Formato recomendado

YYYY-MM-DD_BUILD-XXXX_CEN-_TIPO__v01.ext

Exemplos práticos

• 2026-01-26_BUILD-1842_CEN-login_invalido_PRINT_mensagem-erro_v01.png
• 2026-01-26_BUILD-1842_CEN-carrinho_desconto_VIDEO_fluxo-completo_v01.mp4
• 2026-01-26_BUILD-1842_CEN-checkout_cartao_HAR_timeout-gateway_v02.har
• 2026-01-26_BUILD-1842_CEN-perfil_salvar_CONSOLE_typeerror_v01.log

Regras simples para manter consistência

• Data: use sempre YYYY-MM-DD.
• Build: use o identificador real (número do pipeline, tag, versão, commit curto). Se não existir, use um marcador do release (ex.: REL-1.8.0).
• Cenário: use um nome curto e estável (sem espaços; use hífen/underscore).
• Tipo: PRINT, VIDEO, HAR, CONSOLE, LOG, PAYLOAD.
• Versão: v01, v02 quando substituir/atualizar evidência.

Passo a passo: anexar evidências no Jira sem perder contexto

1) Antes de anexar: confirme o “mínimo reprodutível”

• Ambiente (ex.: homologação, staging, produção controlada)
• Build/versão
• Usuário/perfil (sem expor credenciais)
• Dados de entrada (IDs, parâmetros, massa)
• Passos executados e ponto exato da falha/validação

2) Gere a evidência no formato adequado

• Print para estado estático
• Vídeo curto para fluxo/instabilidade
• HAR para rede/API
• Console/log para erro técnico

3) Nomeie o arquivo no padrão

Renomeie antes de anexar. Isso evita anexos duplicados e facilita localizar evidências em auditorias.

4) Anexe no item correto

• Em caso de execução de teste: anexe no item onde o resultado é registrado (ex.: execução/registro do teste).
• Em caso de defeito: anexe no bug para suportar a análise e a correção.
• Quando a evidência serve aos dois: anexe no bug e referencie no comentário do teste (ou vice-versa), mantendo um “ponto de verdade” para evitar divergência.

5) Registre o contexto em comentário padronizado

O anexo sozinho raramente explica o que aconteceu. Use o template de comentário para deixar claro o que foi validado e qual evidência comprova.

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

Template de comentário: “Evidência de Execução”

Use um padrão fixo para reduzir ambiguidade e facilitar leitura rápida. Ajuste os campos conforme o seu processo, mas mantenha a estrutura.

[EVIDÊNCIA DE EXECUÇÃO]
Data/Hora: 2026-01-26 14:35 (BRT)
Executor(a): Nome Sobrenome
Ambiente: Staging
Build/Versão: BUILD-1842 (commit abc1234)
Plataforma: Web
Navegador/OS: Chrome 121 / Windows 11
Cenário: CEN-login_invalido
Pré-condições: Usuário existente; senha incorreta conhecida
Passos: 1) Acessar /login 2) Informar email válido 3) Informar senha inválida 4) Clicar em Entrar
Resultado esperado: Exibir mensagem “Credenciais inválidas” sem autenticar
Resultado obtido: Mensagem exibida, autenticação não realizada
Status: PASS
Evidências: 2026-01-26_BUILD-1842_CEN-login_invalido_PRINT_mensagem-erro_v01.png
Observações: Mensagem está com texto correto e sem quebra de layout

Exemplo para falha (FAIL) com múltiplas evidências

[EVIDÊNCIA DE EXECUÇÃO]
Data/Hora: 2026-01-26 16:10 (BRT)
Executor(a): Nome Sobrenome
Ambiente: Staging
Build/Versão: BUILD-1842
Plataforma: Web
Navegador/OS: Firefox 122 / macOS 14
Cenário: CEN-checkout_cartao
Pré-condições: Carrinho com 1 item; cartão de teste válido
Passos: 1) Ir ao checkout 2) Selecionar cartão 3) Confirmar pagamento
Resultado esperado: Pedido confirmado e número do pedido exibido
Resultado obtido: Tela trava em “Processando” e retorna erro 504
Status: FAIL
Evidências:
- 2026-01-26_BUILD-1842_CEN-checkout_cartao_VIDEO_trava-processando_v01.mp4
- 2026-01-26_BUILD-1842_CEN-checkout_cartao_HAR_timeout-gateway_v01.har
- 2026-01-26_BUILD-1842_CEN-checkout_cartao_CONSOLE_erro-fetch_v01.log
Observações: Intermitente (2/5 tentativas). Ocorre após ~30s.

Cuidados com dados sensíveis: o que não deve ir para anexos/comentários

Evidência não pode comprometer segurança, privacidade ou conformidade. Antes de anexar, revise se há dados sensíveis visíveis ou embutidos no arquivo.

Checklist de dados sensíveis comuns

• Dados pessoais: nome completo, CPF/RG, endereço, telefone, e-mail real, data de nascimento
• Dados financeiros: cartão, CVV, extrato, chave Pix
• Credenciais: senhas, tokens, API keys, cookies de sessão
• Identificadores internos: IDs de clientes reais, números de pedido de produção, logs com payloads sensíveis
• Informações de infraestrutura: IPs internos, URLs privadas, headers de autenticação

Redaction (mascaramento) na prática

• Em prints: use blur/caixa sólida para ocultar dados; mantenha visível o suficiente para entender o contexto (ex.: últimos 2–4 dígitos).
• Em vídeos: pause e aplique blur em trechos sensíveis ou refaça a gravação com dados de teste.
• Em HAR/logs: remova/mascare campos como Authorization, Cookie, Set-Cookie, tokens em query string, payloads com PII. Se necessário, gere uma versão “sanitizada” do arquivo.
• Preferência: use contas e massas de teste. Evite evidências em produção com dados reais.

Como sinalizar que houve redaction

No comentário de evidência, registre explicitamente:

Observações: Evidência sanitizada (tokens e dados pessoais mascarados).

Histórico de mudanças (changelog) para auditoria

O histórico de mudanças do Jira registra alterações em campos e status, com autor e timestamp. Ele é essencial para auditorias porque permite responder perguntas como: quando o resultado foi alterado, por quem, e o que mudou.

O que auditar no changelog

• Alterações de status relacionadas à validação (ex.: de “Em validação” para “Aprovado”)
• Trocas de responsável (assignee) durante a validação
• Mudanças em campos de resultado (ex.: PASS/FAIL, versão testada, ambiente)
• Atualizações de prioridade/severidade quando justificadas por evidência

Passo a passo: usar o changelog para checar consistência

• Abra o item no Jira e localize a área de Histórico / Activity / History (o nome varia por configuração).
• Verifique se a mudança de status que indica “validado/aprovado” ocorreu depois do comentário de evidência e anexos.
• Se houver alteração de resultado (ex.: FAIL para PASS), procure o comentário correspondente com nova evidência (v02).
• Quando identificar mudança sem evidência, registre um comentário solicitando complementação: “Alteração de status para Aprovado sem evidência anexada. Favor registrar [EVIDÊNCIA DE EXECUÇÃO].”

Como evitar “aprovações silenciosas”

• Padronize que toda transição para estados de aprovação/validação exija comentário com o template “Evidência de Execução”.
• Quando houver retrabalho, registre nova evidência com versão incrementada (v02, v03) e mencione o motivo: correção aplicada, mudança de ambiente, novo build.

Como evitar perda de contexto (evidência em chats externos)

Conversas em chat são úteis para rapidez, mas são frágeis para auditoria: links expiram, arquivos somem, mensagens não são facilmente rastreáveis e o contexto se perde. A regra prática é: o chat coordena, o Jira registra.

Práticas recomendadas

• Se a evidência nasceu no chat: baixe o arquivo e anexe no Jira com o padrão de nome. No comentário, registre que foi coletado via chat e o que ele demonstra (sem depender do chat para leitura).
• Se houver decisão no chat (ex.: “aceitar risco”): replique a decisão no Jira em comentário, com data/hora e responsáveis envolvidos.
• Evite links temporários: prefira anexos no Jira ou links para repositórios internos estáveis (quando permitido), sempre com contexto no comentário.
• Centralize a narrativa: mesmo com anexos, descreva no comentário o “porquê” e o “resultado”, para que a evidência seja compreensível sem abrir todos os arquivos.

Mini-checklist antes de finalizar uma validação

• Existe comentário com template “Evidência de Execução” preenchido?
• Anexos estão nomeados com data + build + cenário?
• Evidências estão sanitizadas (sem dados sensíveis)?
• O changelog reflete a sequência correta (evidência → mudança de status)?
• Nenhuma informação crítica ficou apenas em chat?