Os testes integrados em ERP (UAT)

Meu foco na verdade é falar sobre a automação de testes e de suas vantagens. Ocorre que para fazer isso, é importante que eu tenha o leitor contextualizado no tema e assim, fiz este artigo preliminar para alinhar o conhecimento. É um artigo breve, coeso e com foco bem específico. O tema de testes de homologação ou testes integrados é muito mais amplo do que escreverei a seguir (aqui).

 A estratégia e a execução dos testes integrados para as diferentes plataformas de TI é muito distinta. Planejar testes integrados para uma solução mobile ou para o deploy de uma solução de ERP são muito diferentes tanto em abordagem quanto em expectativas.

Para reduzir este artigo, não irei focar nas diferenças entre uma e outra plataforma mas apenas nas particularidades de se testar uma solução de ERP. Para facilitar o tema, estou falando de um ERP com deploy simples não estou envolvendo integrações de omnichannel ou de uma camada de intranet elabora integrando à plataforma. Irei abordar o escopo do teste, os pré-requisitos técnicos, o ambiente e a base de testes de um ERP. 

1. O Escopo do teste:

ERP é processo. Testar uma solução de ERP precisa levar em conta as consequências do fluxo da informação indo além da simples funcionalidade da solução. O teste envolve pelo menos quatro camadas:

1. Se a solução foi do início ao fim (end to end);
2. Se as informações corretas foram enviadas do início ao fim;
3. O layout da navegação - normalmente de baixo impacto no ERP, diferentemente de uma solução WEB;
4. E o contexto to teste. Validar uma solução de ERP é entender os gatilhos que existem por detrás da solução. É necessário ir além da aplicação e compreender o processo.
5. Explico: Falando de um cneário de teste de um processo de venda simples. A venda de um produto precisa levar em conta o impacto em controladoria através dos centros de lucro, o impacto nas movimentações contábeis e a continuidade do fluxo de informações para outras ferramentas que se alimentam deste subprocesso como o planejamento de vendas e as movimentações de estoque.

 Hipoteticamente, tendo em mente contexto do teste. Seria possível desenvolver toda uma solução de logística que não está contabilizando corretamente o custo de material ou onde os impostos específicos para uma determinada operação não estão sendo corretament tratados. Isso comprometeria a solução final mas não necessariamente seria identificado se as pessoas corretas estivem envolvidas. O projeto teve o E2E, as informações trafegariam dentro do siistema e a navegação atende.... Mas falhou no contexto.

 2. Pré requisitos técnicos para os testes:

A realização dos testes integrados necessitam de alguns pré-requisitos que estão associados à natureza da mudança. Não vou falar aqui dos aspectos organizacionais ou de projeto como agenda, férias individuais, atividades sobrepostas, quality gates e etc. A abordagem é estritamente técnica

De forma geral, os principais elementos dos testes serão:

1. Adequar as retrições de perfil de acesso similar ao existente em ambiente produtivo
2. Adequar as retrições de QAS pois nem sempre detém as mesmas características de produção
3. Cenários de testes (contemplando a mudança, regressão e os testes negativos)
4. Massa de dados para os testes
5. Testes de integração - quando há outros sistemas envolvidos na entrega. Este fica entre o teste de sistema e o UAT

 3. O ambiente e a base de testes de um ERP:

O ERP é normalmente uma solução integrada com muita interdependência. Serão necessário dados mestres e dados transacionais para os testes.

Os testes são executados em um ambiente que tem outros desenvolvimentos e portanto podem haver conflitos ou dependências que amarram o go live de mais de uma solução. Nada pior do que uma alteração de regras de NFe no meio de um grande projeto de outbound.

•  Dependência: No Brasil, um dos aspectos que mais mudam são as regras fiscais. Para que se possa testar uma solução de um cenário de mudanças fiscais, por vezes é necessário avaliar todas as combinações de entrada e/ou saída de mercadorias. Para se testar a entrada, precisamos de notas fiscais de venda de um fornecedor. Para se testar a saída, precisamos de material em estoque e assim por diante. É arriscado simular cenários sem a correta massa de dados;
•  Coerência: Como não é possível sobrescrever com facilidade a base de dados de QAS/UAT, é muito importante tentar manter uma certa coerência na base de testes. Explico: Forçar material em um estoque compromete o custo médio do material e a contabilização. O seu estoque não reflete as entradas fiscais e tem impacto nas obrigações acessórias.

O impacto direto é que o próximo projeto pode demandar um teste de fechamento e assim sendo, cenários incompletos irão exigir mais das áreas de negócio para filtrar as exceções. Processos de venda precisam ser fechados, entradas físicas precisam da contraparte fiscal e os períodos (mês) deveriam ser fechados. Se houve o teste de uma venda e não há material em estoque, é necessário fazer um ajuste de inventário correto para evitar impacto na contabilidade e em contralodoria

São portanto dois pontos: Gerar massa de dados para os testes e manter a base atual com dados coerentes para futuros projetos. Um dos grandes desafios para deploys complexos que envolvam vários cenários de regressão será sempre a massa de dados, que pode demandar semanas até que o ambiente esteja preparado de fato para iniciar o UAT.

•  Volumes: Por vezes é necessário gerar um grande volume de dados para se testar uma determinada funcionalidade. Grandes volumes permitem identificar tanto problemas de performance quanto variação no fluxo de informação como por exemplo erros de arredondamento;
•  Cenários de Regressão: Como já foi mencionado acima, a interdependência das informações é altíssima. Tudo é integrado. Raras são as funções de negócio que operam stand alone - e este é um dos motivos pelos quais as empresas que são vendidas tem um maior valor quando usam o SAP: A coerência das informações dentro do sistema é seu ponto mais forte. Por exemplo, o preço de venda impacta na margem e altera o custo médio assim como indica variações com relação ao custo standard. Uma alteração em um cálculo de pricing pode ter um efeito cascata em vários pontos do sistema que nem sempre o analista tem visibilidade. É por isso que os testes de regressão são essenciais. Um dos problemas de ERP é que falhas colaterais devido a um deploy podem levar semansa senão meses para serem identificados;
•   Atualizando a Base de Dados: Não falo do banco de dados mas da base de dados geradas por um ERP. Não é simplesmente copiar e colar tabelas dado que todas as informações são interdependentes (não entrarei aqui no tema de segurança e de informações confidenciais) Em uma empresa, ao longo do ano, podem existir vários desenvolvimentos na plataforma de ERP. Na teoria o proesso é simples: Copia o ambiente de produção e sobrescreve o ambiente de qualidade.

Ocorre que normalmente o refresh não está alinhado com outros sistemas e isso pode comprometer a massa de dados ou coerência do ambiente, sendo necessário um trabalho adicional para gerar estes registros;

Sempre que ocorre um refresh, os cenários de testes validados são sobrescritos e assim: Ou o UAT pode ser diretamente impactado e precisa ser refeito OU então o histórico de testes é perdido e tendo o refresh ocorrido logo após o Go Live de um projeto, não haverá mais referência histórica par facilitar troubleshooting (e neste caso, os cenários de teste eletronicamente controlados são a única evidência de sucesso/fracasso).

•  Projetos concorrentes: Outro ponto de atenção são desenvolvimentos concorrentes acontecendo em timeframes que se sobrepõem. Dada as integrações e interdependências, o ERP tem um alto controle dos objetos. Projetos em colisão podem forçar uma entrada antecipada de alguns deploys ou revisão de go live. No caso de UAT, a principal atenção é ter certeza de que se está validando corretamente o cenário que irá para produção - digo isso pois pode ser que um erro de sistema tenha sido corrigido por um projeto concorrente que não está indo para produção no mesmo timeframe;
• Key Users:  Existem outros elementos como a agenda dos usuários, a distribuição dos papéis e responsabilidades e a garantia de que o correto key user está validando o cenário que será movido para produção. Por vezes a sobrecarga de atividades ou o indivíduo que não detém o conhecimento especifico acabam por comprometer parte da entrega.

CONCLUINDO:

 Deployments em ERP na maioria das vezes são cenários complexos que exigem muita atenção ao detalhe. É o tráfego da informação que está em jogo ao mesmo tempo em que o capital humano necessário para validar e revalidar os cenários é significativo.

 As constantes mudanças das regras fiscais, o perfil brasileiro de se automatizar soluções até a camada do procedimento gera um ambiente altamente integrado com muito desenvolvimeto específico. As operações cada vez mais enxutas colocam uma carga de responsabilidade e de pressão sobre os capital humano. E finalmente, as alterações constantes vão criando uma sobreposição de camadas de soluções que demandam cada vez mais atenção aos testes de regressão para se garantir que a última modificação não alterou a anterior.

 A sobrecarga dos usuários, o esforço para gerar a massa de dados para os testes e a constante sequencia de projetos são elementos críticos que incrementam o custo direto e indireto de um projeto. Existem formas de se mitigar este risco e é sobre ele que eu falarei no próximo artigo. Além do elemento de custo, tempo e qualidade, existem também a estratégia de se manter o conhecimento dentro da empresa. A gestão deste conhecimento não está necessariamente relacionada com a automação mas é reforçada quanto se decide por utilizar esta via.