Por Mara Costa
Um especialista responde — e a resposta vai te surpreender.
Quando o assunto é inteligência artificial e mercado de trabalho, raramente falta alarmismo. Manchetes proclamam o fim de profissões, fóruns de tecnologia se dividem entre profetas do apocalipse e entusiastas ingênuos. Mas Ricardo Polanski Alves não pertence a nenhum dos dois campos. Engenheiro de qualidade de software radicado em Curitiba, ele acumula passagens por empresas como Ericsson, CI&T e White Prompt — onde atende clientes nos Estados Unidos e na Europa — e vive hoje no cruzamento entre automação de testes, sistemas financeiros de alta criticidade e, cada vez mais, na fronteira onde a inteligência artificial precisa ser testada por quem entende de qualidade. Nesta entrevista exclusiva, ele desfaz mitos, coloca o dedo em feridas que o mercado prefere ignorar e apresenta uma visão que é, ao mesmo tempo, mais otimista e mais exigente do que qualquer uma das narrativas dominantes.
O PROFISSIONAL QUE TESTA O QUE OUTROS CONSTROEM — E QUE AGORA TESTA A PRÓPRIA IA
É uma tarde de quarta-feira quando Ricardo Polanski Alves entra na videochamada. Ao fundo, monitores com dashboards de cobertura de testes e um terminal aberto — o cenário de quem acabou de encerrar uma sessão de revisão de pipeline. Ele faz isso todos os dias: da sua base em Curitiba, conecta-se a equipes na Connecticut, em Frankfurt, em Minnesota, garantindo que sistemas financeiros e de saúde digital funcionem exatamente como deveriam — e que evidências disso estejam documentadas quando o regulador bater à porta.
A trajetória de Ricardo é uma linha direta do operacional ao estratégico. Começou como administrador de sistemas na CentralServer, gerenciando servidores Linux e infraestrutura AWS. Migrou para qualidade de software na CI&T, onde construiu do zero frameworks de automação com Selenium para sistemas de carteira digital e reembolso. Passou pela Ericsson, testando sistemas de faturamento de telecomunicações em escala global. Hoje, como QA Engineer na White Prompt, cuida do sistema de gestão de financiamentos da Libertas Funding LLC, nos EUA — um ambiente onde um bug não é apenas um inconveniente técnico, mas um evento com potencial de consequência financeira e regulatória imediata.
“Quando você testa um sistema financeiro de verdade, você para de pensar em testes como uma etapa do processo. Você começa a pensar como um mecanismo de proteção”, diz ele, escolhendo as palavras com cuidado. “E quando você traz IA para essa equação — seja para automatizar testes, seja para tomar decisões financeiras — o nível de responsabilidade não diminui. Ele sobe.”
A ENTREVISTA
Existe uma narrativa muito forte de que a IA vai eliminar profissões inteiras na tecnologia. Os testadores de software estão nessa lista?
Essa narrativa é poderosa porque tem um grão de verdade — mas apenas um grão. Sim, a IA está eliminando tarefas. Tarefas repetitivas, mecânicas, que não exigiam julgamento real. O testador que passava o dia executando manualmente os mesmos fluxos de login? Esse trabalho específico está desaparecendo — e honestamente, já deveria ter desaparecido há mais tempo.
Mas o trabalho de garantir que um sistema financeiro funcione corretamente, dentro das exigências regulatórias, sem expor dados de clientes, sem introduzir viés em decisões automatizadas? Esse trabalho está crescendo. E está crescendo justamente porque a IA está tornando os sistemas mais complexos e mais difíceis de validar. A pergunta certa não é ‘a IA vai substituir testadores?’. A pergunta certa é: que tipo de testador a IA está tornando obsoleto, e que tipo ela está criando? E a resposta, se você olhar honestamente para o mercado, é que ela está eliminando o testador operacional e criando uma demanda urgente pelo testador estratégico — aquele que entende de negócio, de regulação, de arquitetura. Esse profissional não está em risco. Está em falta.
“A IA está eliminando o testador operacional e criando uma demanda urgente pelo testador estratégico. Esse profissional não está em risco. Está em falta”.
Na sua trajetória — CI&T, Ericsson, White Prompt — como você viu essa transformação acontecer na prática?
De forma muito concreta. Na CI&T, quando eu estava trabalhando com sistemas de carteira digital e reembolso, a automação ainda era vista como algo auxiliar — um complemento ao teste manual. A gente construía frameworks Selenium do zero, integrava com Cucumber para BDD, e o grande desafio era convencer o time de que investir em automação valia o esforço de manutenção.
Na Ericsson, o contexto mudou completamente. Sistemas de faturamento de telecomunicações em escala global, integrados com Jenkins e AWS, com equipes distribuídas em vários países. Ali, automação não era uma opção — era infraestrutura. Qualquer release sem cobertura automatizada simplesmente não avançava no pipeline. E começamos a usar ferramentas analíticas para priorizar quais módulos testar primeiro com base no histórico de defeitos. Isso é IA aplicada a testes, mesmo que a gente não chamasse assim na época.
Hoje, na White Prompt, trabalhando com o sistema de gestão de financiamentos da Libertas Funding, a dimensão regulatória é central desde o primeiro dia. Não basta o Cypress passar. Precisa passar de uma forma que eu consiga mostrar a evidência, rastrear o comportamento, demonstrar que aquele fluxo financeiro específico foi validado de ponta a ponta. E é exatamente aí que a IA começa a entrar como aliada — mas também como objeto de auditoria.
Você usa Cypress como tecnologia principal. Como a IA está mudando a forma de trabalhar com frameworks como esse?
O Cypress é um bom exemplo de como a IA está sendo integrada às ferramentas que já usamos, em vez de substituí-las. Nos últimos dois anos, surgiram capacidades baseadas em IA que mudaram partes significativas do meu dia a dia.
A mais impactante, na prática, é o self-healing de seletores. Antes, quando o front-end mudava — o que em ambientes ágeis acontece toda semana — um seletor quebrado significava horas de manutenção. Hoje, ferramentas com IA identificam o elemento correspondente na nova versão da interface e atualizam o teste automaticamente. Isso liberou uma quantidade enorme de tempo que eu agora dedico a desenhar estratégias de teste mais robustas.
A segunda mudança é na geração de casos de teste. Ferramentas baseadas em modelos de linguagem conseguem ler a documentação de um sistema e sugerir cenários que um testador humano demoraria dias para especificar. Eu uso isso como ponto de partida — nunca como ponto de chegada. Porque a IA não sabe que em um sistema de financiamento, um cenário aparentemente simples de ‘aprovar um pedido’ pode ter dezenas de variações regulatórias dependendo do perfil do cliente, do estado americano e do tipo de produto financeiro. Esse conhecimento de domínio é meu.
“A IA não sabe que em um sistema de financiamento, um cenário aparentemente simples pode ter dezenas de variações regulatórias. Esse conhecimento de domínio é meu”.
Você também trabalha com sistemas de diagnóstico por imagem com IA, no IEBT para a Vidalink Diagnostics, nos EUA. Como é testar um sistema em que a IA é o produto?
Essa é a fronteira mais fascinante — e mais desafiadora — da minha carreira atual. Na Vidalink, a plataforma usa IA para quantificar biomarcadores de imagem e apoiar pesquisas clínicas. A IA não é uma ferramenta auxiliar: ela é o produto. E isso muda completamente o que significa garantir qualidade.
Em um sistema tradicional, você testa comportamento determinístico: dada a mesma entrada, espera a mesma saída, e escreve um caso de teste para isso. Um modelo de ML para análise de imagens não funciona assim. Ele produz probabilidades. Seu comportamento pode mudar sutilmente se o modelo for retreinado com novos dados. E o que é ‘correto’ muitas vezes depende de consenso clínico, não de uma regra de negócio explícita.
Então o meu trabalho com Playwright nesse contexto envolve validar não só se a interface responde corretamente, mas se os outputs do modelo estão dentro de intervalos estatisticamente esperados para determinados inputs de referência, se as evidências geradas são suficientes para uso em contextos de pesquisa regulada, e se o sistema como um todo se comporta de forma consistente ao longo do tempo. É uma dimensão de qualidade completamente diferente — e que a indústria ainda está aprendendo a definir.
Quais são os maiores erros que você vê empresas cometendo ao adotar IA em seus processos de qualidade?
O primeiro erro, e o mais comum, é confundir cobertura com qualidade. Métricas de cobertura de código são um proxy útil, mas perigoso se interpretado isoladamente. Eu já vi projetos com mais de 90% de cobertura que liberaram para produção com bugs críticos em fluxos de pagamento — porque os testes cobriam linhas de código, não comportamentos de negócio. A IA pode gerar casos de teste em escala, mas se você não definir o que é crítico testar, ela vai gerar muito e validar pouco do que importa.
O segundo erro é reduzir o time de QA antes de ter maturidade para isso. Vi isso acontecer em pelo menos duas empresas que conheço de perto. A lógica era: ‘temos automação com IA, precisamos de menos testadores’. O que aconteceu foi que os testes proliferaram sem critério, a manutenção virou um fardo, e os defeitos críticos continuaram escapando porque ninguém com conhecimento de domínio estava no loop. Automação sem estratégia é só caos mais rápido.
O terceiro, que é específico de ambientes financeiros, é não considerar a IA como objeto de auditoria. Se você usa uma ferramenta baseada em IA no seu pipeline de testes em um ambiente regulado, ela tem acesso ao seu ambiente de desenvolvimento. Quais dados ela processa? Os logs que ela gera cumprem os requisitos de trilha de auditoria? A maioria das empresas não faz essas perguntas. E os reguladores — cedo ou tarde — vão fazer.
| “Automação sem estratégia é só caos mais rápido”. |
Sua trajetória começa em Curitiba, passa por Ericsson em Frankfurt, White Prompt em Connecticut, IEBT em Minnesota — tudo remoto. O que essa globalização do trabalho de QA significa para quem está começando?
Significa que a barreira geográfica, que antes era o maior limitador para um profissional brasileiro de tecnologia, praticamente desapareceu. Quando eu comecei como administrador de sistemas na CentralServer, em Curitiba, o teto era o mercado local. Hoje, trabalhando remotamente para clientes nos EUA e na Europa, o benchmark que eu preciso atingir é global — e isso é simultaneamente mais exigente e mais justo.
Mais exigente porque a barra técnica não tem concessões geográficas. Um cliente em Connecticut espera o mesmo nível de um QA Engineer que estaria em São Francisco. Mais justo porque mérito e habilidade falam mais alto do que localização. E profissionais brasileiros, na minha experiência, têm uma capacidade muito forte de adaptação a contextos complexos e a comunicação com múltiplas culturas — o que em ambientes de QA distribuídos é uma vantagem real.
Para quem está começando: o inglês não é diferencial, é pré-requisito. Não o inglês de turismo — o inglês técnico e de negócios, que permite você participar de uma discussão sobre requisitos com um product owner americano e depois escrever uma análise de impacto que o time de compliance vai usar. Esse é o inglês que abre portas globais.
Para o profissional de QA que está lendo essa entrevista e com medo do futuro, qual é a sua mensagem?
A mensagem honesta — não a confortável, mas a honesta — é que o medo é legítimo se você está parado. Se você ainda está no modelo de testador manual que executa scripts repetitivos sem entender por que está testando aquilo, sim, esse modelo está sendo substituído. E a janela para se reposicionar não é infinita.
Mas a mensagem real é que nunca houve, na história da engenharia de software, um momento de maior demanda por profissionais de qualidade verdadeiramente qualificados. O mercado está cheio de pessoas que sabem usar Cypress ou Selenium. Está com fome de pessoas que sabem desenhar uma estratégia de testes para um sistema financeiro distribuído, que consigam conversar com o produto, com compliance e com o desenvolvedor ao mesmo tempo, e que entendam que a qualidade de um sistema financeiro tem consequências reais na vida de pessoas reais.
Então minha mensagem concreta é: vá fundo nos domínios onde a qualidade é crítica. Aprenda sobre sistemas financeiros, sobre sistemas de saúde, sobre infraestrutura crítica. Aprenda a fazer as perguntas que a IA não consegue formular sozinha. Porque a pergunta mais importante em qualidade de software nunca foi técnica: foi sempre ‘estamos testando a coisa certa?’ — e essa pergunta continua sendo humana.
Para fechar: se você pudesse resumir em uma frase o papel do testador de software na era da IA, como seria?
“O testador de software na era da IA não é mais só o guardião da qualidade do sistema — é o guardião da confiança que as pessoas depositam nele.” Ele faz uma pausa. “E confiança, por definição, precisa de um ser humano para ser construída e para ser cobrada.”
O QUE FICA DA CONVERSA
Quando a chamada encerra, sobra uma sensação que não é exatamente conforto — mas é algo mais útil: clareza. Ricardo Polanski Alves não oferece o anestésico de que “tudo vai ficar bem” nem o veneno de que “nada vai sobrar”. Oferece algo mais raro: uma análise ancorada em experiência concreta, de quem constrói frameworks de automação de manhã, responde a requisitos de compliance à tarde e, à noite, pesquisa como auditar os próprios algoritmos que estão mudando a profissão.
Sua trajetória — de administrador de servidores Linux em Curitiba a QA Engineer atendendo clientes nos EUA e na Europa — é, ela mesma, um argumento contra a narrativa da substituição. Cada salto na sua carreira foi impulsionado não pelo domínio de uma ferramenta, mas pela capacidade de entender contextos cada vez mais complexos e de fazer perguntas que as ferramentas, sozinhas, não fazem.
A IA vai transformar profundamente o trabalho de quem testa software. Já está transformando, e Ricardo é o primeiro a reconhecer isso — inclusive como usuário ativo dessas ferramentas. Mas o que ele articula com precisão é que essa transformação não está reduzindo a necessidade de inteligência humana aplicada à qualidade. Está relocalizando essa necessidade para um território mais exigente, mais estratégico e mais escasso em profissionais realmente preparados.
“A IA precisa de alguém que entenda o suficiente para desconfiar dela”, ele disse, em um dos momentos mais reveladores da conversa. “Desconfiar bem — com método, com critério e com responsabilidade — é o trabalho mais humano que existe em tecnologia hoje.”
QUEM É RICARDO POLANSKI ALVES
▶ QA Engineer radicado em Curitiba, PR, com mais de 8 anos de experiência em qualidade de software.
▶ Atualmente alocado na Libertas Funding LLC (Connecticut, EUA) pela White Prompt, onde lidera automação de testes do sistema de gestão de financiamentos com Cypress e TypeScript.
▶ SDET na Vidalink Diagnostics (Minnesota, EUA) pela IEBT, desenvolvendo frameworks Playwright para plataforma de IA aplicada a pesquisas clínicas.
▶ Ex-QA Engineer na Ericsson (Frankfurt, Alemanha), onde testou sistemas de faturamento de telecomunicações em escala global com Selenium, Jenkins e AWS.
▶ Ex-CI&T, onde construiu frameworks de automação do zero para sistemas de carteira digital e reembolso.
▶ Formado em Análise de Sistemas pela UNIBRASIL e pós-graduado em Administração de Banco de Dados pela PUCPR.
▶ Inglês C1, com atuação profissional diária em contextos internacionais.
▶ Pesquisador na interseção entre IA, qualidade de software e conformidade regulatória em sistemas financeiros e de saúde digital.
5 VERDADES QUE RICARDO POLANSKI ALVES QUER QUE O MERCADO SAIBA
▶ A IA substitui tarefas de teste — não o julgamento sobre o que merece ser testado.
▶ Cobertura de código não é sinônimo de qualidade. Um sistema pode ter 90% de cobertura e falhar catastroficamente em produção.
▶ Em sistemas financeiros regulados, a accountability é sempre humana — alguém assina por baixo de cada decisão.
▶ Auditar algoritmos de IA é a nova fronteira do QA — e o mercado global está com fome de profissionais preparados para isso.
▶ A pergunta mais importante em qualidade de software nunca foi técnica: sempre foi ‘estamos testando a coisa certa?’
