Por que (e como) automatizar testes SAP: GUI com Python e Fiori com Playwright

No SAP, um erro raramente fica restrito a uma tela: ele se propaga por finanças, compras, estoque e produção, com impacto direto na operação e no caixa. Validar manualmente cada mudança, atualização ou correção é lento, caro e arriscado. Automatizar os testes deixou de ser um luxo para virar necessidade.

Mas existe um detalhe que muita gente ignora: o SAP não tem uma interface só. Há o SAP GUI, o cliente desktop clássico, e o SAP Fiori, a interface web moderna. Cada um pede uma abordagem de automação diferente. Neste artigo mostramos por que automatizar testes SAP e como fazer na prática, automatizando o SAP GUI com Python e o Fiori com Playwright, e orquestrando tudo com o Proton.

Por que automatizar testes no SAP?

O custo de um defeito no SAP é alto e o ritmo de mudanças é intenso. Automatizar traz retorno rápido:

• Atualizações constantes: cada ciclo do S/4HANA pode afetar processos que já funcionavam.
• Projetos de migração: sair do ECC para o S/4HANA exige revalidar centenas de fluxos, inviável só no manual.
• Risco de regressão: uma mudança em um módulo pode quebrar outro sem ninguém perceber.
• Velocidade e escala: o que levaria dias de teste manual roda em minutos, a cada entrega, dentro do pipeline de CI/CD.
• Liberação de pessoas: o time deixa de repetir roteiros manuais e foca em análise e em casos de maior valor.

SAP GUI e SAP Fiori: duas frentes, duas abordagens

Antes de automatizar, é preciso saber o que se está testando. O SAP GUI é a aplicação desktop tradicional, com transações como VA01 ou ME21N. Já o Fiori é a camada web, construída sobre o SAPUI5 e organizada no Fiori Launchpad. A diferença é técnica e muda a ferramenta: o GUI se automatiza pela API de scripting nativa do SAP, enquanto o Fiori, por ser web, se automatiza com ferramentas de navegador. Um detalhe importante: os IDs de controle no SAP GUI são estáveis, o que facilita muito a automação; no Fiori, o UI5 gera IDs dinâmicos, o que exige estratégia.

Automação do SAP GUI com Python

O SAP GUI traz uma API de scripting que expõe cada elemento da tela de forma programável. Depois de habilitá-la (no servidor e no cliente), dá para controlá-la com Python usando a biblioteca pywin32, que conversa com o objeto de automação do Windows. O script se conecta a uma sessão já aberta e interage com os campos pelo ID do controle:

import win32com.client

# Conecta-se a uma sessao do SAP GUI ja aberta (Scripting habilitado)
sap_gui = win32com.client.GetObject("SAPGUI")
application = sap_gui.GetScriptingEngine
connection = application.Children(0)
session = connection.Children(0)

# Abre a transacao de criacao de pedido de vendas (VA01)
session.findById("wnd[0]/tbar[0]/okcd").text = "/nVA01"
session.findById("wnd[0]").sendVKey(0)

# Preenche os campos do pedido
session.findById("wnd[0]/usr/ctxtVBAK-AUART").text = "OR"     # tipo de documento
session.findById("wnd[0]/usr/ctxtVBAK-VKORG").text = "1000"   # organizacao de vendas
session.findById("wnd[0]").sendVKey(0)

# Le a barra de status para validar o resultado
status = session.findById("wnd[0]/sbar").text
assert "criado" in status.lower()

Os IDs como wnd[0]/usr/ctxtVBAK-AUART são consistentes entre execuções, o que torna os scripts de SAP GUI bastante estáveis. Essa abordagem é ideal para automatizar processos transacionais clássicos, que ainda concentram grande parte da operação em muitas empresas.

Automação do SAP Fiori com Playwright

Para a camada web, o Playwright é uma excelente escolha: tem espera automática nativa (essencial para lidar com o carregamento assíncrono via OData), execução paralela e suporte a múltiplos navegadores. O segredo é evitar os IDs gerados pelo UI5 e localizar elementos por papel de acessibilidade e texto visível:

import { test, expect } from '@playwright/test';

test('cria pedido de venda no Fiori', async ({ page }) => {
  await page.goto('https://meu-sap.exemplo.com/fiori#Shell-home');

  // Localiza pelo texto, nao pelo ID dinamico gerado pelo UI5
  await page.getByRole('button', { name: 'Criar Pedido de Venda' }).click();
  await page.getByLabel('Cliente').fill('1000');
  await page.getByRole('button', { name: 'Salvar' }).click();

  await expect(page.getByText('Pedido criado com sucesso')).toBeVisible();
});

Quando precisar mesmo de um ID, ancore no sufixo estável definido pela aplicação (por exemplo, page.locator('[id$="--btnSalvar"]')), nunca no prefixo volátil. Aprofundamos essa estratégia no guia de testes automatizados no SAP Fiori.

Orquestrando os cenários com o Proton

Aqui está o ponto que une tudo. Em um ambiente SAP real, você terá cenários no GUI (Python) e no Fiori (Playwright), rodando em vários ambientes e de forma recorrente. Mantê-los como scripts soltos em máquinas isoladas vira um caos. O Proton, a plataforma de automação da Atomic, resolve isso ao orquestrar todos esses cenários em um único lugar.

Em vez de gerenciar tecnologias separadas, a equipe ganha uma camada única de orquestração e visibilidade:

• Orquestra cenários de SAP GUI e de Fiori lado a lado, agendando e disparando as execuções de forma centralizada.
• Consolida resultados, relatórios e evidências de todos os fluxos em um painel único, facilitando auditoria e governança.
• Construído sobre tecnologias open source, evita o lock-in de uma ferramenta proprietária.
• Integra os testes às automações de RPA e ao CI/CD, conectando qualidade e operação.
• Escala a cobertura de processos sem multiplicar a complexidade.

Na prática, o Proton transforma scripts isolados em um processo de qualidade contínuo, com uma visão consolidada de quais processos do SAP passaram, quais falharam e onde estão os riscos.

O Proton na prática na automação SAP

Mais do que executar scripts, o Proton organiza toda a operação de automação em um só lugar. Veja como isso funciona em um cenário SAP real, do disparo ao diagnóstico do resultado.

Centro de Automação: tudo em um só painel

No Centro de Automação, cada grupo reúne automações de diferentes tipos, incluindo as de SAP (identificadas por tags como "sap"), com versão, prioridade, última execução e status (Passed, Failed, Running, Stopped). É a visão consolidada que mostra, de relance, a saúde de todos os processos.

Evidências de cada passo

Durante a execução, o Proton captura as telas do SAP, como esta do Fiori (S/4HANA Cloud) ao criar um pedido de venda. Essas evidências ficam anexadas ao resultado, o que facilita a auditoria e a investigação de problemas.

Linha do tempo da execução

A linha do tempo mostra cada componente do fluxo SAP na ordem em que rodou, com status e duração. No exemplo, o login (LoginSAPOne) passou, mas a etapa de criação do pedido (CreateSalesOrderV2) falhou, resultando em uma taxa de sucesso de 33%, com capturas de tela de cada etapa.

Detalhes do resultado e diagnóstico

Ao abrir um resultado, o Proton reúne o log completo, os componentes executados e as capturas de tela. É tudo o que a equipe precisa para diagnosticar rapidamente uma falha, sem ter que reproduzir o cenário manualmente.

Boas práticas para automação de testes SAP

• Comece pelos processos mais críticos e de maior risco para o negócio.
• No GUI, aproveite a estabilidade dos IDs; no Fiori, prefira localizadores por papel e texto.
• Use esperas inteligentes e mantenha dados e ambientes de teste controlados.
• Organize os cenários com padrões como o Page Object Model, tema que detalhamos no guia de automação com Selenium.
• Centralize execução e resultados no Proton e integre ao CI/CD para feedback a cada entrega.

Automatizar testes SAP protege os processos que sustentam a empresa e dá velocidade às mudanças, sem aumentar o risco. Com SAP GUI em Python, Fiori em Playwright e o Proton orquestrando os cenários, a Atomic Solutions, com 10 anos de mercado e cases como o da Gerdau, ajuda a sua empresa a chegar lá. Fale com a gente para automatizar o seu SAP de ponta a ponta.