Open Book Testing for on-boarding Testers

Adapted from my original post on the “Inside HMCTS” blog.

I’ve spent a lot of time helping one of my clients build a test practice. I’ve always hated those typical on-boarding exercises; “read Confluence”, “here’s some documentation”, “this is what the system should do”, “have a look in Jenkins”.

The on-boarding process should try and solve:

  1. Get people ready to work. Quickly.
  2. Understand the product, the domain and the problem being solved.
  3. Get a solid feel for the organisation, what it’s about and what their goals are.

The final point was already being addressed, the client had an induction that they ran that introduced the department and the programme of work. No need to re-invent the wheel there.

But 1 and 2 really weren’t being addressed, at least in my context as leading the Testing Practice.

My initial thought was to pair people up; get them working together on some things. But it occurred to me that perhaps that would be counter-productive, as the new starter would still lack context. Throwing people in at the deep end works for some but not for others.

Brain dumps are boring. I appreciate that having some documents to reference can be helpful, but there’s little gaurentee that they’re up to date, and it isn’t exactly the most riveting experience.

So it was research time. I stumbled on this gem: Open Book Testing.

What is Open Book Testing?

It’s essentially the same concept as an open book exam; except in our context, the book is the system, product or service that we’re testing.

This is a technique that was developed by the guys working on Context-Driven-Testing. The technique sees a collection of questions, defined by existing service and product experts or other testers, presented to new starters.

The objective is that new starters learn the product and service by exploring and using the application to answer the questions. During this process, testers take notes on what they find.

The outcome should be that the new starter learns about the product and the leadership team learns about how the new starter approaches testing. The new recruit has an opportunity to present findings and compare results with the rest of the team and the system gets a fresh set of eyes over it.

I’ve been using this approach for a while now, and find that it creates the most engagement and gets testers ready to work quickly.

They still get to pair up, they still look at documentation etc, but the focus is on using their craft to drive their own learning, something that is individual to all of us.

Jon Bach’s article on Open Book Testing was the main source for this article and the practices I’ve implemented.