Month: January 2016

Book: Exploratory Testing

 

ExploratoryTesting
Exploratory Testing

 

This is a book that we covered in our ST book club.

The book is a well written introduction to exploratory testing, and covers wide and narrow-scale exploratory testing and how to create and use exploratory test plans.  James Whittaker clearly does have good ideas, and they’re well explained here.

That said, I didn’t really like it – I think because it seems to start with the assumption that much of the audience need to be cajoled away from writing and then mindlessly executing test cases and so spends time and effort on stuff that I already took for granted.

I’d recommend it as a good introduction for newer testers or indeed anyone who’s used to writing a prescriptive plan of all their testing up front before getting started.  If you’re already well versed in more modern testing and have thought about exploratory testing at least a bit, you might find it a bit slow – probably still worth a flick through and read for reference, but I wouldn’t dash out and buy it.

Boost your development: Tester Skill Tracks

SkillTrack
A different kind of skill track!

People’s motivation and speed of progression improves dramatically when they have a clear solid vision for what there they want to be in 3-12 months time and a set of concrete actions they can take to get there.   “Be a better tester” is all very well, but what does that actually mean?

To try and answer this question, David Parker and I set out to create a set of TesterSkillTracks.  Each track is a different skill related to testing, and along each track is a set of “levels”.  Each level is defined as something you can do, and is a clear qualitative step up from the previous level – it’s not just “do X more and better”.  We’re using this within Metaswitch Networks (where we both work) and finding it useful.

We’ve found that working on these tracks has enabled people to

  • focus on a particular area to develop
  • stretch themselves further when they’re already really good at testing
  • break out achievable chunks when they’re brand new
  • identify and discuss where their manager thinks their capabilities are different from their own assessment.

So, please take and use and let me know if this helps you.  And please let me know any feedback that you have.  What’s not exactly right?  What makes no sense or could be clearer?  What tracks are missing entirely?  What’s there but completely irrelevant or rubbish?  I’d really appreciate any thoughts, positive or negative.

Some notes and caveats.

  • This is intended to let you break down, clarify and focus “I want to be a better tester” into “The next thing I will achieve is <this>”.  This is not a tick-box exercise of competencies to go up a pay-grade.
  • We have taken a wide view on skills useful to a tester and included various skills that are outside the narrowest definitions of the “tester” role.  We want people to grow and develop beyond just being a particular shaped cog in a machine.
  • We deliberately tried to avoid linking these skills to any particular testing creed or school.

 

 

 

Be a better tester: Ask “Why?”

HumanYChromosome
Humans do not have a “How?” chromosome.

I’ve recently been tasked with educating some of our development teams in “better testing”.  One of the key things I keep coming across is a mindset change, and I realised that while it’s a key part of good testing, it’s also something that I found critical when stepping up to take on lead development roles too…

When I was learning to be a developer, I was trained heavily into asking “How?”  How do we implement this?  How does that work?  How can we make this happen?  How do I fix this?   “How?” is a good question to ask, but once it becomes your instinctive reaction to think “How?”, you’re in trouble.  “How?” is a focusing question, and almost always, you want to start by defocusing and getting the context that you’re working in.  An easy way to do that is to train your first instinct to be to ask “Why?”

Why are we implementing this?  Why does the product work this way?  Why does that happen?   Not only is instinctively asking “Why?” a basic requirement for testing, it’s also the question that will lead you to big gains in development.  Because they lead to us thinking about the context for the work we’re being asked to do, and stop us carefully implementing the wrong thing, or implementing something great, but isn’t extensible in the right way, or implementing something that’s way too over-engineered for what any customer will ever want.

We all (should!) use “How?” and “Why?” but the difference between a good developer and a great one, and an important difference between a developer and a tester is that trained instinct to make “Why?” the first question to ask.