How The Jobs To Be Done Concept Can Help Quality And Testing

By Mike Harris

Testers are always looking for new ideas that can improve my testing understanding of quality. Jobs To Be Done (referred to as JTBD below) has proved useful to product managers and owners to understand why customers “hire” products. Testers can take a cue from them.

JTBD gives us a way of understanding clients' needs by asking for which job did they “hire” a product or service for. JTBD is a different lens with which to focus on the problem. It claims you don't buy a product simply because of who you are or what the product is, you buy products to help you make progress in a specific situation. So by understanding the situation and the desired progress, you understand the job, and by understanding the job you understand the dimensions of performance that matter and can make meaningful improvements to the product or service. It is this analysis that has helped me to test.

In “Competing Against Luck”[1], the authors give an example of JTBD by explaining why people “hired” milkshakes. Research found that people generally “hired” milkshakes to do two jobs: to make their commute to work more interesting and to treat their children in the afternoon. The company that was selling these milkshakes used this insight to work out who their real competitors were. They came to understand that people bought milkshakes for more than one reason.

Can JTBD Help Testers Better Understand Quality?

When we test we are looking for ways in which the program we are testing can be better. This includes looking for bugs, errors in the code, errors in design, UX issues, errors in the specification or user stories and many other issues that will affect the customer. To test a program we need to be able to understand the product from the customer's point of view, so that we can focus on the customer’s needs, rather than just to test that the product does what the specification says it should do.

Quality needs to be defined from the customer’s perspective so that the company retains its customers and can grow. W. Edwards Deming is cited in “Competing Against Luck” as the “father of the quality movement” and he said that “Quality should be aimed at the needs of the consumer, present and future”[4].

JTBD gives us tools to understand why the customer has "hired" the software. From that understanding, we can evaluate the software under test to see if it meets that customer's needs. An example could be that a customer wants to improve ways of keeping staff aligned and has recently moved its staff to working from home. This enables us to consider how the customer can make progress with the product we are testing in that particular situation.

How JTBD Can Help Us Test: An Example

As an example, we are testing charts. We can use JTBD to think about the progress the customer is trying to make by using the charts rather than just thinking about “do the charts work?”

It could be that the progress that the customer wants is to keep their staff aligned with company goals and is hoping to do this by using the charts to communicate information. 

The circumstance of a job is important [1] to defining the job. It could be that the circumstance is that wanting to create an environment where all staff are aware of key company metrics and data. It can also be that this is a job shared by managers who are both confident programmers, and those who are technophobes. You may want to develop a list of circumstances: are all the staff working in the office? Are they all at home? Or some combination?

Analysing the progress that the customer is trying to make and the circumstances of the customer can give you a better understanding of what matters when testing the application. If the customer wants to share the charts with their staff, then as the tester you will want to ask about how the product will support this, and will also want to execute test cases that test how the customer can do this. You can also think of other circumstances.

This type of testing would be done after the charts are selected as the solution. The testing can help in developing charts that do the defined job.

Once we know the circumstance of the customer, we will want to ask questions about how the feature we are testing will accommodate them. We can then develop appropriate test cases.

Using Jobs To Be Done With Exploratory Testing Charters 

As testers, we can also use JTBD to provide a new approach to writing charters for exploratory testing. Existing techniques of exploratory testing as laid out by Elizabeth Hendrickson [3]  in her book "Exploratory Testing" give us tools such as testing charters. The testing charters that can be derived from JTBD can give us an additional valuable perspective. 

For example, charters using JTBD:

Explore: charts 
With: spreadsheets
To discover: <progress>e.g. how to help the customer keep their team aligned with company goals

Or

Explore: charts 
With: spreadsheets
To discover: <the circumstance> e.g. how to help the customer share data with their team that are working at home

And charters not using JTBD:

Explore: charts 
With: spreadsheets
To discover: if the charts are rendered correctly in all supported browsers

Or

Explore: charts 
With: spreadsheets
To discover: the data in the spreadsheets is displayed accurately in the charts

Ministry of Testing can also help you understand exploratory testing more deeply: simply search on the phrase "exploratory testing".

Testing charters can help us think deeply about the product and find issues, which will include ways to improve the product, which we can then discuss with our team.

If we used these testing charters, we could test how a customer could use charts like these to keep their team aligned with company goals:

We could test by looking at how the company goals could be represented by the charts. We can ask questions such as: are there goals that can’t be represented by the charts? Could these goals be represented by other charts? Could these goals be represented by adapting the existing charts?

We can also explore ways in which the charts can be used to keep the team aligned with company goals. For teams working in the office, we can ask: Can the charts be displayed in the office? Will displaying the charts in the office keep the team aligned with the goals? For teams working from home, we can ask: Can the charts be shared in tools that the teams use? Can the charts be shared in a way that they can stimulate discussion? Does sharing the tools help keep the team aligned with the goals?

We can look for gaps between a product's stated purpose for a customer and hidden or latent purposes. For example, we could believe at the outset that the charts are meant to keep the team aligned, but a secondary unstated goal is to keep the department VP appraised of progress.

We can explore the dimensions of performance to find those that matter, and use what we have discovered to explore performance issues that are most important to a customer.

We can also look at the customer’s goals. Alan Klement says that a customer has Be Goals and Do Goals[2]. Be Goals are what motivate the customer to choose and carry out programs of work. Do Goals are fulfilled by more simple tasks. An example of a Do Goal would be the steps to make a chart in your app, and the Be Goal would be what motivates you to choose and make the chart. The tester can use these ideas to ask what the customer’s goals are and whether there are any gaps in how the product being tested fulfills these goals. We often are asked to test ‘Do Goals’ but we also need to test ‘Be Goals’. Considering the Be Goal for the chart is a way to look for gaps in the chart’s functionality.

Alan Klement [2] says that “instead of attaching value to what products are, we should attach value to what products do”. The cards and tickets that we are testing may describe only the functionality that we are testing, but we can look further to see what the functionality does. For example, the card may say that if the user clicks on the link a dialog box should be displayed. That states simply what the functionality is supposed to be, but if we look at what the feature does, we can evaluate whether the dialog box is useful to the customer.

Having knowledge of JTBD will help us collaborate with product owners and managers. I would recommend reading Competing Against Luck and When Coffee and Kale Compete as they will give an understanding of JTBD.  

I would like to thank Ben Newell for reviewing this article.

Further Reading and Recommendations

1. Competing Against Luck: The Story Of Innovation And Customer Choice by Clayton M. Christensen, Taddy Hall, Karen Dillon and David S. Duncan
2. When Coffee and Kale Compete by Alan Klement
3. Explore It! by Elizabeth Hendrickson
4. Out of the Crisis by W. Edwards Deming

Author Bio

Mike has been a tester for 20 years and is currently the tester for Geckoboard. He has been a Tester and a Test Lead and worked as a part of waterfall, lean and agile teams. He is also the Deputy Programme Chair of BCS SIGiST. Mike has a B.Sc.(HONS) from Middlesex University and is an Associate of the University of Hertfordshire. He has also set up and led a Testing Community of Practice and been part of a successful agile transition.

In his spare time, Mike coaches his daughter's cricket team.

Follow Mike on Twitter: @TestAndAnalysis