Ep. 22 - Testes automatizados num mundo cada vez mais digital

Este episódio recebe dois convidados que são referências brasileiras em testes automatizados: Júlio de Lima e Elias Nogueira, que na época morava há seis meses na Holanda. Os dois já trabalharam juntos anteriormente, num projeto curioso de automação sobre o WhatsApp, em que dois profissionais de qualidade construíram, sozinhos, tanto o back-end quanto o front-end de um sistema de envio automático de mensagens, um exemplo prático de como os dois já operavam além da caixinha tradicional de 'QA só testa'.

Esse ponto de partida leva à primeira reflexão do episódio: em vez de pensar em papéis fixos como 'dev' e 'QA', os convidados defendem a ideia de que todos são engenheiros de software com uma especialidade, capazes de atuar em diferentes frentes com foco principal em qualidade. É citado o exemplo do Nubank, onde não existe contratação específica para o cargo de QA: contratam-se engenheiros de software, e quem tem mais afinidade com qualidade aplica essas habilidades dentro do time. É destacado, porém, que isso só funciona quando há apoio real da gestão para investir tempo em testes e automação: não é suficiente decidir 'não vou mais contratar QA' sem antes construir a cultura, o conhecimento e os frameworks de teste que sustentam essa mudança.

A pergunta central do episódio é: que problema estamos tentando resolver com testes automatizados num mundo cada vez mais digital? A resposta direta é time to market. Num mercado onde qualquer aplicativo ou banco digital tem inúmeros concorrentes prontos para receber um usuário insatisfeito, a capacidade de entregar funcionalidades rapidamente, com qualidade, é o que garante sobrevivência competitiva, e só é possível alcançar essa velocidade automatizando processos, sendo os testes automatizados uma parte crucial disso, dando feedback rápido sobre se uma aplicação está pronta para ser entregue.

O apresentador conta sua própria experiência: nunca foi mandado por ninguém a escrever testes automatizados, mas percebeu a necessidade sozinho quando, depois de entregas semanais bem-sucedidas, o time foi forçado a reduzir a frequência de releases para duas vezes por ano, sinal de que a dívida técnica acumulada estava colocando em risco tudo que já funcionava a cada nova entrega.

A conversa então inverte a pergunta: que problemas a própria cultura de testes automatizados pode criar? O primeiro é a falta de preparo das empresas para dar manutenção contínua aos scripts de teste e à infraestrutura necessária para executá-los: muitas empresas começam a automatizar por hype ('quero ter automação porque o Nubank tem'), sem entender que cada script automatizado exige esforço contínuo de manutenção, e esse esforço compete diretamente com tempo de entrega de novas funcionalidades. O segundo problema é acreditar que automação de testes é responsabilidade exclusiva do QA, quando, na verdade, uma vez criado, esse ativo deve ser mantido por todo o time, não apenas por quem o escreveu originalmente.

Os convidados também discutem o risco de qualquer área trabalhar isolada dentro dos domínios da agilidade, seja a galera de qualidade que foca em automação sem conversar com produto e negócio, seja a galera de produto e cultura que ignora completamente o domínio técnico. É levantado que boa parte do movimento ágil atual tem investido fortemente em gerenciamento de produto e facilitação, mas deixado a parte técnica de lado, quando, na origem do Manifesto Ágil, há uma base muito forte de práticas de engenharia, como as do Extreme Programming (XP). A visão defendida é que qualquer time buscando bom time to market com qualidade precisa estar pautado, antes de tudo, por práticas de engenharia de software sólidas: frameworks de gestão como Scrum ou Kanban vêm depois, como estrutura de coordenação, não como coração do processo.

Sobre como começar na prática, a recomendação inicial é usar métricas: identificar onde estão as maiores concentrações de defeitos na aplicação e onde o usuário realmente mais interage, para priorizar automação com foco em impacto real em vez de tentar automatizar tudo indiscriminadamente. Também é discutida uma abordagem de priorização por risco, feita em conjunto entre QA, time técnico e negócio, avaliando impacto e probabilidade de cada risco potencial para decidir onde concentrar esforço de automação numa determinada sprint.

Outro ponto importante levantado é pensar além do usuário final como único 'cliente' dos testes: dev, CTO e PO também são clientes internos, cada um com expectativas diferentes. O PO espera que os caminhos mais comuns do usuário estejam cobertos; o CTO espera saúde da infraestrutura e código com boa manutenibilidade; o dev ao lado espera cobertura adequada do que foi codificado. Mapear essas personas internas ajuda a expandir o escopo dos testes para além do puramente funcional, incluindo testes não funcionais.

Sobre ferramentas, é reforçado que a escolha específica importa menos do que resolver o problema real: seja em Java, Python, TypeScript ou qualquer outra linguagem, o que importa é que a ferramenta resolva o problema identificado. Ainda assim, são citadas ferramentas concretas usadas no dia a dia dos convidados: Selenium WebDriver para testes funcionais de interface web, REST Assured para testes de API, reforçando que, especialmente em tempos de marketplaces e integrações entre sistemas, testar comunicação entre APIs é tão importante quanto testar a interface visual, já que boa parte das transações de grandes players como a Amazon acontece via comunicação entre sistemas, não pela tela. Para aplicativos móveis, é citado o Appium, que usa o mesmo protocolo do WebDriver, e uma tendência mais recente de usar Machine Learning para identificar elementos de interface automaticamente, dispensando a necessidade de identificadores técnicos fixos criados pelo desenvolvedor.

Os convidados recomendam fortemente consumir e apoiar conteúdo nacional sobre testes de software, citando a tendência de supervalorizar referências estrangeiras enquanto excelentes profissionais brasileiros, inclusive trabalhando em grandes empresas internacionais, permanecem pouco conhecidos dentro da própria comunidade brasileira.

Para encerrar, a mensagem final de Júlio resume a essência do episódio: o mercado evoluiu a ponto de exigir que atividades antes tratadas como papéis separados (dev versus QA) se tornem cultura compartilhada por todo o time; quem é QA precisa entender desenvolvimento, e quem desenvolve precisa entender qualidade. A automação só funciona de verdade com apoio de infraestrutura, apoio de gestão e, principalmente, engajamento coletivo, porque o produto só está pronto quando chega, funcionando, às mãos do cliente.