How Is It Possible For Companies To Increase Their Release-Frequency Without Impacting Quality And Security Negatively?

For software maintainability and extensibility, it is essential that the original program versions on which the new features are based are already “clean”. Therefore, it is highly reasonable to first invest the necessary amount of time here, to have a secure base on which later releases can build. These are the building blocks to long-term success. 

Thereby, static and dynamic testing methods should be employed. Both testing methods are complimentary. 

While dynamic analysis requires the code to be executed, this is not the case for static analysis. Therefore, static analysis tools can and should be used early in the development process in the implementation phase and therefore contribute massively to project success: because the earlier testing is done, the more favourable the troubleshooting.

Static code analysis tools check code for syntax, semantics, control flow and data flow anomalies, concurrency issues, and compliance with coding guidelines/standards. Static analysis tools uncover a wide range of bugs without writing test cases and identify security-threatening vulnerabilities. Likewise, static analysis tools take code metrics into account. These metrics give an indication of the so-called inner quality of software. These include maintainability, extensibility, analysability and testability of the software. In order to secure the software quality in the long term and to be able to increase the release frequency, paying attention to metrics makes is reasonable. 

Ideally, code should be analysed statically from the start of the development project onwards, at the best case by the single developer before checking in and then with the increasing integration of the modules. 

Today, good static analysis tools can be easily integrated into continuous integration and continuous delivery processes (CI/CD) and are important components for early testing in the development process (shift-left tests) and the integration of security into DevOps workflows.

It only makes sense to take the code to a further verification step such as code reviews, unit tests or integration tests when the static code analysis no longer indicates any errors. 

If the software is then ready to run at an advanced stage of the project, it makes sense to supplement the static analysis with dynamic tests. In the case of safety-critical software – i.e. software in which people could be harmed in the event of a problem – dynamic test procedures and proof of test coverage (i.e. code coverage) are mandatory for good reason. For example, DO-178C in aviation, ISO 26262 in automotive, EN 50128 in rail, and the general IEC 61508 standard require high levels of code coverage for software with high criticality, such as Modified Condition Decision Coverage (MC/DC), which demonstrates testing of all conditions or decisions in a piece of software. The code coverage shows exactly which tests are still missing, so that the tester can specifically initiate the missing tests. Redundant tests that cost additional time can also be avoided by analysing test coverage. 

Sufficient software testing and analysis is not an additional cost factor, but a key to project success that can be used to increase release frequency without sacrificing quality and security. Used correctly, tools for static and dynamic code analysis offer considerable potential for saving costs and increasing productivity.