User testing/signoff procedures

[Jelena]

Most likely every SAP client has some kind of a procedure in place for the user testing and signoff before the transports may be moved to production. From your experience, what procedures have you seen (not just in the SAP world) and which ones, in your opinion, work the best?

Here are two examples from my past jobs as a programmer:

1) Developer prepares testing scenarios (in Excel); Business Analyst runs them through and marks each line with the result. This spreadsheet is then embedded in another document that lists all the items to be implemented in that week (scheduled weekly implementation).

2) A signoff form (Word template) is prepared by developer/functional analyst and emailed to the business user responsible for testing. The form includes basic information (usualy there is a corresponding ticket) and developer's name/date as form of a signature. The user then signs/dates the form and returns it to the developer. The form is forwarded to Basis admin as an approval to move the transports.

In perfect world, the signoff should not be an additional burden for a developer yet need to ensure that testing has been performed properly. In reality, this may be difficult to achieve. As a developer, I liked the 2nd option better, but it sometimes lead to users signing off without any testing (and then guess who gets blamed when something doesn't work).

What are your thoughts?

[Former Member]

Hi

One of my favorite moans... testing

A requirement for an addtional custom transaction requiring a custom program is raised and approved, the new coding is created and moved to QAS. The functional person logs onto QAS and runs the additional access and it works as expected.

The sign-off in whatever form is given and the program is transported to Prod where the end user says they don't have authorisation to run it. Julius' comments about users with SAP_ALL and developer creating the roles is a good point - all the individual components of the testing need to be accounted for (including SoD and authority checks/call transactions) and security can be the last people to know something new is needed.

Sign-off is fine as long as we know what is being signed off - testing at role level using proper test users with just the one role and SU53 are needed and this isn't always adhered to. The documentary evidence is excellent to have as long as it isn't left to the developer and security to raise and complete and the test users are actually used...

moan over with...

David

[Former Member]

What can at times be a lot of fun (if you are that way inclined) is negative-testing and pen-testing...

Cheers,

Julius

[Former Member]

One thing I feel strongly about in this process is that the programmer should also "develop" the application authorizations to fullfill the user scenarios for using it - or even build the roles in DEV.

This is particularly true for integration scenarios where the enduser is a System or Service user and feedback from them in integration testing is by design zero.

SAP has a very cool process for this - except that it does not work perfectly all the time when developers take short-cuts or don't read the documentation... or the users are rolled-out with SAP_ALL to start with... ).

Cheers,

Julius

[Lakshmipathi]

Invariably, users dont have authorisation to access either to development client or quality client. So as a functional consultant, once we get the documentation on users' new requirement, I will configure / customize the requirement, test it and if found okay, release the request in development and move it to quality. Again in quality, one more test documents would be generated and a screen shot of the document flow / FI posting would be sent to user's mail for their confirmation.

Once they give green signal, the request will be moved to production client. At times, users again change their original requirement once we mailed the test documents. So again we have to start the process from development client to quality and then to production.

We can get the users' confirmation on the test documents generated from development client but in most of the cases, configuration settings in development client would not be in line with production client and in order to ensure a trouble free process, the above process is being followed.

thanks

G. Lakshmipathi

[Jelena]

Thanks for a reply, Rob.

When the users signoff on something, how complex that step usually is? Is it just an email like "yes, I approve it" or is there a Word/Excel document (like in my examples) used? Or is it something more complex, e.g. a workflow or a special software?

Also I'm curious what evidence (if any) is usually expected from the users as evidence of testing?

[Former Member]

We rely on an e-mail from the users. While this may or may not indicate just how much testing was done, the important thing is that it satisfies the auditors. When they ask to look at a transport, we are able to show them the original request, the transport log and the sign-off.

QED

Rob

[Former Member]

I think the developer should be as far removed from the user testing as possible. If the developer creates the test cases, the testing may only cover what the developer thinks should be happening.

Ideally, a functional analyst should both give the developer the business requirements and develop the test cases. When he or she is satisfied that it works, then it should go to the business user for the final sign-off.

Rob