Array
(
)
Request demo

Avoid common pitfalls

Test automation brings a number of pitfalls that you should avoid.  In this page we mention a few that should be avoided as much as possible

Don’t use a test tool that cannot be maintained by the development team

Test automation is a domain of its own. There are many different tools, all based on different technologies. There is a good reason for that. The ideal test tool does not exist. Second best is a test tool that your development team can maintain, therefore always look for test tooling that:

  • Is written in the same language as the app you are testing
  • Can be maintained with the existing knowledge in your team
  • Has specific features that support the app/platform that you are testing.

Don’t try to test processes with a high coverage

Processes are the easiest to understand from an end user perspective. However, process testing with high coverage is an impossible task if you look  at the number of variations that can occur in a process. It is better to:

  • Rely on unit and component testing for testing the extreme scenario’s
  • Focus the process testing on happy flow and only cover the scenario’s with the highest risks
  • Use a product risk analysis to determine the processes that need testing

Don’t test without a plan and proper process

We know from experience that testing is often the last priority in a development team. Only a strict process and a plan that helps you to decide what and when to test will prevent you from waiting to long too start. Therefore it is best to:

  • Write a test plan as soon as you start building your app. Adapt the plan when necessary and don’t make it too detailed
  • Make sure that testing is part of your development process and include it in the “definition of done”
  • Reserve budget and capacity in your team for testing, right from the start of your project. A range of 10%-30% of your development budget should be spent on testing and other quality assurance activities.
Avoid pitfalls

Don’t build screens and API’s for testing purposes only

Although in Mendix is is relatively easy to build screens or API’s it is not a good idea to create screens and API’s just for test automation purposes because:

  • These test screens and API’s pollute your Mendix models and therefore your Mendix app will be more difficult to maintain
  • Test screens and API’s can be dangerous in production because they can cause security risks
  • It is expensive to maintain screens and API’s for test purposes only

Avoid a large testdebt

Mendix projects often start small. Because a Mendix team can create new functionality very fast it is possible to create so much functionality that a serious test debt is already present after a few months of development. Avoid this testdebt by:

  • Creating tests as soon as possible (as soon as the code becomes stable)
  • Invest in testing early. The later you start the less coverage you get for the same investment
  • Prevent refactoring of the code that is necessary for test automation purposes. It is easy to make code testable when first created. It can be painfully hard to make code testable once in production
Niels

Need an expert to help avoid pitfalls

Contact us and one of our experts will help you

Footer contact ENG

  • This field is for validation purposes and should be left unchanged.
  • Menditect
  • Databankweg 12G
  • 3821 AL Amersfoort
    The Netherlands
info@menditect.com
+3185 - 4010494
  KvK: 82975795
   
Volg ons op LinkedIn
Privacy statement End user licence agreement Service Level Agreement
Design & development: TeamCreative

Menu

Request a free demo directly

Enter your information and choose a day and time when you would like to receive the demo (1,5 hrs).