Writing functional test-books cookbook : Product Owner journey 2022

6 min readMay 28, 2022

Hello, after a few years writing backlog and testing bunch of products mainly web and mobile applications, I finally decided to share my distressful experiences to the outside world, mainly to help and exchange experience with those who are struggling too with this matter. This article is the first part of a very long journey, that should end with a hard but satisfying outcome like a ‘Lord of The Rings’ ending…

Product owner journey ?

But wait, let’s clarify things. You might be asking what is really a product owner and what is that role scope. Well …. lets’s check it out with the Wikipedia definition.

“The product owner, representing the product’s stakeholders and the voice of the customer , is responsible for delivering good business results.[26] Hence, the product owner is accountable for the product backlog and for maximizing the value that the team delivers.The product owner defines the product in terms of customer-centric outcomes (typically — but not limited to — user stories), adds them to the product backlog, and prioritizes them based on importance and dependencies.”

Well … to sum it clearly the product owner role is to : Maximize the value of the product while making a compromise between all the demands of all stakeholders.

With that clarified, we can go deep in the subject : The test book.

A test book ?

The objective of making a test-book is simple, its a long checklist to insure that you did not forget to test all the aspects of the solution you are building (iot, web, VR, mobile, anything…) First of all, you should have a backlog with a list of all the features you must build, decomposed in a list of use case and user stories. There are different ways to restructure it but here is one way :

backlog

— use cases

— — user stories

— — — business rules

— — — — implementation (also called technical cases sometimes, this part doesn’t always concern a PO and is mostly a matter of architects , Tech Leas, ui/ux designer, but it’s important to note that technical case explain how the feature should be implemented technically)

For the following steps, we will build from a typical e-commerce user story : The user story is : “ As an user (authenticated)I can add a product inside the cart”

The product backlog

A backlog is a list in any form and any means that allows you to view all the features and their business rule. A business rule is typical all the constraints given by stakeholders that a feature. A stakeholder in that case can be a lot of things (final users, partners, the development team, the ui/ux team, etc…).

So for our case

— use case : cart management

— — user story : “ As an user (authenticated) I can add a product inside the cart”

— — — business rules (just a few examples): A quantity must be a positive integer and is mandatory / when added to the cart the cart must be saved for each user/ a success popup will show a popup confirmation / when adding the stock is checked if the sold out an error message is displayed / etc…

— — — — implementation : a button in the product details page/ the button ui ux description in a wireframe of any mean / a webservice /rest/v1/addToCart/{productId} / a success popup described in a ui ux wireframe, etc…

Test cases ?

Then, the first step is to define all the test cases for all the features. There are mainly 3 types of test cases :

passing case : it works perfectly
degraded case : it works but not perfectly
non-passing case : oh it doesn’t work

Let’s take an example from our use case :

There is one typical mistake one should avoid : testing the front-end interface without checking the back-end API.

Most modern application allows the back-end to expose API that can be called by multiple front-ends, mobiles apps, ERP, CRM, partners, etc…

For those who allergies to code, you don’t need too take your pills but you need to remember one thing … TESTING A PLATFORM FRONTEND ONLY IS LIKE TESTING A CAR WITHOUT DRIVING, BY JUST TOUCHING, AND VISUALY CHECKING IT.

Wrong idea : You need to now the code to test an API => For a car, you don’t need to now how is build the motor, you just need to know that its works and if you push accelerator, the car will move. It’s the same principle with testing API.

There are thousands of reasons to test the back but one of the most dangerous reasons is the security reason. The front end is accessible to all users, and a hacker , meaning that data sent to the server can be altered. You might select a quantity of 5 products, but some “browser extensions” will alter and change it by a string (ex : Doe). The front will accept the input and if the back was wrongly configured and not tested, it might accept it too and that is a HUGE PROBLEM, your system is accepting orders with quantity =string, everything might crash …. (we will talk about these security issues in another article)

Try it out

So let’s build out testbook with an example

use case : As an user (authenticated)I can add a product inside the cart
pre-requirements : user is authenticated, user in the product details screen
scenarii : use connect, then navigate to product details, then select a quantity and push in the add to cart button.
expected output : confirmation popup added

Here are some example of test cases

passing case : success popup success added
degraded case : the internet is cut just after the action, there is no popup but the action is a success
non passing case : the is no quantity selected in the interface| the quantity received by the server is incorrect|the quantity in the interface input is incorrect| many push on the same button were done too quicky

For most cases, all user stories must have at least a passing case and a non passing case.

Note : To test the backend, you will need a tool like Postman, etc…

This part will be covered later but to sum it up, the most common but not only way backend are made is with RESTful webservices and to test them a typical way is first to authenticate to get a token and then request the webservice :

HTTP VERB https://{BASE_URL}/endpoint

example : POST https://mywebsite.com/rest/v1/addToCart/15424

there are others parameters to be taken in account but basically that is the process, we will explain this subject in another article. For the verb part, there is a verb for each action done against a server to interact, the mainly used are GET (read data), POST (submit data ), PUT (update data), PATCH (update data), DELETE (remove data).

Wrapping up

We reviewed the structure of the test-book, its content, and how its is used.

So let’s review quickly:

API / Backend calls MUST be tested, interface only tests are superficial
a use case must have at least one passing case and one non passing case
The test-book and a product backlog must be updated through a project lifetime

Thank you for reading and see you next time !!!