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?

A Plague for Critical Thinkers?

#softwaretesting

Are you a critical thinker? Do you know? Do you care?

If you’re a software tester then the answer to the first question is probably yes.

Plagues

It’s with this aspect in mind that I’ve been reading James Whittaker’s series on the 7 plagues of software testing. I enjoy reading James Whittaker – whether in book or in blog form. He has great insights and viewpoints.

I have become increasingly perturbed by the “7 Plagues..” series of blogs. Yes, there has been the research, analysis and insightful observations, but the thing that has been nagging at the back of my mind has been the use of “plague” in the titles.

Critical Thinking

I believe most testers are critical thinkers – they need to be due to the nature of the job – whether they realize it or not. It’s with this in mind that I feel uneasy about the use of plague – this is more of a rhetorical device (in the parlance of critical thinking.)

Critical thinking (to paraphrase) is the study of arguments/suggestions to analyse the underlying proposals and conclusions to determine whether the argument “holds together”.. In this field the idea of a rhetorical device is one where a loaded/weighted phrase is used without contributing anything to the proposal to advance an argument. I.e. it’s emotional weight is intended to sway the decision rather than a clear argument.

Clarity

Clarity is king in software testing. Yes, there is room for analogy, but when a series of articles pounds the idea of a plague affecting software testing then it is reasonable to assume that some people will think of software testing being “plagued” by certain problems…

I am not going to go through the individual plagues here – I’ve made comments on some of the posts (both agreeing and disagreeing with the contents.) However, in summary, I can say that James highlights some potential pitfalls that testers (and the industry at large) can fall into.

I suspect the meaning was “plights” that can affect tester/industry rather than “plague or epidemic” – maybe even meaning that something was endemic. However, I was tripping up on the use of “plague” and that partly distracted from the content.

“7 plagues of software testing” sounds much sexier and has a better sound-bite than “7 pitfalls for testers and the software testing industry”. So that’s probably the main reason for the titles.

A Plague for a Critical Thinker?

The problem for testers is anything that distracts from the root cause, the underlying problem - the "reduced" argument. Rhetorical devices "get in the way" - they cloud the argument and don't help the analyser understand what a person/statement is trying to say.

So to repeat, "clarity is king".

Critical mass?

Sound-bites should not be what we strive for in the industry. Consistency, clarity and honesty will win more friends and supporters in the long run.

Software testing needs to achieve a critical mass of critical thinkers to carry the profession forward.

So: critical thinking – if you didn’t care before, do you care now?

Simplify, Simplify, Simplify!

#softwaretesting

History is an amazing resource from which to learn. There is a principle originating in the 14th century that can help us when reviewing documentation - whether requirements, user guides, test documentation or whatever else.

Occam's priniciple of simplification (also known as Occam's razor) is something we need to see more in today's software testing circles... It's something I apply to descriptions, specifications and guides.

I think of it as the medieval KISS (keep it simple stupid) - or maybe just KIS (to use the simplification principle.)

Essentially it means removing duplications in the language - this is done by breaking something down into its component parts and removing the duplications (or even the parts that are not necessary.)

It's this act of analysis (whether there are duplications or not) that gives us the simplification/clarification - so it's almost an indirect use of Occam's razor.

A typical example would be to break a convoluted requirement into 2 (or more) requirements - breaking it down into it's constituent parts/requirements. Remember one of the earliest steps in a testing phase is to inspect/review the input documentation...

So, the next time you see fuzzy requirements or some other fluffy descriptions you can calmy tell the author/review-circle that you're invoking one of the following (make sure they know this is slightly tongue-in-cheek):-

1. a 14th century priciple
   
2. the law of parsimony
3. Occam's razor

Where once we had "education, education, education" - then "location, location, location" - Occam gives us "simplify, simplify, simplify" - at least indirectly!