Shift Left Your Safety-Critical Software Testing With Test Automation

We are in a cost crisis with safety-critical software, which means that the increased functionality required has grown beyond the ability to pay for its development. The Boeing 787 program, for example, required 6.5 million lines of code, which cost $4,000,000,0000 to design, develop, and test. The trend in major safety-critical projects shows exponential growth in total costs, with software being a larger portion of the total development budget year-over-year. The next big aerospace program will likely be unaffordable using the same techniques used in previous programs. So what can we do?

Safety certification and the required test and verification required is a large portion of the software development budget. Shift-left testing of software (i.e. earlier in the software development lifecycle) while leveraging automation pays big dividends in cost, risk, and schedule. Figure 1 below shows the cost in millions of dollars per thousand lines of code for commercial airline software development (Boeing and Airbus data), which clearly shows the exponential increase.

Figure 1: Cost of software development per lines of code in commercial aviation projects. Data taken from Airbus and Boeing project metrics.

Where Bugs are Created and Found, and the Impact on Cost

Unsurprisingly, most defects are introduced into a project at the beginning, even before the first line of code is written. Most bugs are found and fixed during testing, but a good percentage (as much as 20%!) are discovered during operation, after the product has been sold and shipped. In certified systems, this either means an extremely expensive fix-test-re-certify cycle or operator workarounds for the problem. Figure 2 shows the relative percentage of bugs introduced and detected over each phase of the software development lifecycle.

Figure 2: Graph showing the percentage of defects introduced and detected during different phases of development.

Defects are cheapest to fix early in the lifecycle, and they become exponentially more expensive to find and fix over the length of the project. In operation, after a product has shipped into customer’s hands, it is the most expensive to fix. The post-deployment defect fix costs are conservative and don’t include damage to your brand and liability from safety incidents in the field. Figure 3 shows the relative cost to fix a defect at each stage of the lifecycle. Clearly, the goal is to move the defects detected and fixed to earlier in the lifecycle, in other words, to “shift left.” In addition, it’s desirable to reduce the number of defects making it through to the customer (a reality in every domain).

Figure 3: Relative cost to find and fix bugs during each development phase. During requirements and design is the baseline (1x) and the least costly place to fix defects. Source for Figures 2 and 3: SAVI Presentation to 2012 INCOSE SE Conference.

The Role of Test Automation in Shift-Left

The safety-critical software industry recognizes the need to change the way things are done. Too many projects are reinventing the wheel, and certifying brand new software is time-consuming and expensive. The growth in connectivity and functionality of new products means methods need to change. In this post, we won’t cover all of the techniques being proposed, but rather concentrate on the role that test automation plays in shifting left the reduction, detection, and fixing of defects and security vulnerabilities.

A huge part of any safety-critical project is testing, and automation is absolutely necessary to achieve safety, security, and quality goals. Here is an example of the ways in which testing automation tools are supporting new software development methods and increasing testing and documentation productivity:

Supporting Agile and Iterative Development Methods: The problems with the waterfall method are understood and many teams are using more modern development methods to improve quality and safety. Test automation is an important part of any iterative development method, since test suites are run on each new iteration of a module, component, etc. Test automation supports these methods with repeatable automated tests, providing reporting at various levels for each test but also accumulative results over time. Dynamic analysis tools are critical to detecting runtime errors that are difficult to detect, and static analysis plays an important role in detecting defects before testing starts.

Supporting Software Inspections: One of the best practices to remove defects early in the development lifecycle is inspections. Inspections mean reviewing everything, not just source code. For example, inspecting requirements and design is critical in preventing the leading source of bugs in the system (see Figure 2). Many bugs are literally designed into the system. Tools play a lesser role at this stage, but do enhance the effectives of code reviews. Automated unit testing, dynamic error detection, and static analysis provide greatly-improved error detection in the early coding stages of a project. The results of automated testing can be presented in code reviews, thus decreasing the dependence on manual error detection and allowing more time for detecting incorrect requirements and design decisions. 

Increasing Testing Productivity: Manual testing is tedious and less repeatable. Results collection can be ad hoc and error can be missed despite “correct” results. Achieving required code coverage, which varies based on safety standard and criticality of the project, is difficult to track. Test automation not only makes testing much less tedious and repeatable, but the reporting capabilities of advanced testing tools create important management information on the state of the project. Adding dynamic analysis, which analyzes the code when it’s running (to detect tricky runtime errors), and static analysis, which analyzes the code before it’s run, greatly increases the bug detection capability of test tools.

Automating Coding Standard Compliance: Many safety-critical projects require source code standards. MISRA, for example, is common in automotive software but has gained acceptance in other industries. Some standards require that code comply to a company standard that meets certain goals. In each case, manually enforcing coding compliance is tedious and error prone. Static analysis tools are ideal for enforcing compliance and advanced tools go further by detecting errors that are beyond format violations.

Automating Certification Documentation: A large portion of the workload in achieving software safety certifications is in documenting processes, validation, and verification. Test automation decreases the cost of documenting test results and coverage analysis significantly. 

Accelerating Re-Use of Third Party Software: A key strategy to increasing productivity is to re-use software. Ideally, already-certified components can be used to reduce the development costs for these subunits. Projects need to make use of COTS (commercial off the shelf) software and possibly open source and other source code. Automating the evaluation of this software with static and dynamic analysis tools decreases the risk of using these components.

Improving Quality, Safety, and Security: Even strict testing regimens can miss critical errors. Code coverage alone is not enough to ensure proper behavior in the case of security attacks or multithreaded code, for example. Static analysis tools can detect errors in source code without running a specific test and can find bugs such as security vulnerabilities that are hard to discover in unit or system testing. Dynamic analysis tools can detect errors in running code during tests that might be reflected in test results (e.g. a slow memory leak). Fuzzing and penetration testing during system testing can find bugs missed during normal operating conditions. In totality, the additional defects and security vulnerabilities found by state-of-the-art tools help reduce cost, risk, and many of the 20% or so bugs that make it into production.

What affect does shift-left have?

It’s clear that something must be done about solving the issues so clearly shown in Figure 2. Too many defects are being introduced, and staying undetected, in the beginning of the lifecycle, and too many are being left in the product when it is manufactured and in customers’ hands (or in planes or cars as the case may be). Adopting new development methods, reusing components, leveraging COTS and open source, and tool automation are all key steps to improving development productivity.

Assuming a development process using state-of-the-art tools, where more defects are detected and fixed earlier in the lifecycle, unit testing is extremely effective, helping fewer bugs make it through to production. In Figure 4, a hypothetical example shows the change in defect detection over the lifecycle – where the bulk of defect detection and fixing is shifted to the left, earlier in the lifecycle.

Figure 4: A graph showing an improved development process that shifts the detection of bugs and security vulnerabilities earlier in the lifecycle.

We know from Figure 3 above that costs rise significantly at each phases of development. Figure 5 below shows the comparison of costs to fix defects in the traditional method versus the new, improved, method shown in in Figure 4. Finding and fixing bugs earlier, unsurprisingly, costs less than fixing them later. In the situation presented here, the overall cost difference is about 40% in favor of the shift-left approach.

Figure 5: A graph showing the relative cost to fix bugs in the traditional approach versus the shift left approach. Even with the same number of total defects, early detection reduces costs significantly.

The Importance of Certified Tool Chains and Qualification Assistance

Using automated tools in safety-critical projects required trust in the tools themselves. The onus is on the manufacturer of the product to have confidence that the processes and tools used to create the software meet the requirements of the standard. Tool vendors can help with this by having tools certified by safety standards bodies before sale to the manufacturers or, in cases where no such pre-certification is possible, provide qualification assistance. They can then use the tool vendor’s certification evidence in their own submission for certification and reduce the effort needed. (For example, Parasoft C/C++test has been certified by TÜV SÜD to be qualified for safety-related software development according to IEC 61508 and ISO 26262 standards.)

In some software safety standards, such as DO-178B and DO-178C, certification is done on a system level and individual tools and software aren’t certified independently. In these cases, the tools vendor provides qualification kits and assistance in terms of documentation and professional services, greatly reducing the cost and effort needed to qualify the tools for use on the project.

Conclusion

Safety-critical software is certainly in a cost crisis. New, large safety-critical projects are becoming too expensive to develop, to the point that they may not be profitable. New methods are needed to develop safety-critical software, and that effort must reduce the number of errors found late in the software development lifecycle. Shifting the detection and fixing of defects and security vulnerabilities to as early in the lifecycle as possible reduces costs significantly. Test automation plays a role in improving test efficiency and outcomes and is an important part of a new approach to safety-critical software development.

“MISRA”, “MISRA C” and the triangle logo are registered trademarks of The MISRA Consortium Limited. ©The MISRA Consortium Limited, 2021. All rights reserved.