Test levels

The Agile software development approach has replaced the traditional testing strategy based on product risk analysis with the delivery of test effort based on sprint impact. As a result, (automated) tests are often focused on a small piece of functionality with the smallest result being the unit test. However, these tests can hardly ever be used as building blocks for functional tests.

No more duplicated testing between test levels

With MTA’s test capabilities we break this impasse, because the principle behind MTA is based on a building block approach. Unit tests form the basis for component tests which in turn are aggregated into process tests. Because you can configure multiple applications simultaneously in an MTA test configuration, you can define process tests even across multiple microservices (applications).

Shift left testing shifts testing activities to the beginning of the development process. This provides great effectiveness and cost savings because errors are discovered early. MTA focuses on the discovery of functional and integration errors. MTA supports shift left test capabilities by:

• capturing test designs during the requirements gathering (plan phase)
• converting the designs with MTA to test automation (create phase)
• executing the tests on the development environment of the Mendix business engineer (verify)

Testing techniques focus on identifying and capturing test conditions, test cases, and test data. MTA supports a number of standard testing techniques:

• White box testing uses as its test base, among others, the internal structure of the code (read: Mendix models). Because MTA relies on these Mendix models, the results of white box testing can be implemented one-to-one as test cases.
• Black box testing is based on testing inputs and outputs of the test object without reference to the internal structure. In MTA, such test cases can be defined as manual tests. The results of techniques such as equivalence partitioning, boundary value analysis, and state transition testing can be captured in MTA through asserts, data variation, and microflow calling where detailed test cases can be built as stubs if necessary.
• Experience-based testing takes the experience of developers, testers, and users as its test base. This includes error guessing, exploratory testing and checklist-based testing. For exploratory testing, screen-based testing tools are generally simpler. The true power of MTA lies more in automating tests based on checklists or expected errors.