‘early Model Based Testing’ (eMBT) is a software testing approach that aims to optimize the test case design phase. This is achieved by stimulating communication and collaboration between all project stakeholders to get early feedback and a shared understanding of the requirements in an early stage of the software development life cycle.
Author: Silvio Cacace, TestCompass, www.compass-testservices.com
“That looks very nice and it works fine. But sorry, it’s actually not what we wanted” Do you recognize this? Off course, you want to prevent this, because it indicates that you have delivered a product that might look nice and works fine but is not in accordance with the customers wishes.
Still 35% of all bugs in production can be traced back to the requirements. And these bugs are almost always related to poorly defined requirements or a lack of understanding around those requirements. To make sure we meet the customer’s needs (business value), we need to achieve a shared clear understanding of the complete set of requirements. In addition, requirements change continuously, and it is therefore important to manage these changes effectively. ‘early Model Based Testing’ (eMBT) is a solid approach to solving these problems and challenges.
‘early Model Based Testing’ (eMBT)
‘early Model Based Testing’ (eMBT) is a software testing approach to ensures the optimization of the test case design phase. But more importantly, eMBT stimulates communication and collaboration between all stakeholders (business and technical stakeholders) with the aim of getting early feedback and a shared understanding of the requirements in an early stage of the SDLC.
eMBT consists of the following 4 phases:
- Exploring
- Review
- Coverage
- Checking
In this blog, I aim to give some insight into the 4 phases of eMBT and how an eMBT tool can support this eMBT approach to testing with a representative example of an app ‘price calculator hardware store’.
Example eMBT approach
The following requirements are stated.
App price calculator hardware store
A hardware store sells hammers (5 euro) and screwdrivers (10 euro).
If a client spends more than 200 euro, then the client gets a discount of 4%.
If a client spends more than 100 euro, then the client gets a discount of 20%.
If a client buys more than 30 screwdrivers, there is an additional discount.
1. Exploring phase
The first phase is the exploratory phase. During this phase, the goal is to explore and examine the requirements and ensure that there are no open ends, ambiguities, inconsistencies, contradictions, etc. And there must be a shared understanding within the entire team, both business and IT.
We start by setting up a test model in the eMBT tool based on all the information collected relating to the requirements. Ideally this phase starts as soon as the business (product owner) defines the requirements and would involve the development team. However, in practice it often happens that this phase begins later, in the refinement sessions or when the requirement is picked up by the development team, as a user story.
The test model in eMBT is a graphical model, based on the principles of a flowchart but with some specific features. The test model has a high level of abstractions so it can be easily understood by all team members, both business and technical. This promotes clear communication and collaboration regarding the requirements in a very early stage.
Flowcharts are a general-purpose type of graph that can be used for testing. Graphs are used in many ways in software engineering, and they come in all kinds of flavours and styles. They may differ in style of nodes, way to draw and connecting them, and notational conventions. But in the end, they all consist of a collection of objects (called nodes and drawn as circles, ellipses, or boxes) and relations between them (called edges and drawn as lines or arrows).
To draw the test model, the following 5 nodes can be used.
The following comment node can be used to add questions or comments regarding open ends, ambiguities, inconsistencies, contradictions, etc.
The first part of the model, based on the given example, will look something like this.
When drawing the test model, you will find that it immediately facilitates discussions about the requirements. It helps to spot inconsistencies in the overall understanding of the problem domain as well as highlighting areas of ambiguity which need to be addressed. As the discussion progresses, you will be able to update the test model, which may in turn lead to further questions and refinements.
When using the decision node with an outgoing yes and no test path, one is forced to think about the happy and unhappy paths, and the boundary values. The open ends will become apparent straight away if there are any.
The first part of the test model containing all questions, comments, etc. should now look something like this.
2. Review phase
Before being able to complete the test model, the questions raised should be answered within the team. This avoids any individual assumptions being made and ensures the whole team has the same clear understanding of the requirements.
The advantage of bringing the business and the test team together for this phase is that they can immediately answer many of the questions and ambiguities as soon as they are raised and we can update the model with these answers when the whole team is present.
eMBT is a very flexible approach, and therefore we can give and ask feedback during several moments or phases. Sometimes a special eMBT-meeting is organized, comparable with the 3 or 4-amigo’s meeting in the BDD process, in which several models are discussed at the same time. But in other situations, the feedback/review of the test model takes place in the refinement session or in a less formal setting. It is very common that several e-MBT meetings or feedback/review moments are necessary for the same requirements, it is an iterative and exploratory process. An iterative approach is necessary to capture changes in the requirements during the development process. A change in the requirements means a change in the test model and so feedback/review is needed once again.
In the next test model, all the answers to our questions, comments, open ends, etc. have been integrated. Of course, this is optional and depends on how the feedback/review is performed. Sometimes it can be more convenient to just write down the answers and comments and include them in the test model later, and have it reviewed again.
During the review phase, the product owner also announced a change in a discount percentage. The discount for a buy of > 200 euros should not be 4% but 5%.
After all our questions have been answered and any changes, comments, ambiguities, etc. have been discussed and incorporated in the requirements, we can update and finish the test model.
The updated requirements look like this now:
App price calculator
A Hardware store sells hammers (5 euro) and screwdrivers (10 euro).
If the total is more than 200 euro, then the client gets a discount of 5%.
If the total is more than 1000 euro, then the client gets a discount of 20%.
If the client buys more than 30 screwdrivers, there is an additional discount of 10%
* There is no stack discount
The complete test model should look like this.
We can check the model to see if we have included all business rules and decisions from the requirements. In the requirements of the hardware store, there are 3 business rules and 3 decisions.
Business rules:
- Buy > 200 euro, discount of 5%.
- Buy > 1000 euro, discount of 20%.
- If buy > 30 screw drives, client gets an additional discount of 10%.
Decisions:
- Buy > 200 euro
- Buy > 1000 euro
- Buy > 30 screw drivers
Because we also want to check the different boundary values, there must be 3 different conditions per decision in the test model.
Now that we have checked whether we have included all business rules and decisions in the test model, we can have the test model reviewed again by the team to be sure that the test model is correct and complete and to make sure the whole team has a shared understanding of the requirements.
The second part of this article discusses the generation of test cases from the model and their execution.
About the Author
Silvio Cacace is a passionate test professional since 1994. He works for Newspark and is the founder of the test approach ‘early Model Based Testing’ and the eMBT tool TestCompass.