Every test manager probably dreams of a world where test scripts work the first time, where tests and test scripts are maintained automatically, and where our testing team spends its time finding flaws and digging deeper into the system rather than redoing the same tests over and over again because of changes in the specification. A dream where every test run results in a test report and provides immediate feedback on the application under test. Yes, it may be just a dream, but a new testing method can now help make this dream a reality.

Let’s see what embedded system designers do and how we could « maybe » learn from them in the field of testing. First, the development team receives requirements (the same ones our test team receives). Based on this, they start « coding » by specifying design patterns. The design pattern can be used and/or refined based on changes to the specifications, and can be used to « automatically » generate code for the target platform. This technical design is frequently used in the automotive industry and other application areas. This « automatic code generation » based on design patterns saves time in a world where
time to market is often the difference between success and failure
.

Now let’s look at testing today. Most companies still manually create tests (even in embedded systems development – ​​even in automotive) from specifications. But the hardest part is how to manage all the tests once the specifications have changed. How often does your specification change? For each change, testers will have to spend time identifying where in the specific tests that are impacted by that change, in order to perform maintenance. But testers are human, and when specifications change frequently and there are a lot of tests to review, it’s obvious that errors can happen. When all the changes are done, it’s time to update the automation. A long and important process starts when testers write a first test script, try to run it, modify it again and again, and at the end, they have something automated. If we are applying embedded systems design techniques here, why don’t we also use a model for testing and automatically generate documentation and test scripts from this model? This idea exists and is called Model Based Testing .

To differentiate an MBT model from a design model, a design model contains details and interactions with internal components, and considers architectural requirements that are not relevant from a black-box testing perspective. Test models are typically less complex than design models of the same system.

What I suggest you do is to create a model independently of the specification, based only on the functional requirements that are controllable and observable from the outside. The data exchange interfaces with your product or your interactions (like set, send, click, drag or get, check and verify) can be automatically imported into the tool . You just need to describe the functionality to be tested based on the requirements and the data you have. You can think of this MBT model as a picture (feature) of a landscape (your product). When your MBT model is finished, it is time to generate your test suite, based on the algorithms provided with the tool. Then, from the picture of this landscape, the tool will describe what it considers to be « tests » necessary to cover the given functionality.

In addition to generating tests, the tool also generates test scripts for your current test automation tool or test framework. With some test automation tools, it is even possible to reuse the data library for stimulation. In fact, in your model, you can use these library functions directly as keywords in the actions (inputs and outputs)! The tool then generates test scripts for you that are ready to be executed automatically. But let’s be honest, there are natural limits to automating test execution in general. But model-based testing can certainly help you increase your level of test automation, enable automatic test generation, and make your life easier. But it is still a tool.

In conclusion, there are some lessons that can be learned from embedded systems design techniques. These techniques are not research ideas – they have been successfully applied in industry for many years. So why not apply these techniques to testing? You can save time and allow the testing team to focus on exploring features rather than creating tests manually, converting those tests to test scripts manually, and updating the tests manually when specifications change. Why not use model-based testing and automating everything?

Read more on: https://www.conformiq.com/category/blogs/

Thanks for reading! Please feel free to share your comments with us!