Want-Ads for QA that Nobody Really Wants

Experienced software QA professionals agree on one thing: "They don't know how to hire us"-"They" being technical managers, especially ones from small firms, who don't manage software test or QA. Technical recruiters often do not know how to hire QA or test team people. And the problem can be compounded by job descriptions like the following:

Wanted for Large System
One QA person who will just come in and test it.
Management skills not required.
Test planning not allowed.

This ad assumes that one person can test a large system, if only a tester will come in and get to work. It's a fantasy. If you have six to twelve people developing a system, one person won't be able to test it-though there are always workaholics who are willing to give it a try. When eventually it becomes obvious that you need to hire more people, your come-in-and-test person might not know how to hire them-or write a system test plan showing what to test and who you need to test it. Your person got some testing done, but nobody knows what they mean by "some."

Perhaps you've told yourself, as some managers do, that you can do without extra QA, since the developers can test the software as soon as they're finished writing it. But a developers' development is never done: they'll be fixing bugs at the end, and can't be relied upon to find them. Despite the need, QA management is viewed as a luxury they can't afford. I've known shops that did without QA management for a year. They had three test engineers, but each was a law unto himself. The company didn't know what it was paying for, and neither did the customers.

Wanted
Twenty-five people off the street to sit in a room
Load-Test a wireless device from the UI.
No other testing required.

Yes, a company actually tried this. And the release was an unhappy one. Twenty-five is too few connections for a server-and it's too many collisions for a room. Handheld devices do need some naïve-user UI testing, but twenty-five is multiplying naiveté beyond necessity. What you save on warm bodies will buy real testing expertise where you need it: on the development platform, and on the server (if they're not the same.)

Wanted
Junior programmers (Java and SQL)
To test an e-business application while
waiting to move into development.
Previous QA experience not required.

I've met several teams like this. They turn up a lot in small, isolated companies whose managers think test engineers are nothing but wannabe (or failed) programmers. Test engineers may actually be screened out as technically unqualified, and everyone hired wants to prove they can program and move into development. One person invents a neat routine that can be adapted to test a whole slew of different functions, runs a bunch of changes, but doesn't save any of them to run again.

Someone else writes table-compares without creating any test data for the tables. And the nominal manager never thinks the business logic can only be tested by the PhDs who write them-as if computer math in a database app is an arcane mystery. Every neophyte works alone, and if any of them discover something useful about test, the others don't hear it. Oh, they meet every couple of weeks, but only so they can argue about automation tools. But automation tools can't solve the problems of a test team that doesn't know how to think test.

I don't mean to say that developers-in-training should never be hired to do test. I've hired many, and most have made contributions well worth the trouble of having to replace them when they moved on. But a test team with nothing in it but proto-developers is lame, and ineffective, like a wheel-reinvention taskforce where nobody has information that the wheel should be round.

Wanted
Hands-on QA manager with proven track record in
Writing automation harnesses and FDA documentation.
Must know ISO9002 and Six Sigma
With development experience in C++ and Java.
MBA with legal and brokerage experience, and double-byte localization.
Foosball strongly preferred (EOE, but prefer members of the race of X-men)

Well, maybe I'm exaggerating, but you've all seen QA ads like this, asking for a person who doesn't exist. Does the company know they're in search of the impossible? Do they think their QA is too hard for anyone without multiple careers-not to mention multiple personalities?

This kind of ad makes a negative impression on knowledgeable candidates, but it's usually meant as a fishing expedition. The company doesn't know what it wants, but figures it will know it when it sees it over the interview table. Wishful thinking, of course. Most managers who run ads like this have never hired for QA, and irrelevant qualifications only add to the confusion. Anyone remotely like this would be overqualified for their shop, and they still don't know which part of the qualifications they really need.

Pretty soon they just give up and hire "somebody who can just come in and test" (q.v.), or somebody who "fits in," i.e. a twenty-something male with limited experience and the word "test" on their resume. What they ask for is way too much, and what they settle for isn't enough: someone who bails, overwhelmed, after a few days, or fit in nicely but must be asked to leave after making hash of one or two releases. It's a folie a deux in any case. All you ever really needed was someone with decent QA experience. Don't write want-ads like these if effective QA is what you want. But what should you ask for in your ads?

Here's a start: 

• Hiring skills (Expect your manager to hire test engineers with different skills, not all naïve, not all senior, not all the same. And not all junior/proto-developers)

Companies who write bad ads are actually signaling their inexperience. Luckily, high tech people are smart, and enjoy learning. Ignorance only becomes a problem when people pretend it isn't there. If you don't know QA, hire a manager with solid experience who does know it. And once you've hired that person, don't second-guess her about how to do the job, or about how to hire additional team members. You may assume that choosing domain knowledge over QA knowledge will get your testing done soonest, but this choice is based on a fallacy of which learning curve is the steepest.

Experienced QA professionals can be trusted to become productive on a new technology in months or even weeks, but it takes years for an isolated group to reinvent the techniques of software test. If your software is suffering from test isolation, get someone to help your group set the already-invented wheel rolling smoothly.