Getting testy with your design: Model-based testing
Unless you've been living under a mountain of textual specification and source code, you've likely heard of either model-based systems engineering (MBSE) or model-driven development (MDD). The results that I have seen, as a result of implementing these capabilities, have been remarkable. One engineer told me that he had been asked to try to measure the ROI (return on investment) of MBSE. He had responded that it did not matter what the ROI was; he could not do his job without it.
The response from this engineer is not entirely unique. As the complexity of these systems continues to grow, the need for these methods grows as well. The net result of the application of MBSE and MDD is an improved ability to manage the complexity and meet time-to-market requirements while continuing to maintain product quality.
I get that, but model-based what?
Moving forward with the understanding that modeling is critical to success, it stands to reason that a similar capability for testing would be an improvement over other, more manual, methods. To that end, with the unveiling of the Unified Modeling Language (UML), the development of the UML Testing Profile (UTP) soon followed. There are a number of key concepts that make up the UTP, which I will not cover here, but you can watch my webinar on this same topic for a run-down on these.
Still, a bit more background is probably in order. The Unified Modeling Language is a standardized object-oriented graphical notation, maintained by the Object Management Group (OMG). The UML provides architectural, behavioral and communication constructs and views that are used to provide a graphical specification for software and, in the case of some solution providers (IBM for one), can even form the basis for code-generation.
As it turns out, code-generation can be leveraged for testing as well. After all, you can't test what you can't execute. This means that only after I have an executable model can I effectively test it! This is where the UTP comes in. In model-based testing, the tests are derived from a model that specifies structural and functional characteristics.
Model-based testing enables the following:
· Early and repeated testing
· Earlier detection and repair of bugs
· A higher degree of automation
· Parallel development and testing of embedded software
· Compliance with safety standards like ISO DIS 26262, DO-178B/C and more
With model-based testing, it is easier to cross-link the requirements, model, code and test data, which in turn makes it easier to trace and synchronize these different elements continuously. This helps to ensure that the test is accurate and complete.
Another thing to note is that test cases are captured using UML, so they are visual. The visual nature of these representations helps to facilitate understanding between the test engineer and the systems and software engineer.
Sounds great! Where can I get some model-based testing?
Fortunately, IBM has put some effort into providing model-based testing capabilities. As part of the IBM
By colocating the design and corresponding test artifacts, traceability and automation is made easier. TestConductor allows the automatic creation of a test architecture based on the specified design.
As you can see in the following screen capture, TestConductor also enables automated reporting of test results including:
· Requirement to test coverage tables
· Test coverage results
· Complete test results in the reports
Finally, TestConductor supports host-based and target-based execution of the tests. This means that the same test cases created early in the test cycle can be re-used for hard
Is there anything else I should know?
I have only scratched the surface in this blog post. I am happy to continue the conversation on Twitter @r_felice. The OMG is a good source for information on the UTP and for more on IBM Rational Rhapsody and TestConductor, check out the product website.