The most accurate and informative source of information about software development and enterprise IT in the entire universe

Tuesday, April 1, 2008

The Software Tester’s Bill of Rights

Software testers are people too! Many of my best friends are software testers, and I can guarantee that they are people. In many countries, people have rights. Well, not everyone has rights. Airline travelers don’t have any rights, as we all know. Celebrities don’t have any rights. Neither do people who talk loudly on cell phones in restaurants or on the subway.

The reason why people talk loudly on cell phones is a design flaw, by the way. If the people who designed cell phones wanted to make friends, they’d program the phones to drop the call if the caller is being too noisy. Hey, rude people, mobile phones have sensitive microphones. You don’t have to shout!

Okay, we’ve established that airline travelers, celebrities and cell-phone abusers don’t have rights. What about the rest of us? We have rights, and that goes double for software testers. You know, testers take it in the shorts most of the time. The customer changed his mind after seeing the beta, and testers have to catch the variances. The architect messed up the caching algorithms? Testers have to account for nondeterministic behavior. The programmers spent too much time playing foosball? Test cycles get compressed. A line-of-business manager decided to release the software early? Test cycles get compressed. An end user found a bug? Testers get blamed for missing it.

Good people, it’s time we fight back with our very own Software Tester’s Bill of Rights. I know that you’re asking yourself, “What a brilliant idea. But who would write this Bill of Rights for us?” Fear not, gentle software tester. I.B. Phoolen is more than happy to draft this important document on your behalf. And now, without further ado, I present: The Software Tester’s Bill of Rights.

1. The Right to Own the Requirements

A tester’s job is to ensure that software meets requirements. Where do those requirements come from? Some from the customer. Some from the architect. There’s the problem.

Many of those requirements are obtuse, poorly written or plainly misguided. Those user stories — c’mon, folks. Don’t you have any imagination? Those performance and reliability metrics — you’ve got to be kidding, that throughput will never fly on a real-world network.

No wonder there are so many defects found by the test team, no wonder the overpaid programmers take so long to get the job done, no wonder the entire project is over budget.

Fortunately, we testers know better. We know what’s a good requirement, and what’s totally lame. Let us fine-tune the specs. Let us control the specs. If we disagree with a feature request, let us revise it or delete it.

If the test team owns the specs, we can guarantee that our tests will show that the application meets those specs on time, on budget, blah blah blah. Guess what? It’s not a bug, it’s a feature!

2. The Right to Kill the Project

That’s right. If the requirements are sufficiently moronic, or if we think the project is silly or necessary, we’re going to axe it. I.B. calls that “improving ROI.”

3. The Right to Choose Our Own Test Tools

Everyone talks about how developers are creative free spirits, who should be able to use the tool chain of their choice. If some programmers want to use Visual Studio or the IBM Software Platform, that’s fine with their managers. If Bob wants to run JBuilder, that’s fine too. If Sally wants to run Eclipse, nobody objects. If some show-offs eschew IDEs altogether to write the entire application with vi, lint, gcc and some duct tape, more power to them.

Meanwhile, C-level executive bozos want to standardize the quality assurance suites to embrace new flash-in-the-pan paradigms like “test automation” and “test driven development. They insist that testers use uniform tools and bug tracking applications, or — heaven help us — “ALM suites.”

Bullfeathers. Testers are just as creative as developers, as you can tell by reviewing my recent expense reports. We demand a generous budget so we can choose our own tools. As far as I’m concerned, every tester has an unalienable right to adopt the defect management system of his or her own choice, even if it’s Excel. If the CIO and VP of IT don’t like it, well, that’s their problem, bunky.

4. The Right to Employ Agile Methods

Preferably, those agile methods would be demonstrated by a perky aerobics instructor wearing a torn sweatshirt and leggings like Jennifer Beals in Flashdance.

5. The Right to Determine Release Schedules

I’ve had it up to here with test cycles being compressed due to boneheaded requirements, flawed architectures or nitwit coders who wouldn’t know an unchecked buffer if it bit them in the nose.

I don’t care if you’re rushing the product out to meet some contractual guarantee or the holiday shopping season. Under this Bill of Rights, any tester — any tester — can push back the release schedule at any time, with or without cause, and there ain’t nuthin’ you can do about it. If a line worker’s power to halt the production line improves the quality of Japanese cars, then by gum it works for software too.

6. The Right to Blame Microsoft for Everything

Self-evident.

7. The Right to Blame Open Source Software for Everything

Self-evident.

8. The Right to Redefine the IT Org Chart

In some organizations, development and test are peers. In others organizations, testers report into the development organization. Both of those models are flawed.

The only reason that companies hire architects and developers is to create applications for the test team to test.

Therefore, ipso facto, development is a subset of the test organization, and should be treated as such. That means that all developers work for the test organization. And, of course, all testers get paid more than developers, and get all the best parking spaces.

Take that, coding prima donnas. Who’s your daddy now?

9. The Right to Wear a Badge and Uniform

Heck, if we’re going to be the Quality Police, we might as well look the part. That’s especially important when doing Fuzz Testing.

10. The Right to a Whopping Pay Raise

If it’s good enough for politicians and CEOs, it’s good enough for software testers: We work hard, so we demand a bigger piece of the pie. Cash is good, but we’d like a generous serving of backdated stock options, too. Oh, while you’re up, could you grab my cell phone? I need to call Jennifer Beals. Thanks.

Retired software engineer I.B. Phoolen lives in Southern California, where he regularly frolics. He rarely updates his blog at ibphoolen.blogspot.com.

No comments: