Organização por Versões e Releases no Jira para Testes

Conceitos-chave para organizar testes por versão

Quando o time começa a testar em paralelo (mais de uma sprint ativa, múltiplos builds no mesmo dia, hotfixes em produção), a organização por versão deixa de ser “um detalhe de preenchimento” e vira o eixo de rastreabilidade do ciclo de testes. No Jira, quatro elementos ajudam a estruturar isso de forma consistente:

• Fix Version/s: versão em que a entrega será disponibilizada (o “vai em qual release?”). É o campo mais importante para agrupar o que precisa ser validado para uma release.
• Affects Version/s: versão(ões) onde o problema existe (o “quebrou a partir de qual versão?”). É essencial para hotfixes e para entender impacto em produção.
• Releases (Versions do projeto): cadastro das versões do projeto (ex.: 2026.01, 2026.01.1). Permite acompanhar progresso e planejar datas.
• Componentes: fatias funcionais/técnicas do produto (ex.: Checkout, Autenticação, API de Pagamentos). Ajudam a dividir responsabilidade, roteamento e filtros por área.

Como esses campos se conectam ao ciclo de testes

• Planejamento: definir a Fix Version/s de histórias/bugs define o escopo do que QA precisa validar para uma release.
• Execução: separar validações por build e por sprint evita retrabalho e confusão sobre “qual ambiente/artefato foi testado”.
• Controle: com Releases e filtros salvos, você enxerga rapidamente o que está pronto para teste, reprovou, está bloqueado e o que falta fechar.

Convenções de nomenclatura (versões, builds e hotfixes)

Defina um padrão simples e previsível. O objetivo é permitir filtros e dashboards sem “gambiarras”. Exemplos práticos:

Versões (Releases / Fix Version)

• Release principal: 2026.01 (ano.mês) ou 1.24.0 (SemVer). Escolha um padrão e mantenha.
• Patch/hotfix: 2026.01.1 ou 1.24.1.
• Release candidata (se aplicável): 2026.01-rc1 (use com cautela; se o Jira ordenar versões, valide como o sufixo se comporta).

Builds (para separar validações dentro da mesma Fix Version)

O Jira não tem um campo padrão “Build” em todos os projetos. Se o seu projeto já tiver um campo customizado (ex.: Build, Build Number), use-o. Se não tiver, uma alternativa operacional é padronizar um rótulo (labels) ou um campo de texto curto. Sugestão de padrão:

• build-2026.01.0+145 (versão + número do pipeline)
• build-145 (se a versão já estiver em Fix Version/s)

Sprints

Use o campo Sprint (do Jira Software) para indicar em qual sprint a entrega foi trabalhada. Para QA, isso ajuda a responder “o que veio nesta sprint” sem misturar com o que ainda está em desenvolvimento para a mesma release.

Componentes

Padronize nomes de componentes com granularidade suficiente para filtrar, mas não tão detalhada a ponto de virar manutenção constante. Exemplos:

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

• Checkout, Catálogo, Login, Admin
• Mobile, Web, API (se fizer sentido separar por camada)

Passo a passo: cadastrar e usar Releases (Versions) no Jira

1) Criar versões do projeto

Objetivo: garantir que Fix Version/s e Affects Version/s usem valores oficiais (sem variações como “1.2”, “v1.2”, “1.2.0”).

• Acesse o projeto no Jira.
• Vá em Releases (ou Versions, dependendo da navegação do seu Jira).
• Crie a versão com o padrão definido (ex.: 2026.01).
• (Opcional) Defina Start date e Release date para ajudar no planejamento.

2) Definir Fix Version/s nas issues de escopo

Regra prática: tudo que precisa entrar na release deve ter Fix Version/s preenchido (histórias, tarefas técnicas e bugs planejados para correção).

• Ao refinar/planejar, preencha Fix Version/s com a release alvo (ex.: 2026.01).
• Preencha Component/s para permitir filtros por área.
• Se houver mais de uma entrega (ex.: mesma história entregue em partes), evite múltiplas Fix Versions na mesma issue; prefira quebrar em issues menores para manter rastreabilidade clara.

3) Usar Affects Version/s para bugs (impacto real)

Regra prática: Affects Version/s representa onde o bug acontece; Fix Version/s representa onde ele será corrigido.

• Ao abrir um bug encontrado em produção: Affects Version/s = 2025.12 (ou a versão em produção).
• Ao planejar correção: Fix Version/s = 2026.01.1 (hotfix) ou 2026.02 (se não for urgente).

Separando validações por build, sprint e release

Separação por release (macro)

Use Fix Version/s como agrupador principal. Isso permite responder rapidamente:

• “O que faz parte da release 2026.01?”
• “O que ainda não foi testado dessa release?”
• “Quais bugs estão previstos para corrigir antes de fechar?”

Separação por sprint (cadência do time)

Use o campo Sprint para recortar o escopo da release por iteração. Exemplo de uso:

• Release: 2026.01
• Sprints: Sprint 12, Sprint 13

Assim, QA consegue priorizar o que “acabou de cair” na sprint atual sem perder o contexto da release.

Separação por build (execução e evidência)

Dentro da mesma Fix Version/s, podem existir múltiplos builds. Para evitar que um “reteste” seja confundido com “teste inicial”, adote uma destas práticas:

• Campo Build (se existir): preencher em bugs e/ou tarefas de validação com o build onde foi observado/testado.
• Label de build: aplicar build-145 em bugs encontrados naquele build.
• Subtarefas de validação por build: criar subtarefas do tipo “Validação QA” com o build no resumo, por exemplo: [QA] Validar Checkout - build 145. (Útil quando o mesmo item precisa de validações repetidas em builds diferentes.)

Como lidar com hotfixes sem bagunçar a rastreabilidade

Cenário típico

Um bug crítico aparece em produção (versão 2026.01). O time vai corrigir e liberar um patch 2026.01.1. Ao mesmo tempo, a próxima release 2026.02 está em andamento.

Regras práticas (recomendadas)

• No bug: Affects Version/s = 2026.01.
• Se for corrigido via hotfix: Fix Version/s = 2026.01.1.
• Se a correção também precisa entrar na próxima release (para não “regredir”): mantenha a mesma issue com uma Fix Version (hotfix) e garanta que o merge/backport esteja rastreado por link (ex.: issue técnica de backport) ou por uma issue espelho, conforme prática do time. Evite múltiplas Fix Versions no mesmo bug se isso confundir relatórios.
• Crie uma versão específica para hotfix (patch) no Jira e trate-a como release com critérios de QA próprios (mais enxutos, porém rigorosos em risco).

Checklist operacional para QA em hotfix

• Confirmar Affects Version/s (onde reproduz).
• Confirmar Fix Version/s (para qual patch vai).
• Definir escopo mínimo de regressão por componente afetado (ex.: se o componente é Checkout, validar fluxo feliz + 1 cenário de falha + integrações críticas).
• Marcar claramente o build/ambiente testado (campo/label de build).

Filtros salvos (JQL) para acompanhar pronto para teste, reprovado e bloqueado

Os exemplos abaixo assumem que você usa status como To Do, In Progress, Ready for QA, In QA, Failed QA, Blocked, Done. Ajuste os nomes para o seu fluxo real.

1) “Pronto para teste por versão”

Objetivo: listar itens que entraram no funil de QA para uma Fix Version específica.

project = ABC AND fixVersion = "2026.01" AND status = "Ready for QA" ORDER BY priority DESC, updated DESC

Variação (inclui o que já está em teste):

project = ABC AND fixVersion = "2026.01" AND status in ("Ready for QA", "In QA") ORDER BY priority DESC, updated DESC

2) “Reprovou em QA por versão”

project = ABC AND fixVersion = "2026.01" AND status = "Failed QA" ORDER BY updated DESC

Dica: se seu fluxo usa um status equivalente (ex.: “Reopened”, “QA Failed”), padronize um único status para facilitar relatórios.

3) “Bloqueados por versão”

project = ABC AND fixVersion = "2026.01" AND status = "Blocked" ORDER BY updated DESC

Variação (bloqueados em QA):

project = ABC AND fixVersion = "2026.01" AND status in ("Ready for QA", "In QA", "Blocked") AND flag is not EMPTY

Observação: o campo flag pode não existir/estar disponível em todos os projetos. Use apenas se fizer parte do seu Jira.

4) “Bugs encontrados em produção (por Affects Version)”

project = ABC AND issuetype = Bug AND affectedVersion = "2026.01" ORDER BY created DESC

5) “Hotfix em andamento (patch)”

project = ABC AND fixVersion = "2026.01.1" AND status not in (Done) ORDER BY priority DESC

Como salvar e padronizar filtros

• Monte a busca avançada (JQL) na tela de Issues.
• Clique em Save as (Salvar como) e use um nome padronizado, por exemplo: [QA] Ready for QA - 2026.01.
• Compartilhe com o time/um grupo (ex.: qa-team) para evitar filtros duplicados.
• Crie uma variação “template” usando apenas fixVersion = latestReleasedVersion() ou unreleasedVersions() se sua instância suportar essas funções; caso não suporte, mantenha filtros por versão e revise a cada ciclo.

Dashboards simples para acompanhamento por versão

Um dashboard de QA por release deve responder três perguntas em poucos segundos: (1) o que está pronto para testar, (2) o que reprovou, (3) o que está bloqueado.

Widgets recomendados (mínimo viável)

• Filter Results: para listar “Ready for QA” da versão.
• Pie Chart: distribuição por status (para a Fix Version).
• Two Dimensional Filter Statistics: status x componente (para ver gargalos por área).
• Created vs Resolved Chart (opcional): para bugs da Fix Version (tendência de estabilização).

Passo a passo: montar um dashboard por release

• Crie (ou reutilize) filtros salvos para a versão alvo: pronto para QA, reprovado, bloqueado, bugs da versão.
• Crie um dashboard chamado, por exemplo: [QA] Release 2026.01.
• Adicione gadgets:

Filtro base da versão (para gráficos):

project = ABC AND fixVersion = "2026.01"

Critérios de QA para fechar uma release (Definition of Done de Release)

Fechar uma release no Jira (marcar como released) deve refletir que, do ponto de vista de QA, o escopo está validado e o risco residual está aceito. Defina critérios objetivos e verificáveis.

Critérios recomendados (ajuste ao seu contexto)

• Escopo controlado: todas as issues com Fix Version/s = 2026.01 estão em status final acordado (ex.: Done/Closed) ou explicitamente removidas do escopo (mudança de Fix Version para próxima release).
• Sem pendências críticas: não existem bugs abertos de severidade crítica/alta com Fix Version/s = 2026.01.
• Reprovados tratados: itens em Failed QA foram corrigidos e revalidados (ou tiveram decisão formal de risco/aceite, registrada na issue).
• Bloqueios resolvidos: nada permanece em Blocked dentro do escopo da release; se existir bloqueio externo, a issue deve ser movida para outra Fix Version ou removida do escopo.
• Rastreabilidade por versão: bugs relevantes têm Affects Version/s preenchido (principalmente os encontrados em produção) e Fix Version/s coerente.
• Regressão mínima executada: para os componentes alterados na release, existe evidência de execução do conjunto mínimo de regressão acordado (por componente/risco).

Consultas rápidas para “gate” de fechamento

1) Itens da release ainda não finalizados

project = ABC AND fixVersion = "2026.01" AND status not in (Done, Closed)

2) Bugs críticos/altos ainda abertos na release

project = ABC AND fixVersion = "2026.01" AND issuetype = Bug AND priority in (Highest, High) AND status not in (Done, Closed)

3) Itens bloqueados

project = ABC AND fixVersion = "2026.01" AND status = "Blocked"

Boas práticas de governança para manter a organização funcionando

• Fix Version/s não é opcional: trate como campo obrigatório no processo (nem que seja por checklist de refinamento).
• Uma issue, uma entrega: se a mesma issue “vai em duas versões”, normalmente há falta de fatiamento; prefira dividir.
• Componentes com dono: cada componente deve ter responsável (time/pessoa) para triagem e suporte a QA.
• Hotfix é uma release: crie a versão patch no Jira e use filtros/dashboards próprios; não misture com a release principal.
• Revisão semanal de versões: QA e PO/PM revisam issues com Fix Version da release para remover o que não será entregue e evitar “escopo fantasma” no fechamento.