Configuração do Jira para Gestão de Testes em QA

Objetivo da configuração para QA no Jira

Para que a gestão de testes funcione no Jira (registrar bugs, evidências, vincular com requisitos e acompanhar status), o ambiente precisa estar preparado com: (1) um projeto adequado ao time, (2) permissões mínimas para o trabalho diário, (3) campos que capturem contexto técnico e reprodutibilidade, e (4) um fluxo simples que permita rastreabilidade entre demanda → teste → defeito.

Entendendo o tipo de projeto: company-managed vs team-managed

Company-managed (gerenciado pela empresa)

• Quando é comum: organizações com governança central, padronização de workflows, telas e campos.

• Impacto para QA iniciante: você geralmente não configura o projeto; solicita ajustes ao administrador. Em compensação, costuma ter mais recursos de padronização (campos globais, esquemas de telas, permissões detalhadas).

• O que observar: tipos de issue disponíveis (Bug, Task, Story, Test), telas de criação/edição (quais campos aparecem) e regras de transição (quais status existem e quem pode mover).

Team-managed (gerenciado pelo time)

• Quando é comum: times menores, autonomia para ajustar campos e status sem depender tanto do admin.

  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

• Impacto para QA iniciante: você pode conseguir ajustar campos e algumas configurações diretamente (dependendo do papel no projeto).

• O que observar: se você tem acesso às configurações do projeto (Project settings) e se consegue adicionar campos às telas.

Como identificar rapidamente qual é o tipo do projeto

• No menu do projeto, procure Project settings. Em muitos ambientes, projetos team-managed exibem configurações mais “simples” e orientadas ao time; company-managed costumam ter seções como Permissions, Screens, Workflows (ou acesso restrito).

• Se você não consegue ver configurações ou recebe mensagem de permissão, trate como company-managed do ponto de vista prático: você vai precisar alinhar com o admin.

Permissões essenciais para o fluxo de QA (o mínimo para trabalhar)

Sem essas permissões, o QA fica impedido de registrar evidências, atualizar status e manter rastreabilidade. Valide com alguém do time ou com o admin se você possui:

• Criar issues (Create issues): para abrir Bug e/ou registrar itens de teste quando aplicável.

• Editar issues (Edit issues): para completar campos, ajustar severidade, atualizar versão/build, etc.

• Transicionar issues (Transition issues): para mover status (ex.: To Do → In Progress → Done; ou Bug: Open → In Analysis → Fix in Progress → Ready for Retest → Done).

• Comentar (Add comments): para registrar análise, dúvidas, alinhamentos e decisões.

• Anexar arquivos (Create attachments): para evidências (prints, vídeos, logs).

• Ver issues (Browse projects / View issues): básico para acessar o backlog e os bugs.

• Vincular issues (Link issues): para conectar Bug ↔ Story/Task/Requirement e manter rastreabilidade.

• Ver/editar watchers (opcional, mas útil): para notificar pessoas-chave (dev, PO, suporte).

Passo a passo: como validar suas permissões na prática (sem acesso de admin)

• Teste de criação: tente criar um Bug no projeto. Se o botão de criar não permitir selecionar o projeto ou o tipo de issue, pode ser permissão.

• Teste de edição: abra uma issue existente e tente editar um campo (ex.: Environment). Se o lápis/edição não aparecer, falta permissão de edição ou o campo não está na tela.

• Teste de transição: tente mover o status. Se o botão de transição não aparecer ou der erro, pode ser permissão ou condição no workflow.

• Teste de anexos: tente anexar um print. Se não houver opção de anexar, falta permissão ou está bloqueado por política.

• Teste de link: procure por “Link issue” e tente vincular a uma Story. Se não existir, pode ser permissão ou configuração.

Campos recomendados para QA: obrigatórios vs opcionais

Campos bem definidos reduzem retrabalho e aumentam a chance de um bug ser reproduzido e corrigido rapidamente. A ideia é equilibrar: obrigatório o suficiente para garantir contexto, mas não tão pesado que desestimule o registro.

Campos essenciais (recomendado tornar obrigatórios para Bug)

• Resumo (Summary): título curto e específico. Ex.: Checkout falha ao aplicar cupom com frete grátis.

• Descrição (Description) com estrutura de QA: passos, esperado, obtido.

• Ambiente (Environment): onde ocorreu (ex.: Staging, Homolog, Produção). Se possível, padronize como lista.

• Versão/Build: número da versão do app/web ou build do pipeline. Ex.: v2.18.0 (build 4512).

• Severidade (impacto técnico/negócio) e/ou Prioridade (ordem de atendimento). Se o time usa ambos, defina claramente o uso.

• Componente (ou módulo): para direcionar ao time certo. Ex.: Pagamentos, Login, Catálogo.

Campos úteis (opcionais, mas altamente recomendados)

• Dispositivo/Browser/OS: especialmente para apps e web. Ex.: iPhone 13 iOS 17, Chrome 121.

• Conta/Perfil de usuário: tipo de usuário (admin, cliente, vendedor) ou massa de teste.

• Regressão? (checkbox): indica se é bug reintroduzido.

• Intermitente? (checkbox): ajuda a priorizar investigação.

• Epic/Story vinculada: para rastrear origem.

• Labels: tags rápidas (ex.: payment, ui, api), com cuidado para não virar “bagunça”.

Modelo prático de descrição para Bug (copiar e colar)

Contexto: (o que você estava tentando fazer e por quê)\n\nPré-condições: (login feito? feature flag? dados existentes?)\n\nPassos para reproduzir:\n1) ...\n2) ...\n3) ...\n\nResultado esperado:\n- ...\n\nResultado obtido:\n- ...\n\nEvidências:\n- print/vídeo/log anexado (referenciar)\n\nAmbiente/Build:\n- Ambiente: ...\n- Versão/Build: ...\n- Browser/OS/Dispositivo: ...

Mesmo que o Jira tenha campos separados, esse modelo ajuda quando o time ainda não padronizou telas e campos.

Como configurar (ou solicitar) campos e telas para QA

Cenário A: você tem autonomia (mais comum em team-managed)

O objetivo é garantir que, ao criar/editar um Bug, os campos de QA apareçam na tela.

• 1) Liste os campos necessários: Ambiente, Build/Versão, Componente, Severidade/Prioridade, Passos, Esperado, Obtido.

• 2) Verifique se já existem campos nativos: alguns projetos já têm Environment, Component/s, Priority.

• 3) Adicione campos ao tipo de issue Bug: em configurações do projeto, procure por campos/issue types e inclua os campos na tela de criação e edição.

• 4) Defina obrigatoriedade com parcimônia: se o projeto permitir, torne obrigatórios pelo menos Ambiente + Versão/Build + Severidade/Prioridade + Descrição estruturada.

• 5) Padronize valores: para Ambiente e Severidade, prefira lista (dropdown) para evitar variações (ex.: “homolog”, “hml”, “stg”).

Cenário B: você não tem acesso de configuração (comum em company-managed)

Nesse caso, seu trabalho é especificar claramente o que precisa para o admin configurar com rapidez e sem idas e vindas.

Solicitação pronta para enviar ao administrador (exemplo)

Assunto: Ajustes no Jira para fluxo de QA (campos e permissões)\n\nProjeto: ABC\nTipo de projeto: (se souber) company-managed\n\nNecessidades de QA:\n1) Permissões para o grupo QA: criar/editar issues, comentar, anexar arquivos, transicionar, linkar issues.\n2) No tipo de issue Bug, incluir na tela de Create/Edit os campos:\n   - Environment (lista: Dev, Staging, Homolog, Produção)\n   - Build/Versão (texto curto)\n   - Component (usar Components do Jira ou campo equivalente)\n   - Severidade (lista: Blocker, Critical, Major, Minor, Trivial)\n   - (manter) Priority\n3) Se possível, tornar obrigatórios em Bug: Environment, Build/Versão, Severidade (ou Priority), Description.\n4) Habilitar Link issues para rastreabilidade (Bug <-> Story/Task).\n\nMotivo: garantir reprodutibilidade, evidências e rastreabilidade entre demanda e defeitos.

Definindo severidade e prioridade (uso prático no dia a dia)

Se o time só usa um dos dois, combine a regra: ou “Severidade = impacto” e “Prioridade = fila”, ou unifique em um único campo para evitar duplicidade.

Campos e rastreabilidade: como garantir que Bug aponte para a origem

Rastreabilidade mínima em QA no Jira costuma depender de vínculos e consistência de preenchimento.

• Vincular Bug à Story/Task: ao abrir um bug encontrado durante a validação de uma demanda, use Link issue e selecione um tipo de link padronizado (ex.: “is caused by”, “relates to”).

• Usar Epic/Component: ajuda a agrupar e filtrar por módulo.

• Versão/Build: permite responder “em qual build apareceu?” e “em qual build foi corrigido?” (se o time também preencher fix version/release quando aplicável).

• Evidências anexadas: prints e vídeos reduzem tempo de triagem e suportam auditoria.

Checklist de configuração mínima para o fluxo de testes funcionar

1) Projeto e tipos de issue

• Existe um projeto onde QA registra bugs e acompanha demandas.

• Tipo de issue Bug disponível (ou equivalente).

• Tipos de issue para demanda (Story/Task) disponíveis para vincular.

2) Permissões mínimas para QA

• Criar e editar issues.

• Comentar.

• Anexar arquivos.

• Transicionar status.

• Linkar issues.

• Visualizar o projeto e as issues.

3) Campos mínimos no Bug (na tela de Create/Edit)

• Environment (lista padronizada).

• Build/Versão (texto).

• Componente (Components ou campo equivalente).

• Severidade e/ou Prioridade.

• Descrição com passos para reproduzir + esperado + obtido (em campo único ou separados).

4) Fluxo mínimo de status (para não travar o trabalho)

• Bug pode ser criado em um status inicial (ex.: Open/To Do).

• Existe um status que represente correção em andamento (In Progress).

• Existe um status para pronto para reteste (Ready for Retest/Ready for QA).

• Existe um status final (Done/Closed) e, se usado, um status de rejeição (Won’t Fix/Invalid/Duplicate) com motivo registrado em comentário.

5) Rastreabilidade mínima

• QA consegue vincular Bug ↔ Story/Task.

• Campos de versão/build permitem identificar onde ocorreu.

• Evidências anexadas ficam na própria issue.

Quando você não tem acesso: como alinhar com o administrador do Jira

O que levar para a conversa (para ser objetivo)

• Lista de permissões que QA precisa (em termos de ações: criar, editar, anexar, comentar, transicionar, linkar).

• Lista de campos e quais devem ser obrigatórios para Bug.

• Valores padronizados para listas (Ambiente, Severidade).

• Exemplo de issue ideal (um bug bem preenchido) para o admin validar se a tela suporta.

• Impacto se não ajustar: bugs sem reprodutibilidade, perda de rastreabilidade, retrabalho na triagem.

Perguntas que destravam rapidamente

• “Qual grupo devo usar para QA e quais permissões ele já tem?”

• “O campo Environment existe e está na tela de Bug? Se não, podemos adicionar?”

• “Conseguimos tornar Environment e Build/Versão obrigatórios apenas para Bug?”

• “O workflow do Bug tem um status de pronto para reteste?”

• “O time pode linkar issues? Qual tipo de link vocês preferem padronizar?”

Alternativa temporária quando não dá para configurar agora

• Use o modelo de descrição estruturada (Passos/Esperado/Obtido) dentro do campo Description.

• Padronize no time um prefixo no Summary para ambiente e build, até o campo existir. Ex.: [HML][4512] Falha ao....

• Registre componente e severidade via Labels temporariamente, com uma lista acordada (ex.: comp-pagamentos, sev-critical).

• Garanta o vínculo manual no texto (colando a chave da Story) se o link estiver bloqueado, e solicite a permissão de link como prioridade de configuração.