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/

The Phoenix Checklist – Mind Map

I’ve written about the Phoenix Checklist before here and think the list is so important that I include a quick reference on my site here.

I wanted to print the list out for quick reference at my desk so I decided to create a couple of mind maps. I like using mind maps for quick reference stuff. It suits my mind. I know of a few people who have taken the checklists, printed them and then laminated them. Good stuff.

Anyhow, here’s the mind maps I created and printed.

 

 

Running Lean Book Review

One of the things that strikes me about the book Running Lean is how practical almost all of the advice is. It’s not a long book, but it gave me great breadth of knowledge in to the aspects of running a lean business. It’s not a massive step from most of the good Toyota books on lean but it does have a different angle (more start-up company focused) and it does make many of the lean ideas easier to understand.

I really liked the way the author focused on the Lean Canvas idea for distilling and communicating ideas about your business. It sometimes felt overkill but overall it was useful and I’ve already seen some value from having a go at writing down my ideas.

The book also serves as a way of questioning your ideas about your business with particular respect to whether or not you have an audience that will actually buy your products.

For example the author, Ash-Maurya, states:

“Failing to build a significant path to customers is among the top reasons why startups fail”

Throughout the book Ash talks a lot about finding the right audience and the right product – it’s the basics of getting success in the market – but Ash also talks a lot about why it’s important to only build the minimum to satisfy this audience and market needs.

There is some talk about work in progress, Kanban boards and daily flow, but not enough to make it worth buying this book just for those topics. Instead, this book takes a more holistic approach across many functions and elements of a business so it glances over many topics but does give a nice wide view of running a lean business.

There are some interesting work hacks (i.e. – how to get stuff done) in the book also but again, there are other books with more depth in time management, productivity and work ethics.

I don’t believe this book is for those wanting a deep dive on certain areas of running a successful and lean business. Instead I believe it is for those who want an introduction and some techniques, tools and models to use to decide, plan and act on their business, and for this audience this book is very good indeed.

There are some interesting ideas and insights in to how to get continuous flow working in your business as well as ideas on how to ensure you’re best prepared to ship software.

I really enjoyed this book but I think that if you read around lean anyway you will already have gained most of these insights. Saying that, the Lean Canvas is a neat tool for helping you think about and organise your thoughts around your business. It can certainly help you drive out the audience for your business and some of the ideas around what it is you are offering and for what price.

Overall a pretty good book. Very well written too and great for those who are thinking about heading down the lean route or are looking for ways to optimise their existing business.

This review was part of the O’reilly blogger review programme.

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.