01 / 13
QUALITY ASSURANCE

Plano de Evolução
QA Mônica

Reestruturar a atuação de QA para que a Mônica evolua como especialista — sem abandonar o valor que entrega hoje.

Tipo Documento Interno
De → Para CTO → QA
Duração 12 semanas + escala

O Problema

QA ficou no final da fila — e isso tem custo.

Acúmulo de Funções

A Mônica é QA do time, mas acumulou responsabilidades que vão muito além do escopo técnico:

Report de cliente — coleta, monta, envia, follow-up
Release de app — checklist, stores, rollback
Refinamento — lidera discussões de negócio
QA — testes reativos, sem automação

Resultado

~30%

do tempo é dedicado ao core de QA

Zero automação de testes
Zero métricas de qualidade
Sem estratégia de testes
~2h/semana para evolução técnica

O problema não é que ela faz essas atividades. O problema é que sobra pouco tempo para o core de QA.

Distribuição de Tempo

De 12h/semana para 24h/semana em QA Core.

HOJE (AS-IS)

QA Core30% · 12h
Report de Cliente20% · 8h
Organização de Release18% · 7h
Apoio a Refinamento15% · 6h
Reuniões gerais12% · 5h
Evolução técnica5% · 2h

IDEAL (TO-BE)

QA Core + Automação + Métricas60% · 24h
Refinamento (testabilidade)12% · 5h
Validação de qualidade (release)8% · 3h
Evolução técnica / estudo10% · 4h
Revisão de reports5% · 2h
Reuniões5% · 2h

Fluxo Atual (Caótico)

QA fica no final da fila — só acontece se sobrar tempo.

Início do Dia
↓

Report de Cliente

~8h/sem
Coleta dados → Monta relatório → Envia ao cliente → Follow-up
↓

Organização de Release

~7h/sem
Monta checklist → Valida build → Publica nas stores → Comunica stakeholders
↓

Refinamento

~6h/sem
Sem preparo prévio. Discute negócio, UX, prioridade. Define critérios na hora.
↓

Não sobrou tempo

Dia acaba sem testar nada

Sobrou um pouco

Testes reativos, sem estratégia

Zero automação · Zero métricas · Zero evolução técnica

Fluxo Ideal (TO-BE)

QA é a primeira atividade do dia, não a última.

Início do Dia
↓

Verifica Board de Testes

PRIORIDADE
Histórias prontas para QA → Executa conforme plano de testes da sprint
↓

Passou

Move para Done + Evidências

Bug

Devolve com reprodução

↓

Automação

Escreve/atualiza testes automatizados → Roda suite de regressão
↓

Refinamento

Preparo + foco em testabilidade

Release

Smoke test + GO / NO-GO

Evolução

Automação, métricas, estudo

QA protagonista · Automação progressiva · Evolução contínua

Recebimento de Testes

Como uma história chega para o QA — com regras claras.

Dev finaliza e move para "Ready for QA"
↓

Dev preenche checklist obrigatório

Link do PR/branch Ambiente de teste O que foi feito O que testar
↓

Incompleto?
Volta para dev

ou

Completo?
QA pega o card

↓

Execução de Testes

Happy Path
Edge Cases
Dispositivos
↓

Sem bugs

Cria automação se crítico → Done

Bug encontrado

Documenta com template → Dev corrige

Regra: Card sem checklist preenchido volta automaticamente para o dev.

Release de App

Responsabilidades separadas: QA valida, PM/DevOps opera.

PM / Product Owner

1 Define data de release
↓
… Aguarda GO do QA
↓
4 Comunica stakeholders
↓
5 Publica nas stores
↓
6 Comunica clientes

QA — Mônica

2 Recebe build candidata
↓
2b Smoke test + Regressão
↓

GO

NO-GO

Gate de Qualidade

Nenhuma release sai sem o OK dela

DevOps / Dev

1b Gera build candidata
↓
1c Disponibiliza em staging
↓
! Se NO-GO: corrige blockers → nova build

De-Para das Atividades

O que muda em cada frente — sem cortar nada do dia pra noite.

Report de Cliente

Mônica faz tudo: coleta, monta, envia, follow-up
Analista/PM executa. Mônica revisa dados de qualidade
8h/sem 2h/sem

Release de App

Coordena tudo: checklist, stores, comunicação
Apenas validação: smoke test e GO/NO-GO
7h/sem 3h/sem

Refinamento

Sem preparo, opina sobre tudo (UX, negócio, prioridade)
Preparo 24h antes. Foco: testabilidade e edge cases
6h/sem 4h/sem

QA Core — O que ganha

Plano de testes por sprint
Automação e2e (Cypress/Playwright)
Métricas: escape rate, cobertura, bugs em prod
Shift-left: testa antes do dev começar
CI/CD: gate de qualidade no pipeline

Dia Ideal da Mônica

Visualizando como seria um dia típico no modelo TO-BE.

09:00 – 09:15 QA CORE

Verifica board: cards em "Ready for QA", bugs reabertos, prioridades

09:15 – 11:00 QA CORE

Testa histórias prontas conforme plano de testes da sprint

11:00 – 11:30 REFINAMENTO

Prepara cenários de teste para refinamento da tarde

11:30 – 12:00 CONSULTORIA

Revisa report de cliente (se for semana de report)

13:00 – 14:00 REFINAMENTO

Foco em testabilidade e edge cases

14:00 – 16:00 AUTOMAÇÃO

Escreve/atualiza testes automatizados + roda suite de regressão

16:00 – 16:30 QA CORE

Smoke test de build candidata (se tiver release)

16:30 – 17:00 EVOLUÇÃO

Atualiza métricas de qualidade / estudo técnico

Roadmap de Transição

12 semanas em 4 fases — gradual e respeitoso.

SEM 1–4

📝 Documentação

Tornar conhecimento tácito em explícito.

Playbook de report de cliente
Mapeamento completo do release
Templates: report, checklist QA, bug
Runbook de release (QA vs. operação)
SEM 5–8

🤝 Transferência

Treinar e fazer transição assistida.

Shadow: PM aprende report
Shadow: PM/DevOps no runbook
Report delegado com revisão
Primeira release no novo modelo
SEM 9–12

🎯 Foco em QA

Papel consultivo + core de QA.

Primeiro plano de testes estruturado
Primeiros testes e2e rodando
Dashboard de métricas
Retrospectiva da transição
MÊS 4+

🚀 Escala

QA como pilar estratégico.

CI/CD com gate de qualidade
Regressão dos 20 fluxos críticos
Métricas na retro de sprint
Report e release rodam sem ela

Ferramentas de QA

As plataformas que vão sustentar a nova operação de qualidade.

Qase

RECOMENDADO

Plataforma moderna de gestão de testes. Interface limpa, integração nativa com CI/CD, e suporte a testes manuais e automatizados no mesmo lugar.

Criação e organização de test cases com suítes hierárquicas
Test runs com tracking de execução, evidências e status em tempo real
Dashboards e reports automáticos — escape rate, cobertura, resultados por sprint
Integrações com Jira, GitHub, Slack, CI/CD (Cypress, Playwright, Selenium)
API aberta para automação de fluxos e coleta de métricas
Acessar qase.io
Ideal para times que estão começando automação e precisam de métricas rápidas.

TestLink

OPEN SOURCE

Ferramenta open-source consolidada para gestão de testes. Auto-hospedada, sem custo de licença, com controle total sobre os dados.

Gestão completa de test cases, suítes e planos de teste
Versionamento de casos de teste atrelado a releases e builds
Relatórios de execução, métricas de cobertura e rastreabilidade de requisitos
Integração via XML-RPC API com Jira, Mantis, Redmine e ferramentas de CI
Controle total — self-hosted, dados internos, sem vendor lock-in
Acessar testlink.org
Ideal para times que precisam de controle total e não querem depender de SaaS externo.

Métricas de Sucesso

Como saber se o plano está funcionando.

Meta em 30 dias

Tempo em QA Core≥ 45%
Reports sem Mônica≥ 50%
Releases sem Mônica (operação)≥ 50%
Testes e2e automatizados≥ 5
Cenários escritos antes do dev≥ 30%

Meta em 90 dias

Tempo em QA Core≥ 60%
Reports sem Mônica100%
Releases sem Mônica (operação)100%
Testes e2e automatizados≥ 20
Cenários escritos antes do dev≥ 70%
-20%

Escape rate
(bugs em produção)

-50%

Cards devolvidos
(checklist incompleto)

2x

Tempo em QA Core
(12h → 24h/sem)

5x

Tempo para evolução
(2h → 10h/sem)

Riscos & Próximos Passos

O que pode dar errado — e como começar.

Riscos & Mitigações

Mônica sentir que está "perdendo" responsabilidades

Mitigação: Posicionar como evolução de carreira. Conversa 1:1 antes de iniciar.

Queda de qualidade nos reports durante transição

Mitigação: Mônica revisa reports nas primeiras 4 semanas pós-delegação.

Ninguém disponível para assumir atividades

Mitigação: Identificar responsáveis ANTES da Fase 2. Considerar contratação júnior.

Dev não preencher checklist de entrega

Mitigação: CTO reforça obrigatoriedade. Cards sem checklist voltam automaticamente.

Resistência do time ("sempre foi assim")

Mitigação: Apresentar benefícios para todos: menos bugs, releases mais seguros.

Próximos Passos

1

1:1 com Mônica

Apresentar como oportunidade de crescimento. Ouvir preocupações e ajustar juntos.

2

Identificar responsáveis

Quem assume report (PM? Analista?) e coordenação de release (PM? DevOps?).

3

Alinhar com o time

Novo fluxo de entrega: checklist obrigatório, cenários no refinamento.

4

Iniciar Fase 1

Mônica começa a documentar processos. Checkpoints quinzenais com o CTO.

"A transição deve ser gradual, respeitosa com o trabalho que a Mônica construiu, e orientada para o crescimento profissional dela."