cubes
###LEFTMENU###

.mzT@BPMN: Model-based testing for enterprise IT

How can MBTsuite be used in a production environment? The following success story gives an example of effective deployment of MBTsuite.

BPMN is a method for graphic modeling of business processes. BPMN can be used to display the resulting enterprise IT as well and additionally visualize it for verification and testing purposes. Suitable testing procedures are required in order to ensure correctness, quality and reliability of the process specifications annotated in BPMN. Additionally, they have to be easy to specify despite their high complexity.

Together with the modeling tool Innovator for Business Analysts and the case tool Team Foundation Server, MBTsuite is the ideal tool for this task. It can be used to automatically generate the test cases from the BPMN model and export them into Team Foundation Server for further use.

How does the test case creation toolchain work in detail? The following model shall exemplary show the workflow from BPMN to test cases generated with MBTsuite.

It shows a strongly simplified workflow model for product creation and sale: After an incoming order, the product is to be created, tested and finally shipped.

Via an add-in, the model can be directly imported into MBTsuite. There, a test case tree is created applying different strategies. Within MBTsuite, the test cases can be filtered, for example to ensure requirements coverage. The test cases can also be visualized directly in MBTsuite with a visualizer plugin.

Finally, the test cases can be exported into Team Foundation Server or other test management tools.

The complete toolchain is designed to minimize the effort of test case creation and maintenance.

Introduction

To develop high quality software and systems and to ensure quality, reliability and correctness, suitable test methods are required. With growing complexity of the system to be developed, testing becomes increasingly difficult and more costly. To achieve the best possible test configuration and gapless covering of the planned test goal, a structured method is required that surpasses manual or automatized test case creation based on requirements.
At the beginning of every development process stand the requirements for the system to be developed. As early as this stage, serious errors can develop from misunderstandings and false interpretations which are often not recognized until application. Mistakes like these are among the most cost-intensive. Therefore, it is recommended to document requirements in an intuitively understandable form that leaves as little room for interpretation as possible. BPMN offers a graphic notation for this purpose that provides a slender and simple language especially in the fields of enterprise IT and workflow management through its focus on business processes.
Additionally, a graphic documentation of requirements significantly supports the model driven approach for system development and test specification, since the respective models can be derived from the requirement models. This article tries to show how the test specification development procedure can look in detail.

BPMN

The BPMN 2.0 [OMG10] as a graphic notation defines a manageable vocabulary, which makes it clear, precise, easy to understand and especially easy to learn and apply in comparison to human language.
Basic elements of BPMN include:

•    Activities: Actions or work steps
•    Sequence Flows: Arrows that indicate the course of a process
•    Events: Point in time or time intervals connected to functionality
•    Gateways: Fork points

In the BPMN, models can be distinguished by their degree of abstraction. So-called functional models are very abstract models which describe the rough process operation instead of specifying every single step. These models are optimally suitable for drafting and coordination among the various stakeholders, testers, users and IT developers. Functional models are also ideal for requirements for workflow-oriented software systems.
Furthermore, so-called executable models exist, which are specifically detailed so far that they can be used as direct input for implementation and integration of workflow management systems.

Innovator for Business Analysts

Innovator for Business Analysts [MID10] by MID is a new modelling tool that was specifically developed for the role of business analysts, requirements analysts as well as process modellers, IT architects and system testers.  The tool implements the BPMN in its entirety, offering many more UML elements at the same time as well, for example state diagrams and text-based functions for e.g. managing requirements. The tool does not aim to implement the OMG standards completely, but to supply the respective user with the specification method necessary for his role.

MBTsuite - the test case generator

With the test case generator MBTsuite, the company sepp.med GmbH provides a program for the model-centric test which builds a bridge between modelling and test management respectively test automatization tools. The .mzT models specified in the modelling tools can be imported into and evaluated in MBTsuite. The software derives test cases from the models, taking into account various strategies, which can then be exported into test management tools and be processed further in them. The resulting test sets are complete and can be adjusted to defined test objectives by preselected model attributes, in order to avoid test case explosion.  Through the modular architecture and the openly greated interfaces, MBTsuite can easily be combined with arbitrary modelling and test management tools, allowing for easy integration into existing tool chains.

TFS - the clever alternative

The Team Foundation Server (TFS) by Microsoft offers an environment that supports project works in software development teams from beginning to start. From with system requirements through to development and test management, the TFS provides a central platform for all accruing steps.
Additionally, it presents functions for source code versioning, automated builds, test automatization and much more. Communication between all team members is supported and it serves as a workflow management system within a project.

The model-centric test

For specification and development of suitable tests, software developers use the method of model-based testing (MBT). In case system development is model driven, automated test case creation from development models is obvious. This achieves savings, since tests are designed, developed and changed together with the system. Experience has shown that development models alone are not enough to specify adequate tests. Often they are limited to the requested functionality and do not contain all possible scenarios necessary for the test. With this method it could merely be verified whether the software created from the model works as intended by the model.
What is problematic about this is that errors in the development model lead to erroneous test cases as well.
For this reason different approaches exist which try to avoid these problems by adding test specific environment models, usage models and so on. However, these lack the tester’s view on the system and the possibility to optimize the tests through test management information and test strategies. This is necessary since a solely combinatorial generation of test cases from development or test models generally leads to a test case explosion that is far from manageable. A further developed approach that takes these problems into account is the method of model-centric testing (.mzT) [SE09-2]. The test cases specified here are specifically created for the test and are derived directly from the requirements. Through the resulting independence of test cases from development models, faulty system modelling does not automatically lead to faulty tests. Furthermore, test management information, the know-how of test designers (Tester’s Mindset) and the user view (Usage analogous to later application) are applied as well. .mzT concentrates on the validation of the system under test and the possibility to conduct economically justifiable tests through optimized test case selection. Furthermore, test cases are created fitting for the respective test objectives. This reduces the effort for actual execution significantly.
If requirements are present in form of a requirements model, it is possible to convey the model to a testing model successively. In this way, a continuous methodology and notation from requirements to test is given. In the following, this methodology will be exemplarily demonstrated with the introduced tools.

Model-centric test with BPMN

If reduced to its basic elements, a test model consists of test steps, which constitute possible points of interaction with the system under test (SUT) and verification points for pure test instructions. In the BPMN, these elements are displayed as activities. The processing logic is modeled via sequence flows and gateways. Every path of the resulting graph describes one or more possible test cases, depending on test configuration and test data.

From requirements model to testing model

Now, how can a requirements model be transferred into a test model? The following requirements model, created with Innovator for Business Analysts, shall serve as an example (see figure 1). In this strongly simplified and abstract model a product is to be created, tested and shipped after an incoming order. At the very end, a bill is sent. As long as the validation fails, the product is being revised. The process activities have to be checked in the test, which is why they are transformed to test steps (<<TS>> in the diagram). The initial event defines that the process is started through an order. This order has to be conducted by the performing tester, which makes another test step necessary.  The process ends with the shipping of the bill, which the tester has to check as well. Therefore, a verification point (<<VP>> in the diagram) has to be inserted. Further verification points could be set at useful places, for example after product revision. In the activities, detailed information is deposited about the implementation of the respective steps. This leads to the following model (see figure 2): The test step “Review product” is only reasonable if the test fails. This dependency has to be described at the corresponding gateway using a machine-readable syntax – Python in the case of MBTsuite (see adjoining detail excerpt).
Afterwards all the test steps that influence the test result have to be divided, so that the corresponding equivalence classes are created. In “Create product” one faulty and one correct product has to be created (similarly “Revise product”). To maintain the formatting of the diagram, it can be modelled in collapsible processes. Hereby, the variables checked in the gateway are defined in the activities in script language. For example, in “Revise product correctly”, the defined instruction would be “erg = 1”. See figure 3 for the resulting test model. Furthermore, priorities for sequence flows can be assigned via labels in order to sort the test cases by priority. It could be imagined to assign a low priority to the “Revise product faultily” sequence flow. Thereby, it would only be included by respective indication in the test case generator. The resulting diagram can now be directly exported into the test case generator MBTsuite by an add-in.

Test case generation with MBTsuite

After export, a test case tree can be created with MBTsuite by applying different strategies. The test case tree contains all possible test cases, taking into account the respective generation strategy and the related selection parameters, such as loop limitations, priorities and so on. Among others, one possible strategy is the “Full Path Coverage”. Without any further parameters, it theoretically extracts all possible paths of the graph. To achieve a result within a finite timespan, specific parameters have to be set, depending on model and strategy. In the example, “Full Path Coverage” was chosen. The maximum path length was set to 50, loop limitation to three and priority to “high and middle”. With the given parameters, MBTsuite generates four test cases and the test case tree. Subsequently, the test case tree can be optimized further through different filters. Possible filters are for example node coverage (all nodes of the test case tree, at least once) or edge coverage (All sequence flows of the test case tree, at least once). Figure 4 shows the created test case tree. It is filtered by node coverage, which keeps only the remaining test cases selected.

Test management with Team Foundation Server

The test cases exported from MBTsuite can now be imported into and administered with the test management compontents of Microsoft’s Team Foundation Server. Figure 5 shows the detail view of one of the two test cases. Here, the test cases can be edited if necessary or enriched with additional information. In the field “Action” the detailed descriptions of the individual test cases are displayed, which have to be processed one by one afterwards. Finally, the test cases can be executed assisted by the tool, for example manually. If a test case is started, one reaches the view in figure 6: For every test step of a test case the results “passed” or “failed” can be documented. In case of an error, detailed descriptions can be recorded. During and after execution, numerous statistic information and data can be accessed.

Conclusion

The specification of best possible tests in system and software development requires a suitable methodology. The goal is to create as good tests as possible with minimum effort, taking the specific test objectives into account and keeping the effort of test case execution as low as possible. Model-centric testing as a best practice method of model-based testing is outstandingly suitable for the achievement of this goal (see [PS09], [BM08], [BM09] as well). It is furthermore advantageous to use a consistent and coherent specification language within the system development and testing process. For this purpose, the new BPMN version 2.0 is eligible. As a graphic notation with focus on business processes it is well apt for the documentation of requirements of enterprise IT systems. Through its strict focus it constitutes a slender, easy to learn and intuitively understandable language.
The modelling tool Innovator  for Business Analysts by MID, the test case generator MBTsuite by sepp.med and the Team Foundation Server by Microsoft as a test management tool in combination provide a practical tool chain, which can be applied using the methodology of .mzT and BPMN. In this manner, optimized test scenarios can be created on a simple, low-on-errors and resource-efficient way.

References

[OMG10] – OMG: „Business Process Model and Notation”, dtc/2010-06-05 –
http://www.omg.org/spec/BPMN/2.0 (last view: Sep 2010)

[MID10] – MID the modeling company: „Innovator for Business Analysts“,
http://www.mid.de/fileadmin/mid/PDF/Datasheets/Datasheet_Innovator_for_Business_Analysts.pdf (last view: Sep 2010)

[SE09-1] – sepp.med GmbH: „.getmore (GEnerating Tests from MOdels to Reduce Effort)) – Der Testfallgenerator”, http://www.seppmed.de/fileadmin/pdfs/metamethoden/Broschuere_getmore.pdf (last view: Sep 2010)

[MIC10] – Microsoft: „VISUAL STUDIO TEAM FOUNDATION SERVER 2010“,
http://www.microsoft.com/germany/visualstudio/products/team/visual-studio-team-foundation-server.aspx (last view: Sep 2010)

[SE09-2] – sepp.med GmbH: „.mzT – modellzentriertes Testen – Mehr Effizienz bei Design & Spezifikation im Test“, http://www.seppmed.de/fileadmin/pdfs/metamethoden/Broschuere_mzT.pdf (last view: Sep 2010)

You have to be logged in to download the PDF document. Please log in or register. It only takes a minute!

nerd

Find Model Based Testing in your social network:

MBTsuite on Facebook
Model Based Testing on Twitter
Model Based Testing on XING