Tuesday, June 21, 2011

Blood in the water

The workplace is getting || this close to the next major release of our software. So tempers are short, stress levels are rising, regression scripts are breaking, new emergency fixes are being released and... what?

Oh yes. In theory, it's not supposed to be this way. There's this mystical thing called a "lock date", after which nothing more than bug fixes to the release project are integrated. I'm not sure when this release's lock date was, but it flew by a while back. The actual lock date for our software is typically some time after no-one is using that version any more.

I only wish I was exaggerating... Today an emergency fix went out to a customer. The "emergency" consisted of one set of extra logging, and two minor feature requests. That's right. New features. There were four requests for emergency fixes came in during the day, most of them rather less than the life-and-death-the-regulators-will-have-you-for-lunch kind of things that emergency fixes are supposed to be for.

This release has at least eight new development projects in it as well as a massive number of bug fixes, most of them copies of someone's emergency two weeks ago. This tested by a team of five-soon-to-be-six over the course of maybe two months. Um. You think maybe there's a slight problem with scale here? Possibly even a little case of "bit off more than we could chew"?

The problem, really, is one that bedevils anything that makes software. No-one can estimate a software project until they've done enough work with it to have a good idea what they need to do. When the project is paid for by Customer X who has a drop-dead must-have-it date of Y, things get... interesting. Because usually Customer X's drop dead date is somewhere earlier than the time it would take to build and test the feature - and rather than have Customer X take their money elsewhere, the sales guys tell them we can do it, then let the project managers explain why the feature isn't going to be quite as advanced as they expected... Hilarity, as a rule, does NOT ensue.

And people wonder why testers have such a negative reputation. We testers are the ones stuck between that immovable release date and the stealth features, late development (usually because someone failed to account for little things like "the developer is human and needs to sleep at least a few hours each day"), unforeseen weirdness with third party interfaces, the world's weirdest regulations, and who knows what all else. (Whatever it is, I saw most of it today. Yes. I'm tired. Yes, I'll be really glad when this release goes out. Then I can take a deep breath and dive headfirst into the next one.)

More on the tester negativity thing later, when I'm not too fried to think.

2 comments:

  1. The last time I was in this situation, I had to test a feature that had been completely developed in it's own special little silo for a year and was stuffed into a release at the last minute because said release was "not exciting enough." It comes in many flavors but always tastes the same and there's never a great solution. Queue sharks!

    ReplyDelete
  2. Hi Marlena,

    I don't think there's a tester anywhere who doesn't know all about the sharks and the blood in the water. It seems to be an integral part of the software development process (which makes me wonder why there's no designated shark handler who has the job of releasing the sharks - and the even more fun job of getting them back into their enclosure once the release has escaped!)

    ReplyDelete