So, you're a tester? What's that?

 #qa #testing #softwaretesting

This was an internal blog post that I thought I'd share.

So, you're a tester? What's that?

Have you ever been asked this question? Where to start the answer...

Are you into Quality Assurance (QA), Quality Control (QC) or just Quality?

I think about this question from time to time, depending on the articles, blogs or tweets that I'm reading. There's been plenty of tester twittering about quality in the last couple of days so the question re-surfaced for me again.

QA:
If you think of yourself as being in QA, do you really "assure" quality?

Isn't the assurance really taken care of by the developers/designers (that implement changes) and the project leaders that direct the effort?

Ok, QC then:
Do you control quality? Do you make it better or worse? Your testing effort surely feeds back into the design/development loop - and this is a valuable (sometimes I'd use the word crucial) contribution. But is it the tester that's controlling quality?

In some senses "quality control" is taken from production line uses. This essentially is a sampling and checking exercise. Well, sampling definitely fits into the activity of testing. Checking is one element of testing - it's a comparison against a static (unchanging) output. However, this only covers a subset of testing.

Production lines also produce the same output (or at least intend to), so software does not fit this model. By definition, a development project is producing something new/unique - so the idea of a production line check only works for test cases that are known to already work - ie regression test cases.

Ok, what about new test cases and the learning (and even exploring) side of testing. Yes, QC doesn't quite do it here either...

Ok, so are you just into quality?
Well, there's a problem. Quality is not a judgement that you as a tester can make about a product! Some fault-prone products may need to go out during a certain quarter to keep the cashflow ticking over - without that there's a risk for less R&D, jobs, products and testing needed etc.

So how do you think about quality? I like Weinberg's definition that "quality is value to some person". This might ultimately be your project sponsor or product owner - and their values are "usually" a reflection of what they think the customer's value are / will be.

So, when you're maybe so far detached from the customer how do you make sense of quality?

Even if you are making reports against your project sponsors definition of "good enough" quality, your findings (reports) are still only one factor in the "release" equation.

Diamonds in the rough?
It's those reports, investigations and approach to digging for that evaluation that is the real key to a tester's role. I think of it as being part investigative journalist (credit to Michele Smith for that analogy that I'm happy to borrow) or researcher. You're digging for the story, the real story, the story behind the facade - it's serious and not a tabloid activity - the story/evaluation is a professional finding.

But, it's a report (or set of findings). Don't get emotionally involved with the product so that you're "disappointed" if a product releases with what you think is "bad quality".

Your reports are used to frame the product - put the story of the product in a setting - you're certainly not any type of police (hopefully all are agreed on that.)

Remember, if you are "disappointed" then take the team approach and sit down to look at improving that investigation (test execution & design) and reporting next time - this is tester + developer + project manager together.

Downbeat? No!
The best approach you can have towards testing and quality is that your testing is providing information about the product (telling a story as I usually say) that will help your project leaders / sponsors understand if their idea of quality (their values) are being backed-up or disproved by your findings.  [Credit to @michaelbolton for parts of this sentence!]

The tester is providing very valuable information about areas of the product that are meeting expectations, or not, issues and questions about the product's usage and suggestions for further areas of investigation.

It's only the tester that's providing this vital information - remember when the project sponsor is making a decision about releasing a product they don't fret over the results of the code desk check...

Confused?
You still don't know what a tester does? Well take a smattering of investigative journalism, professional researcher, scientific experimentor, philosopher and put into a devil's advocate mould and you're getting close....

What would you add into the mix?