*Por Paulo D. T. Silveira
A realização de testes integrados é um fator chave em uma implementação de ERP. Os testes integrados simulam a adequação da solução construída para a operação da empresa. Testes integrados em um ambiente de projeto ERP são um dos pontos mais relevantes da implementação, e tem como finalidade mitigar os riscos de implementação. Sem aprovação dos resultados dos testes integrados, uma empresa não deve fazer o Go Live.
Os testes devem utilizar massas de dados simulados e dados reais, conforme o nível de preparação de dados e o ciclo do teste. A realização de testes funcionais se compõe de três processos principais: planejamento, execução e correção de defeitos. A criação de cenários de testes de acordo com os processos de negócios denominados tests scripts é fundamental para avaliar a integração do processo, aspecto chave do ERP.
Após várias experiências de implementação e estratégias de testes, com base em experiência empírica em Projetos de implantação de ERP em diversos segmentos, chega-se à conclusão de um cenário recomendado de realização de 3 ciclos de testes com objetivos distintos. Deve-se considerar como premissa para a realização de testes integrados a realização de testes unitários durante a fase anterior do projeto (construção ou parametrização).
Um processo adequado de condução de testes integrados considera os seguintes ciclos, sendo eles:
CICLO I – normalmente neste ciclo são realizados testes integrados com maior número de funcionalidades possíveis, utilizando dados fictícios com o objetivo de avaliar todo o ciclo de processos, como por exemplo, da requisição de uma compra até a contabilização correta da transação e pagamento da fatura, com respectivo impacto na tesouraria, ou de um pedido de cliente até o depósito no caixa da empresa.
Um mínimo de 60% de precisão (ou resultado positivo) é requerido neste teste, com tempo de execução dentro do planejado. O planejamento de tempo para execução de teste deve ser um parâmetro a ser considerado na verificação de sucesso do teste. Se o teste ultrapassa o tempo planejado sem ter alcançado este padrão mínimo de 60% de aprovação funcional, o sinal é de que o ciclo do teste se esgotou e não teve sucesso, devendo ser desconsiderado. Neste caso o teste deve ser repetido, desde o planejamento até a sua análise. Resumidamente, o CICLO I tem como objetivo a verificação funcional integrada da solução para cenários limitados de negócio (cenários são alternativas de execução de um processo de negócio). As razões de falhas de testes podem ser:
- Scripts mal planejados,
- Pessoas não focadas e não qualificadas para o ambiente de teste. Recomenda-se que testes sejam realizados por Key Users da empresa,
- Organização de projeto com atividades paralelas aos testes (desenvolvimentos, parametrizações paralelas, por exemplo).
- Dados inadequados, insuficientes ou sem consistência.
CICLO II – o objetivo dessa segunda fase deve considerar dois fatores simultâneos: realizar testes em funções não aprovadas no CICLO I e a utilização de dados mestres reais (desde fornecedor até cliente, passando por produtos etc.). Deve ser feito para todos os cenários relevantes de negócio. Tem-se uma complexidade maior, pois se trata de simulação real. Para tanto, os dados devem ser saneados e precisos. Espera-se que este ciclo tenha aprovação de pelo menos 80%, sendo realizado dentro do tempo planejado. Da mesma forma que o CICLO anterior, o CICLO II deve ser planejado (scripts, cronograma específico etc.), ter uma equipe focada e protagonismo na realização através dos Key Users. Resumidamente o CICLO II tem como objetivo o teste funcional integrado para todos os cenários chave do negócio, ou seja, simula-se a operação regular.
CICLO III – eventualmente pode ocorrer dentro do ambiente de produção, o que indica segurança máxima em caso de aprovação dos resultados do teste. Também as atividades de performance de telecomunicação e condições da infraestrutura podem se aproveitar deste momento de testes. O CICLO III tem como objetivo avaliar funções críticas remanescentes do ciclo II e testar cenários de negócio de menor incidência nas operações da empresa. O CICLO III pode apresentar fatores relevantes para o Go Live da operação e não pode ser desconsiderado.
Os ciclos de testes devem ser cuidadosamente planejados, desde a preparação de scripts até o ritual organizacional adequado (equipes de testes identificados, especialistas funcionais – Key Users envolvidos). É importante ressaltar que a participação deve ser protagonizada pelos Key Users, pois trata-se de um ritual diferenciado dentro do projeto. A não participação nos testes por parte dos Key Users desqualifica o teste.
Outra condição básica é a utilização de dados saneados e definitivos da organização. Quaisquer métodos de implementação (Waterfall, Agile ou Activate no caso SAP) devem considerar os conceitos aqui apresentados para a realização de testes integrados. Um ciclo de teste não pode ser executado em um prazo inferior a 8 dias e deve ter um limite máximo entre 20 e 30 dias, mesmo para operações complexas. Estender a execução do teste acima deste limite máximo é sinal de insucesso. Além do tempo de execução mencionado anteriormente, deve-se considerar o tempo de análise e preparação entre ciclos. Ou seja, realizar em um novo ciclo de testes sem analisar os resultados do ciclo anterior ou não preparar scripts para as diferentes funcionalidades e cenários é inócuo para o projeto.
A duração do ciclo de teste deve ser razoável dentro dos padrões aqui mencionados. Por exemplo, um teste Requisition to Payment (da Requisição ao Pagamento) deve ser em função das quantidades diferentes de cenários. Novamente, o tempo excessivo para a realização dos testes é sinal de insucesso, além do próprio resultado incorreto. Testes integrados sem sucesso devem ser repetidos.
*Paulo D. T. Silveira é sócio-diretor da TGT Consult e analista de risco em projetos de implementação de ERP. O autor já realizou atividade de análise de riscos em diversos projetos de referência no Brasil e no exterior. Entre estas experiências constam empresas como Petrobras, Fiat, AB Brasil e Saraiva, entre outras. Estas experiências (cases) foram base para o desenvolvimento de dissertação de mestrado com o tema – Gestão para mitigação de riscos em implementação de ERP – Estudo de caso sobre fatores críticos de sucesso. Dissertação apresentada e aprovada em 2016 na Faculdade FIA de Administração e Negócios – Programa de Pós-graduação em Stricto Sensu. O autor passou por empresas como EDS, Ernst&Young e Gartner, entre outras tendo sido certificado em SAP em FI – CO em 1998.
No Comment