Teste de regressão SAP: upgrades, releases e escopo

O teste de regressão SAP prova que uma mudança, um support package ou um novo release não quebrou processos de negócio que já funcionavam. Você define o escopo com análise de impacto, executa primeiro os processos de maior risco e o repete toda vez que o sistema muda, e não só uma vez antes do go-live.

Os gatilhos são transportes, upgrades e releases na nuvem. No SAP Cloud ERP public edition, é a SAP que define as datas de upgrade, então a sua suíte de regressão precisa estar pronta antes de o release chegar.

A regressão é um dos tipos de teste do meu guia de testes SAP. Este artigo cobre o que a dispara, como definir o escopo, quando automatizar e como impedir que um programa e o suporte em produção quebrem o trabalho um do outro.

O SAP é um sistema integrado. Uma mudança em uma condição de preço pode quebrar o faturamento, e um campo novo em uma ordem de venda pode parar uma interface. Um support package pode alterar um programa padrão de que você depende.

O teste de regressão executa de novo testes em processos que não deveriam mudar. O teste funcional pergunta se a novidade funciona, enquanto a regressão pergunta se todo o resto continua funcionando.

Ele vale para toda a vida do sistema, e não só durante um programa:

1. Transportes. Cada mudança levada do desenvolvimento para a qualidade é um risco de regressão para os processos que ela toca.
2. Support packages e feature packs. Correções e novas funcionalidades da SAP alteram o código padrão sob a sua configuração.
3. Upgrades de release. A passagem para um novo release, ou um release na nuvem que você não agendou, muda muito mais coisas de uma vez.
4. Conversões. Uma conversão de ECC para S/4HANA mantém a sua configuração e o seu código customizado, então tudo o que você manteve precisa ser testado de novo. O meu guia de migração de ECC para S/4HANA explica onde isso entra no plano.
5. Integrações e extensões. Uma mudança em um sistema conectado ou em uma extensão side-by-side pode quebrar o lado SAP sem nenhum transporte SAP.

Mantenha a suíte de regressão separada dos testes escritos para funções novas. A suíte é uma biblioteca estável dos processos que o negócio não pode se dar ao luxo de perder, como order to cash, procure to pay e o fechamento mensal.

On-premise, você escolhe quando fazer o upgrade. Nas edições em nuvem, a SAP define uma parte maior do cronograma, e o teste de regressão vira um compromisso recorrente no calendário.

Public edition: dois upgrades por ano

O SAP Cloud ERP public edition, antes S/4HANA Cloud Public Edition, recebe dois upgrades principais por ano, em fevereiro e agosto. Entregas menores de funcionalidades chegam entre eles.

A SAP faz o upgrade do sistema de teste primeiro e o de produção algumas semanas depois. Esse intervalo é a sua janela de regressão, e não há segunda chance depois que a produção recebe o upgrade.

O curso de Cloud ALM da SAP sobre testes pós-upgrade e de regressão recomenda criar um plano de teste de regressão no Cloud ALM e reutilizá-lo a cada release. A public edition também inclui uma ferramenta gratuita de automação de testes com scripts de teste pré-entregues, então os processos padrão têm um ponto de partida.

Private edition: um ciclo de release de dois anos

O SAP Cloud ERP Private, a private edition vendida pelo RISE with SAP, segue o ciclo de release on-premise. Segundo o SAP Learning, um novo release base sai a cada dois anos, feature pack stacks vêm a cada seis meses e cada release tem sete anos de manutenção padrão.

Você precisa instalar pelo menos um upgrade a cada sete anos para continuar na manutenção padrão, e o RISE permite solicitar um upgrade por ano. A SAP faz o upgrade técnico, mas o planejamento, a preparação e os testes continuam sendo trabalho do cliente ou do parceiro.

Essa divisão importa para o orçamento. O upgrade em si pode estar na assinatura, enquanto o teste de regressão em volta dele não está.

Esta tabela coloca os gatilhos de regressão lado a lado:

Mudança	Com que frequência	Quem define a data	O que a execução de regressão deve cobrir
Transporte para a qualidade	Diária ou semanal	A sua equipe	Os processos que os objetos alterados tocam
Upgrade da public edition	Duas vezes por ano, fevereiro e agosto	A SAP	Todos os processos no escopo, primeiro a lógica customizada, na janela antes da produção
Feature pack stack da private edition	A cada seis meses, se você aplicar	Você, dentro do cronograma da SAP	As funções padrão alteradas que você usa, mais o código customizado
Upgrade de release da private edition	Pelo menos a cada sete anos, até um por ano sob solicitação no RISE	Você, com a SAP	A suíte completa, o código customizado e as integrações
Conversão de ECC para S/4HANA	Uma vez	Você	Tudo o que você manteve

Executar a suíte completa depois de cada mudança é lento e caro. Executar pouco demais deixa defeitos passarem, e a lacuna aparece em produção.

A análise de impacto fica entre esses dois extremos. Ela compara o que mudou com o que você realmente usa e lista os processos e objetos de maior risco, para que a execução de regressão comece por eles.

Estas são as ferramentas que você vai encontrar:

1. SAP Solution Manager. O Business Process Change Analyzer, parte da Test Suite, mostra quais processos de negócio uma mudança afeta. O Scope and Effort Analyzer estima o impacto de um support package ou enhancement package antes da instalação, e a SAP o chama de ferramenta de planejamento.
2. SAP Cloud ALM. O Cloud ALM gerencia os planos de teste de regressão, a execução e os defeitos, e se conecta a ferramentas de automação. Para os upgrades da public edition, a ferramenta Release Assessment and Scope Dependency da SAP mostra quais mudanças de um release afetam o seu escopo.
3. Tricentis LiveCompare. Segundo a documentação do LiveCompare, ele identifica um conjunto mínimo de objetos de maior risco a testar e depois relata acertos e lacunas de teste em relação ao seu repositório de testes. A SAP o revende como SAP Change Impact Analysis by Tricentis, e ele se integra ao Tricentis Tosca.
4. Panaya. O produto de upgrade SAP da Panaya combina análise de impacto de mudanças, correção de código, gestão de testes e automação, e cobre versões do S/4HANA, feature pack stacks e support package stacks.

Verifique a situação do seu Solution Manager antes de construir sobre ele. O SAP Support informa que a manutenção padrão do Solution Manager 7.2 termina no fim de 2027. Os clientes que contratam a manutenção estendida do Business Suite 7 o mantêm até o fim de 2030, e a SAP recomenda migrar para o Cloud ALM antes do fim de 2027.

A análise de impacto estreita o escopo. Ela não o define sozinha, então mantenha um núcleo de processos críticos para o negócio que rodam todas as vezes, diga a ferramenta o que disser.

A minha comparação de ferramentas de teste e validação SAP cobre como esses produtos se encaixam e o que o seu contrato de suporte SAP já inclui.

A regressão é onde a automação de testes se paga, porque os mesmos testes rodam várias e várias vezes. Isso não significa que toda suíte de regressão deva ser automatizada.

A minha regra é simples. Quando há um grande número de casos de teste que exigem testes extensos e repetidos, automatize. Abaixo disso, o teste manual funciona bem.

Um cliente da public edition que executa uma suíte completa duas vezes por ano, mais os transportes entre elas, atinge esse patamar rapidamente. Um sistema pequeno na private edition que muda poucas vezes por ano talvez não.

Faça estas perguntas antes de comprar:

1. Quantos casos de teste de regressão você tem, e quantos deles rodam em cada ciclo?
2. Com que frequência você os executa, contando transportes, feature packs e upgrades, e não só upgrades de release?
3. Quanto tempo leva uma execução manual, e ela cabe dentro da janela de regressão?
4. Quem vai manter os scripts quando telas e processos mudarem?

A manutenção de scripts é o custo que as pessoas subestimam. Uma suíte automatizada que ninguém atualiza falha por motivos que não têm nada a ver com o sistema, e a equipe deixa de confiar nela.

Nos programas que liderei, as minhas equipes usaram Tricentis Tosca, Worksoft, Panaya, SAP Cloud ALM, SAP Solution Manager e UiPath. Escolha pela adequação aos seus sistemas e à sua equipe, não pela demonstração. O meu guia de automação de testes SAP cobre por onde começar e como avaliar o retorno.

O problema de regressão mais difícil em um programa SAP não é o ferramental. São dois fluxos de mudança passando pelos mesmos sistemas ao mesmo tempo.

Enquanto o programa constrói funções novas, o suporte em produção continua corrigindo a produção. Se os dois fluxos compartilham um único caminho de desenvolvimento e qualidade, uma correção do suporte pode quebrar os testes do projeto e uma mudança do projeto pode escapar para um release do suporte. Aí ninguém consegue dizer qual mudança causou uma falha.

A minha resposta é manter dois ambientes separados. Um é para o projeto e outro para a operação do dia a dia (BAU), para que as mudanças do suporte em produção e as do projeto sejam testadas separadamente.

Ambiente do projetoAmbiente da BAU

O que passa por eleAmbiente do projetoFunções novas, configuração e código customizado do programaAmbiente da BAUCorreções e pequenas mudanças no sistema em produção

Foco da regressãoAmbiente do projetoOs processos que o programa altera, mais a suíte centralAmbiente da BAUOs processos que cada correção toca, mais a suíte central

Vai para produçãoAmbiente do projetoNo go-live ou em uma onda de releaseAmbiente da BAUComo releases de suporte, no cronograma habitual

Dois ambientes resolvem a separação e criam uma tarefa nova. Cada correção da BAU também precisa chegar ao ambiente do projeto, ou o projeto entra em produção sem ela.

Planeje isso desde o início:

1. Faça o retrofit de cada mudança da BAU no ambiente do projeto em um ritmo fixo, e acompanhe cada uma.
2. Execute de novo os testes do projeto afetados depois de cada retrofit, e não só no final.
3. Congele as mudanças da BAU à medida que o cutover se aproxima, exceto correções urgentes que passam pelos dois ambientes.
4. Execute a suíte de regressão completa no ambiente do projeto antes do go-live, com dados mascarados em nível de produção.

O segundo ambiente custa dinheiro, mas também custa um go-live em que ninguém consegue dizer qual mudança quebrou o faturamento. A minha estratégia de testes do S/4HANA mostra onde os ciclos de regressão ficam ao lado dos testes de integração e de aceitação do usuário.

Construa uma suíte de regressão antes de precisar dela. Liste os processos que o negócio não pode se dar ao luxo de perder, escreva um teste para cada um e execute-os uma vez à mão para ver quanto tempo leva um ciclo completo.

Esse número diz se a próxima janela de upgrade é realista e se a automação vai compensar. Se você está no meio de um programa, verifique se as mudanças do projeto e da BAU compartilham um único caminho até a produção.

Se você quer uma visão independente sobre a sua abordagem de regressão ou o seu plano de upgrade, eu ajudo organizações com isso. Você pode entrar em contato comigo aqui.

O que é teste de regressão SAP?

Ele executa de novo testes em processos de negócio SAP que não deveriam mudar, para provar que um transporte, support package, upgrade ou novo release não os quebrou. Ele cobre fluxos integrados como order to cash e o fechamento mensal, e não só os objetos alterados.

Com que frequência o SAP Cloud ERP public edition precisa de teste de regressão?

Pelo menos duas vezes por ano, porque a SAP faz o upgrade da public edition em fevereiro e agosto. A SAP atualiza o sistema de teste primeiro e a produção algumas semanas depois, então a execução de regressão precisa terminar nesse intervalo. Os transportes entre os releases precisam de execuções próprias, menores.

Quem faz o teste de regressão em um upgrade da private edition do RISE with SAP?

A SAP faz o upgrade técnico. O planejamento, a preparação e os testes ficam com o cliente ou com o parceiro de implementação, então orce o esforço de regressão separadamente da assinatura.

Quais ferramentas ajudam a definir o escopo do teste de regressão SAP?

As ferramentas de análise de impacto comparam o que mudou com o que você usa. As opções comuns são o Business Process Change Analyzer e o Scope and Effort Analyzer no SAP Solution Manager, e a ferramenta Release Assessment and Scope Dependency para a public edition. Tricentis LiveCompare e Panaya fazem o mesmo trabalho, enquanto o SAP Cloud ALM gerencia os planos de teste de regressão e a execução.

O teste de regressão SAP deve ser automatizado?

Automatize quando houver um grande número de casos de teste que exigem testes extensos e repetidos. Abaixo disso, o teste manual funciona bem. Conte os seus casos de teste e com que frequência rodam antes de comprar uma ferramenta, e orce a manutenção dos scripts.

Como fazer teste de regressão durante um programa SAP enquanto se dá suporte ao sistema em produção?

Mantenha dois ambientes separados, um para o projeto e outro para a operação do dia a dia. As mudanças do suporte em produção e as do projeto são então testadas separadamente. Faça o retrofit de cada correção da BAU no ambiente do projeto e execute de novo os testes afetados.