What makes you less interchangeable?

I was told a really interesting story the other day about a company who remove all obvious identification from CVs during recruitment.

It works a little like this:

  • They get the CVs for an open job position.
  • Someone who is not doing the active hiring removes the candidates name, any company names (of past and present companies) and other personal information from the CV leaving just a set of skills, extra curricular activities (although social space names/handles were hidden) and supporting information.
  • The anonymous CV is then forwarded to the hiring team.
  • The team then review the CV with less bias and prejudice (or at least that is the aim of this process).

To make sure they were discussing the right candidates they would tag each CV with a unique reference number which was tied back to the actual candidate. It worked perfectly for them and they found that each candidate was reviewed on their merits and skills alone, not by any bias or prejudice in the mind of the hirer based on their name, age, sex or other personal information.

This company reported a much higher success rate for hiring. More “A” players were hired and less “bad hires” were brought in. It sounds like an interesting process.

But it got me thinking about the sea of conformity that is happening in the Testing community.

Let’s say 100 testers applied for a testing job and the above system was in place.

  • Would each CV be distinct enough?
  • Would the hiring manager be “floored” by any single application? Or down hearted by the sameness of each candidate?
  • What would be on your CV to make you stand out in the process?
  • Why would your CV be chosen?
  • How would you “win” during the CV review stage, rather than waiting until the interview? (believe me, I know many Testers who submit below standard CVs and aim to do the “wow” during the interview..but what if you don’t get to the interview?)
  • Would all applications (and therefore Testers) be interchangeable?

If the system had a bug and you got somebody else’s CV, would it be vastly different to yours? If yes, how? If not, is that not worrying?

In a sea of conformity the only way to escape is to be different.

  • What are your strengths?
  • What differentiates you from the rest?
  • What makes your application stand out?
  • What makes you less interchangeable?

Update : As Stephan pointed out in the comments…would you want to work for a company that hires this way? 🙂

Testing Sucks. I hate Testing.

You may know the situation; you are at a conference (or meetup) and you get talking to someone who says they “hate testing”. What do you do?

  1. Run away?
  2. Tell them to “man-up” and stop complaining?
  3. Join them in a whinge about Testing?

There are many other potential answers, but another one I’ve started doing recently is asking two simple questions. I’ll come to those two questions later.

Too many people say they hate Testing when in actual fact it can be the software itself, or the domain they are working in, or the methodology they are using. I strongly believe that you do your best testing when you “commit with passion” [1] to doing a good job. I also believe that to “commit with passion” (and therefore do your best work) you have to have some affinity to the product you are testing.

There are a number of factors that affect our motivation towards our jobs and the products we work on. These include, but are not limited to:

  • company culture and ethos
  • peers and co-workers
  • management structure
  • testing approach
  • restrictive systems and processes
  • technology stack
  • company benefits and rewards.
  • and many more

I believe that having an affinity with the product we are testing brings out the best in us. I believe that many testers who complain about testing are complaining about the factors above in varying combinations, but more often than not, they are complaining about the product they are testing.

Over the last few years I’ve made a conscious effort to talk to testers at events/conferences that plainly don’t want to be there. Many of them have indeed indicated that they hate testing.

When asked two simple questions though they fundamentally start to think differently about their “hatred” of testing. It’s not scientific, but it’s enough to give me hope that we can start to change some hearts and minds, one tester at a time.

The questions I ask anyone who says they hate their testing job are:

  1. What is your favourite piece of software?
  2. Would your view of testing change if you were testing this favourite software instead?

Most people smile and answer question two with a big fat yes. Yes it would.

It’s a very leading question and no doubt testing their favourite product conjures up images of a culture, approach and financial situation different to their current one, but a significant part of this vision or thought is most likely that they get to test a product that they enjoy, understand and can relate to in an environment that suits their personal style and preferences. (this vision may never meet reality…but it’s worth a try)

One person I spoke to a year ago was testing banking software and he hated it. I asked him the questions above and he said he liked “social media” software and would love to test it. A month or so ago I saw him again. He’s now working for a start-up blog aggregation company and he loves it.

That’s not to say that working on “social” software is better than banking software, but each of us is naturally more interesting in certain domains than others. Some would never dream of working in the aerospace industry, but others flourish in this industry. Some are drawn to start-ups pushing stuff out of the door and building on modern tech, others are drawn to corporate mega giants with miles of red tape and out-dated tech. Each to their own.

So next time you meet someone who says they hate testing it’s worth asking them whether it is “testing” they hate, or the product they are testing.

[1] – Commit with passion is a term used in the book The Jazz Process – http://www.jazzprocess.com/book/

Getting a grip on exploratory testing

Last week we had the pleasure of inviting James Lyndsay to our offices in rainy Basingstoke for a two day course on “getting a grip on Exploratory Testing”.

The whole test team were there for the two days and we worked through a number of elements of Exploratory Testing, right from time managements and focus to techniques and approaches. James is incredibly knowledgeable and his experience was tapped by the team for the two days.

Each of the team took away a number of insights, but here are my own personal observations:

  • I focus very heavily on the user and their experience of using software
  • I also tend to visualise the problem and walk through it often randomly
  • I also focus heavily on any claims made in any documents, guidance or specifications.
  • The team all approach the same problem in subtly different ways. This is a good thing.
  • Knowing how long we have to test is crucial. It changes our approaches and styles.
  • My approach of using Mind Maps for planning and documenting is a style that works well for me, but not always for others.
  • I tend to use a different map for different problems. I use mind maps, tables, doodles and general free form notes. I also tend to scrap a map if it’s not working.
  • Our judgements on what is an issue and where to focus testing differ between people even in the same business. What I see as issue – other might not and vice versa. This highlights the need to understand your target audience; something we’ve been working hard at here.
  • I need to work on my “straying” from charter. I often get too involved in side paths which are not on charter. This is not always a bad thing but I need to be mindful of it.
  • I often explore the application to drive out charters and ideas for further testing as a form of planning
  • We need to instigate more exploratory testing debriefs

The two day course was insightful, very well delivered and fun. There were lots of hands-on practicals and James tailored the content for our needs here at NewVoiceMedia. Overall it was a great two days and I know the team very much enjoyed it. We just need to put our learnings in to practice, something I am already seeing the guys doing.

Here’s James’ website with course details.