この記事は、Software Engineering – Enterprise Networking の Principal Engineer である Marc Faggion によるブログ「Moving Towards a Culture of Systemic Software Quality at Cisco
」（2022/1/27）の抄訳です。
ソフトウェア開発に開発者やコンポーネントが多数関与する場合、ソフトウェアの品質を維持するためのツールと手法は、単なるコードとテスト用のものから進化させる必要があります。バグがまだ残っているのにリリースするようでは、フールプルーフのプロセスがないことは明らかです。では、開発からリリースまでのソフトウェアの品質を向上させるには何が必要でしょうか。
ソフトウェアの品質を維持するための重要な考慮事項をご紹介します。
単体試験の先を見据えた対策
バグ、つまりソフトウェアの不具合は、ソフトウェア エンジニアリングに必ず付いて回る問題です。小規模なプロジェクトの場合、コードを記述してテストを実行し、その結果判明したバグを修正して完了を宣言すれば十分です。テスト駆動開発（TDD）が好きな場合は、逆の手順も可能です。つまり、最初にテストを作成してから、テストに合格するコードを作成します。
どちらも単体試験のアプローチであり、テスト対象のユニットが仕様どおりの機能であるかを検証するために使えます。このテストをアーカイブしておけば、一連の回帰試験が始まり、ユニットに変更を加えてもユニットが当初の仕様どおりに機能するかどうかを検証できます。
強力な単体試験フレームワークを開発することはソフトウェア品質の基本の 1 つですが、それだけではソフトウェアの品質を保証するのに十分ではありません。この種のテストは、個々のユニットが正常に機能すればユニットの総体も正常に機能することを前提としています。また、ソフトウェアユニットの数が増えるにつれて管理して実行するテストの数も増え、場合によっては数千件にも達し、厄介な作業になるという問題もあります。
テストの連鎖
単体試験の次のレベルでは、機能とソリューションのテストに移ります。これらのテストは、機能しているシステムから始めて、エンドオペレータの観点でインターフェイスをテストします。自動化されたテストを用いて、構成の変更、さまざまなパケット、さまざまな接続システム、トポロジ、その他の要素をテストし、ソフトウェアが意図したとおりに動作することを確認します。これらのテストは、すでにテストしたものが機能することを確認するのには適していますが、ランタイムや関係するリソースが膨大になる可能性があります。半年前からテスト実行を予定する必要が生じることも珍しくなく、1 回のテストが完了するまでに 1 ～ 2 週間かかることもあります。
コード分析
ソフトウェアの品質のもう 1 つの側面は、ソフトウェアそのものです。ソフトウェアの不具合を減らすには、最初からコードを適切に記述する必要があります。担当の開発者には十分な専門スキルがあることを前提として、他の開発者によるコードレビューと静的分析による自動ツールの両方によってコードを検査します。どちらも重要ですが、コンテキストがわからないことがよく問題になります。静的分析ツールは、コードの客観的な問題を特定することしかできません。その水準を引き上げて言語とコーディングのエラーをなくすことはできますが、品質を確保するには、意味とコンテキストの詳細が必要です。
他の開発者によるコードレビューはとても有益であり、多くの問題を見つけることができます。しかし、用いられるすべての品質レビュー手法は、効率の点で最も差があります。優れたレビュアーは、自動化されたツールやテストでは見つけられない問題、相互作用、問題を掘り下げることができます。しかし、コードに不慣れなレビュアーは、スタイルガイドラインをチェックすることくらいしかできません。
高品質なソフトウェアの設計
品質の高いコードを作成するということは、機能に関するアイデアをコードに落とし込むということだけはありません。品質に関する問題は、コードを完璧に記述することで回避できるものもありますが、特定の環境では毎回必ずと言ってよいほどよく見られます。たとえば、C で記述する場合、C にはメモリ管理がないため、コードでメモリリークがよく発生します。他のプログラミング言語には自動ガベージコレクションがあり、リークがメモリ不足となって顕在化しても問題にはなりません。
ソフトウェアの品質を設計するには、一般的なアプローチが 2 つあります。
1 つ目のアプローチは、明示的なソフトウェア構造を導入し、それを使用するようにソフトウェアを移行するという伝統的な方法です。共通機能に標準ライブラリを導入することはシンプルなアプローチですが、アプリケーションコードを機能のコア部分だけにフォーカスするようにしてフレームワーク全体を開発するため、このアプローチは非常に大規模になる可能性があります。これに対する対策としては、コード書き換えツールを使用して既存のアプリケーションを新しいインフラストラクチャに移行することです。
2 つ目のアプローチは、Cisco IOS XE 開発チームが過去 5 年間にわたって実験してきたアプローチで、コードを変更せずにアプリケーションコードの下に構造的な変更を挿入します。つまり、コードがコンパイラを使用する必要がある共通ポイントをインストゥルメント化して、コードベース全体にインフラストラクチャの変更を追加します。そのメリットは、大量のコードを別のランタイムに変更できることです。デメリットとしては、多くの場合、アプリケーションコードは基盤となるランタイムを認識していないため、予想外の動作を引き起こす可能性があることです。これらはコンパイラによってインストゥルメント化された変更であるため、たいていはアセンブラコードが C コードと一致しないことが関係して予想外のことが起こります。
品質フレームワーク
これらのさまざまな品質対策はすべて、品質のスイスチーズモデルに似たプロセスになります（図 1）。すべてのレイヤーで問題を捕捉できない場合にのみ、問題はすり抜けて現場に到達します。
図 1：ソフトウェアの問題の顕在化の有無を表すスイスチーズモデル
プロセスは偶然によってこのように進化しているため、システムには継続的な改善が必要です。さまざまな観点から品質を保証するために、レイヤーを追加する必要があります。複数のレイヤーで同じテストが実行されないように、テストレイヤー間の効率も改善する必要があります。最後に、エンジニアは問題を正確に診断して修正できるように、レイヤー間の相互作用を把握する必要があります。
品質の高いソフトウェアを市場に送り出すためのプロセスは日々進化しています。Cisco IOS XE 開発者は、単体試験、機能テスト、ソリューションテストから、人間によるコードレビュー、静的分析ツール、品質設計フレームワークまで、幅広い作業をカバーするプロセスを構築することで、世界中の企業ネットワークを高い信頼性で運用できるソフトウェアを提供できます。
Cisco IOS XE 開発者チームによるその他の最新ブログもぜひご覧ください。
OpenConfig でマルチベンダーネットワーク管理の複雑さを解決 – シスコブログ
Cisco Catalyst 9000 ソフトウェア品質の考え方 – シスコブログ
エンタープライズデバイスの強化されたプログラムによる管理へようこそ – シスコブログ
高速化と簡素化 – 新しいソフトウェアイメージのアップグレードとパッチ適用ソリューションの設計における指針
シスコ ネットワーキングの動画チャネルをチェック
Authors
