Model-based testing is a promising area of software testing. Many types of research are going on it. Due to many open source and commercial tools, it is now a viable option for industrial testing.
In Traditional testing, test cases are being created with experience rather than a systematic approach. As a consequence, many redundant test cases exist and many aspects of areas are untested. Many times the test cases/test scripts need higher maintenance.
The objectives of model based testing are
- Reduce testing expenses
- Explore effective ways of testing
- Improve test coverage
- In model based testing the tool guarantees test cases automatically with great effectiveness.
- Automatic generation and LTS a file from the dynamic GUI model.
Issues that drive MBT:
- Which kind of modal notation can be used for deriving the test cases.
- Unified modeling language(UML) are not formal enough to completely generate automation test cases.
- Formal finite state machines are large, complex and difficult to apply.
- A tradeoff between formalization and practical suitability needs to be formed.
- Which modeling and test case generation framework is better, easily available and how must useable?
- How efficient is test automation in terms of reducing test costs and how efficient is it in assuring the high product quality?
- How effective are the test cases in detecting the defects?
One best approach is to use models in different environments, maybe one where we need to start from scratch. Domain-specific tools are easier to use than generic ones as they have been designed with domain knowledge.
Details of Model Based Testing
MBT and TCG are implemented by the tool IDATG- integrating design and automatic test case generation. It has been developed since 1997 by Siemens.
Overtime it has become big and now available commercial easily integrates with STEMPPO.
Testability issues should be considered at an early stage. All test objects have to be provided with appropriate interfaces that allow automated test tools to identify them send commands and verify the result.
Design for the test is often neglected area in the software arena, in the hardware area, it is still acceptable to some extent.The creation of the test model requires a huge effort. If only a few cycles of testing is planned recreation Mein not give you much ROI.
The creation of the test model requires advanced skill and should be done by experts or experienced test analysts.
IDATG has a random testing technique. It is good to have feature for any software testing. Random testing can be a part of regression but regular systematic testing should not be omitted.
In model-based testing, the tool generate test cases automatically with great effectiveness.
The workflow of the IDATG:
Use case tasks that represent typical user scenarios or any other test scenarios that might be of interest.
Building blocks that represent frequently used sequences of test apps and can be used as part of a use case task. Similarly to functions in a programming language building blocks can be parameterized.
The task flow model of a task or building block is a directed graph that shows the associated sequence steps.
If there is more than one possible ways to fulfill the task the graph has multiple paths.
The steps of a task flow model may represent atomic action or refer to a building block that may have several steps. In this way a complex flow can be viewed in a very simple way.
IDATG generates valid test cases are based on the task flows and semantic condition defined by the user. The testcase includes the expected results and steps to check them against the actual results.
The user can then go deeper into testing adjusting and choosing between several coverage criterias. Once the test case are generated those can be exported to different format like XML QTP, TestPartner SilkTest winrunner or a plain text.
They are in the executable format.Strict entry and exit criteria needs to be maintained for components functions scripts. Efficient testing can only take place if and only if the components reach to quality.
Test data in Model based Testing
Apart from test sequence, it is also very important to define the input data that should be used for the test. We need to cover an optimum number of data combination to test the components.
But automation cannot really cover all type of combinations. IDATG provides many features to determine the input test data.
CECIL- cause effect coverage incorporating liner boundaries is a good method to find test data.
Cause effect multidimensional equivalent class and boundary values methods can be taken into consideration.
Avoid jargon in MDT- Model Driven Testing
MDT should be compliance with international software testing qualification board that is ISTQB standard terminology. Avoid using the some terms with different meaning.
ROI in MDT- Model Driven Testing
Calculation of ROI (return of investment ) is important to do but does not need to be exact or complete or to be useful and valid. It is important to start with limited set of tests ones that will give real value when automatad.
Manual cost in MDT-
Manual test effort= test case creation + test case execution* number of cycle+ maintenance
Automation cost in MDT-
Automation test effort=Creation of test cases+ test case execution* number of cycle + maintenance
Creating a test model required detailed design documents. But documentation often provided short note in details. Involvement of the test team in early reviews can help to mitigate this issue.
Testability issues should be considered at an early stage all test objects have to be provide appropriate interfaces that allow automated test tools to identify them send and verify results.
Design for test is often neglected area in software in hardware it is still acceptable. The creation of the test model requires huge effort if only few cycles of testing is planned regression may not give you much ROI.
Creation of the test model requires advanced skill and should be done by experts for experienced test analyst.
IDATG has a random testing technique. it is a good to have feature for any software testing.random testing can be a part of Regression. We need to remember we can not neglect the regular systematic testing.
Other tools for MBT(Model Based Testing)
LTSA file is similar to event flow graph (EFG)- that includes all possible GUI states and transitions of the states.
Benefits of Model-Based testing
The main benefit of model-based testing is the ability to automate the test design phase and ease in the test maintenance phase.
Challenges of Model-Based testing
Model-based testing requires good tool to support. It also requires required skills to implement.