Want-Ads for QA that Nobody Really Wants


Companies who write bad Want-Ads undermine their own interests, and might scare off the most qualified prospects. Ignorance of real QA attributes only becomes a problem when a company pretends the ignorance isn't there. If you don't know QA, hire a manager with the right experience to create a QA team. Read on to see some examples.

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.

      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.)

      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

    StickyMinds is a TechWell community.

    Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.