（この記事は、開発元Parasoft社 Blog 「Shift-Left Your Safety-Critical Software Testing with Test Automation」 の翻訳記事です。）
セーフティクリティカルなソフトウェアは、コストの危機に瀕しています。どういうことかと言うと、必要とされる機能の拡大が、その開発のための支払い能力を超えるものになっているのです。たとえばボーイング787プログラムでは、650万行のコードが必要でしたが、設計、開発、テストの費用は4,000,000,0000ドルでした。主要なセーフティクリティカルなプロジェクトの傾向を見ると、総コストが指数関数的に増加しており、ソフトウェアが総開発予算に占める割合は年々大きくなっています。次期の大規模な航空宇宙プログラムは、以前のプログラムで使用されていたのと同じ技術を使用するなら、とうてい支払いきれないコストがかかるでしょう。では、どうすればよいのでしょうか？
安全性の認証とそれに必要なテストおよび検証は、ソフトウェア開発予算の大きな部分を占めています。自動化を活用しながら、ソフトウェアのテストを左に（つまり、ソフトウェア開発ライフサイクルの早期に）シフトすると、コスト、リスク、およびスケジュールに大きな利益がもたらされます。下の図1は、民間航空会社のソフトウェア開発（ ボーイングとエアバスのデータ ）のコードの1000行あたりのコストを示しています。コストは明らかに指数関数的な増加を示しています。
バグが入り込んだ場所、発見された場所、およびコストに及ぼす影響
驚くことではありませんが、ほとんどの欠陥はプロジェクトの初期、それも最初のコード行が書かれる前に入り込みます。多くのバグはテスト中に見つかり、修正されますが、かなりの割合（20％も！）が運用中、つまり製品が販売され、出荷された後に発見されます。認証取得済みのシステムでは、これは非常にコストの高い修正－テスト－ 再認証というサイクル、またはオペレーターによる問題の回避を意味します。図2は、 ソフトウェア開発ライフサイクルの各段階で入り込んだバグ、検出されたバグの相対的な割合を示しています。
欠陥はライフサイクルの早い段階で修正するのが最も安価であり、プロジェクトが期間を経るにつれて、発見および修正のコストが指数関数的に増大します。運用中、つまり製品が顧客の手に渡った後に修正するのが、最もコストがかかります。デプロイメント後の不具合修正費用は控えめに見積もられたものであり、市場に出た後の安全上のインシデントによるブランドへの損害や負債は含まれていません。図3は、ライフサイクルの各段階で欠陥を修正するための相対コストを示しています。明らかに、欠陥の検出と修正をライフサイクルの初期段階に移動すること、つまり「シフトレフト」することが目指すべきゴールです。さらに、顧客にまで届く欠陥(現実としてあらゆるドメインで存在します）の数を減らすことが望ましいでしょう。
シフトレフトに際してのテスト自動化の役割
セーフティ クリティカルなソフトウェアの業界は、物事のやり方を変える必要性を認識しています。新しいソフトウェアの認証には時間と費用がかかります。新しく開発される製品では接続性と機能性がますます拡大しており、これは手法をを変える必要があることを意味しています。この記事では、提案されているすべての技術をカバーするのではなく、欠陥やセキュリティ脆弱性の削減、検出、修正をシフトレフトする際にテスト自動化が果たす役割を中心にとりあげます。
セーフティクリティカルなプロジェクトの大部分はテストであり、安全性、セキュリティ、および品質目標を達成するためには、自動化が絶対に必要です。テスト自動化ツールがどのように新しいソフトウェア開発方法をサポートし、テストとドキュメントの生産性を向上させるかについて、次に例を示します。
アジャイルおよび反復開発手法をサポート：ウォーターフォール手法の問題が認識されるようになり、多くのチームがより現代的な開発手法を採用して品質と安全性を向上させようとしています。反復開発手法では、モジュール、コンポーネントなどの新しいイテレーションごとにテストスイートが実行されるため、テストの自動化が重要です。テストの自動化は、テストを自動で繰り返し実行できるようにし、テストごとにさまざまなレベルでレポートを作成するほか、期間とともに蓄積されたテスト結果をレポートすることで、これらの開発手法ををサポートします。動的解析ツールは、検出が困難な実行時エラーを検出するために重要であり、静的解析はテスト開始前に欠陥を検出する上で重要な役割を果たします。
ソフトウェアインスペクションのサポート：開発ライフサイクルの早期に欠陥を除去するためのベストプラクティスの1つがインスペクションです。インスペクションとは、ソースコードだけでなく、あらゆるものをレビューすることを意味します。たとえば、システムの主要なバグの原因を防ぐには、要件と設計を調べることが重要です（図2参照）。多くのバグは文字通り設計としてシステムに作り込まれているのです。この段階では、ツールの役割は大きくありませんが、コードレビューの効果を高めることができます。自動化された単体テスト、動的エラー検出、および静的解析は、プロジェクトの初期コーディング段階において、エラー検出能力を大いに向上させます。自動テストの結果はコードレビュー時に表示できるため、手動によるエラー検出への依存が軽減され、要件や設計上の決定の誤りを検出するのにかけられる時間が長くなります。
テスト生産性の向上：手作業によるテストは面倒で繰り返しが困難です。収集された結果は一貫性がない場合があり、結果が「正しい」にもかかわらずエラーを見逃す可能性があります。プロジェクトの安全基準と重要性に基づいて必要なコードカバレッジを達成しているか追跡することは困難です。テスト自動化は、テストの面倒をなくし、再現性を向上させるだけでなく、高度なテストツールのレポート機能により、プロジェクトの状態に関する重要な管理情報を作成します。実行中のコードを分析して（トリッキーなランタイムエラーを検出する）動的分析と、実行前にコードを分析する静的分析を追加することで、テストツールのバグ検出機能が大幅に向上します。
コーディング標準への準拠の自動化：多くのセーフティクリティカルなプロジェクトでは、ソースコード標準が必要です。例えば、MISRAは自動車用ソフトウェアで一般的ですが、他の業界でも受け入れられています。一部の規格は、コードが特定の目標を満たす企業標準に準拠していることを要求します。いずれの場合も、手動でコーディングコンプライアンスを実施するのは面倒でエラーが発生しやすくなります。静的解析ツールは、コンプライアンスを強制するのに理想的であり、高度なツールは、フォーマット違反以外のエラーも検出できます。
認証用文書作成の自動化：ソフトウェア安全性の認証を達成するための作業負荷の大部分は、プロセス、妥当性確認、および検証を文書化することにあります。テストの自動化により、テスト結果とカバレッジ分析を文書化するコストが大幅に削減されます。
サードパーティ製ソフトウェアの再利用の促進：生産性を向上させるための重要な戦略の1つは、ソフトウェアを再利用することです。理想的な状況では、認証済みのコンポーネントを使用することで、サブユニットの開発コストを削減することができます。プロジェクトでは、COTS（市販品）ソフトウェアと、おそらくオープンソースやその他のソースコードを使用する必要があります。静的および動的分析ツールを使用してそのようなソフトウェアの評価を自動化すると、コンポーネントを使用する際のリスクが減少します。
品質、安全性、セキュリティの向上：厳格なテストを実施していても、重大なエラーが見落とされる場合があります。コードカバレッジだけでは、セキュリティ攻撃やマルチスレッドコードなどの場合に適切な動作を保証するには不十分です。静的解析ツールは、特定のテストを実行せずにソースコードのエラーを検出し、単体テストやシステムテストで発見しにくいセキュリティ脆弱性などのバグを見つけることができます。動的解析ツールは、テスト時にに実行中のコードでテスト結果に影響を与えるようなエラーを検出できる可能性があります（たとえば、少しずつ発生するメモリリークなど）。システムテスト時にファジングテストおよび侵入テストを行うと、通常の動作状態では見つからないバグを発見できることがあります。総合的には、最先端のツールによって欠陥やセキュリティ上の脆弱性をより多く発見すると、コスト、リスク、運用にまで持ち越される20％程度のバグのうちの多くを減らすのに役立ちます。
シフトレフトの影響
図2に明確に示されている問題を解決するために、何らかの対策が必要であることは明らかです。多くの欠陥がライフサイクルの始めに入り込み、製造されて顧客の手に渡った製品（場合によっては航空機や車に）残っています。新しい開発方法の採用、コンポーネントの再利用、COTSとオープンソースの活用、ツールの自動化はすべて、開発の生産性を向上させるための重要なステップです。
最先端のツールを使用した開発プロセスでは、ライフサイクルの早い段階で欠陥が検出されて修正され、単体テストは非常に効果的であり、運用に入り込むバグが少なくなります。図4は、ライフサイクル全体にわたる欠陥検出の変化の例を示しています。欠陥検出と修正の大部分がライフサイクルのより早い段階、つまり左側にシフトしているのがわかります。
上の図3から、開発の各段階を経るごとにコストが大幅に上昇することがわかりました。下の図5は、欠陥を修正するコストに関して、従来の方法と図4に示した改良された新しい方法の比較を示しています。当然ながら、バグを早期に見つけて修正するほうが、後で修正するよりもコストがかかりません。ここに提示されている状況では、全体的なコストの差は、シフトレフトアプローチのほうが約40％優れています。
認証済みツールチェーンと認証支援の重要性
セーフティ クリティカルなプロジェクトで自動ツールを使用するには、ツールそのものが信頼できなければなりません。ソフトウェアの作成に使用されるプロセスやツールが規格の要件を満たしていることを確認するのは、製品の製造元の責任です。ツールベンダーは、ツールを製造業者に販売する前に安全規格団体の認証を受けるか、そのような事前認証が不可能な場合には、認証支援を提供することによって、これを支援することができます。製造業者はツールベンダーの認証のエビデンスを自社の認証申請書に使用し、労力を軽減することができます（例えば、 Parasoft C / C ++testは、 TÜVSÜDの認定を受け、IEC 61508およびISO 26262規格に準拠した安全関連ソフトウェア開発の認定を受けています）。
DO-178BやDO-178Cなどのソフトウェア安全規格では、システムレベルで認証が行われ、個々のツールやソフトウェアは個別に認証されません。このような場合、ツールベンダーは、ドキュメンテーションやプロフェッショナルサービスに関して認証キットと支援を提供し、プロジェクトで使用するためのツールを適格にするために必要なコストと労力を大幅に削減します。
まとめ
セーフティ クリティカルなソフトウェアは間違いなくコストの危機にあります。新しい大規模なセーフティクリティカルなプロジェクトは、利益に見合わないほど開発のコストが高くなってきています。セーフティクリティカルなソフトウェアを開発する新しい方法が必要であり、ソフトウェア開発ライフサイクルの後半に発見されるエラーの数を減らさなければなりません。欠陥とセキュリティ脆弱性の検出および修正を可能な限りライフサイクルの早い段階に移行することは、コストを大幅に削減します。テストの自動化は、テストの効率と成果を向上させる役割を果たし、セーフティクリティカルなソフトウェア開発に対する新しいアプローチの重要な部分です。