For a recompile, where the program is not expected to have changed even one 
iota, a regression-test is a very poor substitute for verification. I'd be 
amazed if your tests would be extensive enough to pick that the program was 
different, whereas a comparison (masking or "reconciling" the date/time change) 
will give you 100% surety that the recompiled-program-with-no-changes is indeed 
identical, in all but the date/time, to the original.

If your audit procedures still insist that you do the regression-test, still do 
the comparison and ignore the results of the regression-test (it's wasted). 
Because you then have a task which is ignored/wasted, the tendency will be to 
become "sloppier" with the regression-tests in general.

Look at an site which accepts RC=4 as "OK" without needing to look at the 
diagnostics. It is highly likely that there's dark and stinky stuff in their 
systems. Slackness leads to slackness.

A program which is 100% identical (executable code) to the previous program has 
already been tested to the exact extent of the previous program. Are there 
auditors, in a financial environment, who buy that? Yes. Do they all? It seems 
not. Or it is open at least as to whether things have been explained to them.

ABO is different, the executable code changes. The changes are can be 
"reconciled", through the listing. An automatic verification is going to give 
way better results than any regression-test. Yes, for sure, that is a harder 
argument with an auditor, but even if the regression test is still forced, I'd 
go with the verification every time to "prove" the system, and, yes, that again 
means the regression-test (applied for the entire process) is again degraded.

Analogies are tricky, but how about this (abstracting all "human error"): you 
have a very long list of single-digits which you have to add up; you have a 
process which removes all sequences of digits which add up to a factor of 10 
(and is guaranteed not to have removed anything else) by a total of all of 
those digits at the bottom of the list, and lists all those removed numbers 
separately. We assume 100% accuracy either way (ABO isn't doing anything for 
that), and it is going to be quicker to add up the new "full" list than the 
original, and the total of the removed digits can be verified to the total in 
the new list to demonstrate that nothing is lost. Given that the original list 
has been audited for its addition, is there a requirement to again audit the 
speeded-up addition of the new list?

For IBM-MAIN subscribe / signoff / archive access instructions,
send email to with the message: INFO IBM-MAIN

Reply via email to