Strategy on Testing IT Roles for PRD move and Question on S_TCODE

[Former Member]

Good Morning All - I am trying put a strategy on testing Procedures, wanted to take suggestions from forum:

Question 1:

What is the best practise across industry in testing IT roles for DEV-PRD move, for funtional roles we have spec from business so sorce doc for testing is that spec.

I am trying to put a strategy on IT support roles, at our company we have customized roles for IT out of standard SAP roles. Testing each and every TCODE doesnt make sense. Guys can you please help me how to go about it.

Question 2:

Auth Object S_TCODE: We have a requirement to identify all roles which have ranges (ex: SE38-SH01)and roles which have '' in S_TCODE. Is there any agr tables or standard reports which will help me to pull this data? SUIM can help but its lot of work to pull for each role.

Thanks Much,

Arvind

[jurjen_heeck]

> I am trying to put a strategy on IT support roles, at our company we have customized roles for IT out of standard SAP roles. Testing each and every TCODE doesnt make sense. Guys can you please help me how to go about it.

Funny to see that IT departments never can or have to define the required functionality. I'd suggest to concentrate on 'negative testing' to make sure the IT employees can not harm the system or the data therein. Make sure for instance that they cannot interfere with the functional processes for which you have designed and built roles to match.

> Auth Object S_TCODE: We have a requirement to identify all roles which have ranges (ex: SE38-SH01)and roles which have '' in S_TCODE. Is there any agr tables or standard reports which will help me to pull this data?

Have a look in table AGR_1251, filter for object S_TCODE.

1- To find ranges, go to the multiple selection of the 'high' field, select tab 'exclude single values' and hit the box left to the first empty row and set it to '='.

2- To find the stars enter #* in the 'low'field. (The hash symbol escapes the meaning of the star)

[Former Member]

>

> Funny to see that IT departments never can or have to define the required functionality. I'd suggest to concentrate on 'negative testing' to make sure the IT employees can not harm the system or the data therein. Make sure for instance that they cannot interfere with the functional processes for which you have designed and built roles to match.

>

I would tend to agree that the testing suggestions is a good one. At the same time, There is no blanket cover of what should and shouldnt be a stand-alone function. If the SD Functional authorizations are given to the SD team and EDI authorizations are given to the EDI team and the EDI guys execute functin modules to manipulate data to send files to a different system, do we call it transgression of domains?

For a start it is a good thought to have - each one does their job and more or less it should be like that, but if it is interpreted as IT guys should have no functional authorizations, then it is a reflection of poor understanding (like the other thread we have where the operator wants to remove all BC objects from Functional consultants)

As you rightly said - as long as the IT guys do not change functional data, it should be good

[Former Member]

Thanks Jurjen for quick reply!

Regarding my Question 1:

I should have been more clear, I meant to say I created role for ABAP Developement, BASIS, Middle ware ADMIN and so on....on DEV box, to move this roles from DEV-PRD process say roles should be tested (positive and -). Here is the issue for example in BASIS roles there about 50 system maintain tcodes, it doesnt make sense to me to atest all 50 tcodes so wanted to see what will be the best approach that I can use when we these kind IT developer or Admin roles.

Thank You.

[jurjen_heeck]

Now I think your testing procedures are too strict. What if you need a role with which one can delete clients. Do you really want to test that in PRD or only in a sandbox? I'd do the latter.

[Former Member]

Here is the issue for example in BASIS roles there about 50 system maintain tcodes, it doesnt make sense to me to atest all 50 tcodes so wanted to see what will be the best approach that I can use when we these kind IT developer or Admin roles.

True. DEV is different for Prod, so should be the roles, even for IT people. Each IT position should have a specific role(not SAP Role) in Production and hence relevant SAP roles should be assigned.

Gp.

[Former Member]

Hi Arvind,

There are no short cuts to role testing.

It all depends on the way you have created role, weather you have maintained the SU24 values properly or not. Whats the architecture?? Parent -child role concept used..etc..Testing is very essential for each Tcode. Its always good to test the things better , it might take time but it will ease our your task when you move to production environment.

Even a small miss in testing can cause you issue later. You can however create GUI scripts if you just want to check the appearance of next screen. But it all depends on how much risk you are willing to take for later stages.

[Former Member]

Jurjen - Here is an example for SEC User Admin, we ask user ot test whether they can create/change/modify/.... (SU01, SUGR, SUIM...)so on things on Dev before we move there roles to PRD, there is really no negative testing.

Management and BASIS thinks they should not be restricted to any of their activities on any system TCODES which includes PRD, so there isn't really negatvie test.

So in above scenario its only + testing, and for + tesing i think i really cannot ask them to test all tocdes which are in there basis role.

your thoughts?

Thanks.

[Former Member]

>

> So in above scenario its only + testing, and for + tesing i think i really cannot ask them to test all tocdes which are in there basis role.
> 
> your thoughts?
> 
> Thanks.

My thoughts are that they should test all their transactions in a suitable test environment. If that process is required for functional/end user roles then it should be the same for IT roles.

[jurjen_heeck]

> your thoughts?

Have them work a few days/weeks with the new roles in DEV and TST. If all goes well you can call that a succesful test.

[Former Member]

I completely agree with you Alex and Jurjen!

I dont get req. spec from IT folks, that is the reason I try to copy SAP standard templates. With my last project i took same path as Jurjen suggested, asked them to test what they use on regular basis and attached that docs as supporting for PRD move. I know its not a best approach but I dont know if there is another way to tackle this because they dont want to test all 50-100 tcodes which are in PFCG role. however they want all that 100 TCODES, I know its strange but it is how it is

Thanks.

[Former Member]

I see what you mean now.

I would take this approach:

Import the role to QA and send them a spreadsheet with all the transactions on it.

Tell them that it will be imported into Prod when you get the sheet back with a mark against each transaction to show that they have tested it.

Until they do it, it will not be transported.

If they do not test it then they will not get it. Most likely they will tick the boxes without testing and when they do get a problem with the role then it is their responsibility for not testing it.

[Former Member]

Thanks Alex and Jurjen!

I appreciate your sugestions, I guess will try to incorporate above suggestions. I will keep this thread open for little time for great minds to share their suggestions.

Thanks Again.

[Former Member]

> Until they do it, it will not be transported.

Bugger here is that they already are working in PROD and it works so far as it has always done before as well to support the system and the modules and the users.

They will just "sit it out" while you grow a beard...

You need to offer them some advantages from switching to your new role (only) and have some management support.

Company-wide "security base line" policies, which are reviewed and comparative results are made available to management also helps quite a lot!

One of my customers even published the system's current compliance status in their intranet, for everyone to see... Works like a charm --> if the policy is a well thought out and sustainable one and you have good tools to measure it, in which case it is also unlikely to mention many tcodes....

Cheers,

Julius

[Former Member]

>

> > Until they do it, it will not be transported.
> Bugger here is that they already are working in PROD and it works so far as it has always done before as well to support the system and the modules and the users.
>

You already hinted in the rest of your reply how to manage that one. Let them know exactly how bad things are at the moment!

I like the idea of publishing the compliance data. People seem happy for the IT function to do it but slightly less supportive when you start compare operations of different groups or countries.....

[Former Member]

> ...but slightly less supportive when you start compare operations of different groups or countries.....

If the lowest effort to get off the "red list" is to test the 50 transactions and the new authorizations to use them and get it over with, then the path of least resistance will be the solution you are offering them.

For this, security needs to be organizationally located somewhere it is not trodden on or stepped over... and you need to work hard at gaining respect for usefull (secure) solutions so that they come to you before inventing workarounds

Cheers,

Julius

[Former Member]

Indeed you are right. Security is often seen as the "whipping boy" but doesn't and shouldn't be. Over the last few years things seem to be improving but as soon as I see a client where the sec team has the "security officer" mentality, I know there needs to be some PR performed.

[Former Member]

Q1.

Should have followed your Auth Concept. Positive testing - what you want users to have, Negative Testing- what you don't want users to have.

Q2.

Should have searched in this forum..(AGR*) repeated several times.

Gp