Building a successful test team is hard work.

I’ve outlined 8 lessons I learned from growing a successful test team in an article titled “The Blazingly Simple Guide To Growing A Test Team”.

It has been published in the October edition of Testing Trapeze.

Testing Trapeze October Front Cover

Testing Trapeze October Front Cover


The article sits along great articles from Erin Donnell, Richard Robinson, Margaret Dineen and Dave Robinson.

Testing Trapeze is a bi-monthly magazine edited by Katrina Clokie and put together with an amazing team.

The 8 lessons I learned from building and growing a test team are:

  1. Appreciate it will take time
  2. Understand the purpose of the testing team
  3. Appreciate that certifications don’t make someone a great tester
  4. Automation specialists don’t kill the need for testers
  5. Find people with a passion for testing
  6. The recruitment process is key to your success
  7. Interviewing is about selling yourself and solving your problem
  8. Quality is not just the responsibility of testing

You can read more in the October edition of Testing Trapeze.


I’m proud to announce a new range of merchandise from The Social Tester.

I’m promoting my new online store at Zazzle.

My first design, available in two flavors, is the classic “Works on my machine”. With the alternative “Doesn’t work on my machine”.

Each month I’m hoping to put a new design online.

The service I’m using, Zazzle, print these tees on demand and so far I’m impressed with the quality of the goods.

Here’s yours truly modelling one of the early versions of this design bought from Zazzle.*

Works on my machine - t-shirt

Works on my machine – t-shirt

It’s a good quality tee and the design looks good on it.

Why not head on over to the store and buy your friendly developer a “Works on my machine” tee and a “Doesn’t work on my machine” one for yourself.

You can get the designs on caps and baby grows also!

I’ve sold a few of these already (the design has been online for some time) and the feedback has been positive about the quality, delivery and design – thank you to all who have bought from the store.

Here’s the online store –


* This design has evolved since the t-shirt I’m wearing was bought. The store design is the latest and final design of this tee-shirt. More designs are on the way :)

The BCS SIGIST (Special Interest Group In Software Testing) was the first conference event I ever attended. It was about 6 years ago and I remember being amazed that people actually got together to talk about testing.

SIGIST was where I first saw Michael Bolton, James Whittaker, Dot Graham, James Lyndsay and Julian Harty. There were also plenty of vendors and lots of interesting discussions in the pub after.

In my opinion though the quality of the talks soon went downhill and I soon stopped going.

There were alternatives that I felt offered better value and a more consistent and relevant set of talks. Meetups were better attended and more sociable. The UKTMF had more interesting topics and more discussion. The London Tester Gathering had more beer. The SIGIST just felt old fashioned in a rapidly changing conference world.

Yesterday I went to the SIGIST event after a three year hiatus. And it was good.

It wasn’t amazing, but it was good.

The event is now held at The Barbican Centre which, for me personally, is a lot trickier to get to than their previous home at RCOG centre. It’s a personal thing, but it was an opinion shared by a couple of other attendees.

The food, drink, rooms etc were good although the rooms were not easy to find and a distance from the main networking area – cue people getting lost.

There was one vendor stand selling some sort of TMMI service so nothing to see there. :)

I reckon there were 50(ish) attendees – not a great turn out and in a big(ish) lecture hall it felt woefully under attended.

The annual AGM was also the opening part of the day. If you’ve never been to an AGM (at any organisation) then keep it that way. It was formal and boring, but essential for the BCS I guess….

An introduction from Stuart Reid kicked things off. A great keynote by Declan O’Riordan then followed. Declan talked about being an assertive tester.

Declan’s interest is in security testing and he talked about how a lack of assertiveness can lead to a lack of good security testing. He also talked about how lack of assertiveness can manifest itself, such as in people being Passive/Aggressive. Declan talked about some interesting behavioral facts whilst tying it to testing. Declan’s got a really easy presentation manner which added to the talk.

After a networking slot it was time for my morning workshop with Paul Gerrard. The main hall continued with track sessions.

Paul presented his ideas about a new model for testing. You can read more about the model here.

The session was good. Paul spoke about modeling our testing and presented his new model of testing. It’s worth reading and applying it to your own thinking to see if it works. Paul’s after feedback about it.

We use modeling as an aid for creating tests here at NVM but we don’t use it as a way to agree scope – something I’m sure we’ll start doing. We also don’t share our models across teams which is something I’d like us to try more of. So I took a lot away from Paul’s workshop.

After a decent lunch I went to the presentation tracks.

Up first was Russell Gallop who did a good presentation on Agile and CI for embedded software but it was clear he was at the wrong event. No one in the audience was working on embedded software and few of the audience were programmers.

It’s a shame when this happens as the speakers put a lot of time and effort in to presentations only to be presenting to the wrong audience.

Next up was David Orr who presented about “Testing Your Mind”.

I’ll be honest I was expecting something different but it was good. David spoke about his experience of working in three different changing contexts and how each one challenged him. I did expect it to be about the way testing can become frustrating and stressful sometimes and how our minds cope with it. But it was more about how the testing changed to cater for this changing process and environments. Not a bad thing but a mis-match in expectations.

Then came a discussion panel.

I must admit, although I have deep respect for all the people on the panel, I didn’t get much from this part of the session. The panelists are all great but they are all similar in the way they think about testing. The panelists were Tonnvane Wiswell, Ole Hansen, Mike Jarred and Declan O’Riordan.

They shared common values and ideas about the testing topics discussed. This resulted in four people all agreeing with each other and not being able to add much to what the previous panelist had said.

I want to see some Jeremy Kyle sort of panel with chairs thrown and security getting involved. Only joking, but you get the point. A panel discussion should be just that – a discussion – and there wasn’t much of that. Not the fault of the panelists. Maybe just needed a divisive topic or more diversity in panel members.

There was also no audience participation in the discussion. This assumes that the audience (for who’s value the panel is there for) had nothing valuable to add.

I like panel sessions where a seat is available for audience members to chip in with opinions and observations – a Goldfish bowl approach.

It also felt like the initial topic was one possible solution to a bigger problem, rather than the underlying real problem. Starting with a possible solution leads to discussions around this topic rather than the real problem.

“How do we get testers involved in earlier stages of projects?” was the opening gambit. A common question in the community. But what problem is that solving?

  • Why do people feel the need to involve testers earlier in the project?
  • What problem will that solution solve?
  • What problems will it create?
  • Will it work? Why might it not work?
  • Are there other people we should involve earlier?
  • What does early mean?
  • What about those who work in a collaborative agile environment already?
  • What benefits have been seen by early collaboration?
    Yada Yada.

Like I said, the panelists were great but the panel session just didn’t seem to work. Not enough discussion and not enough rigorous debate for my liking. :)

More coffee.

Then Paul Gerrard closed with a presentation about the Internet Of Things. This was good. It’s a topic I’m super excited about. It’s an infrastructure and network of devices that I think the testing community are ill prepared to test.

Paul talked about what the Internet Of Things is and what it means for society. He talked about the problems with it, the good it can bring and of course, the challenges we will face testing it.

How will we test it? Can we even test it? What happens when we miss something? What impact will it have on society? How can we recover from an epic fail? It’s a fascinating topic.

Good talk and lots to think about.

The SIGIST face stiff competition in the testing community and I do wonder how long the event will remain a viable option to run.

Meetups are free, better attended and more social.

Other conferences are much better value for money, more modern and more engaged with the community.

Online courses and other resources are more convenient for learning.

And of course, social media has replaced the need for many people to meet face to face anymore.

Can the SIGIST position itself somewhere in the market and regain it’s audience?

Many companies are offering a job in testing.

Many companies are offering a career in testing.

Testing - A Job or a Career

Testing – A Job or a Career

A career is a series of experiences. These experiences may come from many  jobs at many companies. Or they may come from a single place of work with a varied set of experiences.

A job is what some companies are offering. And there is nothing wrong with this.

Jobs are good. So too are careers. Some people can experience more in a single company than others may experience in 10 other jobs.

Being honest about the role you have is the key to getting the right person.

If you are offering a job then say so. If you are offering a career then say so too.

Some people just want a job. Some people want a career. It’s important to match the person and the job. By matching the right people to the right jobs you stand a chance of solving your problems. (You are solving a problem..right?)

It seems so simple but it’s a mistake many hiring managers make.

Get it wrong and you spend money recruiting the wrong person.

I once took a role that I believed to be a career. When I joined it was clear it was a job. I didn’t want a job, I wanted a career. I knew I would never get that at this company – I left after just 6 days (3 of which were spent trying to find out who to hand my notice in to).

I’ve also made the mistake of hiring people who wanted a job when I was offering them a career. It’s not good.

One is no better than another. Someone who takes a number of jobs can build a strong career.

Contractors, by their nature, are often looking for the next job. But they can build a strong career from those different jobs.

Your task is to match the right person to the right role.

In the interview be clear about what you are offering and strive to understand what the candidate wants.

Is it a job, or a career?

Be honest with the candidate and you’ll likely get the right match. Get it wrong and you’ll have probably hired the wrong person.

The international standard for Software Testing, ISO 29119, is soon to be upon us. There are people writing it and expanding it and creating it right now.

I’ve signed the petition against it because I don’t agree with some of it and it’s supposed to represent the industry I work in and I had no chance to input to it.

I wasn’t involved in shaping any of it, yet it’s soon to become a strong international standard in software testing.

My concern is not about how it will affect myself as such, but about how it will stunt the growth of the companies who sign up to it. It’s my belief that the standard will stunt the growth of the employees also.

I believe standards are useful. I believe standards can be helpful. They can turn laws in to process, or set out norms of operating that are good for business and society. This is useful.

Standards can also be restrictive though.

A company operating under this ISO 29119 standard may lose their ability to experiment and find new ways of doing good testing. Our industry and craft could suffer. The standard may hinder our ability to evolve our testing to be relevant to the market demands of the companies we work for.

I’m not overly worried just yet though. The standard is not even complete and it will take years before it starts impacting the market. The standard will likely be voluntary to adopt also. Companies that are experimenting and pushing boundaries will most likely not adopt it. At least not without a compelling reason. That means testing can still evolve.

That means there will still be a place for people like me. People who want to apply relevant test techniques and approaches. People like me who want to create new ways of testing that don’t yet exist.

And how can a standard cover something that doesn’t yet exist?

After writing this post I realised I’m describing a similar testing industry to right now. An industry where lots of companies rely on certifications. An industry where the minority are doing the innovative testing.

So will the ISO 29119 make a difference? Will it even get off the ground? Should we be trying to fight it if we don’t agree with it?

Or should we just accept it will happen and continue to do the best work we can; continue to be relevant to the companies we work for?

I suspect time will tell. As it always does.

If you don’t think the ISO 29119 is a good idea then consider signing the petition.

We’ve been recruiting heavily for a while now and it’s been an epic journey from those early days 4 years ago when I started here at NewVoiceMedia to where we are today.

The Dev team has grown very quickly indeed and we’re still recruiting for talented Developers to join us.

I’ve been involved in pretty much every hire in to the Dev team over the last 4 years and have thoroughly enjoyed this recruitment process. It’s where the inspiration for this latest series of blog posts has come from. When you’ve interviewed 150+ people at various stages of recruitment you start to find ways to optimise this process, see interesting patterns and work out whether or not you enjoy it. I enjoy it :)

When you receive a tonne of good candidates each week it’s important to have a process that is efficient and effective. I like to use Kanban to visualise the process and aid with tracking people as they move through our recruitment process.

Kanban is a visual tool to show you your work in process so that you can start to make decisions from the information. LeanKit have a decent description of what Kanban is on their website so I won’t repeat it here.

A Recruitment Kanban Board

A Recruitment Kanban Board

Above is an image of a typical recruitment Kanban board. The above shows a simple recruitment process from the point of view of a recruiter.

Any Kanban tool will work for visualising your stages and process, from post-its on a whiteboard to a fully fledged Trello board. I like Trello because it’s super easy to use, is free and can pretty much be configured to map out any process. The above is a doodle I did in the Paper App.

For this example I’ll use a standard recruitment process that starts with a backlog of applicants, then a phone interview, then a coding exercise, followed by a face to face and then hopefully an offer and a “Yes”, or it may just be a “No” from any stage within the process. Testers and Scrum Masters miss the Code Review stage unless that exercise is relevant but essentially follow the same flow.

An important part of an efficient system is to ensure you don’t spend time copying and pasting details. If you work closely with your recruiter you should be able to get them to send an email directly to Trello (with or without salary details depending on your level of sharing) so the candidate they are putting forward appears directly in the backlog of your Kanban board.

On the backlog are people who are applying for a role (hopefully you’ll be as quick as possible to provide timely feedback for the person applying :) ). Then it’s a case of moving them through the different phases as you do your interviewing. I think it’s important to include an “Offer In Progress” stage because there are sometimes delays and of course, until you receive the signed paperwork back they technically have not accepted.

Each stage will no doubt trigger some actions for you and your team such as sending the coding exercising, reviewing the code and then getting all of the contract preparation stuff sorted for example. Simply flow people through your system and use the Kanban board to show you where people are in the process, where your bottlenecks are and also give you clues as to how efficient your recruitment and interviewing process is.

I find Kanban a really effective way to see how applications are processed. I firmly believe in responding to every single candidate as quickly as possible and Kanban helps me to do this and avoid bottlenecks in our system.

How do you manage your hiring?

This is part of a series exploring how to hire good testers – the reverse “how to remain relevant and employable” is covered in my book Remaining Relevant – a book for testers who want to take control of their careers. It’s full of advice on how to find good jobs, perform well in an interview and take control of your own self learning.

You can follow more posts in the series using this category link – or by subscribing to my RSS feed