Friday, 13 October 2017

The nonsense of gender-influences on testers

Have you been watching Duck Quacks Don't Echo? Lee Mack has guests on and they talk and test lesser-known facts. For instance, did you know that:
  • People with blue eyes have a higher tolerance for alcohol than brown-eyed people
  • The chlorine in swimming pools smells because the pool is dirty
I'll be honest, the gags are naff, and not all facts are interesting facts, but I approve of their testing of things, and every once in a while, there's a fact that tickles my professional interest. For instance, take these three facts:
  • Men are better at multitasking
  • Women are better at remembering driving routes
  • Taxi drivers have a larger hippocampus than regular people
If this were true, these give some interesting ideas towards lots of aspects of testing and test management, not limited to task assignment and team selection. But it's all nonsense of course. If this is to be believed, a male tester would be a good choice of team member for a project with concurrent streams and context switching, whilst a female tester would be a good choice for accurate repro steps and reliably repeating tasks they've seen demonstrated. But surely everyone with some years of industry experience has met members of both genders who has admirable skills in both areas at a level to aspire to? I certainly have. Repeatedly.

But there was science! Admittedly, it's "edutainment" science, but they had people on with doctorates who explained things. I struggled to reconcile this. Then they gave me the fact about the taxi drivers, and it was all made clear.

Taxi drivers have a larger hippocampus because of their constant effort in tactical route selection and thier dependency on short and long term memory. Like a trained muscle, practising this activity makes them better at it, and as they hit the peak in their training, the task becomes easier.
It stands to reason here that the male taxi driver will follow a route better than the female new driver.

My takeaway here is that an experienced person would trump any gender-enabled amateur, and that anyone can do anything they want to with some practice. As a very tall person who has attempted basketball and racket sports this would appear to hold true.

Monday, 29 August 2016

T7: Dig Deeper

During a recent conversation on Testers.io, I asked whether anyone had cool resources or ideas that I could take to my test team meeting as an activity to keep everyone thinking. My team is mixed level, so I want activities that add XP to my juniors but without boring the seniors. (Side note: I hate junior/senior terminology, and want something better. Ideas?)

Ideas weren't forthcoming, so I thought I'd start writing some of my own. If I give this project a name, I'll be able to scope it.

T7: Tools To Train Test Teams To Think

That's really not a cool name, but it'll do for now.

First idea is Dig Deeper. This is a training exercise intended to encourage testers to think beyond "this works" and on to "this does what we want it to do".

This is derived entirely from a section of Explore It! so all credit goes to Elizabeth Hendrickson. Her story was about an installer.

Scenario: a new software installer for the next version of the software.

In Elizabeth's scenario, the tester's initially worked to a "this works" criteria, namely that it ran without error.

Works: Installer runs without error

This was shown later to be insufficient when a member of another team showed that the software wasn't actually installed.

Dig Deeper: Software is installed to correct locations, registry values appropriately set, application launches & performs some basic operations

There could be more "deep" criteria than this, but you see how this works. Take a seemingly reasonable test criteria, and refine it.

We tried this in our last team meeting. The team got the idea very quickly, and solved the 4 example problems I'd prepared. I sought feedback, and it was... middling. These were the problems:
  • It was a bit simple, so doesn't really deal with the complex problems we deal with day-to-day
  • All of the examples were based on things we have done, so it's hard to separate yourself from your domain knowledge to answer the question "properly"
  • At least one of the examples was more "what else" than "dig deeper"

Seems like this could be a good tool, and it's my use of it that needs some work!

I used a very simple slide deck which you're free to pinch: Google Drive.

Any & all feedback welcome!

Friday, 24 April 2015

The Carwash Analogy

I was recently having a discussion with a developer friend of mine about why he should recruit testers (since they currently don't). It bothers me that the end of the conversation didn't end "Dan, you're absolutely right, I'm totally getting me some of them!".

Explaining testing well is no easy task. What if the company is doing well with their current quality level?

The problem here is that testers don't have a largely tangible output. We provide a service. We deal in information, and our net output could be described as confidence.

What if we made the analogy between testing and a car wash? My friend has developers doing unit tests and sanity checks on the end-to-end process, so he's already at Level 2. It's 50p more than Level 1, and probably £2 more than not washing his car. Adding testers dials you up to Level 8. The car wash is much more thorough. There's some premium soaping and scrubbing that's happening at the same time as the Level 2 stuff. There's a bunch of stuff happening that you were never going to get at Level 2 that takes a little longer. Waxing, buffing and the like. Totally premium, and totally costs a few quid more.

So what's the result?

Either:
* you know your car is cleaner as a result of getting Level 8, or
* you're more confident that dirt that was probably removed by Level 2 is definitely gone now

Don't fool yourself. Level 8 doesn't mean sterile. But you certainly gave it your best try. 

Testers don't actually remove issues. I also think this analogy is imperfect in that it draws a parallel between what's probably a perfectly good wash and developers checking their own code, which I feel understates the importance of testing. All the same, I might try this on my developer friend and see if it helps.

Be careful: clean cars are addictive. Once you've sat in something cleaned at Level 8, you'll wonder quite how good Level 9 could be!

Friday, 10 April 2015

The Persona of a Tester

Hey it's springtime, and there's a new testing blog, so given the time of year, you should be expecting a write-up of my experiences at the recent (and excellent!) TestBash 2015.

I might get to that, but not today.

Instead, I wanted to share a great picture with you that really captured the essence of testing for me, and perhaps why I still enjoy testing after years in the industry when some tire of it, or use it as a stepping stone to other things. 




For me this image is a person who has trained to be where they are, and who sets off exploring equipped with the best tools they can find. A confident step forwards, and they're into the untrodden. Sometimes, maybe a little faster than they should (or is that just me?).

You can extend the analogy further by saying they've got a supportive team, that the tools or the person or the team isn't separately enough, or that in times of recession people in this career are, rightly or wrongly, in lower demand. But that's all afterthought I put in when writing this post.

Following Karen Johnson's great workshop at TestBash, I considered that maybe I should spend some time considering my own persona when analysing requirements for testability. Whilst this orange chap might represent me, I'm sure there are plenty of other testers who wouldn't identify the same way, and their requirements for testability would differ.

I know some would say you can't boil testing down to an image, but I hear they can convey about 1000 words of it. This is how I identify as a tester right now, but I very much doubt that's static. I'll let you know when I find something I identify with more.

Image is CC licensed and originated here.