Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Access quality system data to test local object in Development system

former_member961883
Discoverer
0 Kudos

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

1 ACCEPTED SOLUTION

matt
Active Contributor
0 Kudos

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.

11 REPLIES 11

nikolayevstigneev
Contributor
0 Kudos

This message was moderated.

0 Kudos

One way of doing it, I suppose. But in some places, even getting this to your test system would be problematic.. for your career...

0 Kudos

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.

0 Kudos

Hi,

I'd be explaining this situation to anyone with managerial responsibility for your systems.  As I see it, you have two options:

  1. Your company makes some effort to add enough test data into DEV to enable proper unit testing of any changes or fixes, and understands that without that in place, there is no such thing as a task that must be done tomorrow as you don't have a safe and robust environment to support that sort of turn-around.  A lot of this comes with experience and the confidence to push back on those asking you to do the impossible of course...  Again, I see so many posts here on SCN in the ABAP forums where junior programmers are obviously being almost bullied into practices that just make no sense.

  2. Your company accepts that due to the lack of test data in DEV, each and every change, enhancement or bug fix will take longer as you need to work in the QA system.  Of course, actually moving code through on a transport doesn't take that long in reality but as Nikolay has mentioned, sometimes you need to test line by line and this just doesn't work.  I've worked with ABAPers over the years who have (rightly) refused to work in this situation and ensured that proper data is available in DEV.

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.

0 Kudos

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.

0 Kudos

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?

What do you think - shall we remove this conversation?

0 Kudos

SAP offers a tool for moving consistent data to development systems, among others:

Works well once set up correctly, but comes at extra licensing costs.


Thomas

0 Kudos

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

0 Kudos

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.

0 Kudos

I've rejected it now. I was torn as well, but I think on balance, it's better off not in SCN.

matt
Active Contributor
0 Kudos

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.