Como garantir qualidade de software antes do produto existir

“Não temos um produto ainda; estamos no desenvolvimento.”

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.