The Quality Assurance Job Description Demystified


As with any other type of job listing, a quality assurance job description is general at best and incomprehensible at worst. They are often vague and lack an accurate explanation of the role that needs to be filled.

That a clear and accurate quality assurance job description is hard to find is really no wonder. If pressed, most people wouldn’t be able to write a job description for the position that they hold themselves. What they can do is make a list of duties and responsibilities that they would like someone else to deal with. It’s the “here-is-all-the-stuff-I-don’t-want-or-know-how-to-do” job description.

Why am I bothering to be critical of the Quality Assurance Job Description? Because I have extensive experience being the person on the wrong end of…”if they only knew what they wanted.”

The subject is Quality Assurance. How can an applicant be expected to assure quality when they are actually interviewing to soothe nerves, massage egos, or do the Hokey-Pokey? If you want your product to be “quality” then that should be the focus of your quality assurance job description.

It seems to me that writing a quality assurance job description really should not be all that complicated, but alas, I am apparently in the minority. QA job descriptions range from cryptic to non-informative to just plain dangerous.

The titles lack uniformity which can cause confusion for the job seeker. The skill sets listed vary greatly; from very niche-specific software experience (regardless of whether or not it meets the needs of the job) to being able to write code (which should never be a main QA job); from establishing testing criteria (although no one at the company understands why that is a benefit) to language fluency so that you can be the “QA Manager” and direct an offshore team (whether or not you know anything about testing).

There are many pitfalls for a prospective applicant to navigate. I have stumbled into many of them myself and if you are interested in one of the many Quality Assurance Careers, you will too…time and again, I’m afraid.

Here I endeavor to bring some clarity to an otherwise murky subject. I hope that I can help you as you look for your first (or next) QA job. You will undoubtedly need to read a quality assurance job description or two to get there. I wish you luck as well as, hopefully, some perspective.




Who Comes Up With These Job Descriptions?

First we need to understand who is writing the quality assurance job description for a company. More and more, this task is being handled (or at least finalized) by Human Resources. As wonderful as any HR department is, they have no more insight into effective QA requires than anyone else outside of the Quality Assurance department.

Beginning from a perspective of “QA means testing” (after someone has written imperfect code), and believing that testing will fix bugs in the code, most people outside of Quality Assurance just don’t know what QA does or how they do it. This is often the genesis of some whacky job ads.

Even when they do gain some insight into Quality Assurance Methodologies and Processes, it is all too easy to fall prey to listing only easily measurable criteria. Many a quality assurance job description is too focused on the specific “technical” skills necessary for the position.

(Each of these is from an actual quality assurance job description)

It is much easier to state:
• 5+ years of testing experience for multi-tier web based applications built using JAVA/J2EE technology stack
• 3+ years experience with SilkTest
• 7+ years Load Runner experience, implementation experience a plus
• Bachelor's degree in computer science or equivalent

Than it is to try and quantify:
• Self motivated and takes pride in work
• Strong verbal, technical writing and interpersonal skills
• Improve test process and test coverage

And thus, specific technical skills appear to be the most accurate part of the quality assurance job description. But beware! Often these listed technical skills are a wish list, and an inaccurate one at that.

When the question of “what skills do we need on our QA team?” arises, many answers are given. Each team member has an opinion, the engineering team has an opinion (or several), the product managers have an opinion, management has an opinion, and the list goes on.

When the person tasked with creating the job description finally attempts to reconcile all the noise thrown at them, the “specific” technical skills appear to be their salvation. They can ask for specific numbers of years and names of programs…all they have to do is put them together.

This may be what the QA team really needs and it may not. It may be a prime listed requirement in the QA job posting, but when you interview you might find that no one you interview with really cares about that skill.

Use the technical skills as a guide; are you even close? Are you familiar with any of the technology listed? You should be, but you should remember to ask about specifics regarding these skills when communicating with the poster about the job; Do they know what they want?

Also watch out for technical skill listings that you know won’t be necessary in a short time on the job. If you are the expert in Silk, or Loadrunner, or Java, or Perl and the tasks listed in the job description can be completed in a very short time, then what will your position be when you have accomplished the listed tasks? Not every quality assurance job description will list the specific goal for each role, but some do. If you are the expert, judge the listing like an expert.

Then they add the intangible qualifications:
• Diverse interests and a passion for technology
• Champion and lead initiatives to automate testing, reduce test cycles
• Analytical and problem solving skills with hands-on, “get it done” attitude
• Self motivated and takes pride in work

Those are all fine and dandy, but what use do they serve in a quality assurance job description? Any of the intangibles listed above can be faked in most interviews. I have seen it done. “Why yes, I am quite enthusiastic!! I love technology and have ‘get-it-done’ attitude!” All sounds great in the interview…but how does this candidate actually provide value?

I suppose those intangibles are better than listing:
• Able to breathe
• Not an idiot
• Can interact amicably with other humans

But really, do they get you a “better” applicant? If you saw a job description for a tester that included “self motivated and takes pride in work” would that keep you from applying for the position? I hope not.

What I am saying is that there are useful items in a quality assurance job description and there are throw-aways. You must pay attention as you read the listing to what the job really will entail. What are they really trying to tell you they are asking for?

And just because they always make me shake my head when I read a quality assurance job description, here are what I call the “are-you-serious?-qualifications”.
Again these are all from actual job descriptions:

• Must be able to manage time and maximize amount of test coverage on each title
*Does this mean they don’t want you to waste your time and not really test?

• Develops solutions to moderately complex problems
*I can just hear the CEO: “Here at Company ‘X’ we strive for mediocrity!”

• Uses advanced knowledge in the creation, preparation, and conduct of quality assurance reviews
*Don’t know about you, but I tend to use obsolete and antiquated knowledge when I go about my work

When you come across any sort of these absurd entries, send them to us. If they make me laugh as well, I’ll add them to the list (be sure to include your humorous thoughts when you send it).

Ok, more on the mystical quality assurance job description…




Where You Can Get Into Trouble

One section to be aware (and wary) of is the Responsibilities. Not always broken into its own section, you may have to sift through the whole posting to pick these out – but make sure you do so. This is where they will hide the “stuff-I-don’t-want-to-deal-with” list.

Watch out for line items that make you responsible and accountable, but over which you will have no control. This is not usually an evil trick. Most times what is desired is for whoever gets the position to actually succeed (often where the last person didn’t) – it’s just that you probably won’t be given the tools you’ll need.

Be aware of these entries. They are all too common. Dig them out and be sure to pursue a resolution that you are comfortable with if and when you interview; what variables will you be able to affect, what processes are already in place, what is and is not working right now? Get answers to these types of questions so that you have a clear understanding of whether or not you will have a chance to succeed.

Here are some real-world examples from actual quality assurance job descriptions. Do you see how not clarifying could set you up for failure?

• Champion and lead initiatives to automate testing, reduce test cycles

o Why aren’t these automation initiatives already being championed at the company? Does the company not buy-in to this type of process?

• May serve as a coordinator for all testing activities on a project

o “May?” Will it or won’t it?

• Develop test plans and detailed functional and usability test cases for each deliverable of the software and project implementation services

o “…each deliverable..?” Ok, and how many deliverables is that exactly?

• Provide deep information to developers to resolve issues quickly

o These two phrases are not mutually inclusive. You may be able to “provide deep information” but how much control do you think you will have over developers resolving issues quickly? It may be quick, but maybe the developers aren’t motivated to be quick. Are you really to be held accountable for the speed of their resolutions?

• Must have an understanding and application of QA principles, concepts, industry practices, and standards

o That’s a pretty wide net you’re throwing there. I’ve been in QA since 1997 and I know there are so many different principles, standards, concepts and even more schools of thought as to what passes as such. That is a well-meaning, but unclear bullet point




When You Know They Don’t Know

If you have managed to navigate the quality assurance job description this far, here are a few more hints that you are reading a QA listing written by someone who just doesn’t get it. They probably mean well, but don’t understand what they are asking.

Be careful of listings that include these items, it shows that you are dealing with someone (or a company) that has no idea how to create long-term cost savings while improving quality. They want you to match their magic formula, and then produce the magic that their formula assures them you have – and in the ways that they understand. Good luck.

Reduce Cost / Shorten Test Cycle / Champion the Cause
The inclusion in any quality assurance job description of any of these phrases should be cause for pause. For some these are just buzz words (I’m not saying that like it’s a good thing), for others these phrases are the “magic” bullet they think their company needs.

There are two potential challenges with meeting any of these requests. The first is that none of these requests is quantified. By how much are you to reduce cost, or shorten the test cycle? How are you to be judged as a champion for quality? These are glorious goals, but what is the reality?

The second challenge is that of implementation. If these things are so needed and do-able, then why aren’t they being done already? It is, of course, possible that the company does not have anyone as wonderful as you in place to meet these goals – that’s possible. If so, it should raise the question of “why not?”

Maybe they’re just finally getting around to it – again that’s possible. And maybe they have found you at just the right time – that’s great! But have you considered what you might be up against?

The company already has a way of doing things (obviously). What they want is for you to come in and change those established “systems”. Honestly, I think that is a very commendable request (mostly). But what is not taken into account is the resistance you may encounter.

In what painless ways are you going to reduce cost? Will everyone just trust you when you implement the new processes and procedures necessary to shorten the test cycle? It behooves you to get some answers to these types of job description entries when you are interviewing. Now is the time to unearth some of the nasty secrets that they didn’t post on the job board.

“Champion quality across the company…” has always just sounded ominous to me. This says to me that the company is already filled with enough people who either don’t understand, or don’t care enough about their product to make it better. Is there no one championing the cause of quality now?

Perhaps they just don’t know how to go about creating quality improvements themselves. Maybe they think that all it will take is someone to be the “bad guy” and tow the hard line – demanding improvement (not very inviting). Maybe quality hasn’t been a high enough priority before (DANGER!!).

In any of the scenarios above (however common), what you have is a company that has not seen fit to prioritize the quality of their own product over many other myriad tasks. Now they want someone else to come in and make it all better. Be careful, this may be like trying to teach pigs to sing.

Chances are in order to reduce cost, shorten the test cycle, and/or “champion” quality, there will be many and/or potentially severe changes necessary. This is usually difficult for people to adjust to. You are being brought in to wield the scalpel or chainsaw and make the changes.

It is common for people to not succeed in this task. Established, rewarded behavior can be very difficult to change (assuming the company actually wants to change). Your task is to fix quality by introducing more and better (and cheaper and quicker) testing.

“Won’t quality go up if we just test more?” is the common thought. Just sprinkle a little more testing in at the end and you get a better product, right? Wrong! Testing is a skill and a useful tool to enable an increase in quality. But unless you “bake-in” quality from the start, you are spending more, getting less, and cannot understand why your product can’t make the kind of improvements you want.

Being the “champion” will mean that you have to convince people that there is a better way to use their time – this is always greeted with great joy and fanfare, isn’t it? You get to show people that they are not using their time as effectively as possible – everyone takes this critique with open arms right?

Seriously, I am not trying to badmouth being a “champion” or carrying high the “quality standard” (read the rest of this site and make up your own mind). What I am cautioning is that when you see a quality assurance job description that is looking for an outsider to come in and be the torchbearer for quality for a company, you should ask yourself why. And then ask those that you interview with. It’s not that you shouldn’t take the job; it’s that you should make an informed decision as to whether or not you want the job.


“Excellence is the gradual result of always striving to do better.”
~Pat Riley




Must Have Experience With “Bugbase X”?
This requirement always gets me. I can’t help it – I just think this is such a useless line item in a quality assurance job description. Who cares if I have used “Bugbase X” before? It’s a bugbase right? Like, a database with a GUI and a few standard buttons, right?

If this is an important point to make, then the job poster has probably been hiring the wrong people. IT’S A BUGBASE!! Very much like standard makes of bicycle, if I can ride one I can probably ride most of the rest without issue.

“Is that a Schwinn? Ah bummer, I only know how to ride a BMX.”

Since 1997, I have used no fewer than 15 bugbases. And I have been able to figure out all that I needed to use each and every one of them. Now that is not to say I haven’t had any problems with them, but the problems have had nothing to do with understanding how they work. The problems have revolved are the fact that so many of them DON’T WORK.

If you are to require that I use “Bugbase X” then it seems I should be allowed to require you to explain why your company sees fit to waste the immense amounts of money on a crippled, poorly implemented, slow, featureless defect tracking system. If a quality assurance job description actually states that I should have experience with “Bugbase X” then I know they’ve had issues in the past (they’re not asking for that experience so that I’ll fix the bugbase).

I have never worked with a Software Quality Assurance Professional that couldn’t use any bugbase thrown at them. A bugbase may have poor search capability, lack useful features, allow only a couple of data entry points, or be so painfully slow that it literally wastes hours of workers time each day, but they are all simple to use (once you understand what they can’t do).

A real SQA Professional can use any bugbase. In fact, most of them can regale you with sidesplitting stories of bugbases “gone wild” or the worst ones they ever used. But if you feel a need to list in your quality assurance job description that you require experience with yours…you don’t understand much about quality.




My Quality Assurance Job Description

If you can’t figure out how to use my bugbase, you won’t last on my team long…I let that sort itself out. If you can’t figure out a bugbase, then your testing, measuring, and reporting skills will lack the necessary thought processes to excel in QA – and that’s alright, becoming a QA Tester is definitely not for everyone.

I also know that I can hire an automated testing expert if I need to get scripting handled and set up for long-term maintenance. I don’t require that each person I hire have “7+ years php scripting”, or “extensive familiarity with the SDLC” – these are skills and experience that can be learned.

What I’m looking for is an attitude. I want people in search of excellence. I look for people that get excited about the possibilities. I get people that learn to continually improve…and never stop.

Beyond that, I just need to know how your brain works. How do you think? What perspective drives you right now? Are you going to be a useful addition to my team or not?

My quality assurance job description just has this:







Return from Quality Assurance Job Description Demystified to Successful Quality Assurance Home



E-mail Address
First Name (optional)
Then

Don't worry — your e-mail address is totally secure.
I promise to use it only to send you SQA the Right Way!.