Qualidade não é etapa final.
É parte da estratégia.

Nota: BUG = bug aberto em produção (usuário afetado), fonte: projeto Jira BUGS, mapeado por data de criação na janela de cada sprint — contabilizando apenas escapes distintos, sem tarefas de follow-up/correção nem subtarefas derivadas. SUB-BUG = falha identificada em homologação antes do deploy, fonte: projeto BT (issuetype Sub-bug). Sprints 34 e 36 não registraram BUGs novos em produção no período.

Fechamento das últimas janelas. Sprint 40: 14 BUGs × 8 SUB-BUGs — razão 0,57. Sprint 41: 4 BUGs (BUGS-35, 37, 42, 44) × 2 SUB-BUGs (BT-620, BT-718) — razão 0,50. Sprint 42 (06–17/07): 22 BUGs em produção × 2 capturados em homologação — razão 0,09, a pior janela de toda a série. Sprint 43 (20–31/07): 8 BUGs × 5 SUB-BUGs — razão 0,63, recuperação parcial.

Encerramento da série por sprint: a Sprint 43 foi a última do time — o Kanban entrou em 27/07/2026, dentro da sua última semana, e as duas cadências convivem nesses 3 dias úteis. Sem janela de sprint para agrupar, esta tabela é congelada como registro histórico e o indicador passa a ser apurado por mês-calendário (ver série mensal abaixo), mantendo as mesmas fontes.

Contagem da Sprint 42: os 22 são a contagem bruta de todas as Tarefas de nível superior abertas no projeto BUGS na janela (subtarefas excluídas), sem depuração manual de follow-up ou duplicata — critério 100% reproduzível por JQL. Sob o critério manual usado na Sprint 41, 5 itens seriam candidatos a exclusão (BUGS-55, 57, 63, 67 e 69), o que levaria a 17 BUGs e razão 0,12. Nenhum dos dois cenários altera a leitura.

Leitura honesta de julho. Julho é o pior mês desde a entrada do QA: 32 escapes em produção contra 8 capturados em homologação. A razão caiu de 2,75 (maio) para 0,25 — 11 vezes. Não é ruído de amostragem: o volume absoluto de escapes multiplicou por 8 no mesmo intervalo. A concentração está na Sprint 42, que sozinha responde por 22 dos 32 escapes, puxada por uma sequência de falhas de reCAPTCHA no cadastro, instrumentação de GTM/Analytics e gestão de usuários da empresa.

Contexto do período. Julho concentrou uma rodada ampla de ajustes em todo o sistema. Mudança de larga superfície com o mesmo volume de teste manual produz exatamente este resultado: o número de pontos que podem quebrar cresce, a capacidade de verificar não cresce junto, e a diferença sai em produção. O contexto explica a curva — não a absolve. A conclusão operacional é a mesma: a cobertura de regressão precisa deixar de depender de tempo humano.

A Sprint 43 já reage (razão 0,63), mas ainda abaixo de 1. A meta da nova série mensal é atravessar 1,0 — capturar em homologação pelo menos tanto quanto escapa para o usuário.

O que esperar de agosto — hipótese registrada antes do fato. Agosto começa com três variáveis mudando ao mesmo tempo: nova cadência (Kanban), nova estrutura (duas squads, mesmo QA) e refatoração geral do sistema. Refatoração é a categoria de mudança com maior taxa de regressão por linha alterada — reescreve comportamento existente sem critério de aceite que o descreva. Com o QA cobrindo duas frentes e o estagiário ainda em onboarding (que consome capacidade antes de devolver), a expectativa honesta é que a razão de agosto não suba sozinha. O que muda o resultado não é esforço manual adicional: é suíte de regressão automatizada rodando no CI a cada PR e limite de WIP na coluna de teste, para que o gargalo apareça no quadro antes de aparecer no usuário. Este parágrafo fica registrado com data para que, no fechamento de agosto, seja possível separar o efeito da refatoração do efeito da mudança de método — e não atribuir tudo ao Kanban.

Nota metodológica. Mesmas fontes da série por sprint: BUG = Tarefa de nível superior criada no projeto Jira BUGS dentro do mês (subtarefas excluídas); SUB-BUG = projeto BT, issuetype Sub-bug, por data de criação.

Cuidado ao comparar com a série por sprint: uma sprint tem 10 dias úteis e um mês tem ~21. Os valores absolutos não são diretamente comparáveis entre as duas tabelas — só a razão BUG × SUB-BUG é, por ser adimensional. Julho aparece nas duas séries por ser o mês de transição.

Agosto em detalhe — a hipótese registrada acima, confrontada com o fato.
1. Queda real, ainda insuficiente. 15 bugs contra 37 em julho (−59%), quase o dobro da meta de 8. Um mês de queda não é tendência; setembro confirma ou desmente.
2. Concentração no fim do mês. 8 dos 15 entraram nos três últimos dias úteis (27 a 31/08), 6 deles no mesmo tema: regras de subsídio, licença e selo.
3. Dois casos graves. Cobrança indevida de empresas com subsídio ativo (severidade máxima). Correção estrutural do estado de licenças em andamento, não apenas dos sintomas.
4. Higiene de registro. 3 registros são o mesmo incidente do Emissor de NF em triplicata e 1 é a causa raiz de bug já contado. Sem repetições seriam 12; mantidos os 15 pelo critério único.
5. Mediana de correção subiu de 1 para 7 dias por causa do cluster subsídio/licença, fechado na primeira semana de setembro (12 dos 15 já corrigidos). A conclusão que se mantém desde julho: o problema não é a velocidade da correção, é a quantidade que escapa.
Referências no Jira: cluster subsídio/licença BUGS-93, 95, 96, 101, 102, 104 · triplicata BUGS-81/82/83 · causa raiz BUGS-104 (ligada ao BUGS-96).

Leitura e plano de ação. A escalada mai→jul foi interrompida, mas o patamar (15/mês) segue acima da meta (8) e da base (12). Detecção majoritariamente interna e correção rápida: o gargalo é a quantidade que chega à produção, concentrada em áreas específicas.
Correção estrutural do ciclo subsídio/licença/selo, causa dos 2 casos graves de agosto. Quality Gate (SonarQube) e testes E2E nas jornadas críticas como barreira antes do deploy nas áreas que mais escapam. RCA em implantação e automação de testes: 9 casos automatizados concluídos, 13 em automação (11 UI e 2 API). Registro com origem obrigatória e revisão de duplicidades a partir de set/2026.
Critério de sucesso: setembro e outubro com no máximo 8 bugs/mês cada. Dois meses seguidos, não um mês bom.

Nota de método. Conta-se falha que chegou ao usuário final com o sistema no ar, registrada na esteira BUGS do Jira, por mês-calendário da data de abertura, em consulta reprodutível (JQL). Base de comparação: média mai+jun/2026 = 12 bugs/mês; meta de −35% = máximo 8/mês até out/2026. O período ClickUp não é comparável e fica fora da conta. Valores brutos, sem ajuste manual: duplicidades são corrigidas no Jira para os ciclos seguintes, nunca subtraídas no mês do reporte.

Diferença em julho (32 × 37): a série mensal acima foi extraída em 31/07/2026; este fechamento, em 08/09/2026. Os 5 registros a mais são bugs de julho abertos ou reclassificados no Jira após o corte anterior. Vale o número mais recente (37).