TL;DR: Se o quadro do Jira da sua equipe de tecnologia virou um “cemitério de cards” sem padrão ou se a comunicação entre desenvolvedores e a equipe de qualidade está gerando gargalos e retrabalho, este guia prático resolve o seu problema. Descubra como estruturar um fluxo de QA no Jira eficiente segmentado por ambientes (DEV, HML e PRD) e como criar cards de teste padronizados que facilitam a vida do time.
O problema dos fluxos genéricos no Jira
Quem trabalha como Analista de QA em equipes ágeis sabe que poucas coisas são tão frustrantes quanto um quadro Kanban mal configurado. No modelo tradicional de mercado, os fluxos costumam ser lineares demais (To Do, In Progress, QA, Done).
Esse minimalismo esconde um grande gargalo: o desenvolvedor move o card para a coluna de testes sem dar nenhuma pista do que foi feito, onde testar ou quais dados utilizar. Do outro lado, o QA se depara com uma “caixa preta” e perde horas preciosa estudando o problema do zero ou interrompendo o desenvolvedor com dúvidas básicas.
Para resolver esse problema de comunicação e dar total transparência ao progresso das tarefas, implementamos na empresa onde atuo como QA uma metodologia robusta de movimentação de cards integrada a um template de testes padronizado. A seguir, mostro o passo a passo de como esse fluxo funciona na prática.
A Metodologia de Movimentação de Cards: Workflow Multi-Ambiente
A grande virada de chave da nossa engenharia de processos é que o fluxo do Jira reflete os nossos ambientes de implantação. Em vez de apenas uma coluna genérica de testes, dividimos o ciclo de vida do card entre Desenvolvimento (DEV), Homologação (HML) e Pré-Produção/Produção (PPRD/PRD).
Como QA, o meu ciclo de trabalho acontece de forma estratégica passando pelas seguintes etapas e colunas:
1. Coluna: Pendente (A Origem do Trabalho)
Aqui nascem as demandas do ciclo técnico. Nesta coluna, eu atuo de duas formas:
- Demandas de Ajuste/Melhoria: Criação de cards de tarefas específicas (como correções visuais ou ajustes pontuais em uma tela).
- Bugs Independentes: Criação de cards para reportar falhas de mau funcionamento encontradas no software.
2. Coluna: Em Desenvolvimento (Planejamento e Escrita)
Quando uma nova História Mãe ou Tarefa (Task) é liberada pelo PO ou time de desenvolvimento, eu crio uma Subtarefa (Subtask) de teste vinculada a ela. Esse novo card de teste vai direto para a coluna Pendente.
Ao iniciar a configuração dele, movo o status para Em Desenvolvimento. É aqui que a mágica do QA acontece antes mesmo do código ir para a tela. Uso essa etapa para:
- Estudar o problema a fundo;
- Ler os critérios de aceite da história ou tarefa;
- Planejar os casos de teste e mapear os cenários em formato BDD (Behavior-Driven Development);
- Documentar toda a descrição técnica no card.
3. Coluna: QA em Teste (Execução e Validação)
Assim que os desenvolvedores finalizam a codificação e aprovam o Pull Request (PR), o card principal é movido para Liberado para QA. Nesse momento, eu movo a minha subtarefa de teste para a coluna QA em Teste e começo a validação prática no ambiente de DEV.
A partir daqui, o fluxo assume regras de negócio cruciais baseadas na complexidade do erro e na dinâmica de trabalho do time:
- Cenário de Sucesso (Aprovado por QA): Se os testes passarem sem ressalvas na tela e todas as evidências (prints ou GIFs) forem registradas com sucesso, eu movo o card para a coluna Aprovado QA. O item fica aguardando a geração da GMUD (Mudança) para subir de ambiente.
- Erros Básicos e Alinhamento com Devs (O “Acordo” do Time): Se eu encontrar um bug bobo, algo simples de layout ou uma inconsistência rápida que o desenvolvedor consiga corrigir “tranquilamente” antes do PR ser formalmente aprovado por outros programadores, nós não abrimos um card de bug. Nós apenas devolvemos o card original uma coluna para trás, retornando para Liberado para QA, adicionamos uma marcação de bandeira vermelha com o motivo do impedimento e sinalizamos o Dev. Isso evita penalizar a equipe de desenvolvimento com métricas infladas de bugs abertos por bobeira.
- Erros Complexos em DEV (Abertura de Bug por Timesheet): Por outro lado, se a nova funcionalidade apresentar falhas graves (erros críticos de comportamento, quebras severas de padrão ou funções que simplesmente não executam a ação esperada), a abordagem muda. Como nossa operação é baseada em horas trabalhadas e registramos nosso esforço no Reports and Timesheets do Jira, o desenvolvedor precisará de tempo dedicado e faturável para resolver o problema. Nesses casos, abrimos sim o card de Bug Independente em ambiente de DEV, garantindo o rastreio correto das horas de correção de ambas as partes.
Como lidamos com dados sensíveis e contratos de confidencialidade estritos no nosso ambiente corporativo, eu obviamente não posso trazer prints reais do quadro Kanban do Jira da minha empresa aqui para o blog.
Por isso, para ilustrar exatamente como essa engenharia funciona sem quebrar nenhuma regra de compliance, eu estruturei uma representação visual idêntica do nosso ecossistema técnico.
Assim, você pode ver como as colunas interagem e como os cards de Tasks, Subtasks e Bugs Independentes se comportam nas esteiras de DEV, HML e PPRD/PRD.
O Ciclo de Vida e Re-Teste do Bug em DEV
Quando esse card de Bug é aberto, ele segue um fluxo rigoroso de rastreabilidade e validação:
- Vínculo de Tickets: O card de Bug nasce na coluna Pendente. Na seção de tickets vinculados do Jira, eu faço a amarração completa: vinculo a História ou Tarefa mãe à qual ele pertence e o relaciono diretamente com a Subtarefa de testes onde a falha foi descoberta.
- Correção e Nova Subtarefa: O card de Bug percorre as colunas do quadro até que o desenvolvedor o corrija e o mova para Liberado para QA. Ao entrar no Bug, em vez de apenas fechar o card, eu crio uma nova subtarefa de testes exclusiva para ele.
- O Re-Teste: Aplico o modelo de testes para validar o que foi relatado. Chamamos essa etapa carinhosamente de Re-Teste porque, além de checar se a falha antiga sumiu, precisamos garantir que a correção não quebrou outras partes do sistema (o famoso “mexeu em um canto e bugou outro” que todo QA conhece bem!).
- Aprovação em Massa em DEV: Caso tudo seja aprovado, o card de Bug, a sua subtarefa de Re-Teste, a História/Tarefa mãe e o card de testes antigo mudam juntos para a coluna Aprovado por QA.
- Transição de Ambiente e Conclusão: No momento em que a funcionalidade nova sai de DEV e vai para Homologação (passando pela coluna de Preparar GMUD), todos esses cards de teste e bugs que estavam aprovados em DEV mudam seu status para Concluído. Isso sinaliza o encerramento daquela esteira local, já que as validações nos próximos ambientes (HML e PRD) exigirão novos testes e novas abordagens.
4. Transição de Ambientes: Homologação (HML) e Produção (PRD)
Quando o código é autorizado a subir de nível através de uma GMUD, o processo se repete nos novos ambientes utilizando subtarefas dedicadas para garantir o isolamento dos testes.
- O Filtro de Qualidade em HML: Quando o desenvolvedor publica em Homologação, o card vai para a coluna Publicado em HML, sinalizando que está pronto. Movo para Em Testes HML.
- Esse mesmo comportamento em esteira se aplica caso o projeto exija validações em ambiente de Pré-Produção (Teste em PPRD) antes de bater o martelo e enviar a funcionalidade para a coluna final de Concluído em Produção.
Templates Práticos: Como criar Cards de QA que desenvolvedores adoram ler
Para que o fluxo de movimentação funcione sem atritos, a padronização da escrita dos cards é fundamental. Se a descrição for vaga, o time perde o alinhamento. Na nossa estrutura, dividimos as responsabilidades e os modelos de escrita de acordo com o tipo de card.
Abaixo, você encontra os templates estruturados em Markdown que utilizamos no nosso dia a dia para garantir clareza, organização e eficiência.
1. Template para Tarefa (Task)
Responsabilidade de criação: Equipe de Desenvolvimento / QA.
Utilizado para detalhar as etapas necessárias para a implementação ou ajustes técnicos de uma funcionalidade.
- Detalhes Técnicos: Mapeamento do modelo de tela (seção e link do projeto no Figma) e resolução preferencial de tela.
- Critérios de Aceite: Regras de execução e de negócio que o usuário precisa realizar no produto.
- Mapeamento de Riscos: Impactos ou dependências que a nova funcionalidade terá ou gerará em outras telas.
Quer ver modelos detalhados de escrita? Para entender como traduzir requisitos em ações práticas com exemplos reais, confira o meu artigo completo sobre Guia Completo de Casos de Teste: Como Criar, Documentar e Validar com Eficiência.
2. Template para Subtarefa de Teste (Subtask)
Responsabilidade de criação: Equipe de QA.
Utilizado para planejar o escopo do teste, descrever os cenários (de preferência em formato BDD) e coletar as evidências de validação (como prints ou GIFs).
Quando lidamos com falhas complexas em DEV (que demandam tempo faturável no Timesheet) ou erros em Homologação, a estrutura precisa cobrir:
- Passo a Passo para Reprodução: Caminho exato executado até o erro ocorrer.
- Resultado Obtido vs. Resultado Esperado: O que o sistema quebrou em contraste com o comportamento correto.
- Análise de Severidade e Prioridade: O impacto técnico do defeito na experiência do usuário e a urgência de negócio para a correção.
Quer aprender a documentar falhas de forma impecável? Veja o passo a passo definitivo de como estruturar um relatório de falhas limpo e profissional no meu artigo sobre Como Reportar e Rastrear Bugs com Eficiência: Guia Profissional para QAs e Desenvolvedores.
3. Template para Bug Independente / Crítico
Responsabilidade de criação: Equipe de QA / PO
Utilizado para documentar falhas complexas encontradas em ambiente de DEV (que exigem medição de horas no Timesheet) ou qualquer erro identificado em Homologação (HML).
Os benefícios reais no dia a dia do time (e do bolso)
Implementar um fluxo tão segmentado e padronizado exige disciplina, mas os resultados justificam o esforço. O primeiro grande impacto é a redução drástica no vai e vem de perguntas entre QAs e desenvolvedores. Com critérios de aceite claros de um lado e relatórios de bugs técnicos do outro, o Cycle Time (tempo que o card passa sendo ativamente trabalhado) cai significativamente.
Além disso, para operações baseadas em consultoria ou fábricas de software que faturam por hora trabalhada, esse modelo é um divisor de águas. O uso correto do Reports and Timesheets do Jira atrelado a cards bem específicos (Histórias, Tarefas e Bugs Independentes) garante que cada minuto de engenharia ou de re-teste seja devidamente contabilizado e auditável. É a engenharia de qualidade trabalhando em sintonia com a saúde financeira do projeto.
Conclusão e próximos passos
Centralizar e madurecer o fluxo de QA no Jira vai muito além de mover cards de uma coluna para a outra. É sobre criar uma cultura de responsabilidade compartilhada, onde desenvolvedores e analistas de qualidade jogam no mesmo time para entregar software estável sem gerar atritos internos.
Se você deseja continuar evoluindo os processos e a documentação técnica da sua equipe de tecnologia, recomendo acompanhar os outros guias práticos que publiquei aqui no blog:
- Planejamento Estratégico: Como Criar um Plano de Testes Eficiente: Guia para QAs e Desenvolvedores
- Automação de Testes: Testes Manuais vs Automatizados: quando usar cada um em QA
Compartilhe:
Gostou dessa abordagem? Como funciona o fluxo de QA e a movimentação de cards no Jira do seu squad atual? Já teve que abrir bug em ambiente de desenvolvimento por causa do Timesheet ou vocês também têm esse ‘acordo de cavalheiros’ para erros simples? Comente aqui embaixo, vou adorar trocar uma ideia e entender como a sua equipe organiza o dia a dia da qualidade!”
