The challenge of testing web applications is becoming more and more predominant in our world. Basically the big challenge is how to describe what we want tested in a graphical manner, while facing frequent changes to the user interface with little time and ever-increasing application complexity.
Usually, we as testers base our test cases on specifications (when we get some). Commonly, the specifications are described in English (or French, or German, or…) prose, but also sometimes in the form of business process models, flow charts or other diagrams. In this blog, I do not want to talk about textual specifications – graphical specifications are the trend and generally the preferred means of explaining how an application should operate. Based on these specifications, we manually define our tests based on user interface interactions. We use these test descriptions to either manually execute tests or to implement test scripts and execute them again on our application. Let me assume you looked at model based testing (MBT) before, but found state-based modeling notations and message-oriented modeling of interactions which you did not quite understand how to apply in your context.
How can we improve model based testing for graphical user interfaces? First of all, model based testing should reuse existing assets like business processes, flow charts, user interface recordings and others. These assets should accelerate the model creation so you can quickly generate tests and test scripts. This is arguably the most advanced form of model based testing which some call “Keyword-driven model based testing” or simply “Keyword-driven MBT”.
Let me explain how this works, using my favorite definition of what a model is, “a model describes the landscape of what we want to test”. Think of your application as a landscape, and you want to capture this landscape in a model. You could say this landscape may have a forest, a river and a mountain. Well, when you import a business process model you will most likely only get an outline of your landscape: some lines hinting at a mountain in the distance, and a river originating from the mountain and crossing a plain.
Now, the idea of “keyword-driven MBT” is to use some pre-defined building blocks, like trees, to refine an outline into an actual forest, to add water to the river, and to add a rock face to this mountain. In other words, these building blocks enrich and correlate the logic expressed in a business process model with data and user interface information from your actual application.
Let us transition from this artist’s view into the real world: your application user interface is made from buttons, forms, menus, etc. and data is entered and displayed via these elements. So with “keyword-driven MBT” you will model with button clicks or form entry (etc.) to turn an abstract business process model or flowchart into a model from which you can automatically generate tests and executable test scripts. This approach enables you, the tester, to fully understand how business logic impacts the user interface and data, and vice versa. It enables business analysts to understand how the user interface impacts the business logic. Imagine how this approach can speed up getting from specification to tests!
In addition, new testers in your organization will be able to really understand the application more quickly, and get started much faster, since the tool uses an intuitive and natural language for people used to GUI testing. And let’s not forget that that model and test review will also become easier than ever.
To conclude, a keyword-driven MBT approach to modeling is really innovative for applications that are tested via graphical user interfaces. Graphical modeling from pre-defined building blocks is really the next step and the future in the evolution of model based testing. Pre-defined building blocks simplify modeling as well as test automation. (Read more on automation with model based testing here.)
Alexis Despeyroux is a Conformiq technical field application engineering specialist.