One Test Case is All You Need

[Originally on Ministry of Testing, November 20, 2013: One Test Case is All You Need. Reposted from the web archives]

• Does it work?
• Do the old features work as before?
• Does it work on the CEO smart phone?
• Does it look good on the owners CRT monitor?
• Does it make management look good?
• Does it make a difference to the customer?

When you start your work of identifying testcases and test ideas – consider it an exercise to identify the fewest testcases needed for the application. What would be the one thing you want to confirm and explore – to build confidence for the customer?

Many times I have experienced that, in an enterprise setting and due to market pressures, the most important test cases where the regression tests and a few daily smoke-tests. Often these were the tests that major releases depended on also.

“No problem Mr D – the dinosaur count is defined as a global constant.”

What testcases matter?

Really – it’s a trap to consider that the individual testcases matter … for the business. When we look into the business purposes it’s not even the app being built either. It is what the app enables the business to do: the business features and transactions between the users and the business. And remember that there will very likely be a difference between what the business wants and what the users want.  Let us look at an example here:

The local LEGOLAND theme park has a park app (iOS and Android) [In 2013]. They are proud of it, and have printed ads on the physical map and mentioned everywhere. The theme park management probably has a business case for the investment in app development and advertising, that pays off beyond “we need one of those app things” (true management quote).

The smart phone app enabled you to do the things that the physical map had: Offers and advertisements for restaurants and season ticket upgrades, a simple list of performance shows and similar push information from the park to the visitors. To ease navigation the in-app map always started at the entrance…

[which is not where I am all the time]

Look at the User Needs

But when I visit the park I want these things:

• Given that I open the map, I want to see where I am per the phone GPS
  • – and how to navigate to a specific ride
  • – and mark where I have parked the card
   
• Given that I open the show program,
  • I want to see it compared to the actual time
  • I want to compare it to the times where I have booked rides[1]
   
• Given that I open the list of rides
  • I want to mark them individually as “go see”
  • I want to know the estimated wait time
  • I want to add a reminder if I book a ride at a specific time
   
• Given that I am in the park with friends and family, I want to communicate with them
  • Where are you, where are you going next
  • When and where are we eating

Compare that to the existing functions mentioned above and you can see why I use text and phone messages – and the old-school solution of a physical map. Imagine the app development having just one requirement to justify the quality of the app: Given that the person is in our park, help them to make it enjoyable.

If you can come up with just one business transaction – that crystallizes why the customer will be kicking and screaming to want to use your application, then you have a very good understanding of your customer and all you need is that one testcase.

---

[1] For the LEGOLAND ride ”Traffic School” you book a specific time-slot.