No post for day 13. Whilst researching I found an excellent post (with contextual gifs!) that already covered everything I wanted to say, and the internet doesn’t need more duplication right (source).

Day 14: How can you deliver greater value to customer?

There is an urban myth that goes; when faced with the challenge of writing in space, the US spent millions developing a special pen, whilst the Russians …simply…used pencils. The implication is that the designers behind the pen, were trying to solve a problem based on feedback from business, instead of working with the astronauts to really understand the true requirement.

As testers we often provide the last line of defence between what a user wants and what a user gets. This being said, the majority of testing often seems to come from the business and focus primarily on business value. Part of the the responsibilities of testing involves empowering the business to make decisions about their software, which may influence the money that software makes. This allows testers to provide business value, but what about customer value?

Before going further, it will be useful to define each type of “value”, as to prevent these two points from overlapping too heavily.

Business Value:

‘How much money can we make if we do this thing what we are planning to do” -

Bieberlabs

Customer Value:

The benefits that a service provides that a customer is willing to pay for.

-Harvard Business Review

Almost all commercial software has been written for the purpose of providing the customer with benefits, which they would be willing to pay for, that they would not have access to otherwise.

The problem of defining customer value in software, becomes more complex when in order to answer, we first need to be able to answer the question: “what does the customer define as a value”. You may find that what the customer defines as value, differs from your expectations. To understand why the customers use our software, the best option is to ask them directly, if that is not an option for you, try asking the following around your organisation:

In your own words, why, do you think our customers use our product?

The results will vary with every software project, but there is at least one aspect that they share:

Providing a benefit/s that cannot be obtained cheaper or in the same form elsewhere.

As testers, we validate that the software delivers the expected functionality, thus ensuring that the customers can utilise the value that the software returns. For example, testing an instrument that is able to write in space.

The real space pen, costing in at: $3.98 — image source

When we understand the customer value our product brings, we can introduce testing to allow us to explore, how, our product provides the benefits that the customers are willing to pay for. I challenge you to write down the top three. Once written down, try to convert the customer benefits, not the software, into use cases and test it using the software… wait … what? ok, let me explain.

Say you work for a company that provides a car insurance comparison service. Your customer “benefits” may be:

Question 1: Using our platform users can save on average 10mins when searching for 5 quotes, compared to doing it by hand.

Using our platform users can save on average 10mins when searching for 5 quotes, compared to doing it by hand. Question 2: Using our platform customers can find cheaper deals by exposing providers the customer may not have heard of

Using our platform customers can find cheaper deals by exposing providers the customer may not have heard of Question 3: Using our platform, the insurance companies have access to more customers

Ok so there are the use cases, so how do we test them with our software? Here are a few examples:

Answer 1: Perform 5 separate lookups using direct quote comparison websites and compare the time taken to using the comparison application.

Perform 5 separate lookups using direct quote comparison websites and compare the time taken to using the comparison application. Answer 2: Send out an internal survey or read the user reviews to ask if anyone has discovered a new insurance companies through the app.

Send out an internal survey or read the user reviews to ask if anyone has discovered a new insurance companies through the app. Answer 3: Encourages us to talk to our clients more and in doing so, provides the comparison site with the opportunity to reiterate the value the comparison site is bringing them. This allows us to better understand the origin of requirements and devise test strategies that align with how all aspects of the system will be used.

So now that we have explored a few examples of the customer value our software provides, what does this have to do with software testing?

If we as testers are able to clearly articulate to the stakeholders, the customer value that will be impacted by a bug or missing functionality, it then allows us to:

Identify additional test scenarios

Allow us to prioritise testing around high customer value aspects of the application

Identify edge cases from assumed edge cases

Develop a deeper understanding of why we are testing the software

Identify bugs earlier during the requirement planning

Understand what defines the power users from the casual users

Understand why the users interact with the application in the way that they do

All of these points allow us to deliver greater value to the customer by delivering a higher end experience in the areas that matter most to them. We as testers have to find the customer’s voice in the swarm of business needs and development practise. Developing the right product (or pencil), is as important, if not more important, as building the product correctly. Understanding the customer, is what makes the difference between, testing that your pencil can write in a vacuum, or testing that the product can write in a vacuum…. and can actually be held by a space suite.

I have used this within my current role, to speak to people all over the organisation and now, see what we do for our customers in a different light. Since starting this article, I have used it in at least half a dozen meetings and numerous exploratory testing sessions.