Are you performing functional testing and facing these challenges?

• Does your product need to get to market faster?
• Does its complexity increase over the versions?
• Are your release cycles getting shorter?
• Need to reduce testing costs?

If you are facing any or all of these challenges, you are reading the right article!

In many conferences, forums and discussions, we hear a lot about new development practices and methodologies to solve these problems. But our testing challenges remain.

AGILE testing is a good thing, but it is not enough because it does not solve our problem of automating tests so that they can be done quickly enough. So how do you speed up the time to market for a product that is becoming increasingly complex and is under constant pressure to reduce costs? Continuing to use testing practices that are more than 20 years old is unlikely to be the solution.

In fact, test automation using record and playback is still manual testing . Reducing the test automation backlog is a good thing, but the reality is that you will never be able to code all your regression test scripts. You don’t have the time or budget to do it. So it’s not the solution.

If we start from this point, where is the problem? I often see people confusing the effectiveness or quality of tests with the number of tests. How many tests do you have? So what? Are you sure they cover all the cases? Based on your tests, do you know the real coverage of the functionality you are supposed to test? And if, as in many projects, you have hundreds or thousands of tests, do you know what each of these tests actually does? Do you have time to run all these tests? I think you get what I mean: it is not the number of tests that matters, but the quality and completeness of these tests.

When you create tests without a model of the system to be tested, the only way to judge the quality of your tests is the number of tests and maybe the coverage of the requirements. Today, testing with models brings a new dimension to testing and this new dimension is a new way to measure quality: functional coverage. Functional coverage gives you more information about what you are testing. You will not model the tests or test cases, but the functionality you want to test will be captured in a model. It is always better to describe a landscape by showing a picture rather than describing it with words. By graphically modeling your functionality, you will better understand the functionality to be tested, you will be able to automatically cover all aspects of your functionality and therefore you will get better tests. Let the test design tool describe this landscape for you! The tool that works this way will test functions that you did not see the first time or not at all due to the complexity of the application, especially negative paths.

Another time saver and quality improver, a test design tool that generates test cases directly from a model of the expected correct operation of the system also generates the test oracles, ie the expected results when executing the test cases. So, in the end, you will have more time to test and you will have more time to test your application more thoroughly and KNOW what you tested and why. As a test, this confidence is a lifesaver – or at least a sleep savior. But be careful, and I repeat, I am not talking about modeling tests but modeling the functionality to be tested. (If you want to know why, please follow this other article: « How Model-Based Testing Can Generate Tests I Can’t Think Of « ).

Additionally, models will help you stay on track with each release of your application. If something changes, you can quickly update your model and then update your tests and test scripts automatically by simply generating tests again. Second, between two releases of an application, you can evaluate your old test suite. What percentage of your functionality is covered by your current test suite? You will also be able to generate new tests to increase the coverage of your test suite and see which previous test cases become invalid due to the change in the operation of the system captured in the model. You manage the complexity every time you use and update your model. In other words, I recommend that you keep your knowledge in a graphical model. Your tool should generate test cases for you based on the modeled functionality and automatically update your test scripts and documentation so that you have an impact analysis. You will save a lot of time and certainly reduce costs and time to market.

Since the test design tool understands the entire operation of the system under test, it generates test cases that cover 100% of the operation of the system. This is very different from manually creating test cases or scenarios and achieving 100% coverage of what you originally wrote. What did you miss? You will only know when a user stumbles upon it after delivery. Hopefully, it will not be a critical bug.

In conclusion, good thousands test coverage does not mean hundreds and thousands of test cases, but good known test cases based on full functional coverage . So why not demand 100% functional coverage every time?

Read more at: www.conformiq.com/blog/

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