Solution Manager Scope Effor Anlyzer (SEA en adelante) permite realizar un análisis inicial en el caso que se realice algún proyecto de actualización que permitirá tener información sobre el impacto del cambio, tanto a nivel de código, como para estimar las pruebas necesarias, para validar la nueva configuración.
Business Process Change Analyzer (BPCA en adelante) realiza un análisis sobre el impacto que tendrán los cambios en los procesos de negocio.
Tanto el análisis de SEA como de BPCA se realiza teniendo en cuenta las estadísticas de uso del sistema, se recomienda contar con estadísticas actualizadas de al menos 3 meses previos a la ejecución de uno u otro análisis. Así mismo, la ejecución de SEA es una herramienta orientativa, pensada para la fase de planificación de proyectos, y sus resultados no deben considerarse como única fuente para la ejecución del mismo.
BPCA necesitara estar alimentado de los casos de tests para ser más eficiente en su resultado.
Se accederá a está herramientas accediendo a la transacción SM_WORKCENTER - Solution Manager: Work Centers URL.
Es posible que al iniciarse el navegador aparezca el siguiente mensaje de advertencia.
En caso que aparezca se pulsa la opción Continuar en la página werb (no recomendado) :) y ya aparece el panel del usuario con el que nos hemos logado y las tiles que tiene accesible organizadas por secciones, como en este caso son Custon Code Management, Change Management o Test Suite.
El análisis de SEA se basa basa en las estadísticas de uso y en las relaciones de Boom of Materials (BOMs) de los objetos de primer nivel, para proporcionar el listado de ejecutables (Transacciones y Programas) que se tienen que validar durante las pruebas. Por medio del Test Scope Optimizer (TSO) es capaz de calcular la combinación de ejecutables óptima para reducir el número de pruebas.
Se recomienda ejecutar en análisis SEA en horas en las que no haya mucha carga de trabajo en el sistema, ya que la generación de BOMs genera una carga importante en el sistema.
Se ejecuta el siguiente tile
Y se selecciona la opción New para crear un nuevo análisis
Se selecciona el sistema y la versión a analizar. Previamente deberá estar creado el maintenance planner con los cambios que se van a realizar.
El maintance planner id es un documento que se crea desde el Marketplace de SAP cuando dices a que Enhacement o nivel de Packages quieres subir te genera este documento, el usuario con el que se genera el análisis SEA debe tener permisos para ver estos documentos desde el OSS. Esta parte normalmente viene dada por el equipo de BASIS que nos tiene que informar en cada caso que Maintance Planner ID seleccionar.
%20-%20Internet%20.png)
Se selecciona el Planner Transaction Id
%20-%20Internet%20.png)
Se especifica el sistema dónde están los desarrollos, el sistema dónde están las estadisticas y dónde está el sistema en el que se va a realizar la optimización del test.
Aquí se recomienta informar los sistemas de producción para los dos primeros apartados, dónde están los objetos custom y modificaciones a analizar y las estadísticas. En cambio se recomienda informar un entorno no productivo para el Test Scope Optimization para no sobrecargar el entorno de producción.
%20-%20Internet%20Explorer.png)
Una vez completado este paso se selecciona la Solución y la Branch.
%20-%20Internet%20Explorer.png)
Posteriormente se debe indicar el alcance del test a realizar, para este caso concreto se selecciona un alcance creado que no tiene ningún tipo de filtro y se analiza el 100% del alcance.
Se selecciona el alcance creado.
%20-%20Internet%20Explorer.png)
Y por último en el últiomo paso antes de lanzar análisis se revisan toda la configuración que se ha relizado del análisis.
Una vez validado se puede lanzar análisis Start Analysis.
Una vez finalizado el análisis se pulsa en el nombre del análisis se accede al analisis realizado.
Una vez dentro se muestra tres pestañas.
En este apartado se hace un resumen de todo el esfuerzo, lo calcula en días, contando como un día laboral de 8 horas y una persona.
La grafica muestra la distribución de las modificaciones de los objetos custom en las siguientes tres categorías:
- Ajustes Requeridos: Los objetos en esta categoría se verán impactados durante el update y deberán ser revisados minucioisamente después del update para evitar errores. Las modificaciones que están en conflicto con la versión del upgrade y que aparece en las herramientas SPAU y SPDD aparecerán en esta categoría.
- Ajustes propuestos: Los objetos custom que son asignados a esta categoría usan objetos del repositorio de SAP que han sido cambiados en esta nueva versión del producto. Sin embargo, estos objetos no suelen causar ningún problema a la hora de trabajar por lo que podremos evitar ajustar estos objetos a no ser que nos causen algún error o problema en la fase de tests.
- Ajustes no necesarios: En esta categoría aparecen todos los objetos que no son impactados durante el upgrade o que están marcados como no usados.
En la parte de abajo aparece la grafica de Regression Test Efforts for Optimized Test Scope que muestra todos los esfuerzos relacionados con las pruebas de regresión funcional. Nos muestra el esfuerdo medido en días que nos supondría realizar todos los test de regresión. Muestra los días de esfuerzo que ganaríamos y el porcentaje total de tiempo ahorrado.
En esta sección nos muestra los objetos que se deben analizar y los divide en objetos que pertenecen a la SPDD, a la SPAU y el impacto por aplicación. Primero nos muestra una imagen global en la que se muestran los siguinetes gráficos para tener una visión global.
Para acceder al detalle se puede acceder mediente el desplegable:
En esta sección nos muestra los objetos que se deben analizar y los divide en objetos que pertenecen a la SPDD, a la SPAU y el impacto por aplicación.
Dentro de este detalle hay dos pestañas para movernos entre el detalle de Modifications y el detalle de Custom Developments.
En modifications lo primero que muestra es una estimación de lo que va costar pasar la SPAU y la SPDD.
A continuación se muestra el impacto de las modificaciones a realizar durante la SPAU por módulo.
A continuación se muestra el impacto de las modificaciones a realizar durante la SPDD por módulo.
Por último muestra una lista de los objetos impactados.
Lo primero que se muestra es una estimación en días del esfuerzo de realizar para realizar ajustes y pruebas.
Lo siguinete que se muestra es un recuento de objetos clasificados por impacto.
Después de muestra una grafica con el numero de objetos impactados por cada uno de los paquetes de desarrollo.
Y el esfuerzo Requerido en cada uno de estos paquetes.
Por último se muestra un minucioso detalle de todos los objetos custom a adaptar.
En este apartado volvemos a tener dos apartados diferenciados, Overview y Detail.
En el primer apartado se muestran tres gráficos:
- Nos muestra la suma del esfuerzo de ejecución de todos los casos de test de los proyectos o soluciones seleccionados en el análisis.
- Proporciona un desglose del esfuerzo de la prueba de todos los procesos impactados con TSO (Test scope optimization).
- Proporciona un desglose del esfuerzo de la prueba de todos los procesos impactados sin TSO (Test scope optimization).
En el segundo apartado se muestra el apartado Solution Documentation.
Statistics Test Management.
Test Scope and Effort with TSO - Full Scope versus Custom Code and Modifications.
Test Case recomendations.
En este apartado se muestra una overview del alcance de la prueba y las actividades de mantenimiento. En la columna X vemos los procesos de negocio impactados. En la columna Y “izquierda” nos muestra el porcentaje de la cobertura de la prueba En la columna Y “derecha” nos muestra el esfuerzo en días que nos supondrá la realización de las pruebas. La línea Azul nos muestra la cobertura de las pruebas con puntos en cada paso del proceso. La zona verde es el alcance de la prueba seleccionada Columnas naranjas es el esfuerzo de las pruebas manuales.
El escenario de BPCA es una utilidad de Solution Manager que permite identificar el impacto que pueden producir los cambios. Verificar que se ha ejecutado correctamente el job de carga de TBOMs. El job esta programado cada 3 semanas.
Hay cuatro puntos críticos a los que hay que enfrentarse cuando se produce un cambio en un sistema con distintos procesos de negocio.
- Pruebas en Landscapes con sistemas heterógeneos
- Soluciones de Update de SAP que afectan a objetos críticos en un proceso de negocio
- Setup del sistema para testeos y mantenimiento de los juegos de datos.
- Esfuerzo para la creación y mantenimiento de pruebas automáticas.
- SAP Solution Manager actúa como Hub central para controlar eventos de cambio y testeos integrados E2E.
- Funcionalidad para planificación de testeos basándose en riesgo. Pruebas de funcionales y de regresión.
- Interfases a Partner test Suites.
Se identifican 4 casos de uso para los que aplica BPCA:
- Cambio de Customizing. Se produce una modificación en el Customizing que afecta a un proceso de negocio. Hay que identificar qué procesos de negocio se ven afectados y planificar así las pruebas que es necesario realizar para asegurar que ese cambio funciona correctamente.
- Desarrollo Custom. Se realiza una modificación en un objeto Custom como un programa, módulo de función, clase, etc. Hay que identificar qué procesos de negocio se ven afectados y planificar así las pruebas que es necesario realizar para asegurar que ese cambio funciona correctamente.
- Activación de EhP Business Function planificado. El despliegue de un EhP provoca la activación de una Business Function. Hay que identificar qué procesos de negocio se ven afectados y planificar así las pruebas que es necesario realizar para asegurar que ese cambio funciona correctamente.
- Optimización del alcance de las pruebas necesarias por el despliegue de un SP/EhP. Se debe realizar el despliegue de un SP o un EhP SAP. BPCA permite analizar el alcance del impacto de este cambio sobre los procesos de negocio y calcular el esfuerzo a realizar para generar un plan de pruebas optimizado.
Se accede a la transacción SM_WORKCENTER - Solution Manager: Work Centers URL y se accede al tile Business Process Change Analyzer.
Se selecciona la opción del tipo de impacto que queremos analizar, en nuestro caso el análisis de impacto de transportar una orden de transporte, es decir, se selcciona la opción Transport Requests.
Se selecciona el sistema y el mandante donde está la orden con los cambios a analizar.
Se selecciona la orden, para ello hay que entrar mediante matchcode y buscar la orden concreta.
En esta prueba la orden tiene la modificación de un módulo de funciones estándar que es llamado desde la EXIT MV50AFZ1 Userexit a partir de 21D para tratamiento de entregas
A tener en cuenta para comprobar que tiene sentido con las acciones que obtenemos como resultado en el análisis.
Se selecciona la solucion, el branch y la vista. Que es el alcance del análisis a realizar.
Se añade una descripción al análisis.
En parámetros opcionales se podrá definir el TSO (Test Scope Optimization) TSO es una herramienta que se puede utilizar una vez realizado el análisis. Muestra estadísticas del análisis que facilitan la toma de decisiones para realizar los tests necesarios una vez realizada la modificación.
También permite recomendar casos de Test que cubran un porcentaje determinado de objetos modificados agrupando los procesos que contienen el mayor número de impactos en la modificación.
Por último se lanza el análisis.
Una vez finalizado mostrará los resultados y se podrán revisar e ir creando los casos de test necesarios para ir documentando los procesos de negocio con sus respectivos tests.
Para acceder a los resultados se pulsa el botón Optimize Test Scope.
En el apartado Test Scope Optimization Ranking en el apartado Ranked List se indican las transacciones/ejecutables que hay que habría que probar para cumplir con el 100% de las pruebas. Para esto hay que pulsar el botón Show Executables.
Aquí se puede observar que con probar las 2 transacciones a probar FB02 y DRFOUT se cubriría el 100% de las pruebas con un esfuerzo acumulado de 4 horas.
En la pestaña Test Case Recomendations
Vemos un remumen que nos indica cosas interesantes como que crear un script para realizar esta prueba de manera automática y acumulada costaría unas 20 horas, cada vez que haya que modifcar este script automático nos costaría 3,5 horas. Pero una vez hecho las pruebas nos costarían un esfuerzo de 0,5 horas frente a las 4 horas que cuesta hacer las pruebas de manera manual, todas estas estimaciónes de esfuerzos son orientativas.
En el resumen final vemos como nos recomienda que se creen New Automated Test Case para cada transacción el esfuerzo de crear cada uno de ellos, el esfuerzo acumulado, el esfuerzo de probar a mano cada una de las transacciones y el esfuerzo de probarlas una vez automatizadas estas pruebas.
Muy parecido al caso anterior, se selecciona la opción Planned Business Function Activation (BF a partir de ahora).
Se selecciona sistema.
Se selecciona BF.
Una vez terminado el análisis vemos las transacciones/ejecutables a probar.
