Teste de aceitação do usuário no SAP: quem é o dono e como conduzir

O teste de aceitação do usuário (UAT) no SAP é a fase em que os usuários de negócio executam os seus próprios processos no sistema configurado e o aceitam formalmente antes do go-live. O negócio é o dono, a TI e o parceiro de implementação apoiam, e em um programa S/4HANA eu planejo pelo menos 6 a 8 semanas para ele.

A falha de testes mais comum que vejo é simples: testar pouco no UAT e no teste de integração de sistemas (SIT). Quando o cronograma escorrega, essas duas fases são comprimidas, e as lacunas aparecem depois do go-live.

A seguir: quem faz o quê, preparação, roteiros, triagem de defeitos e uma aprovação que tenha valor. Para ver onde o UAT fica entre os outros tipos de teste, comece pela minha visão geral de testes SAP explicados.

O negócio é o dono do teste de aceitação do usuário. Essa é a minha posição, e ela não deve mudar quando o cronograma aperta.

O motivo está no nome. Aceitação é uma decisão de negócio sobre se o sistema faz o negócio funcionar, então só as pessoas que fazem o negócio funcionar podem dá-la. Se a TI ou o parceiro aprova o UAT, ninguém aceitou nada.

A própria metodologia da SAP diz o mesmo. A sua orientação de estratégia de testes para o S/4HANA Cloud Private Edition coloca o UAT na fase Realize. Os especialistas de configuração do parceiro preparam os casos de teste manuais, e os especialistas das áreas de negócio do cliente os executam e documentam os resultados.

Uma divisão de trabalho viável fica assim:

Papel	É dono, no UAT, de	Não é dono de
Donos de processo de negócio	Escopo dos cenários, critérios de aceitação, aprovação final do seu processo	Correção de configuração ou código
Usuários-chave e testadores	Executar roteiros, registrar resultados e evidências, abrir constatações	Decidir sozinhos que um defeito “não é defeito”
Líder do UAT (do lado do negócio)	Plano diário, andamento, condução da triagem, relatórios de prontidão para o patrocinador	Correções técnicas
Parceiro de implementação	Redação dos roteiros, prontidão do sistema de teste, correção de defeitos, apoio ao reteste	Aceitação
TI interna	Ambientes, acessos, interfaces com outros sistemas, transportes	Aceitação
Equipe de dados	Carga e atualização dos dados de teste, apoio à reconciliação	Desenho dos cenários de negócio

O líder do UAT deve vir do negócio, e não do parceiro. Um UAT conduzido pelo parceiro tende a provar que a construção funciona, o que é uma pergunta diferente de saber se o negócio consegue operar com ela.

O UAT precisa de pelo menos 6 a 8 semanas. Com menos que isso, o negócio testa o caminho feliz uma vez, não tem tempo de testar de novo as correções e nunca chega às exceções, onde moram os problemas reais.

Essas semanas só funcionam se o UAT começar em um sistema estável. A orientação da SAP é que os processos de negócio sejam testados depois que as integrações estiverem configuradas e os dados do processo tiverem sido migrados. Isso significa que o SIT precisa terminar antes, com base em critérios de saída acordados, e o meu guia de estratégia de testes do S/4HANA mostra como esses ciclos se conectam.

Antes que o primeiro testador entre no sistema, isto deve estar pronto:

1. Desenhos de processo aprovados. Os roteiros são escritos a partir deles, então desenhos sem aprovação significam roteiros instáveis.
2. Critérios de entrada atendidos e registrados. SIT concluído, nenhum defeito crítico aberto e o sistema de teste congelado, exceto por correções controladas.
3. Um sistema de teste parecido com a produção. Configuração, interfaces, perfis e autorizações como estarão no go-live.
4. Dados de teste realistas. Mascarados, em nível de produção, carregados e reconciliados antes do início dos testes. O meu guia de gestão de dados de teste SAP explica como.
5. Testadores liberados do trabalho do dia a dia. Nomeie-os, acorde as horas deles com os gestores e coloque isso por escrito.
6. Testadores treinados no novo sistema. Uma apresentação rápida dos apps Fiori e das transações que vão usar, antes do UAT e não durante.
7. Uma única ferramenta de gestão de testes. Roteiros, resultados, evidências e defeitos em um só lugar, e não em planilhas paralelas.

O item 5 é onde o UAT costuma falhar em silêncio. Testadores que precisam encaixar o UAT em volta do fechamento mensal vão colocar o fechamento em primeiro lugar, e com razão.

Um roteiro de UAT é um cenário de negócio, não uma lista de transações. “Criar uma ordem de venda” testa uma tela. “Receber um pedido de um cliente novo com bloqueio de crédito, liberá-lo, entregá-lo e faturá-lo” testa o negócio.

Construa os roteiros a partir dos desenhos de processo aprovados e dê a cada um um resultado esperado claro, em termos de negócio. O testador deve conseguir dizer se passou ou falhou sem perguntar a um consultor.

Cubra quatro tipos de cenário:

1. Fluxos centrais. Os processos diários que mantêm o negócio funcionando, como order to cash, procure to pay e record to report.
2. Exceções. Devoluções, bloqueios de crédito, entregas parciais, mudanças de preço, estornos e aprovações rejeitadas.
3. Fim de período. Os passos de fechamento mensal e anual que a equipe financeira realmente executa, na ordem em que os executa.
4. Verificação de perfis. Cada testador trabalhando com o perfil que terá no go-live, para que as lacunas de autorização apareçam agora.

Deixe o parceiro redigir os roteiros e depois peça aos usuários-chave que os reescrevam na linguagem deles. Se o negócio não consegue seguir um roteiro sem ajuda, ele foi escrito para a equipe de construção.

No SAP Cloud ALM, os casos de teste manuais partem de um processo, e os planos de teste os agrupam em ciclos. Os testadores marcam cada passo como aprovado ou reprovado, registram o resultado real e abrem um defeito a partir da execução do teste, o que mantém o vínculo entre roteiro e defeito.

Em programas que ainda usam o SAP Solution Manager 7.2 para gestão de testes, observe que a sua manutenção padrão termina no fim de 2027 (SAP Support). Planeje os programas novos no Cloud ALM.

Nem toda constatação do UAT é um defeito. Tratar todas como defeitos sobrecarrega o parceiro, e tratar todas como solicitações de mudança esconde falhas reais.

Faça uma reunião de triagem em todos os dias do UAT. O líder do UAT do negócio a conduz, com os líderes funcionais do parceiro e um representante da TI, e cada constatação nova sai da sala com um tipo, uma severidade e um responsável.

Uma classificação simples cobre a maioria das constatações:

Tipo de constatação	O que significa	Quem age	Efeito na aprovação
Defeito	O sistema não faz o que o desenho aprovado diz	O parceiro corrige, o testador testa de novo	Defeitos críticos e altos bloqueiam a aprovação
Solicitação de mudança	O desenho foi atendido, mas agora o negócio quer algo diferente	A autoridade de desenho decide, com custo e prazo	Não bloqueia, a menos que o negócio diga que o processo não funciona sem ela
Problema de dados	Dados mestre ou transacionais errados ou ausentes	A equipe de dados corrige, o testador testa de novo	Bloqueia se os mesmos dados forem para produção
Problema de treinamento ou de uso	O sistema funciona, mas o testador não sabia como usá-lo	O líder de treinamento atualiza o material	Não bloqueia, mas alimenta o plano de treinamento
Problema de autorização	O perfil não tem um acesso necessário, ou tem acesso demais	A equipe de segurança ajusta o perfil	Bloqueia para o perfil afetado

Acorde as definições de severidade antes de o UAT começar, em termos de negócio. Um defeito crítico para um processo sem solução de contorno. Um defeito alto tem uma solução de contorno que o negócio não consegue sustentar em volume.

Fique de olho na coluna de solicitações de mudança. Uma lista longa de solicitações de mudança no UAT normalmente significa que o negócio não participou direito do desenho, e esse é um problema a corrigir antes da próxima onda.

O treinamento de Activate da SAP afirma que a fase Realize está concluída quando o teste de aceitação do usuário está concluído e aprovado. Faça dessa aprovação um documento, e não uma troca de e-mails.

Cada dono de processo de negócio assina pelo seu próprio processo. A aprovação deve registrar:

1. O que foi testado. Cenários executados, aprovados e reprovados, com as evidências guardadas na ferramenta de testes.
2. O que ainda está em aberto. Cada defeito em aberto, com a sua severidade, responsável e data-alvo.
3. O que foi aceito com solução de contorno. Cada item nomeado, com a solução de contorno que o negócio aceitou adotar.
4. Quem assinou e quando. Uma pessoa com nome por processo, e não um comitê.

Escreva os critérios de saída antes de o UAT começar e não os altere quando os resultados chegarem. Se o negócio ainda quiser entrar em produção com lacunas, registre isso como uma decisão assinada. O meu guia de quality gates no SAP mostra como esse gate se encaixa nas transições de fase.

A aprovação do UAT não é a decisão de go-live. Ela alimenta essa decisão.

O critério de go-live em que eu insisto é um checklist de cutover detalhado e acordado com antecedência. A aprovação do UAT é uma linha dele, ao lado da reconciliação de dados, do treinamento e do ensaio de cutover.

Depois da aprovação, proteja o que foi aceito. Cada correção e cada transporte daqui até o go-live precisam de reteste, e o meu guia de teste de regressão SAP explica como manter isso sob controle.

Você não precisa de um documento longo. Precisa de um plano que responda às mesmas perguntas todas as vezes, escrito antes de o UAT começar e assinado pelo negócio.

Uma estrutura simples resolve:

Seção	O que contém	Responsável
Escopo	Processos, unidades organizacionais e perfis no escopo, e o que fica explicitamente de fora	Donos de processo de negócio
Cronograma	Datas de início e fim, ciclos, janelas de reteste, execuções de fim de período	Líder do UAT
Equipe	Testadores por processo, a liberação deles do trabalho do dia a dia, contatos de apoio do parceiro e da TI	Líder do UAT e gestores diretos
Critérios de entrada	Saída do SIT atendida, sistema de teste congelado, dados carregados e reconciliados, testadores treinados	Líder do UAT com o gerente do programa
Ambiente e dados	Sistema de teste, interfaces no escopo, dados mascarados em nível de produção, plano de atualização	TI e equipe de dados
Roteiros	Lista de cenários por processo, resultados esperados, vínculo com o desenho do processo	O parceiro redige, os usuários-chave aprovam
Processo de defeitos	Tipos de constatação, definições de severidade, triagem diária, regras de reteste	O líder do UAT conduz a triagem
Relatórios	Andamento diário, defeitos em aberto por severidade, impedimentos para o patrocinador	Líder do UAT
Critérios de saída	Limites de defeitos em aberto por severidade, cenários aprovados, soluções de contorno acordadas	Donos de processo de negócio
Aprovação	Bloco de assinatura por dono de processo, lista de soluções de contorno aceitas	Donos de processo de negócio e patrocinador

Mantenha o mesmo modelo em todas as ondas. O segundo rollout deve reutilizar os roteiros e as lições da primeira onda, e não começar do zero.

Nomeie o seu líder do UAT, vindo do negócio, ainda este mês, e peça a cada dono de processo que indique testadores com tempo liberado. Depois coloque no plano de 6 a 8 semanas de UAT após o SIT, e defenda esse prazo quando o cronograma apertar.

Se o seu UAT está sendo conduzido pelo parceiro, ou vive sendo comprimido, eu ajudo programas a organizar isso direito. Você pode entrar em contato comigo aqui.

O que é teste de aceitação do usuário no SAP?

É a fase em que os usuários de negócio testam o sistema SAP configurado com base nos seus processos reais e o aceitam formalmente antes do go-live. No SAP Activate, ele acontece na fase Realize, depois do teste de integração. Os usuários-chave executam roteiros de cenários, registram os resultados e abrem constatações, e os donos de processo dão a aprovação.

Quem é responsável pelo UAT em um projeto SAP?

O negócio: os donos de processo decidem o escopo e aprovam, e os usuários-chave executam os testes. O parceiro de implementação redige os roteiros e corrige os defeitos, e a TI interna fornece ambientes, acessos e interfaces. Nem a TI nem o parceiro devem aceitar o sistema em nome do negócio.

Quanto tempo deve durar o UAT no SAP?

Planeje pelo menos 6 a 8 semanas em um programa S/4HANA. Isso deixa tempo para executar os fluxos centrais, as exceções e os passos de fim de período, e depois testar de novo as correções. Um UAT mais curto que isso normalmente testa o caminho feliz uma vez e encontra o resto depois do go-live.

Qual é a diferença entre SIT e UAT no SAP?

O teste de integração de sistemas (SIT) verifica se os processos e as interfaces funcionam juntos entre módulos e sistemas, e é executado principalmente pela equipe do projeto. O UAT verifica se o negócio consegue executar os seus processos no sistema, e é executado pelos usuários de negócio. O SIT deve terminar antes de o UAT começar.

O que uma aprovação de UAT deve incluir?

Os cenários testados e os seus resultados, cada defeito em aberto com o seu responsável e data, as soluções de contorno que o negócio aceitou e uma assinatura com nome por dono de processo. Acorde os critérios de saída antes de o UAT começar. Uma aprovação com lacunas deve ser uma decisão de negócio registrada.

O SAP Cloud ALM pode ser usado para o UAT?

Sim. O SAP Cloud ALM suporta casos de teste manuais construídos a partir de processos, planos de teste para cada ciclo, registro de aprovado ou reprovado passo a passo e defeitos abertos a partir da execução do teste. Na orientação da SAP, os especialistas do parceiro preparam os casos de teste e os especialistas de negócio do cliente os executam e documentam os resultados ali.