Test automation – efficiency and quality in medical software development
Nowadays, medical software in particular has to meet increasingly stringent requirements: Performance and efficiency due to constantly increasing data volumes, compliance with legal requirements regarding the highest security standards and data protection and, last but not least, the increasing expectations of users regarding usability and functionality.
This variety of goals leads to a high complexity of the software, which is hardly manageable without suitable tools. Apart from that, an important point is traceability. All risks and errors discovered in tests must be traceable, documented and verifiable – especially if the project is subject to the requirements of ISO 62304.
For this reason, extensive test automations have long been indispensable in medical software development.
What can test automation accomplish?
Automated tests allow frequent repetition of existing tests and thus confirmation that the behavior of already implemented software does not change. A faulty release can thus be prevented without human intervention by defining a successful test run as a necessary condition in the process.
Even more importantly, however, developers can run the tests repeatedly during implementation. In this way, they can detect errors during implementation and correct them. If this were to become apparent only a few months later, during use, this could have devastating consequences, especially if the product is a medical device. Significant additional effort would be required to investigate the earlier adjustments and identify the root cause. By running development and testing in parallel in this way, not only is software quality increased, but the process is also significantly accelerated.
The strategy of test automation and how much automation is possible at all depends on the project. Depending on the scope, a concept is developed on which the automation is based and describes the test architecture.
Good to know
IEC 62304 requires regression testing. This is necessary to determine that changes to system components have not affected their functionality, reliability and performance. Regression tests must already be carried out as part of the integration test as well as for even the smallest changes in the software. Vendors must also justify not re-running all regression tests after a change.
Would you like to learn more about how you can use the IEC 62304 standard in an agile manner in the development process? Click here for our detailed article.
The test pyramid
The lower segment of the pyramid usually contains unit tests or automated test procedures for individual, well-defined components of the software. At this level, the input and output of the components to be tested are usually manageably complex, but numerous. They thus form the basis on which all further levels are built.
The next level of the pyramid, after Mike Cohn also service level mentioned, uses the functions of the basis, in order to generate meaningful output. In contrast to the atomic processes of the base (e.g. comparison of measured values or creation of new entries), complete processes are generated here, such as the return of all key data of a temperature measurement. This means that the return of a service is very formal, but can be understood by a human.
Services are more difficult to test because they often depend on the data status and not all eventualities can be predicted with certainty here. In addition, since services use the same functionalities that are already covered by unit tests, duplications potentially arise here. An example would be that numbers are formatted as degrees Celsius, which is a base function. Since the service tests all potentially contain one or more measurement specifications, one test for each case would not create any additional security here, but would have to revise not only the base test but also all service tests if the representation were adapted.
In the third level, which primarily represents the presentation of information and the input mask (GUI), it makes sense to reduce the tests. In contrast to the strongly linear processes of the basic functions, user interfaces are much more complex, since inputs can be entered independently with much more freedom. However, tests at this level can only run defined processes and should therefore only be used for the most important and known (or assumed) processes.
One-time test effort, permanently reduced development effort?
Test automations reduce effort and errors, but they are not a one-time investment, but an integral part of the development: If the software changes, the tests change as well. Compared to manual tests, “operational blindness” is actively prevented here through automation and the test process becomes less error-prone. However, since they can never cover all complex cases, they must be seen as a supplement to manual tests, because they can only check what they were written for.
Similarly, depending on the general conditions of the project, the timing for introducing the tests must be adjusted. In the initial phase of software projects, where many changes and adaptations are still to be expected, it makes more sense to use test automations at a later stage. On the other hand, in projects that already have very strict requirements at the beginning, it may even make sense to write the tests first and then the code in this way. This allows the tests to run successfully bit by bit; this approach is called test-driven design.
Test automation – the human factor is also a decisive factor
Software developers play a decisive role in test automation, because test scripts can also contain errors. This means that test automations are only as good as the people who programmed them. The systems are usually not based on AI or self-learning algorithms, but on data that developers have created themselves or taken from an existing system. Acceptance with detailed testing by the developers and the clients is still essential for quality control.
Performance and regression
In addition to the requirement to publish software that is as error-free as possible, tests can also fulfill other requirements. Regression tests, for example, are explicitly created to check existing functionalities for new errors.
Performance tests, on the other hand, can demonstrate improvements in application speed with defined and constant data volumes.
The greatest benefit of test automation for companies is the reduction of the overall development effort. Braking bug searches are prevented at an early stage, and at the same time tests are a prerequisite for a clear code base. Poorly readable code is the main cause for unintentional and hard to find bugs. Furthermore, reliable software promotes trust in a company and offers users a secure and functional application.
Our simple solution for the documentation of your test automations
With all measures regarding tests, it is important to carry out the documentation properly. Automated tests have the clear advantage that they can be integrated into digitalized work processes via APIs.
Products like BAYOOSOFT Risk Manager allow you to synchronize tests between ticket system and technical documentation using the Requirements Engineering module. This way, every test run and its result can later be found again in the documentation without any additional effort.
Get to know us
Would you like to test the BAYOOSOFT Risk Manager for free? Then use our free TRIAL for 30 days.
Or visit an online product presentation and get to know BAYOOSOFT Risk Manager directly on the system.
News
Contacts at BAYOOSOFT
Svenja Winkler
CEO
[email protected]
Franziska Weiß
Head of Sales [email protected]
