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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN