8 conselhos para escalar testes de software

Escalar testes de software é um desafio comum para equipes que buscam garantir qualidade e eficiência em ambientes de desenvolvimento ágeis e contínuos. 

E nada como ouvir conselhos de quem liderou times globais nessa missão. No dia 27 de maio de 2025, a Pós PUC-Rio Digital convidou Maurício Aniche, doutor em Ciência da Computação e ex-tech lead na Adyen (Holanda), para falar sobre Scaling Software Testing na Semana da Transformação de Mercado. 

Confira a seguir 8 lições compartilhadas por Aniche no evento. Boa leitura! 

O ideal é fazer testes de softwares rápidos 

A velocidade dos testes de software é fundamental para reduzir falhas causadas por fatores externos, especialmente em cenários com centenas de milhares ou até milhões de testes. Idealmente eles devem acontecer em milissegundos. 

Testes lentos demandam muita infraestrutura, aumentando custos e complexidade. O foco deve ser garantir que os testes sejam rápidos, independentemente de quantas classes são testadas juntas, se há mock ou interações com banco de dados. 

Quanto mais testes rápidos forem executados antes da integração do código na branch principal, maior a segurança para os desenvolvedores. 

Sempre documente os testes de software

A documentação nos testes de softwares é importante para escalar testes em empresas com centenas de desenvolvedores. 

Em times pequenos, a troca de informações ocorre facilmente, mas em organizações grandes, com muitas equipes e aplicações, isso se torna um desafio. Surgem dúvidas recorrentes sobre como testar determinados projetos, o que exige clareza na definição e comunicação da estratégia de qualidade. 

Essa estratégia deve abranger tanto a visão holística sobre qualidade quanto orientações táticas, indicando, por exemplo, quais frameworks usar e como abordar testes que envolvem banco de dados ou filas. 

Para resolver esse desafio, é necessário criar um documento de estratégia de testes, detalhando a visão da empresa sobre qualidade e oferecendo diretrizes práticas. 

Esse documento facilita o alinhamento entre as equipes, resolve conflitos e serve como referência para dúvidas comuns, permitindo que desenvolvedores consultem soluções já testadas. 

Embora a primeira versão possa ser simples e imperfeita, o mais importante é começar e evoluir o conteúdo ao longo do tempo, garantindo que a estratégia de qualidade seja disseminada de forma consistente na organização. 

Priorize testes pre-merge sempre que possível 

O ideal é trabalhar com os dois tipos. Os testes pre-merge são feitos antes de integrar o código e os post-merge depois que o código foi integrado. 

Empresas grandes tendem a ser conservadoras com testes pre-merge para evitar que uma falha bloqueie todos os desenvolvedores. No entanto, concentrar testes apenas após a integração torna a detecção de erros mais difícil e demorada, pois muitas vezes o teste falha horas depois, quando o desenvolvedor já mudou de contexto. 

Por isso, é fundamental priorizar testes pre-merge, evitando que falhas entrem no código principal. Se a equipe estiver focada em testes post-merge, é importante questionar e buscar soluções para mover esses testes para antes da integração. 

Um teste de software não precisa abranger todos os serviços

É preciso reduzir ao máximo o escopo de um teste para não perder o controle técnico, além de não exigir uma carga cognitiva muito intensa do desenvolvedor. Um escopo menor garante testes mais rápidos, estáveis e fáceis de escrever. 

Esse conselho vale para contextos de crescimento de sistemas. O que começa como um monólito simples, com uma aplicação e um banco de dados, acaba se transformando em uma arquitetura distribuída, com múltiplos serviços para evitar que equipes interfiram umas nas outras. 

Isso, porém, aumenta a complexidade dos testes, que podem exigir a configuração de muitos sistemas simultaneamente, tornando o processo inviável tanto tecnicamente quanto cognitivamente. 

Por isso a estratégia de redução doo escopo dos testes, focando no menor conjunto possível que ainda forneça feedback relevante. Embora testes integrados (end-to-end) sejam importantes, são caros e difíceis de manter. 

Assim, é mais escalável que cada time teste seu sistema de forma isolada, simulando as interações com outros sistemas conforme o contrato estabelecido. Isso permite maior independência entre as equipes e evita bloqueios mútuos. 

Por fim, mesmo com essa divisão, é necessário garantir que alterações nos contratos de comunicação entre sistemas sejam detectadas, o que pode ser feito por meio de testes de contrato, complementando a estratégia de testes isolados com alguns testes integrados onde realmente for necessário. 

Foque no negócio ao testar sistemas legados 

Refatorar primeiro para testar, como sugerem muitos livros, é pouco pragmático, já que sistemas legados são geralmente complexos e difíceis de modificar sem riscos. Por isso, o indicado é priorizar e criar "planos de teste" (test plans) mínimos viáveis, pedindo aos times para listar apenas o que consideravam crítico e essencial, sem a obrigação de cobrir todo o sistema. 

Também é importante focar no negócio e não no código: testar funcionalidades importantes em vez de classes isoladas, que não garantem confiança em sistemas complexos. 

Além disso, envolver o Product Manager no processo é fundamental, pois essa pessoa tem visão holística do sistema e pode indicar os principais fluxos de negócio. 

Uma métrica que pode ser utilizada no projeto de testes de sistemas legados é a cobertura de código, por ser barata e oferecer uma visão geral útil. 

Usar a metodologia Test-Driven Development (TDD) é algo bastante individual 

O TDD é uma prática muito individual: quem se sente produtivo usando TDD deve adotá-lo, e quem não se sente, não precisa usar. 

Definir TDD como uma obrigação para toda a empresa é considerado um erro, pois não é uma prática universal. Contudo, independente de fazer ou não TDD, é essencial automatizar os testes, garantindo uma boa cobertura e qualidade no desenvolvimento. 

Estimar o esforço necessário para testes de software depende do nível de senioridade da equipe

A relação entre esforço e tempo depende do nível de maturidade e senioridade do time. Em times mais maduros, o teste já está incorporado na estimativa, pois escrever testes e código de produção fazem parte do mesmo processo. 

Já em times iniciantes, recomenda-se primeiro aumentar a maturidade, promovendo aprendizado, implementando ferramentas adequadas e criando cobertura nos pontos críticos. 

Estimar separadamente o tempo de desenvolvimento e o de testes é visto como improdutivo e apenas uma etapa temporária, necessária enquanto a maturidade do time não evolui. 

Além disso, mesmo em times maduros, é importante planejar tarefas técnicas — como criar bibliotecas de apoio, test data builders e ferramentas para integração contínua — para manter a eficiência e a qualidade no desenvolvimento de testes. 

Experiência e criatividade andam lado a lado na escrita de testes automatizados 

As técnicas sistemáticas de testes e a criatividade se complementam no desenvolvimento de software. Quando alguém entra em um time sem conhecer bem o sistema, aplicar métodos sistemáticos ajuda a cobrir casos básicos e evidentes, mesmo sem experiência no domínio. 

No entanto, desenvolvedores mais experientes, com conhecimento acumulado, conseguem identificar casos específicos que não são óbvios para quem está começando. 

Para quem já conhece bem o sistema, a combinação entre técnicas sistemáticas e a própria experiência é essencial, pois a complexidade das funcionalidades pode fazer com que até profissionais experientes deixem passar detalhes importantes. 

Técnicas mais formais podem ser aplicadas para garantir uma cobertura mais completa, embora, no dia a dia, muitas vezes se resolva boa parte dos problemas com intuição e conhecimento prévio. 

Confiar apenas na intuição é arriscado, pois aumenta a chance de deixar passar falhas básicas, que acabam consumindo tempo que poderia ser dedicado a resolver problemas mais complexos. Por isso, a complementariedade entre métodos sistemáticos e experiência prática é fundamental para garantir qualidade e eficiência.