What do you do when hiring managers are looking for a set of skills you don’t have but you sorely want? You learn.

What do you do when hiring managers are looking for a set of skills you don’t have but you sorely want? You learn.

I see this situation played over and over again. The market is shifting and a new tool or technique is the next biggest standout skill or experience hiring managers are looking for, yet you don’t have that skill. What’s worse is that you can’t get an opportunity to learn that skill in a workplace because you don’t already have it…..a Catch 22 situation.

Read More

Blog Roadmap – 2014

I have neglected this blog over the last few months for a variety of reasons but I’m back on it.

So what follows below is my blogging road map for the rest of this year.

It’s based mostly around hiring the right people. It seems like my world is occupied by hiring right now. It’s a large part of my work at NewVoiceMedia and is a topic I’m deeply passionate about.

I wrote Remaining Relevant to help testers find good jobs and then do well in applications and interviews and I’ve since helped a number of testers improve their recruit-ability.

This next year will see me blog about recruiting from the other angle – from the angle of a hiring manager building an efficient and effective team – not just hiring testers who have all the buzzwords listed on their CV.

When I was recruiting one or two people I could rely on traditional ways of recruiting (adverts on jobs boards). When I was hiring in the numbers of around 5-10 I needed to get more efficient so I started using recruiters (they aren’t all bad) and other mechanisms to find people (which I will share as part of my upcoming posts)

When we’ve been recruiting in the 50+ (not all testers!) mark we really needed to get smart with how we do it.

I’ve only ever seen two presentations at a testing conference about hiring testers and both have made me cringe. One presentation talked about the process of scoring each candidate in a giant spreadsheet regarding some core skills such as test case management, defect writing and spec analysis. The person with the most points got the job.

There was no assessment of person fit, attitude, learning ethos, work ethics or anything else that is SUCH a big part of building an effective team.

The second presentation was about the desire to hire Top Class talent but with internal HR constraints and a crappy budget. The role went unfulfilled because the candidates weren’t good enough….but the salary wasn’t good enough and the aptitude tests by HR were putting off good people. (hint – fight the constraints, change the constraints, influence the people who can change the constraints, ignore the constraints, swap two roles for one or do whatever is necessary to get the person you need for the business to move forward – or of course lower your quality bar :))

It’s clear that most testers often don’t know how to get hired, and most hiring managers don’t seem to want to improve the hiring process.

I didn’t want to build an average test team here at NewVoiceMedia so I didn’t adopt average ways of recruiting. I’m not alone – there are many other talented hiring managers using innovative ways to get good talent to come and work with them – I’m hoping to get some of these people to guest post also 🙂

So the road-map will be focused on hiring. Here’s the road-map:

  • Effort on the CV is a good indicator
  • The certification is not a marker of excellence
  • Stop relying on certifications for hiring
  • Take recruiting seriously
  • What problem are you trying to solve?
  • Recruiting is not quick. Well not always
  • Plan carefully
  • Find a  trusted supplier
  • Don’t rush in to a decision
  • Dedicate time each day to recruitment
  • Kanban recruitment board
  • Tell them the truth. Are you offering a career in testing or just a job
  • Run retrospectives
  • Training versus hiring
  • Outsource all hiring or just some of it
  • Is your job role realistic
  • Writing good job adverts
  • Don’t use Nice To haves
  • Focus on values.
  • What end result do I want from each hire
  • Your recruitment consultants are an advert for your business
  • Learn from each interview
  • Direct contact is okay..if you have a compelling offer
  • Know their experience
  • Never the standard job spec
  • You are always hiring
  • Find people who inspire you
  • Slow down or speed up
  • Practical assessment are ok. In fact you should do them.
  • We don’t have the money to hire
  • Recruiters remove the need for tricky conversations
  • I don’t have the skills to recruit
  • Hire for your culture – not for skills.
  • Different messages for your recruiters
  • Videos
  • Filtering CVs.
  • Understanding a CV
  • CV Review – Look for outcomes
  • CV Review – Working through Jargon
  • Researching on Social Networks
  • Follow up on references
  • Logos on CVs
  • 3 Different Types of CV
  • How to deal with desperate candidates
  • Always be ready to receive an application
  • Should a hiring manager have an online presence
  • Create a business blog
  • Fending off recruiters
  • Networking
  • Follow up on prospects rapidly
  • Create a really great first impression
  • Recruiters – work out the ratio of success of each one
  • Build relationships with recruiters
  • Keep a record of all applicants and their outcome
  • Phone Interviews – Keep them short
  • Phone Interviews – Plan accordingly
  • Phone Interviews – Pair Up
  • Phone Interviews – Make Notes
  • Phone Interviews – Don’t Use a Phone
  • Phone Interviews – Lack of visuals
  • Phone Interviews – End the Call Like a Pro
  • Phone Interviews – Be clear and conscise
  • Interviews – Why do we do them?
  • Interviews – Open Questions
  • Interviews – Informal Discussions
  • Interviews – Leading Questions
  • Interviews – Closed Questions
  • Interviews – Loaded Questions
  • Interviews – Paraphrase Questions
  • Interviews – Hypothetical Questions
  • Interviews – Open With Time For Questions
  • Interviews – Time Keeping
  • Interviews – Appearance Matters
  • Interviews – Physical Proximity
  • Interviews – Make Them Feel Comfortable
  • Interviews – Turn Your Phone Off
  • Interviews – Eye Contact
  • Interviews – Leakage
  • Interviews – Take Notes
  • Interviews – Overpowering number of people
  • Interviewing for Second Life
  • Interviews – Did they actually answer the question
  • Interviews – Do a tour
  • Interviews – Be Honest
  • Interviews – Working with recruitment consultants
  • Interviews – Multi-part interview
  • Interviews – Reflect after the interview
  • Offering – Make it appealing
  • Rejecting – Give feedback
  • Recruiting – Be flexible
  • Accept rejection – don’t keep badgering
  • Killer questions in interview
  • Give people a chance
  • Don’t push a tester to be something they are not…and then call them stupid

And if I manage to blog all of that then I’m hoping you will have a pretty decent set of ideas to help you find good testers for your team.

Note – I may not blog in the order listed above. I will also expect new posts to emerge and existing ideas to be deleted.

You’re brand new

“I’m new to testing – where do I start?”

I get asked the above questions A LOT. It’s a very common question for those who are brand new to testing, those who are shifting from another business function and those who are returning to testing after many years away.

I repeat roughly the same answers quite often so I’m writing a blog post to point people at.

Of course, a little self promotion – if you do nothing else then buy my own remaining relevant book – it is packed with ideas on how to learn, how to network and hints and tips on how to rock an interview 🙂 You could consider it a much longer form version of this blog post.

Join the Software Testing Club. Period.

Check out the AST training courses and learn as much as possible.

Follow the big bad list of test bloggers being curated by the Software Testing Club – there are a lot of them – mostly good – pick and choose carefully though.

Download and read my Blazingly Simple Guide To Web Testing – all of the hints and tips were created from bugs I’ve found in the past.

Join twitter and follow the #softwaretesting #testing hashtags – find interesting people and follow them.

As part of the above question I also often get asked what the day to day activities of a tester are.

It’s tricky to say what the day to day activities of a tester commonly are as the role is so incredibly varied. You might be following pre-defined scripts and checking that the software matches the test case.

You might be exploring the product to discover what it does. You might be analyzing specs, writing user stories, writing automated tests, performance testing, security testing, doing customer visits, studying usability and a whole host of other stuff. You might do some of these things during one working week at some companies, you might do nothing but following scripts at others.

The industry is so varied that I would suggest, if you can, that you take the time to carefully chose the testing role you want. I would always suggest seeking out companies that put exploration and learning above scripted testing, but not everyone has the luxury of holding out for such companies.

Some companies will insist on a certification. It’s your choice as to whether you want to get one. I’m not a fan – but I’m a realist – some companies require them – and if you need a job then go for it. But take the certification for what it is – a certification that you sat the course and got a favorable result. It is NOT a marker of excellence and shouldn’t be your single point of learning.

If you follow some of the above you’ll encounter people and communities that will help you find the resources you need, the people you need to know and hopefully the sources that can help you skill up in the right way. You might even land a job through your networks and community.

Getting Hired – At Conferences

One of the things that I have observed from a number of testing conferences is that none of them have any sustained focus on hiring or getting hired *.

There have been one or two sessions about the topic of hiring but nothing sustained.

The occasional tracks that I have seen have been mostly focused around the hiring strategies of big corporates where bums on seats is sometimes more important than cultural team fit.

Most testers don’t know how to get hired – I wrote a book to help bridge that gap. Those that do know how to get hired are truly in the minority and appear, at least on the surface, to be overall better testers. Mostly this is not true – they are good, but they are often no better at testing than others, it’s just they are much better at getting hired. Getting hired is a skill.

Hiring and getting hired is a vast topic and one which is fraught with contextual challenges, but I believe that a dedicated set of talks from hiring managers from a wide variety of contexts, and maybe some sessions and tutorials on writing CVs, interviewing etc would go down well at most testing conferences. It’s great being good at testing but how do you then go on and get hired…

There are supporting topics such as social profiles, writing clear CVs, networking, self education and interpersonal communication that might also make interesting tracks. Or maybe they wouldn’t. Maybe people go to testing conferences to learn about testing and not the other stuff that comes with our working world…

What are your thoughts?

* The conferences that I have been to

Career Paths And Testing

When you’re advancing your career in testing it’s easy to get sucked in to the lure of big titles like Test Manager, Programmer Manager etc, especially if your using some of the mainstream “career path” guidance tools. The offer of a test manager role might seem like an attractive offer compared to a “test engineer” or something like that. However, apply caution, in my experience most test managers I’ve known have done little other than manage artifacts (test cases). A role title does not accurately reflect the role.

Use your own judgment when you’re applying for roles with big titles. Someone I know is a Test Manager….of himself (and some test cases).

I know a Director of Test who manages a team of 2 testers (and lots of regression test cases).

I know someone who works for a test manager. This test manager manages a team of 45 testers doing nothing but regression testing. The team keeps growing but the testing is not changing. By all accounts he’s hiring people and getting them to manage a load of test cases. Is this test management – I guess so.

After fulfilling your basic needs like salary, location and any other contextual needs I’d suggest to try to find a job that challenges you, not a job that gives you a so called “career path” title.

Find a job that challenges everything you thought you knew about testing. Find a job that provides you with an environment you’ll thrive in. Try to find a job that is modern and relevant. Try to find a job that let’s you think…and gives you room to breathe.

Try to find a job that blows your socks off. And don’t worry too much about what you’ll be called.

Oh yeah – Did I mention I was hiring for a solid tester who likes a monumental challenge?

Oh yeah – I also write a book called Remaining Relevant about how to find those great jobs, get the skills you need and then rock an interview. You can buy it here on LeanPub

Recruiting is still hard work

I’m recruiting again. It’s still hard work.

I figured I would share a little about the roles I have open.

2013-10-07 12.17.39

This time I’m looking for:

A tester with the confidence and skills to take on an epic challenge of working in a fast paced team who have a laser beam focus on delivering to live very very frequently. Most of the “checking” is taken care of by automated tests. As a tester on this team you’ll be involved in writing the Behaviour Driven Development “Gherkin”, pairing with the devs to get the product under test and then exploring the delivered features/stories/product.

The product is insanely good and is generating a real buzz around the office, and the industry. It rocks and it’s going to get bigger and better. As a tester you’ll need to move fast, be pragmatic, fight for your thoughts and beliefs, accept that you might not always be right, look for creative ways to test the product, push your exploratory testing skills further, work alongside a freakin brilliant exploratory tester, use your brain (not a test case) and deliver week after week. None of this turning up to work to tick boxes on a test case. If you find yourself doing that you’ve got something wrong, or confused your responsibilities. (okay – occasionally there may be one or two test cases…)

What do you get in return?

Haven’t I sold it enough already?

Okay here goes:

  • Mentoring from a number of hero grade testers. You’ll find a style and an approach that suits you.
  • Training and mentoring on testing in an lean-agile context.
  • Weekly then Fortnightly 1:2:1s with your manager (most likely me) – this is a great way of remaining on the right path and getting help. No yearly 360 review to find out whether you’re on track or not.
  • An opportunity to put down the test case and open your mind.
  • Training courses provided on topics such as programming, presentation skills, exploratory testing, scrum master approaches, communication skills, security testing, performance testing, etc
  • A huge library of books, online resources and other learning sources
  • Weekly coding / testing meetings and katas.
  • Opportunity to attend conferences and events like UKTMF, SIGIST, Test Bash, International Conferences.
  • Opportunity to find a virtual cross cut team to suit your ambitions (security, performance, test automation, testing, scrum master)
  • Table football, xBox, social events, sports events
  • ShipIt days


Here’s a video of what it’s like to work here.

So what do you say? If you can work in the Basingstoke, Hampshire, UK office and want to become part of a rapidly growing development team then drop me a DM on twitter, connect with me on LinkedIn or email me. I’m looking forward to hearing from you.

Communication and Testing

In yesterday’s test team meeting we did an interactive sessions around communication. Stickies, pens and a whiteboard were all we needed to have a fun session talking around communication.

We started by brainstorming what communication is. Then what factors affect communication. We talked about feedback.

And of course we talked about PAC – Purpose, Audience and Context.

(Those who’ve known me for many years might remember that PAC Testing was my very first testing blog all those years ago in 2009. It’s still running and getting traffic! The links are all wrong on it and the images are no longer there but the site is still up! http://pac-testing.blogspot.co.uk/)

We also talked around some specific examples of communication failure. It was a fun session thrown in at the last minute. It’s always good to throw in some soft skills sessions.

By the way – I’m recruiting for testers!


If you’re interested in coming to work at NewVoiceMedia then drop me an email, or even better – connect with me on Twitter (@rob_lambert) and DM me.

certification of awesomeness

Could not having a certificate make you stand out?

Many years ago when I sat the foundation certificate it made very little difference (if anything at all) to my day to day work. I remarked to a colleague though that the certification would make us all “more employable”. I was right.

certification of awesomeness
Certification of Awesomeness

Back then not many people had the certification so when you saw it listed on a CV (complete with required logo) it made that CV and candidate stand out. Had they taken their learning more seriously? Were they prepared to see what this certification lark was all about? What was this certification thing?

Soon though, everyone had a certification and you no longer stood out from the crowd.

Thankfully though – along came more higher rated (and presumably higher valued) certifications. Great. You could stand out again. Until of course – most people started to get these too.

Now you need something more to stand out. I wrote a whole book to help you work out what I think you need to do. But one thing came to mind* the other day that I realised I missed from the book.

What if your CV was the only one that DIDN’T have a certification?

That would make you stand out.

And any good hiring manager might start to ask “I wonder why they felt the need not to get certified, or list it on their CV?”. And that is an excellent starting point for a good conversation about you, software testing, certifications and your learning.

Note: Although this blog post is a flippant approach to the challenges hiring managers have of finding good candidates – it could actually be a useful approach to standing out.

* I recall some Twitter banter around certifications and why you don’t need them but can’t recall (or find) who actually made a statement along the same lines as I have. If you know who it was please let me know.

– I’ve since been informed that it was Michael Bolton via Twitter who said to leave the cert off the CV – sage advice indeed.

Ha ha – told you so

Quite often I hear presentations and discussions from testers who talk about those moments when they feel it appropriate to say “Ha Ha, Told You So”.

You know? Those moments when the testers advice was ignored and it all went pear shaped. Or the time a tester said the company should be testing earlier, only to find a boat load of bugs too late in the day.

Over the years I’ve heard loads of people saying “ha ha – told you so”.

Sure it’s gone pear shaped, but it’s often at these times that you are needed the most; when your skills and ability are required by the business to get software out of the door.

If all you have to say at times like this is “ha ha, told you so” then you will appear petty, annoying and arrogant.

We shouldn’t be offending people and making them resentful because a decision was made that frustrated us. We need to step up and take ownership. Step up and contribute. Step up and make a difference.

At a conference a few years back a tester was presenting on how happy she felt when the project crashed and burned because they had ignored her advice. The crowd were joining in talking about “wiping the smug look off the developer’s face” and saying things like “at their peril will they ignore the tester”. It’s poisonous, unhelpful and downright ridiculous to think like that. (I was in the minority in the room btw – I walked out with a few others who found that session just too much).

So when you hear a tester shout “ha ha told you so” as a project takes a downward spiral, offer them some constructive feedback and ask for their support. Motivate them to act, not gloat in the destruction. How is that negativity going to help the business release good software.

Releasing software is a team effort. And tester’s are a part of that team.

I’ve resorted to using my blog to recruit again

I’ve resorted to using my blog to recruit again.

Right now I’m recruiting for two roles.

Role 1 – Contract Manual Tester.

I’m looking for a talented contractor to join our team for initially 3 months. The role will have a mix of new feature testing as well as plenty of exploration around our product.
Role 2 – Permanent Technical Tester.

I’m looking for a talented technical tester to join our team. The role will involve refactoring and re-energising our test automation framework. Must have solid experience of Selenium with Java/C#. Knowledge of BDD and SpecFlow would be beneficial.

Both positions are based in Basingstoke, Hampshire, UK.

Here’s a brief introduction of what it’s like to work here:

I often get asked what exactly we build here. To give you some idea:

To get in touch (No Agencies please) DM me on Twitter @rob_lambert or drop me an email rob (at) thesocialtester (dot) co (dot) uk

Let’s say I gave you a giant box to explore

Let’s say I gave you a giant box to explore.

In the box was a machine that did a number of different functions along with an instruction manual. The functions that the machine can perform are complicated but ultimately observable and open to identifying more thoroughly than we currently have done in our user guide.

The machine however has lots of unknowns when it comes to putting spurious data in and connecting with a wide array of third party apps. The results of your actions are outputted to a simple user interface. It’s not pretty but it does the job.

The above was a test that a company I worked for would give during a job interview.


Image from subsetsum on Flickr.

They provided a laptop with this “test machine” running on it (a Java application) and they provided the instructions (a simple two page html document).

When I sat the test I hated it.

I didn’t feel it dug deep enough around some of the diverse skills I, and others, could offer.

In hindsight though I think this type of test was actually very insightful – although maybe the insights weren’t always used appropriately.

I got the job and soon found myself on the other side of the process giving this test to other testers hoping to come and work with us.

When I was interviewing I was handed a checklist to accompany the test. This checklist was used to measure the candidate and their success at meeting a pre-defined expected set of measures.

It was a “checklist” that told the hiring manager whether or not to hire someone.

The checklist contained a list of known bugs in the “test machine”. There were about 25 “expected” bugs followed by a list of about 15 “bonus” bugs. There were two columns next to these bug lists, one headed junior and one headed senior.

If we were interviewing a ‘junior’ (i.e. less than 3 years experience) then the company expected this person to find all of “expected” bugs.

If we were interviewing a ‘senior’ (i.e. more than 3 years experience) then the company expected this person to find all of “expected” bugs AND all/some of the “bonus” bugs.

There was also space to record other “observations” like comments about usability, fit for purpose etc

This interview test was aimed at flushing out those who were not very good in both junior and senior categories.

I’m assuming many of my readers are jumping up and down in fits of rage about how fundamentally flawed this process is…right?

I immediately spotted the fundamental flaws with interviewing like this, so I questioned the use of the checklists (not necessarily the test itself) and I stumbled across two interesting points.

Firstly, there were some hiring managers that stuck to this list religiously (like a tester might to a test case). If someone didn’t find the bugs they were expected to then they didn’t get the job. Simple as that.

Other hiring managers were more pragmatic and instead balanced the performance across the whole exercise. For example – I didn’t find some of the things I was expected to find, but I still got the job. (It turns out a few managers were ticking the boxes next to the bugs people didn’t find to “prove” to senior management (auditors) that candidates were finding the bugs they should have).

Secondly, this test was remarkably good at exploring the activities, approach and thinking that most testers go through when they test.

Whether someone got any or all of the bugs they were expected to was beside the point for me. I was more interested by the thinking and process the tester went through to find those bugs and assess the “test machine”.

It just so happened that most hiring managers were not measuring/observing/using this rich data (i.e. the testers approach, thoughts, ideas, paths, etc) to form their opinion.

Junior or Senior – it made little difference

It was clear from doing these interviews that it made little difference how many years of experience a candidate had and their ability to find the bugs they were expected to.

I actually spotted a very prevalent trend when doing these interviews.

Those that followed the user manual found most of the “expected” bugs no matter what their perceived experience level; juniors, seniors, guru grade – it made no difference.

If they followed the user guide (and often wrote test cases based on the guide) then they found these “expected” bugs.

Those that skimmed the user guide but went off exploring the system typically (although not always) found most of the expected bugs AND some/all of the “bonus” bugs – again, irrelevant of their experience (or perceived experience).

This second point highlighted to me that the approach a tester took to testing influenced the types of bugs they found, but also, in this interview case, it challenged our assumptions about experience and bug count. It also made a few people think whether they had categorised the known bugs correctly – were the bonus bugs too easy to find?

I observed very junior testers finding the “bonus” bugs and senior testers missing them purely because of their approach and mindset. (although not a scientific finding it did give me enough insights to set me on my journey towards exploration and discovery).

It wasn’t even as simple that all seniors did a more exploratory approach and that juniors did a more scripted approach. That simply didn’t happen.

It seemed to run deeper than that. It seemed to focus more around a curious mindset than years of experience.

Obsessed with finding out more

Those that took an exploration and discovery approach appeared to develop an obsession with exploring the “machine”.

They seemed more compelled to discover interesting information about the “test machine” than those who followed a script based on a partial user guide.

Following the guide simply wasn’t enough. They needed to find out the information for themselves. In a sense, they needed “primary” information. Information they had obtained themselves straight from the source (the product). Other testers were happy with using a “secondary” source of information (the user guide) to formulate conclusions. It obviously wasn’t as clear cut as that, as many straddled the middle ground, but the trends did show an interesting difference in approach.

Note Taking & Story Telling

Another dimension to this process, which was what kick started my obsession with note taking, was that those who went off exploring appeared to tell more compelling stories about their testing, often through detailed and interesting notes.

The notes they took enabled them to recite their exploration and discovery story back to others with an astounding level of detail – something most people who followed a script didn’t do ( I can’t say whether they “could” do it though).

As these people got stuck in and delved around in the product they started to tell a really interesting story of their progress. Through narration of their approach and interesting notes they got me and the other hiring managers interested, even though we’d seen dozens of people perform this very same test.

They started to pull us along with them as they explored and journeyed through the product. They wrote notes, they drew pictures, they made doodles and wrote keywords (to trigger memory) as they went.

They built up a story. They built up a story of the product using the user guide as a basis, but using their own discoveries to fill in the gaps, or to even challenge the statements made in the user guide (of course…the user guide had bugs in it too).

They wrote the story of their exploration as it developed and they embraced the discovery of new information. They kept notes of other interesting areas to explore if they were given more time.

They told stories (and asked lots of questions) about how users might use the product, or some of the issues users may encounter that warranted further investigation.

They involved others in this testing process also; they described their approach and they made sure they could report back on this compelling story once they’d finished the task.

What intrigued me the most though was that each tester would tell a different story. They would see many of the same things, but also very different things within the product and the user guide.

They built up different stories and different insights.

They built their testing stories in different orders and through different paths but actually they all fundamentally concluded very similar things. The endings of the stories were similar but the plot was different so to speak.

What they explored and what they found also said a lot about themselves and their outlook on testing.

Their actions and outputs told stories of who they were and what their contribution to our company/team would be. They let their interview guard/nerves down and they showed the real them.

Everyone who sat that test told us something about themselves and their testing, however, we (the hiring managers) were pulled along more with those who built their testing stories as they went rather than those who had pre-defined the story and stuck to it.

The explorers appeared to tell more insightful and compelling stories and they also revealed deeper insights about themselves and the product.

As our hiring improved (better job adverts, better phone screens, better recruitment consultants) we started to interview more people who would explore the product and tell us these compelling stories; these were the people we wanted to seek out.

As a result even those hiring managers who were obsessed with their checklist would find themselves being pulled along with the exploration. They found themselves ignoring their precious checklists and focusing on the wider picture.

It didn’t take long for senior management to see the problems with measuring people against lists too.

Did I learn anything?

Oh yes indeed.

We should never hire purely on binary results (i.e. found this, didn’t find this, is this type of person, is that type of person, isn’t this).

Only by testing the system do we find out the real truth about the product (specs are useful, but they are not the system). In a choice between primary information or secondary information I will gravitate to primary.

When we explore we have the opportunity to tell compelling stories about our exploration, the product, the testing and more importantly, ourselves <– not everyone has these skills though.

All testers will conclude different insights, sometimes they may find the same bugs as others, sometimes very different ones. Therefore it’s good to pair testers and to share learnings often.

The hiring approach should be consistent across all those with the power to hire and should focus on the person, not the checklist.

Good exploratory testing relies on the ability to explain the testing, insights and findings both during the testing session and after (and often relies on exceptional note taking and other memory aids).

If you’re hiring a tester, observe them doing some testing before making an offer.

I believe an obsession to learn more (and be curious) is one of the most observable traits I can see. Exploration and curiosity does not always come naturally to people. Not everyone is curious about the world around them or the products they test, but for testers I believe this trait alone will send them down the many paths of learning. (and this is a good thing)

Someone with 10 years of experience is not always better than someone with 2 years – especially so if they have had 10 of the same year.

Dividing people in to junior and senior camps is not helpful. Where is the cut-off mark (years of experience? – see point above)? We are all on a journey and our skills will change and develop over time – the person is what you are hiring, not the years that they have worked.

The big question I now ask is “Does this person want to be on a journey to mastery? If they don’t, it’s very hard to encourage them to improve.


Note: This post may come across as me suggesting exploratory testing approaches (and therefore exploratory testers) are better than scripted testing approaches (and hence testers who follow scripts). That’s not my intention.

How you perceive this post will depend very heavily on how you perceive the role of testing and the role of the tester to be in your organisation.

You know your organisation and the needs that you and your team have. Some organisations desire people to follow scripts, some organisations desire people to explore the product, some desire something in between and some desire other things all together.



What can you do with a brick?

Last week one of our team, Simon, ran a really fun session with the whole test team on our Exploratory Testing process.

We started by discussing some of the thinking that we’ve identified happens when we plan exploratory testing sessions. We talked through a diagram we created a few years back, and although it’s pretty accurate in identifying some high level ideas of our Exploratory Testing process, it’s by no means complete, but it served it’s purpose as an aid to explaining.

Once we’d been through the diagram Simon introduced the team to one of my favourite games that explores creative thinking.

It’s a common game where people are asked to come up with as many uses they can find for an item.

It’s a really good way of understanding how people think up ideas, how diverse the thinking is within our group and it’s also a good way of injecting some discussions and banter in to our session.

Simon gave the group 5 minutes to write their ideas on post-it notes. The item of choice today was a “brick”.

We then affinity mapped them in to rough categories on the white board and discussed a little around each category as a group.



We then discussed the process of how people came up with their ideas.

It’s always tricky analyzing your own thinking, especially so in retrospect, but we did spot a couple of patterns emerging.

Firstly, whether consciously or not, we all envisioned a brick and started from this image we’d constructed. As it turned out we’d all thought of a standard house brick; some people saw in their minds the one with holes in it, others the bricks with a recess. Either way we started with the standard form of a typical house brick (here in England).



Here’s where we appeared to head off in slightly different thinking ways. After writing down all of the basic ideas that a brick is used for (building stuff, throwing at things, weighing things down) we started to head off in the following three directions:

  1. Thinking of other sizes, shapes and forms that a brick could take
  2. Thinking of different contexts and locations that a brick could be used in it’s original form (outside of those we naturally thought of straight away)
  3. Thinking of everyday objects that we could replace with a brick.

For example:

  • We could grinding the brick down to create sand
  • Use the brick as book ends
  • Take the brick to a philosopher (and/or someone who had never seen a brick before) and try to explain what it was used for
  • Use the brick as a house for small animals, insects and little people
  • Use the holes in the brick as a spaghetti measurer
  • Putting the brick in a toilet cistern to save water
  • Projectile missile and other weapons
  • Use it to draw right angles
  • Use it as a paperweight
  • Use it as a booster seat in a car
  • Use it as a holder for fireworks
  • Use it as a bird bath.

And many, many more.


As you can see we explored a number of uses and we created a decent amount of categories in which a brick would fit.

What was most important though was that we all took time to reflect on where our ideas were coming from.

We also noted that not all of clearly think in the same fashion. Some people remained true to the form and shape of a brick but explored different contexts.

Others ignored the standard shape of a brick and explored different elements and uses of the materials within a brick.

This realisation that we all think differently about something as simple as a brick triggered some further discussions about how we come up with ideas for testing our new features.

It ultimately lead to us to concluding that it would make sense to pair with others during and after our story kick off meeting. It might generate a broader and deeper set of test ideas. It might not. We’ll have to experiment.

For now though we’re running with two testers attending story chats followed by a brainstorming and ideas exchange meeting. We decided it would make sense to not do the brainstorming in the story chat as that will sidetrack the purpose of that meeting, but we will be sharing our wider test ideas with the team as well as writing acceptance tests in SpecFlow for static checks.

Let’s see how it goes.

It was a really good session and we took away a direct change we could try. It’s good to get the team together every week to chat through the ways we are working, thinking and solving tricky testing problems.

We made a recruitment video!!

We’re undergoing a rapid growth here at NewVoiceMedia as we strive to expand our development team to cater for our growing roadmaps and customer growth. As such we’ve been working hard trying to articulate a little more about what it’s like to work here.

We spent a day a few months back with a camera man pointing his digital camera at us throughout various times of the day. It was actually really good to see the final version as I think it’s a good reflection of the kind of company we are. There’s always a worry that the video will be too hyped up or too distant from reality, but the film crew did a great job.

Don’t forget, if you’re a developer or developer in test and you want to come and work for us, then drop me an email or apply online.

P.S – For those that seem to be interested – I am only briefly in the video as the camera pans past one of our stand-ups…

Recruiting is hard work

Despite what many people believe recruiting developers and testers is hard work.

Trust me.

It’s tricky finding good people.

It’s tricky interviewing and finding out whether both parties are a good match for each other.

It’s tricky on-boarding people in to the teams with the minimal amount of disruption.

It’s tricky scaling our development team to meet the needs of a growing company doing great work and pushing boundaries.

As such I’m reaching out to ask for help…again.

I need your help to find us talented people to join our growing team. I can’t offer much in return but should we ever meet at a conference I’ll be sure to buy you a drink, but only if there’s a free bar 🙂

Jesting aside we’re on the hunt for the following roles:

Developer (Permanent and Contract)

Must be able to write simple, maintainable and readable C# code. You must be passionate about learning and developing your skills and sharing this learning with those who work with you. You must be able to work as part of a team and in a agile methodology. You must be able to hit the ground running.

Technical Tester / Developer In Test (Permanent)

You’ll be a proficient programmer who’s obsessed with testing. You’ll need to be able to perform exploratory testing also and infect all of those around you with an obsession for writing automated tests.

In return you’ll get to work with some of the brightest minds in the industry in a learning centred development team. We’re growing fast and we need top notch people to join us and help to create something amazing.

No agencies please.

Do you think you can help? Do you know anyone who might want to work with us here? Do you yourself want to join us?

Drop me an email to rob (@) thesocialtester (dot) co (dot) uk or DM me on Twitter @rob_lambert