Automated Testing in the DevOps context
Automated tests make it possible to run tests at the touch of a button and automatically evaluate them. The variety of possibilities to develop automated tests is great. In the area of unit testing, for example, you use frameworks that provide an environment for creating and running the tests. During the test-driven development, the product code produced can be continuously tested from the beginning of the project. Sections or modules can be quickly identified as the cause of the error. The method can also be used for integration tests with increased abstraction effort.
Testing Strategy and Traceability in Medical Device Software Development
Within the framework of IEC 62304 or even more strongly in the FDA context, it should be borne in mind that a clean description of the software units (according to IEC 62304) and their interfaces is necessary. Traceability between the requirements description and the tests is desirable. In software system testing and overall system testing, it is difficult to find a ready-made solution similar to the Unittest frameworks. It is common to develop a product-specific conceptualised test environment. For this purpose, the external interfaces of the system are used to initiate actions and to check reactions. Thus, for example, a test script can be executed on a test computer in any script language which communicates via a gateway with the interfaces of one or more systems. For all test variants, it is important to start planning and implementing the tests early, because the test planning will influence the software architecture and vice versa.
Infrastructure for test automation
Not only does the development of tests lead to robust and stable software, but also the frequency of execution of those tests contributes to this.
Test automation makes it possible to start and evaluate tests at regular intervals. In this way, for example, computing capacities outside the typical working hours can be used to carry out test runs (so-called nightly-test runs). For this purpose, however, an infrastructure must first be created, which grows together with the project progress and the test complexity. This infrastructure can consist of IT, version management, test framework, test hardware, development and project management tools and any number of other components.
Test automation - What is DevOps?
DevOps, or development and operations, aims to increase the speed of development with increasing quality. DevOps is an approach that promotes collaboration between software development and IT operations. The objective is to accelerate software development and delivery, improve quality and increase efficiency. Through automation, continuous integration, and continuous deployment, teams can respond faster to change and deliver new features or updates. DevOps also fosters a culture of collaboration and shared sense of responsibility, resulting in better communication and smoother workflow.
Continuous Integration
Continuous Integration (CI) is a software development practice in which developers regularly (often several times a day) integrate their code into a common repository. The aim is to detect errors early on and improve the quality of the code. With each integration, the code is automatically tested to ensure that new changes do not interfere with existing features. This promotes faster development, as problems can be identified and resolved early on.
The point here is that a commit of a software change to the master (or trunk) is only made possible when all automated tests are passed without errors. This is the prerequisite for a Continuous Delivery (see below).
Continuous Delivery (CD)
Continuous Delivery (CD) is an extension of the continuous integration and also allows automation of the release process. CD ensures that the code is always in a ready-to-use state. This means having a complete system available at all times, which is available for testing. Continuous delivery includes automated testing and integrations that make it possible to quickly implement and review new features or bug fixes. The goal is to reduce the time between developing and deploying software to respond faster to customer feedback and continuously improve the software.
Continuous Deployment
After Continuous Delivery, the software is delivered continuously. This can also be applied within a project, for example to integrate a subcomponent into the overarching project. Often, all changes checked into the version control system are transmitted without further manual intervention into the live environment after the automatic test execution.
Validation
Software tools used in quality assurance must be validated.
FDA 21 CFR 820.70(i)
Automated processes. When computers or automated data processing systems are used as part of production or the quality system, the manufacturer shall validate computer software for its intended use according to an established protocol. All software changes shall be validated before approval and issuance. These validation activities and results shall be documented.
This means that the tools for DevOps (with Continuous Integration, Continuous Delivery and Continuous Deployment) including testing tools, revision management, storage and distribution of releases, etc. must be validated. If a re-verification (e.g. of the total release) takes place afterwards, a reduced validation can take place.
Software Development Plan
All tools used must be included in the software development plan according to IEC 62304:2006+A1:2015.
It is recommended to include the complete DevOps chain (workflow with Continuous Integration, Continuous Delivery and Continuous Deployment), i.e. all steps used to generate a release, in the software development plan.
Software Release
Software that has been generated and tested completely automatically as part of the Continuous deployment cannot be easily added to the production environment. Thus, further activities such as the creation of the list of unresolved anomalies, archiving, documentation of the completeness of the verification activities, documentation of the release, usability evaluation, release of the technical documentation, adjustments of user documentation, etc. are necessary in order to obtain the final release of a software. Only after that can the software be rolled out into the field. Thus, the classic Continuous deployment, such as for web applications for medical technology, is not possible. Only the Continuous Delivery is applicable, in which already tested software for other departments for further testing or testing. Evaluations of the software changes are provided.
Unser Newsletter „qonzentrat“
kompakt, professionell und präzise
Profitieren Sie von unserem Fachwissen.
Jetzt anmelden
