Voidr
testingautomatione2eexploratory-testing

Por que você não deveria automatizar testes para novas funcionalidades

Entregar uma nova feature com 100% de testes automatizados parece uma boa ideia — mas a realidade é outra. Novas funcionalidades são um mar de incertezas.

Victor Buchalla
Victor Buchalla
CTO & Co-founder
29 de maio de 20245 min

Por que você não deveria automatizar testes para novas funcionalidades

Entregar uma nova feature com 100% de testes automatizados parece uma boa ideia — mas a realidade é outra.

O problema

Novas funcionalidades são um mar de incertezas.

→ Mesmo com bom Discovery, validação com usuários beta e entrevistas, → Quando a feature vai pra produção… muitas vezes não é o que o usuário precisava de verdade

O que acontece?

→ Você precisa ajustar a lógica e a interface com base no uso real → E agora tem dois problemas: refatorar a feature e reescrever todos os testes automatizados

Resultado: Lead time estourado por uma entrega que ainda nem gerou valor real.

Nem toda empresa está no mesmo estágio

→ Em startups, o produto muda o tempo todo — hipóteses, não verdades → Em softwares estabelecidos de missão crítica, o foco é garantir que nada quebre

Automatizar uma funcionalidade ainda instável é um desperdício de tempo — e dinheiro.

O nível de maturidade do produto define o quanto você deve investir em testes E2E desde o início.

Testes automatizados têm um propósito

Eles servem para garantir que o comportamento atual da aplicação se mantenha confiável com o tempo.

Ou seja, só faz sentido automatizar comportamentos que realmente existem e foram validados em produção.

Automatizar algo que ainda não foi usado de verdade é cristalizar uma hipótese.

Qual a melhor estratégia então?

Testes manuais e exploratórios — sim, isso mesmo → Feitos por pessoas fora do time de desenvolvimento, para validar UX e robustez → Use rituais como bug bash ou bug bounty interno: – Integram o time – Espalham conhecimento sobre a nova entrega

Como fazemos na Voidr

Na Voidr, monitoramos continuamente as mudanças nos ambientes dos nossos parceiros.

→ Quando a funcionalidade já está validada e estável, seguimos com a automação dos testes E2E. → Quando ainda há incerteza ou risco técnico, optamos por uma abordagem exploratória, com foco em quebrar a entrega antes que o usuário final encontre o problema.

Você está automatizando hipóteses — ou comportamentos validados?

A diferença muda completamente o ROI da sua estratégia de qualidade.

Compartilhar artigo

Compartilhe este artigo com sua rede

Victor Buchalla
Victor BuchallaCTO & Co-founder

Victor é CTO & Co-founder na Voidr, onde lidera iniciativas de qualidade e automação de testes para sistemas de missão crítica.

Seguir no LinkedIn

Quanto custa cada defeito que escapa para produção?

Diagnóstico técnico personalizado. Analisamos arquitetura e mapeamos oportunidades de melhoria.

Solicitar diagnóstico