Testes automatizados no SAP Fiori: por que importam e como fazer

O SAP roda o coração de muitas empresas: finanças, compras, estoque, logística e folha de pagamento passam por ele todos os dias. Quando uma atualização ou um ajuste quebra um desses processos, o impacto vai direto para a operação e para o caixa. É por isso que testar o SAP, especialmente sua interface web moderna, o Fiori, deixou de ser opcional.

Ainda assim, muitas empresas validam o SAP manualmente, um processo lento, caro e sujeito a falhas. Neste artigo mostramos por que vale a pena automatizar os testes do SAP Fiori, quais os desafios dessa tarefa, como usar frameworks open source como o Playwright e como o Proton entra para centralizar a execução e agregar os resultados. Se você quer o panorama mais amplo de automação no SAP, vale ler também por que automatizar testes SAP.

O que é o SAP Fiori?

O SAP Fiori é a camada de experiência do usuário do SAP, construída sobre o framework SAPUI5. Ele substitui as telas tradicionais do SAP GUI por aplicações web responsivas, organizadas no Fiori Launchpad, com tiles que dão acesso a cada processo. Por ser web, o Fiori abre a porta para automação de testes com as mesmas ferramentas usadas em qualquer aplicação moderna, desde que se conheçam suas particularidades.

Por que automatizar testes no SAP Fiori?

O argumento é simples: o custo de um defeito no SAP é alto e o ritmo de mudanças é intenso. Automatizar traz ganhos diretos:

• Atualizações frequentes: o S/4HANA recebe ciclos regulares de atualização, e cada um deles pode afetar processos existentes.
• Projetos de migração: migrar de ECC para S/4HANA exige revalidar centenas de fluxos, algo inviável só no manual.
• Risco de regressão: uma mudança em um módulo pode quebrar outro. Testes automatizados de regressão protegem o que já funcionava.
• Velocidade e escala: o que levaria dias de teste manual roda em minutos, a cada entrega, dentro do pipeline de CI/CD.
• Confiabilidade: processos críticos validados de forma consistente, sem depender da atenção humana em tarefas repetitivas.

Por que testar o SAP web é tão desafiador?

Automatizar o Fiori não é igual a automatizar um site comum. O SAPUI5 tem características que derrubam abordagens ingênuas de automação:

• IDs dinâmicos: o UI5 gera os IDs dos controles em tempo de execução. Um botão que hoje é __xmlview1--btnSalvar pode virar __xmlview2--btnSalvar amanhã, quebrando localizadores presos ao ID completo.
• DOM profundo e aninhado: os controles renderizam várias camadas de HTML, o que torna seletores baseados em estrutura frágeis.
• Carregamento assíncrono: as telas dependem de chamadas OData. Interagir antes de os dados chegarem é a principal causa de testes instáveis.

A boa notícia é que esses desafios têm solução, com a estratégia de localização certa e ferramentas que entendem o UI5.

Ferramentas open source para testar o SAP Fiori

O ecossistema de código aberto já oferece boas opções, cada uma com seu encaixe:

• OPA5: framework de testes de integração que faz parte do próprio SAPUI5, ideal para quem desenvolve as apps Fiori.
• wdi5: plugin baseado em WebdriverIO e focado em UI5, com APIs que entendem os controles do Fiori. É a alternativa recomendada no lugar do wdi5 UIVeri5, que foi descontinuado.
• Playwright e Playwright-SAP: o Playwright-SAP estende o Playwright com localizadores e helpers cientes do SAP, cobrindo Fiori Launchpad, UI5 e SAP WebGUI.

Para entender as diferenças entre frameworks de automação web em geral, vale conferir nosso comparativo de frameworks de automação.

Automatizando o SAP Fiori com Playwright

O Playwright é uma escolha forte para o Fiori por causa da espera automática nativa, que lida bem com o carregamento assíncrono do UI5, da execução paralela e do suporte a múltiplos navegadores. O segredo está em escolher bons localizadores. Em vez de depender dos IDs gerados, prefira papéis de acessibilidade e textos visíveis, que são estáveis:

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

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

  // Localize pelo texto do tile, não pelo ID gerado pelo UI5
  await page.getByRole('button', { name: 'Criar Pedido de Compra' }).click();

  // O auto-wait do Playwright aguarda o carregamento (OData) antes de agir
  await page.getByLabel('Fornecedor').fill('1000');
  await page.getByLabel('Material').fill('MAT-001');
  await page.getByRole('button', { name: 'Salvar' }).click();

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

Quando um controle só puder ser encontrado pelo ID, ancore na parte estável do ID definida pela aplicação, e não no prefixo volátil gerado pelo UI5. O seletor abaixo casa qualquer ID que termine com o sufixo desejado:

// Em vez de prender ao ID completo (__xmlview1--btnSalvar),
// use o sufixo estável definido na app
await page.locator('[id$="--btnSalvar"]').click();

Para manter a suíte organizada, aplique o Page Object Model, separando os localizadores e as ações de cada tela em classes. Essa e outras práticas estão no nosso guia de automação de testes com Selenium, e valem igualmente para o Playwright.

Estratégias para lidar com os IDs dinâmicos

Resumindo o que funciona na prática no Fiori:

• Prefira papéis de acessibilidade e textos visíveis (getByRole, getByLabel, getByText) em vez de IDs gerados.
• Quando precisar do ID, use seletores de sufixo estável (id termina com) em vez do ID completo.
• Considere ferramentas cientes do UI5, como wdi5 ou Playwright-SAP, que abstraem os controles do Fiori.
• Confie na espera automática e em condições explícitas para lidar com o carregamento OData, evitando tempos fixos.
• Defina IDs estáveis nas apps Fiori sempre que possível, ainda na fase de desenvolvimento.

Centralizando tudo com o Proton

Escrever os testes é metade do caminho. Em um cenário SAP real, com dezenas de processos, vários ambientes e execuções recorrentes, o desafio passa a ser orquestrar e enxergar tudo em um só lugar. É aí que entra o Proton, a plataforma de automação da Atomic.

Construído sobre tecnologias open source, o Proton permite centralizar a execução das automações do SAP Fiori, consolidar os resultados em um painel único e escalar os fluxos sem retrabalho. Em vez de scripts soltos rodando em máquinas isoladas, a equipe ganha visão consolidada de quais processos passaram, quais falharam e onde estão os gargalos, conectando os testes do Fiori ao restante da estratégia de qualidade e de RPA da empresa.

• Orquestração: agenda e dispara as automações de forma centralizada.
• Resultados agregados: consolida relatórios e evidências de todos os fluxos em um só painel.
• Escala: adiciona novos processos e ambientes sem multiplicar a complexidade.
• Integração: une os testes do Fiori às automações de RPA e aos demais fluxos de negócio.

Boas práticas para testes no SAP Fiori

• Comece pelos processos mais críticos e de maior risco para o negócio.
• Use localizadores estáveis e esperas inteligentes para combater a instabilidade.
• Mantenha dados e ambientes de teste controlados e independentes.
• Integre a suíte ao CI/CD e centralize a execução e os resultados no Proton.
• Trate a automação como parte da estratégia de Quality Assurance e da maturidade digital da empresa.

Conclusão

Testar o SAP Fiori de forma automatizada protege os processos mais importantes da empresa e dá velocidade às atualizações e migrações, sem aumentar o risco. Os desafios do UI5, como os IDs dinâmicos e o carregamento assíncrono, têm solução com a estratégia de localização certa e ferramentas open source como o Playwright. E, com o Proton, a empresa centraliza a execução e agrega os resultados, transformando testes isolados em um processo de qualidade consistente.

A Atomic Solutions tem 10 anos de mercado e experiência comprovada em automação no SAP, como no nosso case de sucesso com a Gerdau. Fale com a gente e descubra como automatizar os testes do seu SAP Fiori com o Proton.