A observação surgiu durante a “T03-E01 — Brainstorms & Blueprints: Colocando em prática”, quando a proposta era analisar processos atuais, localizar lacunas e escolher uma ação concreta. À primeira vista, pode parecer que isso só vale para produtos com incidentes, suporte sobrecarregado e uma pirâmide de testes invertida…

Mas um produto em construção também possui um processo. Ele aparece nas primeiras decisões: como as histórias são esclarecidas, o que a equipe considera pronto, como uma mudança é revisada, quais verificações acontecem antes de publicar e como um problema será tratado quando inevitavelmente aparecer.

Começar sem produto não significa começar sem qualidade. Significa criar acordos antes que atalhos virem hábitos e hábitos virem dívida.

Como começar qualidade de software sem burocracia

Alguns times iniciam sem proteção porque “ainda é cedo”. Outros tentam implantar, no primeiro sprint, toda ferramenta, métrica, cerimônia e checklist que conheceram.

Os dois caminhos criam fricção.

Qualidade não exige uma estrutura corporativa completa. Exige que a equipe decida, de forma proporcional ao risco, o que não pode depender de memória, improviso ou boa vontade.

Vamos chamar isso de plano mínimo de qualidade: um conjunto pequeno de acordos que torna a entrega previsível desde o início. Não é um documento longo. É uma resposta prática a perguntas feitas tarde demais: o que precisa estar claro antes de desenvolver? Como saberemos que a entrega funciona? Quem revisa? O que deve impedir uma publicação? Como perceberemos uma falha em produção?

O plano cresce com o produto. Uma aplicação interna não inicia com a mesma estrutura de uma plataforma de pagamentos ou de um sistema que trata dados de saúde. Mas nenhuma delas se beneficia de critérios vagos, mudanças sem revisão ou ausência completa de validação.

Qualidade embutida no processo desde o início

A ideia de construir qualidade no processo não nasceu no software. No Sistema Toyota de Produção, o princípio de jidoka propõe identificar uma anormalidade e interromper o fluxo para não repassar defeitos adiante. Em software, não “paramos uma fábrica”, mas evitamos que uma decisão ambígua ou código sem proteção avance silenciosamente.

Em vez de perguntar “quem vai testar no final?”, perguntamos: “o que cada etapa precisa produzir para que a próxima não receba um problema escondido?”.

Para uma equipe no início, quatro acordos oferecem retorno imediato:

• Critérios de aceite verificáveis. Transformar “a tela deve ser rápida” em um comportamento observável, como “a busca retorna em até dois segundos para 95% das requisições”, incluindo caminho ideal, alternativas e erros.
• Definition of Ready e Definition of Done. A primeira define quando uma história tem clareza para entrar em desenvolvimento; a segunda, quando está realmente concluída. Assim, “feito” não significa algo diferente para cada pessoa.
• Revisão e controle de versão. Mudanças precisam ser rastreáveis e receber uma segunda perspectiva. Em um time pequeno, isso pode ser revisão assíncrona ou programação em pares.
• Automação inicial focada. Uma pipeline que gera o build, executa verificações estáticas e roda testes rápidos já reduz risco. A pirâmide não precisa nascer completa: comece pelas regras de negócio que mais custam quando falham.

O importante é que esses acordos sejam usados no trabalho real. Um checklist esquecido não protege o produto.

Como priorizar práticas de qualidade conforme o risco

Não existe uma sequência universal de ferramentas. O ponto de partida combina impacto e viabilidade: o que reduz risco relevante com um esforço que o time consegue sustentar agora?

Em uma startup com duas pessoas, a prioridade pode ser tornar histórias testáveis, versionar tudo, revisar mudanças em pares e automatizar build e testes unitários. Quando o produto passa a depender de uma API de pagamento, entram testes de integração, cenários de falha e monitoramento. Quando cresce, podem surgir contratos entre serviços, E2E para jornadas críticas, alertas e uma rotina de aprendizado com tickets de suporte.

Em uma empresa maior, segurança, privacidade, arquitetura, observabilidade e aprovações específicas podem existir desde o primeiro dia. A diferença não é “mais qualidade” contra “menos qualidade”. É reconhecer que o custo de uma falha e as obrigações do produto exigem proteções diferentes.

A sessão trouxe uma regra útil: comece pelos quick wins, mas nunca ignore um teste falhando. Um alerta vermelho é evidência de risco, não incômodo de ferramenta.

O que organizações maduras deixam claro sobre qualidade

Um exemplo público é o GitLab. Sua estratégia de testes enfatiza feedback rápido, testes progressivos, uso eficiente de recursos e responsabilidade clara por cada suíte. A documentação usa a pirâmide para orientar a distribuição: a maior parte fica nos testes unitários; os E2E permanecem em menor quantidade porque custam mais para executar e manter.

A lição não é copiar o processo de uma empresa grande. É notar o que ela torna explícito: testes prioritários, responsáveis, bloqueios e condições para encerrar uma entrega. No guia operacional público do GitLab, “done” inclui critérios de aceite atendidos, código revisado, integração contínua aprovada, deploy aplicável, monitoramento quando necessário e documentação ou comunicação atualizadas.

Para um produto novo, isso é direção, não checklist. Não precisamos reproduzir todas as camadas de uma organização global. Precisamos evitar começar com regras invisíveis.

O custo de adiar práticas básicas de qualidade

Considere um cenário ilustrativo: uma equipe lança um fluxo de cadastro sem definir mensagens de erro, limites de uso ou o comportamento diante de uma indisponibilidade externa. Após a primeira reclamação, duas pessoas de desenvolvimento, uma de produto, uma de suporte e uma de operações passam três horas investigando, corrigindo e comunicando o incidente. São 15 horas desviadas, além do cliente afetado e do trabalho planejado que parou.

O defeito pode ser inevitável. A repetição da mesma descoberta não precisa ser.

Quando um problema volta, ele deveria deixar algo melhor: um critério mais claro, um teste de regressão, um alerta, uma decisão registrada ou uma etapa simplificada. Assim, o produto acumula capacidade, não apenas código.

Responsabilidade compartilhada pela qualidade de software

Nem todo produto novo terá Product Owner, QA, DevOps, segurança e suporte como equipes separadas. Em muitos casos, uma pessoa exerce mais de um papel. Ainda assim, as responsabilidades precisam existir e ser nomeadas.

Produto protege a clareza do problema e do valor. Desenvolvimento cria soluções legíveis, revisáveis e testáveis. QA, quando presente, amplia o olhar para riscos e estratégia de validação. Operações ajuda a tornar a produção observável e recuperável. Liderança protege espaço para práticas que impedem que urgência vire padrão. Atendimento transforma o contato do cliente em sinal estruturado de qualidade.

Responsabilidade compartilhada não elimina especialização. Ela impede que a qualidade seja empurrada para a última pessoa da fila.

Um produto em desenvolvimento não é uma empresa “sem processo”. É uma empresa decidindo qual processo terá. Antes do primeiro incidente, ainda podemos escolher que cada falha deixe uma proteção e que cada entrega aumente a confiança para construir a próxima.

Começar certo não é prever tudo. É decidir, desde agora, que qualidade não será uma correção adicionada depois.

O post Como garantir qualidade de software antes do produto existir apareceu primeiro em QA Program.

Se a IA ajuda a escrever testes, a pirâmide de testes muda? O custo muda? A lógica continua fazendo sentido?

A resposta curta é: a pirâmide não muda.

Mas a dificuldade de construir uma pirâmide saudável pode diminuir bastante.

Essa diferença é importante. A IA pode ajudar o time a criar testes unitários, sugerir cenários, acelerar casos de regressão e apoiar a cobertura de código legado. Mas ela não transforma testes lentos em rápidos, não torna fluxos de ponta a ponta menos frágeis por mágica e não substitui uma estratégia de qualidade.

Em outras palavras: a IA não muda a física do sistema. Ela muda a fricção para trabalharmos melhor dentro dela.

Quando o problema volta, a pirâmide está tentando dizer algo

Um problema recorrente em produção raramente volta por acaso. Às vezes ele volta porque a correção foi feita sem teste de regressão. Às vezes porque a regra de negócio só foi validada no fluxo completo do usuário. Às vezes porque existe um grande bloco de código legado sem proteção, onde qualquer ajuste vira uma aposta.

A pirâmide de testes ajuda justamente a pensar onde cada tipo de validação deve viver.

Na base estão os testes unitários: rápidos, baratos e focados em regras pequenas. Eles validam uma regra de desconto, uma condição de CPF inválido, uma exceção para usuário inativo. Não dependem de banco, rede ou ambiente. Por isso podem ser numerosos e rodar o tempo todo.

Acima vêm os testes de integração, que verificam conexões entre partes internas do sistema, como serviço e repositório. Depois, testes de componente, que exercitam um pedaço maior da aplicação com dependências externas simuladas. Mais acima estão os testes E2E, sigla para end-to-end, ou ponta a ponta: fluxos completos do usuário em ambiente real ou próximo do real. Eles são úteis, mas mais lentos, caros e sensíveis a mudanças de interface.

Por fim, existem testes exploratórios: investigação estruturada, não clique aleatório. Uma sessão exploratória com missão, tempo definido e anotações pode descobrir comportamentos que nenhum script antecipou.

Uma pirâmide saudável tem muitos testes rápidos na base e poucos testes amplos no topo. Uma pirâmide invertida acontece quando quase tudo depende de testes E2E ou validação manual. O resultado é conhecido: feedback lento, instabilidade, filas de validação e medo de mexer no sistema.

De onde veio essa ideia

A pirâmide de testes foi proposta por Mike Cohn no contexto das práticas ágeis e depois popularizada por autores como Martin Fowler. Ela nasceu como uma resposta a um problema prático: equipes automatizavam testes, mas concentravam esforço em validações lentas, caras e frágeis demais para dar feedback rápido.

A mensagem não era “E2E é ruim”. Era outra: cada tipo de teste tem um custo, uma velocidade e uma capacidade diferente de localizar defeitos. Quanto mais alto na pirâmide, mais próximo da experiência real do usuário, mas também maior o custo de manutenção e investigação.

O TDD, ou Test-Driven Development, desenvolvimento orientado por testes, também vem desse movimento de buscar feedback mais cedo. Popularizado por Kent Beck nas práticas de Extreme Programming, ele propõe o ciclo Red, Green, Refactor: escrever um teste que falha, fazer a implementação mínima passar e então refatorar.

TDD não é sinônimo de teste unitário. Também não é apenas “ter muitos testes”. É uma prática de design: pensar no comportamento esperado antes de escrever a solução.

IA ajuda mais onde a base costuma estar vazia

Muitas organizações sabem que precisam de mais testes unitários, mas não conseguem chegar lá. Falta tempo, hábito, clareza nos requisitos, domínio do legado ou confiança para mexer em partes antigas.

É aqui que a IA pode ajudar de forma concreta.

Ela pode sugerir casos para uma função existente, gerar estruturas de Arrange, Act, Assert (preparar, executar e verificar, respectivamente), identificar caminhos condicionais, propor nomes de testes mais descritivos e acelerar a criação de testes de regressão depois de um defeito.

Imagine um bug em um cupom de desconto: o cliente aplica um cupom válido, remove um item do carrinho e o valor final fica incorreto. Corrigir o código é apenas uma parte da resposta. A pergunta de qualidade é: qual teste teria capturado esse erro antes do cliente?

Provavelmente não precisamos começar por um E2E longo abrindo navegador, preenchendo carrinho, aplicando cupom e finalizando compra. Antes disso, podemos criar testes unitários para regras de desconto, testes de integração para a comunicação entre carrinho e serviço de cupom e um teste de componente para o checkout com gateway simulado. O E2E fica reservado ao fluxo crítico principal.

A IA pode acelerar a escrita desses testes. Mas a decisão sobre onde testar continua sendo humana e estratégica.

O que empresas grandes mostram na prática

Essa lógica aparece em organizações que operam software em grande escala. O Google, por exemplo, já recomendou como ponto de partida uma distribuição próxima de 70% de testes unitários, 20% de integração e 10% de ponta a ponta. O número exato varia por contexto, mas a forma continua sendo a mensagem: muitos testes rápidos na base e poucos testes amplos no topo.

A Meta também publicou um estudo sobre geração automática de testes unitários a partir de observações de execução. A iniciativa buscou transformar sinais capturados em testes menores, capazes de rodar continuamente e detectar problemas antes que se tornassem bloqueios maiores. Ou seja: em ambientes com altíssima escala, a atenção à pirâmide é imprescindível.

Gerar teste não é o mesmo que gerar confiança

Existe um risco importante: pedir para a IA escrever testes apenas olhando a implementação atual pode gerar testes que confirmam o que o código faz, não o que deveria fazer.

Isso é perigoso quando o próprio código contém o defeito.

Um teste ruim pode aumentar cobertura sem aumentar confiança. Ele passa, aparece no relatório, melhora um número bonito e não protege o comportamento que importa. Cobertura de testes não equivale automaticamente a qualidade. Ela é um sinal, não uma garantia.

Por isso, o critério de aceite continua essencial. Se o Product Owner escreve “o sistema deve tratar erros adequadamente”, a IA também terá dificuldade de saber o que validar. Se o critério diz “Dado que o CPF tem 10 dígitos, quando o usuário clicar em salvar, então deve exibir CPF inválido abaixo do campo sem limpar os outros campos”, o teste passa a ter uma direção.

IA funciona melhor quando a equipe já sabe o comportamento esperado.

O impacto não é só técnico

Quando um problema volta, a organização paga mais de uma vez pelo mesmo risco.

Considere um cenário ilustrativo: um defeito recorrente no checkout mobiliza uma pessoa de suporte, uma de produto, duas de desenvolvimento, uma de QA e uma de operações por três horas. São 18 horas desviadas, sem contar clientes afetados, receita atrasada, comunicação emergencial e interrupção de prioridades.

Se o defeito reaparece porque nunca ganhou um teste na camada certa, não estamos diante apenas de uma falha técnica. Estamos diante de uma falha de aprendizado.

Em uma fintech, isso pode significar cobrança incorreta. Em um SaaS, permissões quebradas para clientes importantes. Em um sistema de saúde, dados exibidos fora do contexto adequado. Em operações internas, retrabalho manual toda vez que o mesmo comportamento falha.

Uma pirâmide de testes saudável reduz esse custo porque aproxima o feedback do ponto onde o defeito nasce.

IA como alavanca, não como terceirização da qualidade

A cultura de qualidade não melhora porque uma ferramenta escreve testes. Melhora quando o time usa a ferramenta para reforçar práticas certas.

Produto contribui com critérios testáveis. Desenvolvimento escreve e revisa testes como parte da entrega. QA orienta estratégia, riscos e lacunas. Sustentação adiciona characterization tests antes de alterar código legado. CS, ou Client Service, transforma tickets recorrentes em sinais de qualidade. Liderança protege tempo para que essas práticas não sejam cortadas sempre que o prazo aperta.

A IA pode ajudar a sair de uma pirâmide invertida, especialmente quando a base unitária está vazia. Pode tornar mais barato começar. Pode reduzir a resistência inicial. Pode sugerir caminhos que o time revisa, adapta e incorpora.

Mas a pergunta continua sendo a mesma: esse teste captura um comportamento relevante? Ele está na camada certa? Ele falharia se o defeito voltasse?

Se a resposta for não, a IA apenas gerou mais código.

No fim, a pirâmide não muda porque continua existindo a lógica de custo, velocidade e confiança. O que muda é que ferramentas como IA podem tornar muito mais simples fortalecer a base da pirâmide. É como ganhar uma boa caixa de ferramentas novas: a estrutura da casa continua a mesma, mas construir e reforçar os alicerces passa a exigir menos esforço e menos tempo.

O problema que volta está sempre contando uma história. A pirâmide ajuda a descobrir em qual camada deveríamos ter ouvido esse sinal antes.

Interessante, não? A IA pode ajudar a escrever mais testes, a pirâmide pode ficar mais saudável e aquele defeito recorrente pode finalmente ganhar uma proteção permanente.

Mas isso ainda olha para uma parte da história: a execução dos testes.

E antes disso?

Como evitar que a regra chegue ambígua? Como impedir que o defeito nasça no requisito, no design, na decisão de produto ou na pressa do desenvolvimento? Como antecipar a qualidade antes da fase formal de testes?

Para isso, temos um post no qual falamos sobre Shift-Left, Built-in Quality e TDD como formas de trazer qualidade para mais perto da origem do problema… Antes que alguém “encontre” o defeito no final.

O post Com IA escrevendo testes, a pirâmide de testes e os seus custos mudam? apareceu primeiro em QA Program.

Isso significa que o time só consegue ser rápido quando abandona o processo?

Essa diferença revela menos sobre a disposição das pessoas e mais sobre como a organização foi preparada para entregar e se recuperar. Se a velocidade depende de improviso, acesso excepcional e alguém disposto a “resolver direto em produção”, ela não é uma capacidade do sistema. É uma reação à crise.

O tempo gasto e o tempo esperando

Para compreender esse cenário, precisamos separar duas medidas apresentadas no encontro.

Lead Time for Changes é o tempo entre uma alteração de código e sua disponibilidade em produção. Ele não representa apenas as horas em que alguém está programando ou testando. Inclui também esperas: uma tarefa parada na fila, uma revisão pendente, a dependência de outra área, uma janela de deploy ou uma aprovação manual.

Por isso, uma mudança simples pode exigir poucas horas de trabalho e levar vários dias até o usuário. O número revela o fluxo completo, não apenas o esforço individual.

MTTR, ou Mean Time to Recover, observa quanto tempo a equipe leva para restaurar um serviço após uma falha em produção. Para que a comparação seja útil, cada organização precisa definir quando a contagem começa; no contexto discutido no encontro, consideramos a partir da identificação da falha.

As duas medidas se relacionam. Se toda recuperação exigir desenvolver uma correção e fazê-la percorrer o mesmo fluxo demorado das mudanças comuns, o Lead Time limitará o MTTR. Mas a recuperação pode ser mais rápida quando existe uma alternativa segura: reverter para uma versão anterior, alterar uma configuração, desativar a funcionalidade afetada ou redirecionar o serviço enquanto a causa é investigada.

O objetivo não é criar um processo descuidado para incidentes. É preparar um caminho de resposta que preserve os controles essenciais sem tratar uma falha ativa como uma demanda comum da fila.

O que a DORA procura revelar

Lead Time e MTTR fazem parte das métricas apresentadas no encontro a partir da DORA, programa de pesquisa que estuda quais práticas favorecem o desempenho da entrega e das operações de software. Essa linha de pesquisa ganhou forma nos relatórios State of DevOps, publicados desde 2014, e ajudou a desafiar a crença de que entregar rápido exige sacrificar estabilidade.

No modelo trabalhado na sessão, quatro sinais são observados em conjunto: frequência de deploy, Lead Time for Changes, taxa de falha das mudanças e MTTR. Eles mostram, respectivamente, com que frequência valor chega à produção, quanto tempo uma mudança leva para chegar, quantos deploys exigem intervenção e quanto tempo o serviço leva para ser recuperado.

Nenhum deles deve virar meta isolada. Um Lead Time menor não representa melhoria se foi obtido eliminando validações necessárias. Um MTTR baixo também pode esconder correções frágeis que apenas adiam a recorrência. Métricas servem para substituir impressões vagas por perguntas específicas: onde o trabalho espera? Qual etapa concentra retrabalho? O que impede uma recuperação segura?

A ilusão de ganhar tempo

Pular etapas produz uma sensação imediata de velocidade. A mudança chega antes porque revisão, teste, registro ou comunicação ficaram para depois. O problema é que esse “depois” frequentemente reaparece como investigação, correção adicional, divergência entre versões e branches ou novo incidente.

O que parecia tempo economizado transforma-se em retrabalho.

Imagine um cenário ilustrativo em que um incidente mobilize duas pessoas de desenvolvimento, uma de QA, uma de operações, uma de produto e uma de atendimento durante três horas. São 18 horas de trabalho desviadas, sem contar clientes afetados, transações perdidas ou entregas adiadas. Se a correção apressada provoca outra falha, a organização paga novamente e interrompe as mesmas áreas que deveriam estar criando valor.

Velocidade sustentável não consiste em remover todos os controles. Consiste em reduzir filas, dependências desnecessárias e operações manuais, enquanto os controles importantes se tornam rápidos, repetíveis e confiáveis.

Feature Flags: separar deploy de liberação

Uma prática que ajuda nessa preparação é o uso de Feature Flags, ou sinalizadores de funcionalidade. Elas permitem alterar o comportamento de uma função sem exigir que um novo pacote seja criado e implantado naquele momento.

Seu benefício central é separar deploy de liberação. O código pode seguir para produção em mudanças menores e menos complexas, permanecendo oculto ou desativado até que exista segurança para disponibilizá-lo. Em vez de acumular muitas alterações em uma grande liberação arriscada, a equipe entrega pacotes menores com mais frequência.

Em uma falha, uma flag operacional pode permitir que a parte afetada seja desligada enquanto o restante do sistema continua disponível. Em uma liberação planejada, pode expor a novidade gradualmente. Também pode viabilizar testes A/B quando dois comportamentos são comparados para grupos diferentes, com uma hipótese e uma medida de resultado.

Um e-commerce pode manter o checkout anterior disponível enquanto introduz uma nova experiência. Um aplicativo de mobilidade pode desativar temporariamente o cálculo dinâmico de tarifas sem interromper as corridas já em andamento. Um sistema hospitalar pode liberar um novo painel de agendamento apenas para algumas unidades e acompanhar falhas antes de expandir o uso para toda a rede.

Feature Flags, porém, não substituem análise de causa raiz, testes ou rollback. Elas também geram complexidade. Flags antigas precisam de responsável, prazo e remoção; caso contrário, diferentes combinações de estados tornam o sistema mais difícil de compreender e validar.

Preparação produz resultado para o negócio

Times maduros não dependem de adivinhação. Criam caminhos para reduzir o impacto, identificar a causa e aplicar a resposta adequada. Isso envolve observabilidade para perceber a falha, responsabilidades claras para decidir, versões recuperáveis, automação de deploy e opções seguras para reverter ou limitar uma mudança.

Produto e negócio ajudam a definir impacto e prioridade. Desenvolvimento constrói mecanismos de entrega e recuperação. QA contribui com cenários de risco e evidências. Operações acompanha o serviço. Liderança remove esperas desnecessárias e protege o tempo destinado à melhoria estrutural.

Quando esses elementos funcionam juntos, velocidade deixa de aparecer apenas durante a emergência. Ela se traduz em menos indisponibilidade, menos retrabalho, menor interrupção das prioridades e recuperação mais previsível para clientes e equipes. Ao observar causas e padrões, a organização deixa de apenas detectar falhas e passa também a trabalhar para preveni-las.

A pergunta relevante não é somente “em quanto tempo resolvemos?”. Precisamos perguntar o que esse tempo revela: houve espera evitável? A correção exigiu improviso? Conseguimos limitar o impacto? O processo ficou mais preparado para a próxima ocorrência?

Correr quando tudo já deu errado é urgência. Velocidade com qualidade é chegar à produção e recuperar o serviço sem transformar cada mudança em uma aposta.

O post Velocidade não é pular etapas. É estar pronto para agir. apareceu primeiro em QA Program.

O sistema volta a funcionar. Dias ou semanas depois, o mesmo defeito retorna.

A urgência explica o atalho, mas não elimina sua consequência. Quando uma correção não é incorporada de forma consistente ao fluxo oficial, a organização não resolveu o problema: restaurou temporariamente a operação.

Corrigir não é o mesmo que resolver

Vale separar três termos. O defeito é uma condição no software, na configuração ou no processo capaz de produzir um comportamento incorreto. A falha é sua manifestação observável. O incidente é a situação em produção que exige resposta porque afeta usuários, operação ou negócio.

Durante um incidente, a prioridade inicial costuma ser reduzir o dano. Isso pode significar reverter um deploy, desativar uma funcionalidade, corrigir uma configuração ou publicar um hotfix, a correção emergencial. Essas ações tratam o sintoma imediato e podem ser exatamente o que a situação exige.

O problema começa quando a resposta termina aí.

Resolver de forma permanente exige investigar por que o defeito surgiu, escapou, chegou à produção e reapareceu. A análise de causa raiz reúne técnicas para atravessar as camadas do sintoma e encontrar causas e fatores contribuintes que possam ser tratados. Em sistemas complexos, raramente existe uma única causa ou um único culpado.

Uma técnica conhecida é a dos “Cinco Porquês”, associada a Sakichi Toyoda e incorporada às práticas de melhoria contínua. A ideia não é repetir “por quê?” mecanicamente, mas evitar que a primeira explicação conveniente seja aceita como diagnóstico.

Se o defeito voltou, a pergunta não é apenas “qual linha de código estava errada?”. Também precisamos saber: a correção chegou a todas as branches necessárias? Qual versão foi publicada? Havia um teste que reproduzia a falha? O procedimento de emergência estava definido?

Versionamento de código é memória organizacional

O Git foi criado em 2005 para apoiar o desenvolvimento distribuído do kernel Linux, um projeto com grande volume de mudanças e trabalho paralelo. Seu valor não está em tornar o trabalho mais formal, mas em permitir que alterações sejam registradas, comparadas, revisadas e integradas sem depender da memória de uma pessoa.

Um commit registra um ponto do código-fonte. Uma branch representa uma linha paralela de desenvolvimento. Uma release é uma versão preparada para uso. Deploy é a ação de colocá-la em um ambiente.

Esses termos não são sinônimos. Voltar para um commit anterior não restaura automaticamente a produção; normalmente é necessário publicar uma release conhecida e segura. Da mesma forma, corrigir uma branch não atualiza todas as outras. A equipe precisa definir como a mudança será incorporada às linhas mantidas, validada e implantada.

Por isso, o risco não está apenas em uma correção “ficar na máquina do desenvolvedor”. Ela pode estar no repositório e, ainda assim, não ter sido propagada para outra branch ou release. O código existe, mas as versões continuam divergentes e o defeito fica esperando o próximo deploy.

Da resposta urgente ao aprendizado

Uma resposta madura não ignora a urgência. Ela cria um caminho seguro para operar dentro dela.

Durante o incidente, a equipe restaura o serviço pelo meio de menor risco e registra o que foi alterado. Depois, reconcilia a correção com a fonte oficial do código, verifica as versões afetadas, adiciona evidências de teste e confirma o deploy. Por fim, analisa o ocorrido sem caça aos culpados, documentando impacto, causas e ações preventivas com responsáveis e prazos.

Análises estruturadas depois de incidentes relevantes, as Post-mortems, existem para transformar falhas em aprendizado compartilhado. Sem acompanhamento das ações, porém, o documento vira apenas um relato bem escrito do próximo problema recorrente.

As métricas ajudam a transformar percepções em sinais comparáveis: mostram se os incidentes estão se repetindo, se a recuperação está mais rápida e se as mudanças adotadas realmente melhoraram o processo. As métricas DORA, originadas de pesquisas sobre o desempenho da entrega de software, observam como velocidade e estabilidade se relacionam. Nesse contexto, o MTTR, Mean Time to Recover ou tempo médio de restauração, mede quanto tempo a equipe leva para restaurar o serviço após uma falha. Já o Change Failure Rate indica a proporção de deploys que causam incidentes ou exigem rollback e correções emergenciais. Esses números não revelam sozinhos a causa do problema, mas orientam a investigação e permitem acompanhar se as ações reduziram sua recorrência.

O custo invisível da reincidência

Considere um cenário ilustrativo: um incidente mobiliza duas pessoas de desenvolvimento, uma de operações, uma de QA, uma de produto e uma de suporte por duas horas. São 12 horas de trabalho desviadas, antes de contabilizar atendimento ao cliente, perda de transações, atraso de entregas ou desgaste reputacional.

Se isso acontece uma vez por mês, são 144 horas por ano consumidas pelo mesmo padrão. A empresa paga pela interrupção das prioridades, pela investigação repetida, pela comunicação de crise e pela incerteza criada para clientes e liderança.

Em um e-commerce, o defeito pode reaparecer no checkout durante uma campanha. Em uma fintech, na conciliação de pagamentos. Em uma plataforma SaaS, nas permissões de determinados clientes. O setor muda; o padrão permanece: uma solução parcial oferece alívio, mas não reduz o risco do sistema.

Qualidade também aparece depois do incidente

Qualidade além dos testes significa entender que a recorrência não pertence a uma única área. Desenvolvimento contribui com integração e testes. QA amplia cenários de risco e produz evidências. Operações fortalece observabilidade, rollback e resposta. Produto e negócio priorizam a correção estrutural. Suporte torna visível o impacto sobre clientes. Liderança protege tempo para aprendizado e evita transformar esforço emergencial em processo permanente.

Responsabilidade compartilhada não elimina especialidades. Ela impede que a organização espere que uma única função compense falhas de versionamento, decisão, comunicação e operação.

Quando um defeito volta, ele revela a qualidade real do produto e a capacidade da organização de alcançar resultados com previsibilidade. Restaurar o serviço foi necessário. Aprender, equalizar as versões e impedir a repetição é o que transforma resposta em maturidade.

A pergunta final não é apenas “quanto tempo levamos para corrigir?”. É: depois da correção, o sistema e a organização ficaram menos propensos a repetir o mesmo incidente?

E se a resposta é não, o problema não desapareceu. Ele só está esperando o próximo deploy em produção.

Mas antes de encerrar completamente essa história, resta outra pergunta incômoda: e se o próximo deploy for amanhã?

Agir rápido não precisa significar abandonar o controle. Times maduros preparam caminhos para entregar, interromper, reverter e restaurar mudanças sem depender de memória ou sorte.

No próximo post, vamos olhar para duas medidas citadas que ajudam a separar velocidade sustentável de improviso: Lead Time e tempo de recuperação. Afinal, ser rápido pode demonstrar maturidade, ou apenas cortar caminho até o próximo problema.

O post Por que o mesmo defeito volta? apareceu primeiro em QA Program.

A resposta curta é: aplicando Shift-Left.

Mas Shift-Left não significa apenas executar mais cedo os mesmos testes que já fazemos hoje. Significa trazer conversas, critérios, validações e decisões de qualidade para etapas anteriores do desenvolvimento, quando ainda é mais simples evitar um defeito do que corrigir suas consequências.

Em muitos times, o fluxo ainda acontece assim: a demanda é entendida, o código é desenvolvido e, só depois, a solução chega a uma etapa formal de testes. Na prática, isso pode transformar qualidade em uma inspeção no final da fila.

E quando a qualidade chega apenas no final, geralmente chega tarde.

Um requisito ambíguo, uma regra de negócio mal compreendida ou uma exceção esquecida não nasce quando o defeito é encontrado. Ele já estava presente em alguma decisão anterior. O teste apenas tornou visível o que o processo deixou passar.

Por isso, defendemos uma mudança de perspectiva: qualidade deve estar embutida em cada atividade do ciclo de desenvolvimento. Esse princípio é conhecido como Built-in Quality, ou qualidade embutida. Em vez de depender de uma pessoa ou de uma área para “garantir qualidade”, todo o time contribui para construí-la.

Onde entram os diferentes testes?

Uma forma de visualizar essa construção é a Pirâmide de Testes. Ela organiza os testes em níveis, considerando velocidade, custo, abrangência e proximidade do código.

Na base ficam os testes unitários: numerosos, rápidos e voltados para as menores partes verificáveis do código. Acima aparecem testes de integração ou de serviço, que observam se diferentes partes funcionam juntas. No topo ficam testes de interface ou ponta a ponta, próximos da experiência real do usuário.

Todos têm valor. A pirâmide mostra que não é eficiente depender principalmente de testes amplos e lentos para descobrir problemas que poderiam ter sido encontrados perto do código.

Foi no contexto da pergunta do participante que, durante o encontro, falamos de TDD — Test-Driven Development, ou desenvolvimento guiado por testes.

O TDD foi desenvolvido por Kent Beck no fim dos anos 1990 e ganhou espaço como uma das práticas de engenharia do Extreme Programming. Sua proposta é usar testes unitários para orientar a construção do código, aproximando a validação do momento em que a solução é desenvolvida.

Na prática, quem aplica TDD é o desenvolvimento. O ciclo costuma seguir três movimentos:

1. escrever um teste unitário que represente uma condição técnica e que, inicialmente, falhe;
2. escrever o mínimo código necessário para fazer esse teste passar;
3. refatorar o código, mantendo o teste aprovado.

Esse ciclo é conhecido como vermelho, verde e refatorar.

A ordem é essencial. Um time pode criar testes unitários depois de escrever o código e, ainda assim, não estar fazendo TDD. No TDD, o teste vem antes e ajuda a conduzir a implementação.

Também é importante não confundir TDD com BDD, ou Behaviour-Driven Development (guiado por comportamentos). O BDD costuma descrever comportamentos esperados em uma linguagem mais próxima do negócio. O TDD, no contexto apresentado, trabalha mais perto do código e de pequenas condições técnicas verificáveis.

Como isso aparece no mercado?

Imagine um e-commerce que precisa calcular descontos combinando valor da compra, tipo de cliente e período promocional. Com TDD, o desenvolvimento pode começar por condições pequenas: um cliente elegível deve receber determinado desconto; uma combinação inválida não pode ser aceita; o valor final deve respeitar um limite definido.

Em uma fintech, a mesma prática pode apoiar regras de juros, limites de transação ou validações de cobrança. Em uma plataforma de assinaturas, pode ajudar em cálculos de renovação, cancelamento e mudança de plano.

Esses testes não garantem sozinhos que toda a experiência funciona. Eles não verificam, por exemplo, se a interface está clara, se os sistemas externos estão integrados corretamente ou se existem riscos de segurança. Por isso, TDD e testes unitários não eliminam os outros níveis da Pirâmide de Testes. Eles fortalecem a base das demais validações.

Qualidade continua sendo responsabilidade compartilhada

TDD é uma prática aplicada pelo desenvolvimento, mas antecipar qualidade depende de mais pessoas.

Produto contribui ao transformar objetivos em critérios claros e reduzir ambiguidades. 

Negócio ajuda a explicitar riscos, prioridades e exceções. 

Desenvolvimento constrói com testes unitários, revisão de código e boas práticas técnicas. 

QA amplia a visão de risco, estrutura estratégias de teste e investiga cenários ainda não 

considerados. 

Liderança cria condições para que qualidade não seja a primeira coisa descartada quando o prazo aperta.

Isso não elimina uma área de QA nem a execução formal de testes. Também não substitui testes exploratórios, validações com usuários, análise de métricas, segurança ou revisão de produto. O que muda é o lugar ocupado pela qualidade: ela deixa de aparecer somente depois que o código está pronto.

Aplicar Shift-Left e tratar qualidade como responsabilidade compartilhada não é mover uma etapa para a esquerda no cronograma. É mudar o modo como o time trabalha: compreender melhor antes, validar próximo de onde cada decisão é tomada, automatizar o que faz sentido e combinar diferentes níveis de teste.

TDD contribui para essa mudança ao permitir que o desenvolvimento valide pequenas condições técnicas antes de escrever o código que deverá atendê-las. Não é a resposta completa para qualidade, mas é uma forma concreta de construí-la mais cedo.

Portanto, qualidade não começa quando alguém executa um teste. Ela começa quando o time entende que cada decisão, de um requisito ao código, pode aproximar ou afastar a entrega do resultado esperado.

O post Como antecipar a qualidade antes da execução formal de testes? apareceu primeiro em QA Program.