Setting up authorizations when execution is done locally

Use

As shown in the technical system landscape section, you have to distinguish between two parts when it comes to eCATT authorizations: the eCATT execution itself and the part in which the application is tested. Normally, this is done on two different systems:

  • The eCATT script is located in the central test system. The eCATT code interpretation is also done in the central system.

  • The test of the application itself is done in the tested system, also called SUT (System Under Test).

When the central system and the SUT are the same, the authorizations in the central system and in SUT contradict each other, when you restrict the access of a user to certain test scripts. If this is the case, there are two ways to overcome this problem:

Option 1

  • Allow activity 16 with SCAT and *.

    This enables the execution in the target system. The reason is that if SCAT is allowed, also SECATT is allowed (and will not be checked separately).

  • Restrict activity 16 with ECAT, ECSC, ECTC to the allowed objects.

Option 2

  • Allow activity 16 with *.

    This enables the execution in the target system for all eCATT objects.

  • As you also want to restrict the execution to certain eCATT objects, instead of restricting the execution of these objects (activity 16), you can simply restrict to display these objects (activity 03). Activity 03 is checked before the execution as well, as nobody should be allowed to execute when he is not allowed to display a certain eCATT object.