02-06-2015 2:23 PM
Hello,
Is there any way to:
1. Access quality system data to test local object in Development system
2. Execute development system object(local object) in quality system
The purpose behind this is to test performance of program with huge volume of data(available in quality system) before transporting object to quality.
Thanks,
Bhavin Shah
02-06-2015 3:46 PM
If you can really only test in the QA system, then that is where you must test it. For iterative development, where you need to test, change, test many times, the way forward is to use transports of copies.
Create your development in a normal workbench request.
When ready to test, create a transport of copies based on your workbench request
Transport the ToC to QA and no further
Test
Make changes, save against your workbench request.
When ready to test, create a transport of copies based on your workbench request
Transport the ToC to QA and no further
etc...
What's nice about this is that you get a version in version management for each ToC.
02-06-2015 3:00 PM
02-06-2015 3:43 PM
One way of doing it, I suppose. But in some places, even getting this to your test system would be problematic.. for your career...
02-09-2015 6:21 AM
Of course, it depends on the project. That's why I've put so many disclaimers in reply.
But several times it really helped me in situations when this evening you get a task which must be done by tomorrow morning. Saving even half an hour of time for the arms of Morpheus might bring you back with a clear head the next day.
Can a weapon itself be harmful? I believe, it depends on who's using it.
02-09-2015 9:20 AM
Hi,
I'd be explaining this situation to anyone with managerial responsibility for your systems. As I see it, you have two options:
This is another scenario where I feel SAP developers are often put in a istuation that isn't fair and forces them to look for practices and solutions that are both illogical and, as Matthew has hinted, potentially bad for their long term career. What happens when a dodgy test in QA suddenly destroys some important test data for an on-going project? Who would get the blame then? The developer who got his dodgy DEV code into QA via the back-door I suspect...
Cheers,
G.
02-11-2015 8:22 AM
Hi, Gareth!
To begin with, I think it's better to wipe out my first post here as it may be misguiding juniors. Warnings and disclaimers are probably not enough and I don't want anyone to be inspired by this solution.
I would prefer the world where situations like what I've described wouldn't occur, that's for sure. And speaking about the career - everyone decides what's worse for him: using such hacks or refusing to do the task from your boss
Needless to say, I check twice all potentially "dangerous" places. I mentioned that the only way of using such approach (if it's ever gonna be used) is simple reports like get_data - show_data.
What happens when a dodgy test in QA suddenly destroys some important test data for an on-going project? Who would get the blame then? The developer who got his dodgy DEV code into QA via the back-door I suspect...
Unfortunately, in case you have no test data in DEV your dodgy code just won't be tested enough until you transport it to QA (there were cases when I tested my code in DEV debugger with manual filling the necessary internal tables ), that's why I strongly prefer option one from what you mentioned.
And in fact we're working on adding test data to DEV system.
As a conclusion, let's wipe it out, cuz at the moment I don't have such option, and work for good.
02-11-2015 9:08 AM
02-11-2015 9:44 AM
02-11-2015 11:12 AM
It could be thought of as evolution in action. Juniors who do stupid things lose their job and never work in ABAP to do stupid things again?
Ha-ha-ha, tough guy you are!
The more I reread the brach, the less I want it to be read by juniors. Guys, burn it down
02-11-2015 12:28 PM
I'm torn. On the one hand I worry this could be of danger to some systems... On the other I remember the universal truth of SCN, that no-one bothers searching. So, those who could do the most damage with it will never read it as they won't search and end up finding it.
Cheers,
G.
02-11-2015 12:31 PM
I've rejected it now. I was torn as well, but I think on balance, it's better off not in SCN.
02-06-2015 3:46 PM
If you can really only test in the QA system, then that is where you must test it. For iterative development, where you need to test, change, test many times, the way forward is to use transports of copies.
Create your development in a normal workbench request.
When ready to test, create a transport of copies based on your workbench request
Transport the ToC to QA and no further
Test
Make changes, save against your workbench request.
When ready to test, create a transport of copies based on your workbench request
Transport the ToC to QA and no further
etc...
What's nice about this is that you get a version in version management for each ToC.