Testing em Startups: Quanto Testing é Suficiente para Ir Rápido sem Quebrar Coisas
Já vi dois tipos de startups que fracassam em testing. E os dois fracassam pela mesma razão: dogma.
A primeira é a startup que não testa nada. "Somos uma startup, precisamos de velocidade. Os testes nos atrasam. Vamos escrevê-los quando tivermos product-market fit." Fazem deploy de cada commit direto em produção, numa sexta à tarde, e na segunda têm três clientes enterprise com tickets críticos que ninguém consegue reproduzir.
A segunda é a startup que testa tudo. Cobertura de 95%. Cada componente de UI tem testes de snapshot. Cada endpoint tem testes para edge cases que afetam 0,01% dos usuários. A equipe demora o dobro para entregar cada feature porque cada mudança quebra 40 testes que ninguém entende. E quando surge uma oportunidade de mercado, não conseguem pivotar porque mover uma função significa reescrever 200 testes.
Nenhum dos dois extremos funciona. A resposta está no meio, e é mais simples do que parece.
A pergunta certa não é "quanto", mas "o quê"
Pare de pensar em porcentagem de cobertura. A cobertura de código é uma métrica de vaidade quando usada como objetivo. Você pode ter 90% de cobertura e nenhum dos seus testes cobrir a lógica de pagamentos que realmente importa.
A pergunta certa é: quais partes do meu sistema me deixam dormir tranquilo sem testes, e quais não?
Se o seu sistema de processamento de pagamentos falha e cobra duas vezes do cliente, você tem um problema existencial. Se um botão tem 2px de margem extra no Safari, ninguém morre.
O testing pragmático começa por identificar o que pode causar dano real e focar ali os recursos limitados da sua equipe.
A pirâmide de testing para startups
A pirâmide clássica de testing (muitos unit tests, menos integration, poucos E2E) continua válida, mas para startups a proporção muda:
Unit tests: a base, mas só para lógica de negócio. Não teste cada função helper, cada utilitário de formatação de datas, cada mapper trivial. Teste a lógica que calcula preços, que determina permissões, que processa dados de negócio. Se uma função contém um if que afeta dinheiro ou dados do usuário, merece um teste.
Integration tests: seu maior aliado. Para startups, os integration tests são os que mais valor entregam por hora investida. Um teste que verifica que sua API de criação de pedidos funciona de ponta a ponta — validação, processamento, persistência, resposta — cobre mais terreno que 20 unit tests individuais de cada etapa.
E2E tests: poucos, mas críticos. Um teste E2E que verifica o happy path completo do seu fluxo principal de usuário (cadastro, ação core, pagamento) é suficiente para começar. Você não precisa de 50 testes E2E cobrindo cada variante. Precisa de 3-5 que cubram os fluxos que geram receita.
A proporção para uma startup em fase inicial deveria ser algo assim:
- 60% integration tests para fluxos de negócio críticos
- 30% unit tests para lógica de negócio complexa
- 10% E2E tests para os happy paths principais
O que você SEMPRE deve testar
Existem componentes que não admitem discussão. Se você não os testa, está jogando roleta:
Pagamentos e billing. Tudo. Criação de cobranças, renovações, cancelamentos, reembolsos, upgrades, downgrades. Cada edge case. Se cobra a mais de um cliente, perde a confiança dele para sempre. Se cobra a menos, perde dinheiro. Teste os cálculos de preços com dados reais. Teste a integração com seu processador de pagamentos em modo sandbox.
Autenticação e autorização. Login, logout, refresh de tokens, expiração de sessões, controle de acesso por roles. Se um usuário consegue acessar dados de outro usuário por um bug de autorização, você tem um incidente de segurança que pode afundar sua empresa. Teste que um usuário com role X não consegue fazer ações de role Y.
Mutações de dados críticas. Qualquer operação que modifique dados que você não consegue recuperar facilmente. Criação de contas, exclusão de recursos, mudanças de estado irreversíveis. Teste que os dados ficam no estado correto depois de cada operação, incluindo os edge cases de concorrência se aplicável.
Lógica de negócio core. O algoritmo que faz do seu produto o seu produto. Se é um sistema de matching, teste o matching. Se é um motor de recomendações, teste as recomendações. Se é um pipeline de processamento, teste cada transformação. Essa é a parte pela qual seus usuários pagam.
O que pode pular (por enquanto)
Nem tudo merece um teste em uma startup pré-escala. Estes são candidatos razoáveis para adiar:
Testes de UI pixel-perfect. Testes de snapshot para componentes de UI geram ruído constante. Cada mudança de design quebra 30 snapshots e a equipe acaba fazendo --update automaticamente sem revisar. O valor real é próximo de zero.
Edge cases extremos. Se você tem 200 usuários, não precisa testar o que acontece quando 10.000 usuários concorrentes fazem a mesma operação. Esse teste tem valor, mas não hoje. Vai precisar dele antes de escalar, não antes de ter product-market fit.
Testes de integração com serviços externos para fluxos não críticos. Se usa uma API de geolocalização para mostrar o fuso horário local, não precisa de um teste E2E que verifique essa integração. Um mock é suficiente.
Código que vai mudar radicalmente. Se está prototipando um fluxo que sabe que vai reescrever em 2 meses, investir em testes exaustivos é queimar dinheiro. Um smoke test básico é suficiente para esse código temporário.
Quando adicionar mais testes
O nível de testing não é fixo. Deve crescer com seu produto e sua equipe:
Antes do seu primeiro cliente enterprise. Clientes enterprise perguntam sobre testing, QA e práticas de desenvolvimento. Além disso, os dados deles são mais sensíveis e as expectativas de uptime são mais altas. Este é o momento de subir o nível.
Quando começar a ter bugs recorrentes em produção. Se o mesmo tipo de bug aparece duas vezes, é um sinal claro de que aquela área precisa de testes. A regra é simples: cada bug em produção vira um teste antes do fix. Assim nunca acontece de novo.
Antes de cada marco de escala. Antes de passar de 100 para 1.000 usuários, revise quais fluxos estão expostos. Antes de passar de 1.000 para 10.000, o mesmo. Cada ordem de grandeza revela fraquezas que em menor escala estavam ocultas.
Quando a equipe cresce. Com 2 pessoas, todo mundo conhece todo o código. Com 8, ninguém conhece tudo. Os testes viram documentação viva que permite a novos membros entender o que o sistema faz e modificá-lo com confiança.
Ferramentas: mantenha simples
Você não precisa de 10 ferramentas de testing. Precisa de poucas, bem configuradas:
- Jest para unit e integration tests em JavaScript/TypeScript. É o padrão de fato e funciona bem para 90% dos casos.
- Playwright para E2E tests. É mais estável e mais rápido que Selenium, com melhor developer experience. Se já usa Cypress, não migre só por migrar — ambos servem.
- Testing Library para testes de componentes. Teste comportamento, não implementação.
- GitHub Actions ou GitLab CI para executar testes em cada PR. Se os testes não rodam automaticamente, não existem.
A chave é que os testes rodem no seu pipeline de CI/CD em cada pull request. Um teste que só roda localmente é um teste que não existe, porque ninguém vai executá-lo consistentemente.
Configure seu CI para bloquear merges se os testes falharem. Sem exceções. O dia em que alguém diz "é urgente, vou mergear sem testes" é o dia em que a cultura de testing morre.
O custo real de não testar
Não testar não é de graça. É uma dívida que você paga com juros:
Bugs em produção custam mais. Um bug detectado por um teste custa 15 minutos de fix. O mesmo bug detectado por um cliente custa horas de investigação, um hotfix sob pressão, comunicação com o cliente afetado e dano reputacional que não se mede em horas.
O medo de fazer deploy. Sem testes, cada deploy é um ato de fé. A equipe começa a fazer deploy com menos frequência. As mudanças se acumulam. Os deploys ficam maiores e mais arriscados. É um ciclo vicioso.
Refactoring impossível. Sem testes, ninguém se atreve a mexer em código existente. O código se degrada progressivamente porque a alternativa (refatorar e rezar) é arriscada demais. Você acaba com uma codebase que ninguém quer manter.
O testing é critério de engenharia
E aqui está a verdade desconfortável: saber o que testar é mais difícil do que saber como testar. Qualquer desenvolvedor pode aprender Jest em uma tarde. Mas decidir o que merece um teste, qual nível de testing cada componente precisa e quando é hora de investir mais em qualidade — isso exige experiência.
Um engenheiro junior testa tudo ou não testa nada. Um engenheiro senior testa exatamente o que importa, e sabe defender essa decisão perante a equipe e o negócio.
Na Conectia, quando validamos engenheiros, avaliamos exatamente isso: critério. Não buscamos gente que saiba escrever testes — buscamos gente que saiba decidir quais testes escrever e por quê. É um dos sinais mais claros de seniority real vs. anos de experiência no currículo.
Os engenheiros seniores da América Latina que conectamos com startups europeias trazem esse critério. Trabalharam em produtos em produção com usuários reais, vivenciaram as consequências de não testar o que importa e aprenderam onde está o equilíbrio entre velocidade e confiança.
Você não precisa de um QA team de 5 pessoas. Precisa de 2-3 engenheiros seniores que saibam exatamente onde colocar cada teste.
Sua equipe precisa de engenheiros seniores que saibam equilibrar velocidade e qualidade desde o dia um? Fale com um CTO — apresentamos engenheiros pré-validados que trazem critério, não apenas código.
