Tengo ciertas dudas como desarrollador ABAP Junior. Últimamente en mi lugar de trabajo se ha optado por realizar pruebas de escenarios en mandantes de calidad o productivo. Algunos de mis compañeros funcionales me indican que no es posible realizar las pruebas en el mandante de desarrollo debido a que no existe data en la misma. Mi pregunta es la siguiente:
¿Para los funcionales no es posible replicar escenarios que se presentan en calidad o productivo, en el mandante de desarrollo?
Por las oficinas hay rumores de que para los funcionales, desarrollo es basura, no sirve, ya que la data maestra se encuentra en calidad y es donde el cliente aprecia los resultados de su solicitud.
De cierto modo, me molesta la situación, porque en desarrollo es donde puedo ver el resultado de mis ajustes una vez termino de tipear código fuente, puedo realizar cambios al instante.
Gracias por la atención que puedan prestarme en esta duda.
Si tu empresa tiene un solo ambiente de desarrollo deben replantear la estrategia.
Te recomiendo leer ésto, para introducir el tema:
Una vez claro esos conceptos, debemos romper esos rumores y acercar las partes (funcionales y técnicos).
Yo he sido funcional toda mi vida, pero ya se podría decir que desarrollo… así que no le tengo nada de miedo al código, y respeto mucho el área de trabajo técnica, los súper entiendo cuando me piden que haga pruebas en “desarrollo”, pero NO es el ambiente de “desarrollo puro”.
Lo explicaré a continuación, pero antes, mejor aclarar algunas cuestiones:
Terminología
OT = Siglas para referir a una “Orden de transporte”.
DEV = Ambiente de desarrollo puro, solo código ABAP o customización (SPRO) de los funcionales; no hay datos maestros; no es correcto crear datos para pruebas. No se debe probar aquí.
DEV-Q = Ambiente de desarrollo para pruebas puntuales. Este ambiente no es calidad; es un ambiente de desarrollo para pruebas puntuales. Básicamente tiene pocos datos maestros, y sirve únicamente para que ciertos desarrollos sean probados en procesos lógicos. No se transporta la OT aquí, se copia. No requiere liberación de la OT para pasar a este ambiente.
QAS = Ambiente de calidad, copia de datos espejo de PRD. Ambiente “dedicado” a pruebas y testing. Los mismos datos del ambiente real estarán en calidad. Debería funcionar igual que en PRD. Para pasar OT aquí, hay que liberar la orden de transporte, lo que significa que no podrá volver a tratarse dicha OT.
PRD = Ambiente de producción, donde trabajan los usuarios finales. Aquí NO se debería hacer testing bajo ninguna circunstancia. Solo pasan desarrollos o customizing vía OTs.
Es un error grave “probar” algo en PRD. Todo lo que sea “pruebas” debe ser realizado en QAS, y para pruebas específicas, en DEV-Q o un ambiente de desarrollo creado para tal fin.
Para los funcionales es posible replicar escenarios de productivo en calidad.
En el ambiente de “desarrollo” no tienes datos maestros. Así que apenas quieras hacer algo del escenario, no podrás.
Bueno, esto es algo subjetivo. Si un funcional dice que “desarrollo es basura”, evidentemente no entiende nada de SAP, y no entiende cómo funciona el landscape (esto de DEV-QAS-PRD) para aplicar correctamente las configuraciones a SAP.
A los del rumor, y tus compañeros de oficinas, pasales el enlace, así se instruyen un poco y aprenden que todos somos parte fundamental en SAP
Es correcta la apreciación, pero no debe molestarte.
En Desarrollo “desarrollas”, y puedes hacer pruebas en un ambiente creado para tal fin.
Habla con tu equipo BASIS, para que creen un ambiente de desarrollo dentro del mismo “ambiente”, para que no queden en sistemas separados. Que no requiera pase de OT, sino que acepte la copia de OTs vía SCC1 (copia de orden de transporte). Esto lo sabe mejor un basis…
Entonces podrás hacer pruebas en desarrollo, si algo falla, modificas en DEV, la misma OT, y no es necesario crear muchas OT para pasar a QAS.
Aclaraste mis dudas con respecto a las pruebas de escenarios. Leí el foro Rol y trabajo del consultor en cada ambiente. Esta duda surge precisamente porque he realizado muchas solicitudes de transporte para tratar un caso de reconversión aquí en Venezuela, yo trabajo en una consultora, por lo que no atiendo a un cliente en especifico, son muchos.
Resulta que la data en calidad, se encuentra totalmente reconvertida a la nueva moneda, pero la data de productivo, esta funcionando aún con dos monedas. Entonces cuando hago pruebas en QAS todo se ve perfecto, pero cuando solicito el transporte a PRD, una vez allí, no son los resultados esperados. Prácticamente estoy usando productivo para pruebas reales, cuando no debería ser así, como indicas.
Para complementar la info de @SidV, te muestro un esquema de landscape clasico:
Como puedes ver DEV, deberia estar compuesto por 3 mandantes:
Sandbox: mandante para jugar con configuraciones, y en este mandante no se generan OT’s, ni deberia tocarse objetos independientes de mandante.
Customizing: Una vez probado el ajuste o desarrollo en sandbox, se hace el mismo cambio en este mandante de manera manual, y se crea la OT, la cual puedes aun no liberarla.
Test: Este mandante sirve para hacer las pruebas de ajustes y desarrollos antes de realizar la liberacion de las OT’s. Este ambiente obviamente no ofrece pruebas integrales, pero si un ambiente de prueba previo al integral que debería ser parte del trabajo del funcional. Ojo que el modelo de desarrollo normalmente es de prototipo, es decir que el funcional no puede esperar a que el desarrollo este 100% a cabalidad a lo requerido sin meter feedback en las etapas de su desarrollo. El que solo quieran hacer pruebas en QAS, y pero aun en PRD, solo va ensuciar el sistema de transporte y el historial de cambios.
Pues aquí deberían en tu cliente analizar qué ocurrió, pues no es viable mantener un sistema SAP que en PRD funciona de una forma y en el resto de los ambientes, de otra. De hecho, hay que analizar bien por qué se hicieron configuraciones directamente en PRD sin replicar dichas modificaciones en los distintos ambientes.
Es algo que tiene que analizar y corregir tu cliente, para que tú puedas hacer el desarrollo cumpliendo los estándares de programación ABAP, y entregar resultados con la calidad de tu trabajo.
Te recomiendo establecer condiciones de tu trabajo, tienes que establecer que el cliente debe cumplir con el landscape estándar de SAP, y que si han hecho modificaciones fuera de ese estándar, son ellos los responsables, no tú. Tampoco es justo que tú te pases desarrollando en ambientes que son heterogeneos y que estés aceptando el riesgo (muy grande) de romper todo directamente en el ambiente de PRD, cuando no debería ser así.
Por escrito tu cliente debe aceptar que la responsabilidad es de ellos.
Eso que indicas está ocurriendo actualmente. Esta mañana realicé ajustes a un smartforms, representa el comprobante de retención IVA, ya he solicitado 2 transportes de OT’s el día de hoy, una vez en QAS, aprecio los cambios en el formulario, pero cuando me dirijo al modulo de funciones para colocar un debug de sesión, no se encuentran mis cambios. Te lo mostrare en una imagen.
Ambiente DEV.
Ambiente QAS.
Ya he creado muchas ordenes, y eso que indicas sobre ensuciar el sistema de transporte y el historial de cambios, es lo que pensé y por eso mis cambios no se aprecian en QAS. no se si estoy en lo correcto.
Tienes mucha razón en eso, de ahora en adelante pondré condiciones, porque como dices, estoy arriesgando la calidad de mi trabajo. Voy a difundir lo que me facilitaste por este medio, a mis compañeros. Ya hice ajustes y solicite un transporte a QAS, y mis cambios no se aprecian en el modulo de funciones, una vez resuelva eso, si los resultados no son los esperados en PRD, exigiré una replica de escenario a QAS.
