The “Magic Wand” of QA…

OK, this isn’t a euphemism for something else, this is a real concept that I have seen employed by managers many times before. I’m sure we’ve all seen it at some point or other, and wondered several things:

• What the f**k?
• How can I educate this person / future people to avoid this misunderstanding?
• Is this my fault?

Firstly, what is the “magic wand of QA”?

This is a concept wielded by project managers in times of stress. When a project is late, it is delivered to QA for testing. OK we won’t go into the reasons why, just accept that the pressure’s on. The magic wand is expected to be waved by the afore-mentioned QA person / team, and *magically* it finds and fixes all defects in a system, without needing to send the product back to development for remedial work. Magic, eh?  The project manager uses the magic wand at his disposal, and gets the product out the door fast.

And what happens when the “magic wand” doesn’t magically fix everything?

Anger. Blame. Resentment. Finger pointing. All the usual stuff. And the quality of the product is QA’s fault. How dare we find (and not fix) defects! We have the magic wand… why didn’t we use it?

Sadly, in some companies I have worked in, the expectations of the magic wand have varied enormously – I have seen some of the following scenarios:

• “Hey QA have the product, we have ticked the QA box, we don’t even need to ask what state the product is in – IT’S FIXED! Let’s release it…”
• “Hey QA have the product, but that means it should be fixed… how DARE they tell us they didn’t fix the defects!”

Just for the record, thankfully my current company is quite enlightened on my role these days, and they are totally into the proper risk-identification / analysis of products, so I’m happy there! ?

So… why do these situations come about?

Well, education is one reason. QA being a bit too… insular? is another reason. A lot of this comes down to “workplace culture”, and some comes down to my own personal culture.

Companies who don’t understand QA and what it can do will invariably fail horribly at some time or other – either on individual projects, or (if they don’t learn from their mistakes) as a company. I have seen both happen.

A lack of understanding in a company about the role of QA… OK people don’t “magically know” what we do. We have to educate them. But more importantly, we have to educate ourselves first. Most of the problems that I faced… I faced before I had my ISEB / ISTQB training. Once I had this training, I realised that my approach was wrong, my employer’s approaches were wrong, and unless I changed things then nothing would change. I would end up stressed all the time, I would end up being blamed for product quality even though I wasn’t the one who put the defects in, and I would be very insular in the workplace.

Any why is my current workplace better?

Well, like I said… I trained myself and realised what I needed to do.

Then I starting putting on “lunch and learn” sessions – was was QA? What was testing? How could I help? How could we work together better? Granted there wasn’t a massive amount of interest – this interest increased when I started putting on free food! but hey.

I also spent more time in project startup meetings, project “retrospectives” (to determine how things were progressing, and how we could have done better as a team), and I also spent more time engaging with the managers about using my skills to save money through testing.

My approach shifted from “let’s break it!” to “let’s determine the risk of releasing this product given its current state”.

I also started pushing to start testing before the code was ready. Documentation, reviews, prototypes, demos. All useful for providing feedback early on. So… the managers were more on board, they had better visibility of what I did and what I could do. But what about the developers themselves?

I started working more closely with the devs. I constantly reinforced the message of “let’s find it before the customers do!”. I introduced “The QA Beer” (where any dev who got a piece of software past me first time which worked, and did exactly as stated in the requirements docs, got a beer bought for them by me personally. Only two have been given out in 2 years, but they are much coveted, and have turned testing into more of a game than a career challenge).

The end result… my current company doesn’t need “the magic wand of QA”. Testing is integral to what we do. The test team is integral in the workplace. I even get asked about long-term improvement projects to the products, so we’re interested as a team in improving what we do now. Much less stress, more interesting, more engaging.

Remember – if you do need to use “the magic wand of QA”, ask yourself this – do you need to wave it at yourself first?