Fluxos de Trabalho de Testes no Jira: Status, Transições e Responsabilidades

O que é um fluxo de trabalho de testes (QA) no Jira

Um fluxo de trabalho de testes no Jira é a sequência de status e transições que uma issue (por exemplo, um item de teste, uma história pronta para validação, ou um bug encontrado em teste) percorre até estar apta para release. A utilidade prática do fluxo é padronizar: quando o QA começa a testar, o que precisa estar pronto para isso, quem age em cada etapa e como registrar evidências, bloqueios e dependências para manter rastreabilidade.

Um bom fluxo de QA no Jira precisa ser: observável (status refletem a realidade), objetivo (critérios claros de entrada/saída), responsável (papéis definidos) e anti-gargalo (regras para evitar ciclos infinitos e filas invisíveis).

Status práticos e o papel de cada um

A seguir, um conjunto de status recomendado para um fluxo de testes. Você pode aplicar em issues de validação (ex.: “História X pronta para QA”) ou em um item de teste agregador (ex.: “Validação da feature Y”).

Critérios de entrada e saída por status (definição objetiva)

Para evitar ambiguidade, defina critérios de entrada/saída como uma “Definition of Ready/Done” específica para QA. Abaixo um modelo prático que você pode adaptar.

1) Pronto para Teste

Entrada (para mover para Pronto para Teste):

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

• Implementação concluída e integrada no ambiente alvo (ex.: homolog/staging).
• Build/versão informada em campo ou comentário (ex.: Build: 1.8.3).
• Critérios de aceite descritos e compreensíveis (no corpo da issue ou anexos).
• Dados de teste, credenciais e acessos disponíveis (ou instruções claras).
• Dependências mapeadas (links para issues relacionadas).

Saída (para iniciar Em Teste):

• QA confirma que os pré-requisitos estão atendidos (check rápido de sanidade).
• Ambiente está estável o suficiente para execução (sem incidentes impeditivos).

Responsabilidades: Dev garante entrega e informações técnicas; QA valida se está realmente pronto; PO esclarece dúvidas de regra de negócio quando necessário.

2) Em Teste

Entrada:

• Item em Pronto para Teste e QA com capacidade disponível.
• Plano mínimo de teste definido (mesmo que simples: cenários principais + bordas críticas).

Saída:

• Se falhar: mover para Reprovado (com evidência e passos).
• Se impedido: mover para Bloqueado (com causa e dependência).
• Se passar: mover para Aprovado (com evidências e escopo testado).

Responsabilidades: QA executa, registra evidências e abre bugs quando aplicável; Dev apoia em dúvidas técnicas; PO apoia em dúvidas de regra.

3) Bloqueado

Entrada:

• Existe impedimento externo ao QA que impossibilita continuar (ambiente fora, falta de permissão, dependência não entregue, massa de dados inexistente, instabilidade).

Saída:

• Impedimento removido e evidência registrada (ex.: comentário com confirmação, link da issue resolvida, print do acesso liberado).
• Retornar para Em Teste (se ainda no ciclo principal) ou Re-teste (se já era correção).

Responsabilidades: QA registra bloqueio com clareza; Dev/PO atuam para remover impedimento conforme natureza (técnica vs negócio/prioridade).

4) Reprovado

Entrada:

• Falha reproduzível e confirmada (não é dúvida de requisito).
• Evidência mínima anexada (print, vídeo, logs) e passos para reproduzir.

Saída:

• Dev corrige e atualiza a issue com referência da correção (PR, commit, versão) e move para Re-teste (ou devolve para Pronto para Teste, se o time preferir um único ponto de entrada).

Responsabilidades: QA define reprovação e qualidade do reporte; Dev corrige; PO decide prioridade se houver trade-off.

5) Re-teste

Entrada:

• Correção entregue e identificada (build/versão).
• Escopo do re-teste definido: “o que corrigiu” + “o que pode ter sido impactado”.

Saída:

• Se passou: Aprovado.
• Se falhou novamente: Reprovado (com atualização de evidência e observação do que mudou).
• Se impedido: Bloqueado.

Responsabilidades: QA valida correção e registra resultado; Dev dá suporte rápido para dúvidas e ajustes.

6) Aprovado

Entrada:

• Testes executados conforme escopo acordado e sem falhas abertas impeditivas.
• Evidências anexadas/registradas e rastreáveis.

Saída:

• Quando alinhado para entrega: Pronto para Release.
• Se surgir regressão antes do release: voltar para Em Teste ou Re-teste (com justificativa).

Responsabilidades: QA aprova tecnicamente; PO pode validar aceite de negócio (especialmente em funcionalidades críticas).

7) Pronto para Release

Entrada:

• Item aprovado e dependências de release resolvidas (ex.: feature flag, documentação mínima, checklist de implantação se aplicável).

Saída:

• Segue para o processo do time (deploy, janela de release, change management).

Responsabilidades: PO/Release Manager/DevOps organizam a entrega; QA apoia se houver validação pós-deploy (quando aplicável).

Como desenhar o workflow no Jira (passo a passo prático)

O objetivo aqui é transformar os status acima em um fluxo com transições claras e poucas “rotas alternativas” que geram confusão.

Passo 1: Desenhe o fluxo em forma de mapa

Antes de configurar ou formalizar, desenhe o caminho principal e as exceções:

Pronto para Teste → Em Teste → (Aprovado → Pronto para Release)  ou  (Reprovado → Re-teste → Aprovado)  ou  (Bloqueado → Em Teste/Re-teste)

Regras simples ajudam: Bloqueado não é “pausa” genérica; é impedimento real. Re-teste existe para separar “testar do zero” de “validar correção”.

Passo 2: Defina transições permitidas (e proíba as que causam ruído)

Exemplo de transições recomendadas:

• Pronto para Teste → Em Teste
• Em Teste → Aprovado
• Em Teste → Reprovado
• Em Teste → Bloqueado
• Bloqueado → Em Teste (se ainda não houve reprovação)
• Reprovado → Re-teste (após correção)
• Re-teste → Aprovado / Re-teste → Reprovado / Re-teste → Bloqueado
• Aprovado → Pronto para Release

Evite transições como Reprovado → Aprovado (pula re-teste) e Bloqueado → Aprovado (não faz sentido). Se precisar de exceção, exija justificativa em comentário.

Passo 3: Amarre critérios com “checklist” operacional

Mesmo sem entrar em detalhes de configuração, você pode padronizar o uso com um checklist no corpo da issue ou comentário fixo. Exemplo para “Pronto para Teste”:

• Build/versão informada
• Ambiente e URL informados
• Credenciais/dados de teste disponíveis
• Critérios de aceite revisados
• Dependências linkadas

Isso reduz discussões e evita que QA receba itens incompletos.

Passo 4: Defina “quem move” cada status

Uma regra prática para evitar ping-pong:

• Dev move para Pronto para Teste quando entrega e preenche informações mínimas.
• QA move para Em Teste, e decide entre Aprovado/Reprovado/Bloqueado.
• Dev move de Reprovado para Re-teste quando corrigiu e informou versão.
• PO (ou responsável de release) move para Pronto para Release quando o item aprovado entra no pacote.

Se o time preferir, QA pode mover para Pronto para Release após aprovação, mas isso deve ser consistente e combinado para não gerar divergência de responsabilidade.

Como registrar bloqueios e dependências (comentários, links e campos)

1) Bloqueios: como escrever um comentário útil

Ao mover para Bloqueado, registre um comentário padronizado. Modelo:

[BLOQUEIO] Não é possível continuar o teste do cenário X. Motivo: ambiente staging instável (erro 502 ao acessar /checkout). Impacto: impede validar critérios A e B. Evidência: print/log anexado. Dependência: resolver incidente/issue ABC-123. Próximo passo: retomar Em Teste após confirmação de estabilidade.

Isso evita bloqueios “mudos” e acelera a remoção do impedimento.

2) Dependências: use links para rastreabilidade

Quando um teste depende de outra entrega, crie links entre issues para que o Jira mostre a relação. Boas práticas:

• Link do tipo “blocks/is blocked by” para dependências reais (ex.: “Esta validação está bloqueada pela entrega da API”).
• Link do tipo “relates to” para contexto (ex.: documentação, tarefa de dados de teste).
• Ao citar uma issue em comentário, use a chave (ex.: ABC-123) para criar referência clicável.

3) Campos: padronize o mínimo para não virar burocracia

Mesmo com poucos campos, dá para manter rastreabilidade de QA. Um conjunto mínimo operacional:

• Ambiente (staging/homolog/dev)
• Versão/Build
• Severidade (para bugs)
• Componente/Módulo (para roteamento)
• Resultado do teste (quando aplicável)

Quando o time não tiver campos específicos, registre no comentário com padrão consistente (ex.: Ambiente:, Build:).

Como adaptar o fluxo para Scrum e Kanban

Scrum: alinhando com Sprint e Definition of Done

No Scrum, o risco comum é “terminar desenvolvimento” perto do fim da sprint e empurrar QA para o último dia. Para reduzir isso:

• Combine que itens só entram como Pronto para Teste quando atendem critérios mínimos (ambiente, build, dados).
• Trate Aprovado como parte do “Done” do time (se essa for a regra do produto). Se não for, explicite que “Done” é dev-done e QA fica como etapa posterior — mas isso deve ser visível no board.
• Use Re-teste para não misturar correção com execução inicial, facilitando medir retrabalho dentro da sprint.

Kanban: controlando WIP e evitando filas invisíveis

No Kanban, o fluxo precisa evidenciar gargalos e limitar trabalho em andamento:

• Defina limites de WIP para Em Teste e Re-teste (ex.: QA só puxa 2 itens por vez).
• Crie uma política clara: itens em Pronto para Teste são “fila” e devem ter prioridade definida (por PO/triagem).
• Use Bloqueado como sinal de impedimento: se crescer, é alerta de problema sistêmico (ambiente, dependências, acesso).

Se o board do time não tiver coluna específica para cada status, mantenha os status no workflow e use swimlanes ou filtros por status para visualização operacional.

Como evitar gargalos e o “re-teste infinito” com regras objetivas

1) Regra de limite de ciclos de re-teste

Defina uma política simples, por exemplo:

• Após 2 ciclos de Reprovado → Re-teste → Reprovado no mesmo item, exigir: análise rápida de causa (ex.: falta de critério, bug intermitente, ambiente) e replanejamento com Dev/PO.
• Registrar no comentário: o que falhou, o que foi tentado, e qual decisão foi tomada (ajustar requisito, criar tarefa técnica, dividir escopo).

2) Regra de “pronto para teste” não negociável

Se QA aceita itens incompletos, o fluxo vira fila de bloqueios. Política recomendada:

• Se faltar informação essencial (ambiente/build/dados/critério), o item não entra em Em Teste; permanece em Pronto para Teste com comentário do que falta, ou retorna para o status anterior do time (se existir).

3) Regra de bloqueio com dono e prazo

Bloqueio sem dono vira esquecimento. Ao bloquear:

• Indique um dono (Dev/PO/time de infra) no comentário e/ou menção.
• Registre um prazo esperado (mesmo que estimado) e reavalie diariamente.

4) Regra de escopo do re-teste

Para não virar “testar tudo de novo”:

• Em cada passagem para Re-teste, Dev descreve o que mudou e onde pode impactar.
• QA registra o escopo do re-teste (cenários afetados + regressão mínima).

Exemplo completo de uso do fluxo (cenário prático)

Cenário: validação de uma melhoria no checkout

• Dev → Pronto para Teste: informa Build 2.4.0, URL do staging, credenciais, e linka dependência API-321 como “is blocked by”.
• QA verifica dependência: API-321 ainda não entregue. Move para Bloqueado e comenta usando o modelo (motivo, impacto, evidência, dependência).
• Quando API-321 é resolvida, QA retorna para Em Teste e executa cenários principais.
• QA encontra falha no cálculo de frete: move para Reprovado e registra passos + evidência; abre bug relacionado e linka como “relates to” ou “blocks” (conforme política do time).
• Dev corrige e move para Re-teste, informando a nova versão Build 2.4.1 e descrevendo a alteração.
• QA re-testa o cálculo e faz regressão mínima (carrinho, cupom, pagamento). Passa: move para Aprovado e anexa evidências.
• PO/Release move para Pronto para Release quando o item entra no pacote da próxima implantação.