Carnival of Testers #7

February saw a huge output of test blog and related posts.

This time my "testers headache" was getting my shortlist down to 60 posts, and then further reducing it for this post. Some new faces have been blogging recently and that's always interesting.

This carnival's selection is a grouping of the thought-provoking, the practical, the plain interesting and the plain amusing. Enjoy!

• Lanette Creamer wrote about learning python, with advice on how to stop your head overheating!
• Puzzles. Spoiler alert! I enjoyed "part-reading" Parimala Shankaraiah's learning journey - an account of tackling Pradeep Soundararajan's puzzle challenge, here. I say "part-reading" as I intend to tackle the puzzle myself - so I had to stop myself reading - not easy with Parimala's engaging writing. 
• Rosie Sherry shares part of her fascinating learning journey, here.

• The STC mag launch was written about by a questioning (name for a group of testers?) of testers, including Brent Strange (link), Markus Gärtner (link), Rob Lambert (link),  Joe Strazzere (link) and Marcin Zręda (link).
• Shrini Kulkarni wrote about his writing block - probably something most bloggers can identify with.
• On the writing theme, Chris McMahon gave an update on the writing about testing list.
• The writing theme continues with Lisa Crispin's accessible book review about writing.
• A cautionary tale on testing terminology was given by Pradeep Soundararajan, here. Never mind monkey & guerilla testing, I'm holding out for chunky monkey testing...

• Justin Hunter wrote two interesting posts, one on DoE and quotes that are applicable to testers and another on an observation of "what is and isn't agile".
• A call to improve communication skills for improved output was made by Daniel Wellman.
• To help in testware tracking, Ewald Roodenrijs wrote about tagging testware.
• Ainars Galvans' insightful post on assumptions reminded me of a phrase from an old manager, "assumption is the mother of all f-ups". Ah memories...

• Joel Sanda gives his interesting take on ET and the desire for more "where it worked" reports.
• Continuing on ET, an angle on ET logging and accountability was presented by James Bach, here, and Michael Bolton, here. Michael also wrote about a type of bug that James named as the Ellis Island bug.
• What is quality and what is art was pondered by Marlena Compton. An interesting discussion in the comments too. If you're head's not hurting after reading it all then you might just be enlightened... Go check it out!

• I had a few deja vu moments (and smiles) reading Elizabeth Fiennes' post on what a tester really does.
• And last, but not least, Markus Gärtner provides a translation of a Chuck Norris and Scrum combo from twitter. The things people twitter about :)

Until next time, happy carnival reading!

SW Testing: A Mystery and a Puzzle

 #qa #testing #softwaretesting !

Mystery and Puzzle? What's the difference.

According to Treverton (from Malcom Gladwell's article) a puzzle is where you don't have enough information to come to some conclusion or recommendation. A mystery is where there may be too much information to really get to the core of the problem and understand it.

I quite like this distinction between the two - I say that without looking up dictionary definitions because I can readily agree with it - and use it.

The typical day of a tester is full of puzzles and mysteries.


Puzzles

Sometimes the tester is faced by a puzzle: There is not enough information to determine is something is working "correctly", where the fault may be (problems with debug implementations) or ambiguous descriptions (the ambiguity is one of the faults.)

In these cases it takes a combination of the research scientist and investigative reporter mentality to persevere and dig/research/test/debug for the additional (missing) information. This is the information needed to enable you to make sense of the findings.

The next person in the chain might make some different sense - or there might not be enough information for them - then it might come back to you to dig for more information to help solve the stakeholders puzzle.


Mysteries

A mystery is a dangerous trap that hits testers quite frequently. This is where there is too much information to make sense or some judgement about what is going on. It might be that several variables have altered at the same time and so reading the "headline" figures is not enough - there is too much noise.

As Weinberg says too much testing can create to much information to cope with - a good counter-argument against too much testing.

So, how to find the way through a mystery?

Sometimes it requires the domain knowledge to help. This is someone that has the baggage of "oh this combination of results can indicate x or y, trying investigating with feature z deactivated..."

Sometimes it's very good to have a fresh pair of eyes on the case - just to get that different perspective. This is a perfect opportunity to bounce ideas around with teammates, maybe even request a pair-testing session.

At other times, it might require walking away from the problem for a while - taking a break - and letting the subconcious start processing the information (the subconcious mind processes data at a much higher rate than the "concious" mind, according to Norretranders.)


Puzzle or Mystery?

So, how do you know that you have too much or too little information to deal with? Start by reducing the information inputs that you have to a minimum - the point where you can make an assumption, "based on the results I can hypothesize A - and then test against it." If you can't get to this minimum then you probably don't have enough information.

I feel a whole series building up around tackling test puzzles and mysteries... To be continued.

However, as far as puzzles and mysteries go I like Churchill's quote (when talking about Russia), "It is a riddle, wrapped in a mystery, inside an enigma" - I have days like that sometimes when trying to deduce what's going on during traffic testing...

Have you thought about the puzzles and mysteries you face in your daily work?