Tipos de Issues no Jira aplicados à Gestão de Testes

Como os tipos de issues ajudam a organizar o trabalho de QA

Em gestão de testes, os tipos de issues no Jira funcionam como “caixas” com propósito e regras diferentes. Quando você escolhe o tipo correto, fica mais fácil: separar planejamento de execução, rastrear o que foi testado, registrar defeitos com qualidade, medir progresso e evitar que QA vire um conjunto de comentários soltos em uma Story.

A ideia prática é: cada tipo de issue representa uma intenção (entregar funcionalidade, executar teste, registrar bug, tratar risco, etc.). Isso reduz ambiguidade e melhora a rastreabilidade entre requisito → teste → evidência → bug → correção → reteste.

Tipos de issues mais usados em QA e quando usar cada um

Story / Task (trabalho de produto ou entrega)

Quando usar: para descrever uma necessidade de negócio (Story) ou um trabalho entregável (Task). QA usa esse item como “âncora” de rastreabilidade: os testes e bugs devem apontar para a Story/Task correspondente.

• Story: foco em valor para usuário (ex.: “Como cliente, quero recuperar minha senha…”).
• Task: foco em atividade (ex.: “Atualizar endpoint de autenticação”).

Como QA se conecta: crie/associe issues de teste (ou sub-tasks de QA) vinculadas à Story/Task e registre evidências de execução nelas (ou em anexos/links).

Sub-task de QA (planejamento e execução dentro da entrega)

Quando usar: quando o time quer que o trabalho de QA esteja explicitamente dentro do escopo da Story/Task, com visibilidade no board e no burndown. É útil para:

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

• Planejar abordagem de testes (escopo, riscos, tipos de teste).
• Executar testes exploratórios e de regressão relacionados à entrega.
• Garantir que “Done” da Story inclua a etapa de QA.

Boa prática: usar sub-task de QA para atividades (ex.: “Executar testes de integração da Story X”), e usar issue de “Teste” (quando existir) para casos de teste mais formais e reutilizáveis.

Teste (issue type específico, se existir no seu Jira)

Quando usar: quando existe um tipo de issue dedicado a testes (muito comum em projetos com plugins/apps de test management ou configurações internas). Esse tipo deve representar um caso de teste (ou um conjunto pequeno e bem definido), com passos, dados, pré-condições e resultado esperado.

• Use para: testes repetíveis, regressão, critérios de aceite que precisam de verificação consistente, cenários críticos.
• Evite usar para: tarefas genéricas (“testar tudo”), ou para registrar execução pontual sem estrutura.

Rastreabilidade recomendada: Teste → link para Story/Task (requisito) e, quando falhar, link para Bug (defeito).

Bug (defeito)

Quando usar: sempre que houver divergência entre comportamento esperado e observado. Bug não é “pendência” nem “melhoria desejável”; é falha verificável.

• Bug deve ser reprodutível (passos claros) e ter evidência.
• Bug deve apontar para a Story/Task relacionada (origem do requisito) e/ou para o Teste que falhou.

Separação importante: se a mudança é uma evolução (não estava especificado), registre como melhoria técnica ou nova Story/Task, não como Bug.

Melhoria técnica (Technical improvement / Tech debt)

Quando usar: para itens que melhoram qualidade, testabilidade, observabilidade, automação, estabilidade ou manutenção, sem necessariamente corrigir um defeito funcional específico.

• Ex.: “Adicionar logs de auditoria para rastrear falhas de autenticação”.
• Ex.: “Criar dados de teste seed para ambiente de homologação”.
• Ex.: “Automatizar regressão do fluxo de checkout”.

Como QA contribui: abrir melhorias técnicas quando o gargalo é estrutural (ambiente instável, falta de dados, ausência de feature flags, baixa observabilidade), e não um bug pontual.

Risco / Impedimento (Risk / Blocker / Impediment)

Quando usar: quando algo ameaça prazo, escopo, qualidade ou capacidade de testar, e precisa de acompanhamento explícito.

• Ex.: “Ambiente de homologação indisponível há 2 dias”.
• Ex.: “Dependência do fornecedor X sem SLA para correção”.
• Ex.: “Critérios de aceite incompletos impedem definição de testes”.

Boa prática: risco/impedimento deve ter: impacto, probabilidade (se risco), plano de mitigação, responsável e data-alvo. Se o risco se concretizar e gerar defeito, aí sim vira Bug (ou uma Story/Task de ajuste).

Padronização de títulos, descrições e critérios de aceite voltados a testes

Padrão de títulos (clareza e busca)

Um bom título permite entender o que é, onde ocorre e qual o impacto, sem abrir a issue. Padronize por tipo:

• Story/Task: [Módulo] Ação/Objetivo (ex.: [Login] Recuperação de senha por e-mail).
• Sub-task QA: [QA] O que será validado + referência (ex.: [QA] Validar critérios de aceite da recuperação de senha).
• Teste: [TC] Cenário + condição (ex.: [TC] Recuperar senha com e-mail cadastrado).
• Bug: [Bug][Módulo] Comportamento observado (impacto) (ex.: [Bug][Checkout] Cupom aplicado zera frete indevidamente).
• Melhoria técnica: [Tech] Objetivo técnico (ex.: [Tech] Criar massa de dados padrão para testes de pagamento).
• Risco/Impedimento: [Blocker] Motivo e área (ex.: [Blocker] Homologação fora do ar impede testes de login).

Descrição: o que não pode faltar para QA

Padronize descrições com seções fixas. Isso reduz retrabalho e acelera triagem. Para itens que impactam testes (Story/Task), inclua:

• Contexto funcional: o que muda e por quê.
• Escopo: o que está dentro e fora.
• Critérios de aceite testáveis: em formato verificável.
• Regras de negócio: validações, limites, mensagens.
• Dependências: APIs, serviços, feature flags, permissões.
• Observabilidade: logs, eventos, rastreio (quando relevante).

Critérios de aceite testáveis (como escrever)

Critério de aceite bom é aquele que vira teste sem interpretação. Prefira formato objetivo, com condições e resultado esperado. Exemplos:

• Fraco: “Sistema deve ser rápido.”
• Melhor: “Ao solicitar recuperação de senha, o e-mail deve ser enviado em até 30s e a UI deve exibir mensagem de confirmação sem revelar se o e-mail existe.”

Checklist para critérios de aceite:

• Tem condição inicial (dado/estado)?
• Tem ação do usuário/sistema?
• Tem resultado esperado observável?
• Tem regras de erro e mensagens?
• Considera permissões, limites e casos negativos?

Passo a passo: como escolher o tipo de issue na prática

1) Comece pela origem: existe uma Story/Task?

• Se é entrega de funcionalidade ou mudança planejada: registre/garanta a Story/Task.
• Se você está testando algo sem item de origem: crie uma Task/Story mínima ou registre um risco de rastreabilidade (ver anti-padrões).

2) Defina como QA será representado

• Se o time quer visibilidade do trabalho de QA no board: crie Sub-task de QA na Story/Task.
• Se o projeto usa issue type Teste: crie os testes como issues e vincule à Story/Task.
• Se não existe issue “Teste”: use sub-tasks de QA para execução e registre casos de teste no corpo da issue (com template) ou em artefato linkado (mantendo rastreabilidade).

3) Durante a execução, o que você encontrou?

• Falha verificável: abra Bug e vincule ao Teste e à Story/Task.
• Necessidade de melhoria (não é falha do requisito): abra Melhoria técnica ou proponha nova Story/Task.
• Bloqueio para testar (ambiente/dados/acesso): abra Risco/Impedimento e vincule à Story/Task.

4) Garanta links mínimos de rastreabilidade

Padronize como regra operacional:

• Teste deve estar vinculado a uma Story/Task.
• Bug deve estar vinculado a um Teste (quando existir) e a uma Story/Task.
• Sub-task de QA deve estar dentro da Story/Task.
• Risco/Impedimento deve apontar para a Story/Task impactada.

Templates prontos (copiar e colar) para padronização

Template de issue de Teste (caso de teste)

Use este modelo no tipo “Teste” (ou em uma sub-task de QA quando não houver issue type específico). O objetivo é permitir execução repetível e evidência auditável.

Seção 1 — Objetivo do teste (obrigatório)  - O que este teste valida e por que é importante.  Seção 2 — Rastreabilidade (obrigatório)  - Issue(s) relacionada(s): PROJ-123 (Story/Task)  - Requisito/critério de aceite coberto: AC-02, AC-05  Seção 3 — Pré-condições (obrigatório)  - Usuário com perfil: [ex.: Admin]  - Feature flag: [on/off]  - Estado do sistema: [ex.: carrinho com 1 item]  Seção 4 — Dados de teste (obrigatório)  - Conta: email=..., senha=...  - Produto/SKU: ...  - Cartão (se aplicável): ...  Seção 5 — Ambiente (obrigatório)  - Ambiente: [DEV/HML/PRD]  - Build/versão: ...  - Navegador/app: ...  - Dispositivo/OS: ...  Seção 6 — Passos (obrigatório)  1) ...  2) ...  3) ...  Seção 7 — Resultado esperado (obrigatório)  - ...  Seção 8 — Evidências (obrigatório)  - Anexos: prints, vídeo, logs  - Links: request/response, trace, dashboard  Seção 9 — Observações (opcional)  - Notas de execução, variações, cobertura adicional

Dica de padronização: numere os passos e escreva resultados esperados observáveis (mensagem na tela, status code, registro em log, alteração em banco quando aplicável).

Template de issue de Bug (defeito)

O objetivo do bug é permitir reprodução rápida, triagem correta e validação do fix.

Seção 1 — Resumo (obrigatório)  - O que acontece + impacto (ex.: “Cupom FRETEGRATIS zera frete para região não elegível”)  Seção 2 — Ambiente (obrigatório)  - Ambiente: [DEV/HML/PRD]  - Build/versão: ...  - Navegador/app: ...  - Dispositivo/OS: ...  Seção 3 — Pré-condições (obrigatório)  - Usuário/perfil: ...  - Feature flag: ...  - Estado inicial: ...  Seção 4 — Passos para reproduzir (obrigatório)  1) ...  2) ...  3) ...  Seção 5 — Resultado atual (obrigatório)  - O que ocorreu (inclua mensagens, códigos, prints)  Seção 6 — Resultado esperado (obrigatório)  - O que deveria ocorrer (referencie AC/regra)  Seção 7 — Evidências (obrigatório)  - Print/vídeo  - Logs/console  - Request/response (se API)  Seção 8 — Impacto e severidade (obrigatório)  - Severidade: Blocker/Critical/Major/Minor  - Impacto: financeiro, segurança, UX, compliance, etc.  Seção 9 — Rastreabilidade (obrigatório)  - Relacionado a: PROJ-123 (Story/Task)  - Teste que falhou: TEST-45 (se existir)  Seção 10 — Notas para reteste (opcional)  - Cenários afetados, regressão sugerida

Anti-padrões comuns e como corrigir

Anti-padrão 1: Bug sem passos de reprodução

Exemplo ruim: “Não funciona o login.”

Por que é um problema: aumenta tempo de triagem, gera ping-pong e pode virar “não reproduz”.

Como corrigir: exigir no mínimo: ambiente, pré-condições, passos, resultado atual/esperado e evidência.

• Passos: “1) Acessar /login 2) Informar usuário X 3) Clicar Entrar”.
• Evidência: print + log/console + status code (se aplicável).

Anti-padrão 2: Teste sem vínculo com Story/Task

Exemplo ruim: issue “Teste do checkout” criada solta no backlog.

Por que é um problema: perde rastreabilidade (não dá para provar o que foi validado para qual entrega) e dificulta priorização.

Como corrigir: vincular o teste à Story/Task correspondente e referenciar critérios de aceite cobertos. Se não existe Story/Task, criar uma Task mínima de rastreio (ou registrar risco de rastreabilidade) e relacionar.

Anti-padrão 3: Sub-task de QA usada como “caixa de tudo”

Exemplo ruim: sub-task “Testar” com descrição “testes ok”.

Por que é um problema: não há evidência, não há cobertura explícita, não há repetibilidade.

Como corrigir: usar o template de teste dentro da sub-task (ou criar issues de Teste) e anexar evidências. Se a sub-task for apenas “execução”, referenciar a lista de testes executados (IDs) e resultados.

Anti-padrão 4: Bug usado para pedir melhoria

Exemplo ruim: “Bug: melhorar mensagem de erro para ficar mais bonita.”

Por que é um problema: distorce métricas de qualidade e priorização; mistura defeito com evolução.

Como corrigir: se o comportamento atual está conforme especificado, registre como melhoria técnica ou nova Story/Task. Se há divergência com critério de aceite/regra, aí sim é Bug.

Anti-padrão 5: Critérios de aceite não testáveis

Exemplo ruim: “Tela deve ser intuitiva.”

Como corrigir: transformar em critérios verificáveis, por exemplo: “Usuário deve concluir cadastro em até X passos; campos obrigatórios devem exibir mensagem Y; validação de e-mail deve bloquear formato inválido.”

Exemplos práticos de organização (cenários)

Cenário A: Nova funcionalidade com testes formais

• Story: [Login] Recuperação de senha por e-mail
• Testes (issues): [TC] Recuperar senha com e-mail cadastrado, [TC] Recuperar senha com e-mail não cadastrado (não revelar existência), [TC] Token expirado
• Se falhar: abrir Bug vinculado ao TC e à Story.

Cenário B: Execução de QA como sub-task

• Task: [Checkout] Ajustar cálculo de frete
• Sub-task QA: [QA] Validar cálculo de frete (casos positivos e negativos) com template de teste no corpo e evidências anexas.
• Impedimento: se não há dados de CEP válidos no ambiente, abrir [Blocker] Falta massa de dados de CEP para validar frete.

Cenário C: Problema estrutural que afeta testes

• Melhoria técnica: [Tech] Criar endpoint para resetar estado de carrinho em HML
• Motivo: reduz tempo de preparação de testes e aumenta repetibilidade.