Code written by testers does not ship. That doesn’t mean one ought to ignore basic software engineering principles.
We’d lost a person from our group to a layoff. Here Meredith, run this person’s module for the current release final regression, the test environment is all set up. Fine, no problem. All test cases passed.
Now run that module as early regression on the next release, and get that module packaged and submitted so it can join the set of automated test modules that get run by the regression test team. First try: some test case failures, oops, feature interaction, I’ll have to do some maintenance as well as the packaging. OK, that happens.
I then made several distressing discoveries … my lost coworker had not been the first person responsible for this module, and I think that what happened was that she had inherited a mess from her inadequately trained and/or inadequately supervised predecessor, and she had made it work for the initial release of the feature but had not had time to fix it properly. A lot of variables were hardcoded instead of being read from the in-house automated testing framework, so the module was tied to a particular testbed. I started fixing that … and discovered another reason for the module being tied to this testbed: this module, which tested a media feature, had been implemented using a special version of sipp that had been built to include a specially hacked version of an unsupported sipp feature. Both test procedure and verification logic depended on use of this special sipp, which was running on the sipp server used for this testbed. The test case routines did not always implement the test cases as written, for example there were test cases that called for media in both directions in the test call, and the routine produced only one-way media. And a few of the test case routines were implemented as written, but the test case was actually wrong (and the wrongness was not due to the feature interaction mentioned above) – I suspect maybe the Dev reviewer(s) had read the test case titles and not always the actual content. And the module was not well written, there were major chunks of duplicated code that should have been abstracted.
So my little packaging task turned into a major refactoring project. Dealt with the feature interaction, made it able to run in any testbed, made it use standard sipp, eliminate code duplication, fixed incorrect test cases, made notes about additional changes needed for adding 2 way media if and when that was desired (my manager and I having decided that me doing that was not worth the additional time it would require).
Sigh.
I suppose I get the weird stuff because I can cope with the weird stuff.
I hope that first guy got a job where he got better training, or maybe found a new line of work.