Estratégia de testes do S/4HANA: ciclos, critérios e papéis

Uma estratégia de testes do S/4HANA decide quais ciclos de teste você executa, em que ordem, quem é o responsável por cada um e que evidência permite passar de um para o outro. Nos meus programas, ela cobre o teste de integração de sistemas (SIT) em rodadas, o teste de aceitação do usuário (UAT) em rodadas e o teste de regressão, cada um com critérios de entrada e saída escritos e uma aprovação com nome.

Os testes consomem cerca de 35 por cento do esforço nos programas S/4HANA que eu planejo, então a estratégia merece tanto cuidado quanto o plano de construção.

Os tipos de teste em si estão no meu guia testes SAP explicados. Este artigo é a camada da estratégia: ciclos, critérios, papéis e a estrutura do documento.

O SAP Activate coloca a maior parte dos testes no Realize. O próprio material de estratégia de testes da SAP para o S/4HANA Cloud Private Edition trata os testes unitários e de string como informais. Os testes completos de processos de negócio, de integração, de migração de dados e de aceitação do usuário são formais e precisam ser documentados.

Esta é a sequência que eu planejo em um programa S/4HANA:

Ciclos de teste do S/4HANA

1. 01

   Unitário e string

   Os consultores testam cada função configurada e cadeias curtas à medida que constroem.

2. 02

   Rodadas de SIT

   Cadeias de processo completas entre módulos, interfaces e dados migrados.

3. 03

   Rodadas de UAT

   Os usuários de negócio provam que o sistema executa os seus processos, rodada a rodada.

4. 04

   Regressão

   Testar de novo o que já passou, depois de correções, transportes e releases.

5. 05

   Conversões simuladas e ensaio

   Executar o cutover como ele vai acontecer na noite real, com base no checklist.

6. 06

   Go-live

   Entrar em produção só quando o checklist de cutover acordado estiver completo.

Testes unitários e de string

Consultores e desenvolvedores testam cada item de configuração e cada desenvolvimento à medida que o constroem. Os testes de string encadeiam alguns passos, como uma ordem de venda até a remessa.

Informais nos termos da SAP, mas não opcionais.

Teste de integração de sistemas em rodadas

O SIT testa processos de negócio completos entre módulos, interfaces e dados convertidos ou carregados. Eu o planejo em rodadas, e não como um evento único, para que os defeitos corrigidos depois de uma rodada sejam testados de novo na seguinte.

Eu não tenho um número fixo de rodadas de SIT. A quantidade depende do número de processos, interfaces e entidades no escopo, e a estratégia deve dizer quantas rodadas e por quê.

Teste de aceitação do usuário em rodadas

O UAT é onde o negócio confirma que o sistema executa os seus processos, com as suas próprias pessoas e dados realistas. Assim como o SIT, eu o planejo em rodadas, para que as correções de uma rodada sejam testadas de novo na seguinte.

O UAT precisa de pelo menos 6 a 8 semanas. Os testadores do negócio fazem isso junto com o trabalho normal, e precisam de tempo para mais de uma rodada. O meu guia de teste de aceitação do usuário no SAP cobre roteiros, rodadas e aprovação em detalhe.

Teste de regressão

Cada correção, transporte e release pode quebrar algo que já tinha passado. O teste de regressão executa de novo os processos que importam depois de cada mudança, durante o programa e depois do go-live.

O material da SAP coloca a regressão principalmente no Run, depois de upgrades de release, mas um programa também precisa dela antes. A abordagem, a análise de impacto e a configuração dos ambientes estão no meu guia de teste de regressão SAP.

Conversões simuladas e ensaio de cutover

Em uma conversão brownfield, eu planejo três conversões simuladas antes do cutover. Cada uma testa a própria conversão, os tempos e a reconciliação, e não só os processos.

O último ensaio deve rodar como a noite real: mesma sequência, mesmas pessoas, mesmo checklist. O meu cronograma de migração e plano de projeto S/4HANA mostra onde essas execuções ficam no plano.

A decisão de responsabilidade mais importante de todas: o negócio é o dono do teste de aceitação do usuário. Não o integrador de sistemas, e não a TI.

Um integrador pode preparar roteiros e corrigir defeitos. Só as pessoas que conduzem o seu fechamento financeiro, o seu order to cash ou a sua fábrica podem confirmar que esses processos funcionam.

A própria orientação da SAP aponta na mesma direção. Os especialistas de configuração do parceiro criam os casos de teste, e os especialistas das áreas de negócio do cliente executam o UAT e registram os resultados.

É assim que eu dividiria a responsabilidade entre os ciclos:

Ciclo	Responsável	Executa	Aprova
Unitário e string	Líder da equipe de construção	Consultores e desenvolvedores	Líderes funcionais e técnicos
Rodadas de SIT	Gerente de testes	Consultores, com usuários-chave entrando nas rodadas finais	Gerente de testes e donos de processo
Rodadas de UAT	O negócio, por meio de donos de processo nomeados	Usuários-chave e testadores do negócio	Donos de processo, depois o patrocinador
Regressão	Gerente de testes	Equipe de testes, com automação onde o volume justificar	Gerente de testes e comitê de mudanças
Conversões simuladas e ensaio	Líder de cutover	Equipes técnica, de dados e funcional	Líder de cutover, líder de dados e patrocinador

Escreva na estratégia os nomes, e não os papéis. “Dono do processo financeiro” é um papel; uma pessoa com nome que aceitou assinar é um responsável.

Os critérios de entrada impedem que um ciclo comece antes de poder ter sucesso. Os critérios de saída impedem que ele termine só porque o calendário mandou.

Escreva os dois antes de o Realize começar, enquanto ninguém está sob pressão de prazo. O meu guia de quality gates no SAP explica como esses critérios viram gates formais com um responsável que pode dizer “não está pronto”.

A tabela abaixo é uma orientação para adaptar, não um padrão para copiar. Defina os percentuais e os limites de defeitos com o seu patrocinador e registre-os na estratégia:

Ciclo	Critérios de entrada	Critérios de saída
Unitário e string	Desenho aprovado; configuração e desenvolvimento concluídos para os itens em teste	Todos os itens testados e documentados; defeitos corrigidos ou registrados para o SIT
Rodada de SIT	Teste unitário concluído para os processos no escopo; ambiente de teste construído e interfaces conectadas; dados de teste carregados; roteiros revisados	Parcela acordada de roteiros executada e aprovada; nenhum defeito crítico aberto; cada defeito menor em aberto tem um responsável e uma data de correção
Rodada de UAT	Critérios de saída do SIT atendidos; testadores do negócio nomeados e liberados do trabalho do dia a dia; roteiros revisados pelos donos de processo; treinamento no sistema de teste realizado	Cada processo no escopo executado pelos usuários de negócio; nenhum defeito crítico aberto; os donos de processo assinaram os seus processos
Regressão	Uma mudança, um lote de correções ou um release pronto para avançar; pacote de regressão acordado para os processos afetados	Pacote de regressão aprovado; qualquer falha corrigida e testada de novo antes de a mudança avançar
Conversão simulada ou ensaio	Cópia de produção disponível; checklist de cutover e run book redigidos; regras de reconciliação acordadas	Conversão ou carga concluída dentro da janela planejada; reconciliação assinada pelo líder de dados; checklist atualizado com as lições aprendidas
Go-live	Todos os critérios de saída anteriores atendidos; checklist de cutover acordado com antecedência	Cada item do checklist concluído e assinado; go ou no-go registrado pelo patrocinador

Duas regras fazem a tabela funcionar. Cada critério dá uma resposta de sim ou não, e cada saída tem um signatário com nome.

Se um ciclo não atingir os seus critérios de saída e o negócio ainda quiser avançar, transforme isso em uma decisão por escrito. Registre o nome de quem aceitou o risco e os defeitos levados adiante.

O gerente de testes o escreve no Prepare ou no início do Explore, e o patrocinador o aprova. Mantenha-o curto o bastante para que os donos de processo o leiam.

Estas são as seções que espero ver:

1. Escopo e objetivos. Quais processos, entidades, interfaces e relatórios são testados, e quais ficam explicitamente de fora.
2. Tipos e ciclos de teste. Unitário, string, rodadas de SIT, rodadas de UAT, regressão, desempenho, testes de migração de dados e conversões simuladas, com o número de rodadas e a justificativa.
3. Cronograma e esforço. Datas de cada ciclo dentro do plano do SAP Activate, com pelo menos 6 a 8 semanas para o UAT, e o esforço orçado com base na parcela de cerca de 35 por cento destinada aos testes.
4. Papéis e responsabilidades. A tabela de responsabilidades acima, com nomes.
5. Critérios de entrada e saída. Um conjunto por ciclo, com o signatário de cada um.
6. Ambientes. Quais sistemas são usados em cada ciclo, como são atualizados e como as mudanças do projeto são mantidas separadas das mudanças do suporte em produção.
7. Dados de teste. De onde vêm os dados, como são mascarados e como são atualizados entre as rodadas. O meu guia de gestão de dados de teste SAP cobre isso em profundidade.
8. Gestão de defeitos. Definições de severidade, cadência de triagem, quem decide a prioridade e o prazo-alvo de correção por severidade.
9. Ferramentas. Onde ficam os casos de teste, os resultados, os defeitos e as aprovações, com um único sistema de registro.
10. Abordagem de automação. Quais testes são automatizados, quais continuam manuais e por quê.
11. Relatórios. O que o relatório semanal de testes mostra e quem o recebe.
12. Critérios de cutover e go-live. O checklist de cutover, os ensaios que o comprovam e quem toma a decisão de go ou no-go.
13. Riscos e premissas. Disponibilidade dos testadores, datas dos ambientes, prontidão dos dados e dependências de terceiros.

Quanto às ferramentas, o SAP Cloud ALM é o padrão para programas novos. A SAP afirma que não há licença separada para o SAP Cloud ALM: ele está incluído no Enterprise Support, e os seus apps de gestão de testes guardam os casos de teste formais, as execuções e os resultados.

O SAP Solution Manager 7.2 ainda é usado em muitos programas, mas a sua manutenção padrão termina no fim de 2027. Para automação, a SAP vende o SAP Test Automation by Tricentis, que funciona com o Cloud ALM; a minha comparação de ferramentas de teste SAP cobre a escolha mais ampla.

A falha de testes mais comum que vejo é testar pouco no UAT e no SIT.

Um mecanismo comum: a construção atrasa, a data do go-live continua fixa e as semanas saem dos ciclos de teste, porque eles ficam no fim do plano.

Estes são os padrões que causam isso, e o que fazer com cada um:

1. O SIT começa antes de o teste unitário terminar. A primeira rodada de SIT vira uma rodada de teste unitário. Mantenha os critérios de entrada.
2. O UAT é planejado para duas ou três semanas. Os usuários de negócio não conseguem testar direito junto com o trabalho do dia a dia nesse tempo. Planeje pelo menos 6 a 8 semanas e libere os testadores.
3. O integrador executa o UAT pelo negócio. Os roteiros passam, e o negócio encontra as lacunas depois do go-live. Mantenha a responsabilidade pelo UAT com os donos de processo.
4. Os testes são orçados como um item pequeno. Com cerca de 35 por cento do esforço, testes orçados em uma fração disso são os primeiros a serem cortados.
5. Os critérios de saída são escritos durante o ciclo. Eles acabam coincidindo com o que a equipe conseguiu fazer. Escreva-os antes do Realize.
6. O go-live é decidido pela confiança, não por um checklist. Ninguém consegue mostrar o que foi acordado, então ninguém consegue dizer o que está faltando.

Esse último ponto é aquele em que eu insisto. O meu critério de go-live é um checklist de cutover detalhado, acordado com antecedência com o negócio, a TI e o integrador.

Ele cobre passos técnicos, cargas de dados, reconciliações, validações do negócio, troca de interfaces, acesso dos usuários e pontos de go ou no-go. Se um item não está concluído e assinado, o programa não está pronto, diga a data o que disser.

Antes de o Realize começar, peça ao seu gerente de testes o documento de estratégia de testes e compare-o com a estrutura acima. Se ele não tiver um responsável nomeado pelo UAT, der ao UAT menos de 6 a 8 semanas ou não tiver critérios de entrada e saída por ciclo, corrija isso primeiro.

Se você quer uma revisão independente de uma estratégia de testes ou de um checklist de go-live, eu ajudo organizações com isso. Você pode entrar em contato comigo aqui.

O que é uma estratégia de testes do S/4HANA?

É o plano que decide quais ciclos de teste são executados, em que ordem, quem é o responsável e quem aprova cada um e que evidência permite ao programa passar de um ciclo para o seguinte. Em um programa S/4HANA, ela normalmente cobre testes unitários e de string, rodadas de SIT, rodadas de UAT, regressão, testes de migração de dados e ensaios de cutover.

Quanto de um programa S/4HANA é teste?

Nos programas que eu planejo, os testes consomem cerca de 35 por cento do esforço do programa. Orce-os nesse nível desde o início, porque testes subfinanciados são a primeira coisa cortada quando a construção atrasa.

Quanto tempo deve durar o UAT em um projeto S/4HANA?

Pelo menos 6 a 8 semanas. Os testadores do negócio executam o UAT junto com o trabalho normal, e precisam de tempo para mais de uma rodada, para que as correções da primeira rodada sejam testadas de novo.

Quem deve ser o responsável pelo teste de aceitação do usuário no SAP?

O negócio, por meio de donos de processo nomeados. O integrador de sistemas pode preparar roteiros, gerenciar o ambiente e corrigir defeitos, mas só as pessoas que conduzem os processos podem confirmar que o sistema funciona para elas.

O que são critérios de entrada e saída nos testes SAP?

Os critérios de entrada são as condições de que um ciclo precisa antes de começar, como teste unitário concluído, ambiente construído e dados de teste carregados. Os critérios de saída são as condições que ele precisa cumprir antes de terminar, como roteiros executados, nenhum defeito crítico aberto e aprovação do dono do processo. Cada um deve dar uma resposta de sim ou não e ter um signatário com nome.

O que um checklist de go-live do S/4HANA deve incluir?

Passos técnicos do cutover, cargas de dados e reconciliações, validações do negócio, troca de interfaces, acesso dos usuários e os pontos de decisão de go ou no-go. Acorde-o com antecedência, ensaie-o nas conversões simuladas ou no ensaio geral e só entre em produção quando cada item estiver concluído e assinado.