Roadmap QA - AguiarDev Talks #24

Terceiro programa da série Roadmap, desta vez com foco em qualidade de software. Samanta Cicilia, Tech Lead na Pagar.me, e João Paulo Vieck, sócio diretor na Warmup, ajudam a traçar o caminho de quem quer entrar ou evoluir na área de QA — partindo dos fundamentos, passando por programação e automação, até chegar em integração contínua e testes não funcionais.

O que foi discutido

• Fundamentos antes da ferramenta — tipos de teste e técnicas de descoberta que sustentam qualquer estratégia de qualidade
• Arquitetura como bússola — entender componentes e fronteiras da aplicação para mapear riscos e cobertura
• Conhecimento de negócio — por que entender o que o software resolve é tão relevante quanto saber testar
• Programação para quem testa — aprender a linguagem e boas práticas antes de sair automatizando
• Tipos de teste e pirâmide de testes — unidade, integração, E2E, smoke, contrato, mutação e os limites da pirâmide como heurística
• Integração e entrega contínua — por que uma automação que só roda "na máquina de alguém" não escala
• Testes mobile e cross-device — os desafios de emuladores, device farms e a impossibilidade de cobrir 100% dos aparelhos
• Testes não funcionais e percepção de qualidade — performance, segurança, acessibilidade e como qualidade muda de acordo com o contexto do cliente

Sobre Samanta Cicilia e João Paulo Vieck

Samanta Cicilia é Tech Lead na Pagar.me e cofundadora do Agile Testers, um dos maiores fóruns brasileiros sobre qualidade de software, com canal no YouTube e podcast próprio. Também ajuda a organizar encontros do MOT (Ministry of Testing) em São Paulo e no Rio, a maior comunidade de teste do mundo. Ao longo da conversa, ela reforça a importância de aprender a linguagem e a arquitetura de uma aplicação antes de automatizar seus testes.

João Paulo Vieck é sócio diretor na Warmup e atua há bastante tempo com teste de software, com um foco forte em gestão de times de qualidade. Antes de migrar para a área técnica, veio de uma trajetória em negócios — trabalhou em bancos e integrações bancárias — o que dá a ele uma visão de consultor sobre o que o mercado realmente procura em profissionais de QA.

Principais pontos

Fundamentos vêm antes da ferramenta

Antes de qualquer ferramenta de automação, o roadmap começa pelos fundamentos: saber quais tipos de teste existem e quando cada um se aplica. Sem essa base, a tendência é tentar resolver todo problema com automação, mesmo quando a resposta certa seria outra abordagem, como um teste exploratório.

"Quando você sabe quais são os tipos de testes você consegue encaixar muito melhor a solução pra um problema que você tem, então a automação é muito importante, mas a automação não resolve todos os problemas; às vezes o que vai resolver o seu problema é um teste exploratório" por Samanta Cicilia

Aprenda a construir antes de testar

Entender a tecnologia que está sendo testada muda a qualidade dos testes escritos. Samanta conta que, ao começar a trabalhar com Node na Pagar.me, sua primeira ação não foi abrir uma ferramenta de teste — foi escrever uma aplicação própria, com API, testes de unidade, testes de integração e um pipeline completo, só para entender o que estava por trás daquilo que ela precisaria validar depois.

"Antes de eu pegar qualquer ferramenta para poder fazer teste, eu escrevi uma aplicação em Node, fiz uma API, fiz teste de unidade, teste de integração, fiz um pipeline" por Samanta Cicilia

Arquitetura mapeia onde estão os riscos

Conhecer o desenho de arquitetura de uma aplicação — mesmo que superficialmente — ajuda a enxergar fronteiras e componentes externos que talvez precisem de uma estratégia de teste diferente. Isso se torna ainda mais crítico em cenários de microsserviços e comunicação assíncrona, onde testar como se fosse um monolito simplesmente não funciona.

"Quando você entende da arquitetura, a comunicação que você está ali testando, você consegue muito mais fácil identificar quais são os riscos, quais são as fronteiras, até onde meu teste vai, onde é um componente externo que eu deveria testar de alguma outra forma" por Samanta Cicilia

De uma carreira de negócio para a era do teste

Nem todo profissional de QA vem da computação. João conta que migrou de uma carreira inteira em bancos e integrações bancárias para a área de testes, e que a transição exigiu aprender fundamentos que ele simplesmente não tinha — mesmo já dominando profundamente o negócio por trás dos sistemas que passou a testar.

"Eu vim da era de negócio e quando eu cheguei na era de teste, cara, eu tomei um susto, bicho, porque eu tinha que conhecer os fundamentos e eu não sabia nada de teste" por João Paulo Vieck

Automação que só roda numa máquina não é automação

Escrever testes automatizados é só metade do trabalho — se aquilo não roda de forma confiável fora do computador de quem escreveu, o time não ganha nada em confiabilidade. João relata o caso de um cliente cuja "automação" inteira dependia de uma única máquina, exigindo um esforço grande de integração para finalmente colocá-la em um pipeline real.

"Eu vi isso, a gente viu isso recente, estava num cliente e ele falou que toda automação dele funcionava em uma máquina" por João Paulo Vieck

Frase de destaque

"O mais importante que você tem que ter para entrar numa área de tecnologia, seja dev back-end, front-end, e olhar um mapa desse, a primeira coisa é coragem. O resto você vai pegando no meio, com o tempo. O que você precisa agora nesse momento é coragem, começa, e aí devagarinho você chega lá" por Samanta Cicilia

Lições do episódio

1. Antes de automatizar, entenda os tipos de teste e escolha a técnica certa para o problema — automação não é solução universal.
2. Aprender a linguagem e a arquitetura da aplicação que você testa importa tanto quanto dominar a ferramenta de teste.
3. Profissionais que vêm de áreas de negócio trazem valor real ao QA, mas ainda precisam construir a base técnica dos fundamentos.
4. Uma pirâmide de testes é um guia, não uma regra fixa — adapte a cobertura de unidade, integração e ponta a ponta à realidade da sua aplicação.
5. Automação só entrega valor quando roda de forma confiável em um pipeline compartilhado, não isolada na máquina de uma pessoa.
6. Qualidade é uma percepção que depende do contexto do cliente — performance crítica num sistema de pagamentos pode ser irrelevante num sistema interno de baixo uso.