Imaginemos la situación: vamos al supermercado y escogemos un producto. Nos fiamos del precio que marca la etiqueta. Pero ¿qué pasa si llegamos a la caja y resulta ser más caro? Como es lógico, eso no nos gustaría y exigiríamos que los productos estén bien tasados, tanto en su etiqueta como en la caja. Para evitar estos errores es necesario ajustar toda la línea de producción. Hay que revisar desde el inventariado de los productos hasta sus etiquetas y el valor numérico que tengan en la aplicación de cobro del supermercado, para asegurar que el dato final sea el correcto. Al final, hablamos de testear la fiabilidad de los datos.

En el ámbito de SAP, la gestión del dato en la fase de testing siempre ha sido una de las más exigentes en esfuerzo y tiempo. Hay que tener en cuenta, por un lado, la complejidad de reproducir los datos necesarios, pero también la de que se cumplan las regulaciones vigentes. Aun así, resulta paradójico que este sea uno de los procesos a los que menor esfuerzo de optimización se dedica.

Es importante tener los sistemas de test actualizados y optimizados, con datos relevantes y válidos para realizar copias de forma eficaz

Teniendo en cuenta la gran cantidad de proyectos en desarrollo relacionados con la conversión a S/4HANA, todos los clientes de SAP deberían reconsiderar su estrategia. Es muy importante tener los sistemas de test lo más actualizados y optimizados posible, con datos relevantes y válidos para poder realizar copias de forma eficaz, independientemente de la plataforma. Este es el modo de asegurar una ejecución de pruebas totalmente fiable.

En este punto resulta clave innovar, incorporando soluciones escalables y flexibles que permitan, por un lado, garantizar una ejecución limpia en los proyectos, y, por otro, proteger la calidad de los datos.

Testing, principales desafíos

Como resulta fácil comprender, la adecuada gestión de los datos en un entorno de prueba presenta una serie de desafíos. Los siguientes son los más importantes.

Datos actualizados e inactividad del sistema. Ambos elementos son muy importantes para ejecutar casos de test completamente fiables. En los entornos SAP, actualizar los datos de pruebas ha sido siempre sinónimo de realizar una copia homogénea del sistema de producción. En este proceso se remplaza la base de datos del sistema de test por la de producción. De esta forma, contamos con una copia exacta de los datos productivos que nos permitirán realizar nuestras pruebas de forma fiable.

En SAP, actualizar los datos de pruebas ha sido siempre sinónimo de realizar una copia homogénea del sistema de producción

Sin embargo, este proceso presenta una serie de inconvenientes, ya que no solo sustituimos los datos, sino también toda la configuración y, por tanto, es necesario efectuar una posterior restauración manual del entorno de test. Este procedimiento nos obliga a abordar tareas como el renombrado de sistemas lógicos o el reconexionado con los sistemas satélites. Además de ser una tarea propensa a errores, la necesidad de abordar estos procesos puede hacer que se tarde demasiado tiempo (incluso días) en tener disponible el sistema de prueba. En muchas organizaciones, esta complejidad implica que el refresco de los datos de test se efectúe una o dos veces al año, o incluso que sea algo inviable.

Compliance. Los sistemas de test siguen estando sujetos a normativas como la LOPD o el RGPD. Hay que tener en cuenta que su esquema de seguridad suele ser distinto del de los sistemas de producción, dado que los usuarios que acceden a unos y otros no son los mismos.

En general, los sistemas de test tienen un modelo de autorizaciones más laxo, que permite que los equipos de soporte resuelvan incidencias con rapidez. Como contrapartida, esa laxitud nos obliga a ser muy cuidadosos con los accesos a ellos. La mejor solución es que los sistemas de pruebas cuenten con datos anonimizados. Así se podrán seguir ejecutando de forma fiable y con la seguridad de que no es posible acceder a información confidencial.

La mejor solución es que los sistemas de pruebas cuenten con datos anonimizados

Costes de infraestructura. Con los procedimientos tradicionales los sistemas de test tienen una base de datos de un tamaño análogo a la de los de producción. Además, dependiendo de la complejidad del landscape, puede ser necesario disponer de varios sistemas en función del volumen de proyectos o de la necesidad de formación. Todo esto hace que mantener los sistemas de test suponga un alto coste, y más si se enmarcan en entornos cloud.

Agilidad y resolución de incidencias. En muchas ocasiones los sistemas de test se usan para reproducir errores acaecidos en los sistemas de producción. Para ello, normalmente hay que contar con la misma fuente de datos que tiene el sistema donde surge la incidencia, ya que es posible que el error no ocurra con una muestra diferente. Si los datos de prueba están desactualizados, los equipos de soporte tendrán que conceder acceso al entorno productivo, con los riesgos que ello implica.

Selective data migration

Para resolver estos desafíos con un enfoque distinto al tradicional, existen herramientas basadas en selective data migration. Estas, en vez de copiar toda la base de datos de producción, seleccionan los datos de aplicación teniendo en cuenta ciertos criterios. Por ejemplo, seleccionan los datos del último año o los ligados a una sociedad en concreto. Dicha selección se extrae del entorno de producción y se inserta en el sistema de test. Esta forma de proceder tiene varias ventajas:

• Solo se copian en test los datos de aplicación, no se remplaza la configuración. Por tanto, no son necesarias las tareas de readaptación; en consecuencia, el proceso es mucho más ágil a la hora de construir los sistemas de test. Además, se puede automatizar fácilmente. También es posible refrescar los entornos de prueba de forma más frecuente y con bajo impacto, así como tener los datos siempre actualizados para permitir unas pruebas fiables.
• Durante el proceso de copia se pueden implantar políticas de anonimizado de datos sensibles, lo que facilitará todo lo relativo al compliance.
• La copia de datos puede ser selectiva. Se reduce así drásticamente el volumen de los sistemas de test y, por tanto, el coste asociado.
• Se permite la copia de objetos de negocio de forma consistente (por ejemplo, los asociados a una incidencia).
• Permite crear plantillas para mover datos entre entornos.

Con este tipo de herramientas será posible efectuar una gestión flexible de los entornos de test, lo que permitirá tener datos siempre actualizados y poder realizar pruebas fiables. Todo ello al tiempo que se controlan los costes asociados y, además, se reduce la probabilidad de que ocurran errores durante la ejecución.