Generic steps to generate test design using MBT

Below are the four common steps, tester should use to generate test design using MBT.
1. Understand the requirements and list down all functional points for the requirement – Analyze the requirement and break each requirement into number of functional points, which has some inputs and responsibilities.

2. Associate each of the functional points with sequence or as use case – This step will link each of the functional points to connect with other functional points to archive our goal or requirement.
3. Provide structural information in the model – To accomplish this, normally UML diagram will be used which helps to understand the flow of the model.
4. Provide behaviors information for each of the listed functional points – This step tells what all parameters each functional point takes and what its responsibility and what its output is. This step is important as this step gives clarity for analyzing model to generate test design.

What makes MBT adoption slow?

Model Based Testing is an innovative methodology but yet to gain momentum in the testing organizations. As with all the methodologies, MBT as a trending methodology also needs to be supported by communities of practices (CoP) both within and external to the organization. There is no such CoP active for MBT that users can reach out to. One reason could be that each of the MBT tools uses its own way of modeling and generate test design. With lack of common standards both with modeling approach and tool’s proprietary nature, the users fear the lack of interoperability between the tools if they wanted to switch to a different tool. MBT cannot remain a theory and a best practice but also backed up a good tooling. We have some good players in the industry and we will have a look at them in the coming weeks.

Debunking Common Myths of adopting Model Based Testing

Myth #1:  Model Based Testing may take huge learning curve

False!  In practice, it does not require to understand complete modeling concepts; also it requires is understanding of basic modeling and scripting depending on Model Based Testing tool.

Myth #2:  Model Based Testing consumes more effort to generate test design

If the MBT tool expert and domain expert are different resources, then Model Based Testing effort could be more, in which huge chunk of effort is spent on review and rework. If the domain expert can be made the Model Based Testing tool expert, then it is very much possible that Model Based Testing effort will be less than or equal to the traditional method.

What are the key essentials in embracing Model Based Testing?

To adopt Model Based Testing effectively, three aspects need to be ensured:

Essentials for MBT

a)    Sponsorship from the top management: The top management should recognize the potential benefits of Model Based Testing and drive this initiative.

b)    Create an environment for adopting model based testing

c)    Identify resources with both positive attitude and technical expertise towards such new methodologies.  It’s the sense of curiosity and confidence that really matters. This alone can reduce the learning curve.

Can developer design model be reused for generating test cases

When there is a plan to adopt Model Based Testing, generally people think of reusing product design model. Product design is for developers to implement requirements that contains low level design. The purpose of

product design is to break down the requirements into smaller tasks and for each task; corresponding class is defined to implement its responsibilities.

Now, before we think of reusing the model, we need to define the scope for adopting model based testing. If MBT is planned to generate test cases for developer testing (white box testing), then it is feasible to reuse product design model.

If the scope is for system testing, then it is not feasible because system testing does not look for class level design. In system testing, scope would be to verify and validate product behavior with respect its requirements; for which, test analyst should create model for system level testing.

How Model Based Testing solves traditional testing issue of keeping test cases updated with requirement changes.

In product based companies, biggest challenge with testing is maintaining test cases. Few reasons for maintaining test cases are a) to keep test cases up to data with respect to requirement b) that test cases document being a live document, it needs to be understood and maintained by new testing resource.

Suppose if Tester A writes test cases and later if Tester B role to maintain. Tester B needs to know with what level of understanding Tester A has written those test cases, because without that Tester B cannot modify or delete the test cases. This is one of the biggest problems companies are facing. If the test cases are very few, then it would not be an issue, but when we say product, it will have near to 1000’s of test cases. When there is a change in the requirement and if tester needs to maintain, then it is very much time consuming.

Can Model Based testing solve this problem?

Yes, when Tester A understands the requirement and creates a model, complete test artifact will be generated from the model automatically. When Tester B needs to modify the test artifacts, and walks through the model, it will be very easy to understand. Later one can modify the model as per the requirement change and generate test artifact automatically.

Can Model Based Testing reduce silo between different resource group with in project.

Silo in SDLC

In the current traditional practice, manual tester initially understands requirement either by discussing with the analyst or customer or through the specification documents; subsequently he waits till application prototype is ready. Once prototype is completed, tester uses prototype as a reference and starts writing test cases with his understanding. Once test cases are ready, they undergo review. As test cases are written with tester’s understanding, (1) it is difficult to validate an individuals understanding, because of which most of the bugs logged are rejected. (2) Sometimes developer also understands few requirements differently and implement accordingly; this gets detected only testing phase. Later, it takes lot of efforts to convince developer to make understand his mistake and then fix that issue, which is very much time consuming.

 Is there a way to resolve the silos between developer and the tester?

MBT reduces silo in SDLC

Yes, Model Based Testing has capabilities to solve or reduce this silo. In Model based testing, tester understands the requirements and creates a model of his understanding. With this model, reviewer can easily understand his level of understanding by walking through the model and suggest or correct his mistakes. Also there are high chances of correcting requirements related issue.

Once the model is reviewed and approved, this model can be sent to the developer as a reference to understand the specification. This gives clarity and synchronize requirement understood across development and test phase resources.