Comments on: Privacy of Data – SAP Implementation

By: amjadm

amjadm — Wed, 30 Dec 2009 10:22:25 +0000

I haven’t tested or certified new software for over a decade
but the last time I did it we had a bunch of false data for use by the development team. Once we were happy with that, we took a copy of the program and ran it on our own, using the last backup copy of the real data – none of the development team were allowed to see the data we used. The final test was to set it up on a server in parallel with a production server and run it in real time with the same data being fed to both – again, the development team weren’t allowed to view the data or the output. In both these last two tests all data was purged from the test systems immediately we were finished with the tests. We did find a couple of things that needed correction in the final test and changes were made and a retest done. At no time did the development people ever lay eyes on real data.

By suitable data, I meant it had data of the correct types and sizes in the layouts and style in which the production side uses data – for example a database that’s supposed to have name address etc has fake names and addresses, but they are laid out like real ones, as per the Data Dictionary said for that database – and do the same for the rest of the test data.

To sign off on the acceptance, the company execs will probably want to see it run with live data, but that doesn’t mean the developer has any need or right to watch that test or see the data used. If the execs come back and accept, the developer walks away happy, if they say it doesn’t work, yet it works with the fake test data, then it’s up to the company to identify why the two data sets are different and provide that information to have the problem fixed. Often, an issue at this point is not a data difference, but the data input is NOT exactly as it was specified in the project proposal at the start because someone missed out on a minor data input method.

By: donethat

donethat — Sat, 26 Dec 2009 13:25:58 +0000

AmjadM: You lost me when you said “provide suitable data”. You got me right back when you qualified with “prepared to sign off on acceptance testing with falsified data”.
These days, smart executives do not sign off on anything less than “100% guaranteed”. Because they recognize loopholes and are not about to put their neck in one. I know I would not be able to provide that guarantee unless I tested on a copy of live data. The deliverable’s reliability would have to be qualified – and that’s a Catch 22. Both camps have reasonable positions. There will have to be some sensible negotiation.

By: amjadm

amjadm — Sat, 26 Dec 2009 05:11:49 +0000

Thanks Tom, I liked your approach. One of my friends on a separate forum has responded as follows:
Is the implementer justified in asking for super user password for production env.?

Answer is ‘no, as long as you can provide suitable data to mimic the
normal operations and are prepared to sign off on acceptance testing with falsified data, he is way out of line asking for anything else. If you insist he’s responsible for perfect operation in the real life environment, then there could be some area of concern for him to access to check things, but not until it goes live. Even then you could get by by having someone else with the relevant access codes working hand in glove as required.

Tom , any comments on this please.