Skip to Content

The Year of Testing Dangerously

In my Bulletproof Doc weblog I discussed problems with forms in Production, and stressed the importance of rigorous testing.  Here I want to spend a bit of time on the flip side: test data itself can be dangerous.

In my view, the trickiest time to be testing SAP output documents is when fax or email servers or any Production printers are connected to a test system.  After all, the cameras are rolling.  If a tester doesn’t realize where he is sending a document – or what it contains – or a recipient doesn’t know from whence it came, problems can arise.

Some examples:

A) A test document sent from your QA system to a printer in one of your warehouses is mistaken for the real deal and triggers a product shipment (but, hey, there is a silver lining: at least now you’ve shown that your form can handle a quantity of 9,999,999.99 units).

B) A document with inappropriate language, including an unflattering nickname for a business partner’s CEO and some off-color header text, slips through the test fax server to a business partner.  And no one is laughing.

Some basic ways to safeguard against the above scenarios:

A) Insert a noticeable watermark (e.g. the words ‘THIS IS A TEST DOCUMENT ONLY’) across every page of your forms.  Set a condition so that it is generated whenever the current system (sy-sysid) is not your Production environment.  This is simple to produce in SAPscript via an IF…ENDIF construct within a dedicated Page Window.  A similarly dedicated node in a Smart Form with a check on the current system in its Conditions tab would also work.

B) Set and enforce a clear policy for test data creation, barring the use of any language that a reasonable person might find offensive.  If you encounter any such data, either scrub it or quarantine it somehow to limit its reach.

Due to test data re-use, there is no predicting what will wind up getting pulled into an output form.  From there, it has the potential to reach a public audience, either directly or indirectly.  Which is why it’s also a good idea to communicate both internally and externally to any parties that might be impacted by output docs being tested.  If possible, print preview them to ensure nothing improper appears.  And after output has been issued, confirm that it went where you expected.

Fortunately, serious problems during output testing don’t seem to occur often.  But problems do occur…

Let’s just say: I’ve had to call my neighbor about a frisbee landing on his roof before.

Then again, I’d rather have to face my neighbor over an errant frisbee than a ball through his window.

This is part 7 of a series of Weblogs on SAP output forms.

Be the first to leave a comment
You must be Logged on to comment or reply to a post.