開発工程管理のポイント

3. 実装工程管理のポイント |

4. 試験工程管理のポイント

試験の内容を管理する

通信・ネットワークシステム開発の試験工程で最低限実現しなければならないことは、試験対象となっているものが設計工程で作成した外部仕様をきちんと満たしていることを保証することです。モジュール試験であれば試験対象のモジュールがモジュール外部仕様を保証する必要がありますし、ノード試験であればノード外部仕様を、そしてシステム試験であればシステムがシステム要求仕様を満たしていることを保証することになります。

図1. 試験工程で最低限保証すべきこと

試験工程で試験対象が外部仕様をきちんと満たすことを保証するためには、試験の内容が適切である必要があります。そのために試験の内容を管理する必要があるのですが、そのアプローチには定量的なアプローチと定性的なアプローチがあります。

定量的なアプローチでは、試験対象となっているシステムやソフトウェアの規模や性質から、統計データに基づいて妥当な試験項目の数を求めます。このアプローチは、システムやソフトウェアの規模が大きくなってもさほど手間をかけずに実施できる一方で、項目数の妥当性は評価できても項目ごとの試験内容の妥当性までは評価できないという限界もあります。したがって定量的なアプローチだけでは不十分で、通常は定性的なアプローチと組み合わせて利用されます。

定性的なアプローチでは、試験の具体的な中身を見ることで、試験計画が外部仕様として保証しなければならないことが網羅されるような計画になっているかをチェックします。通常の開発では、少なくとも試験担当チームの内部レビューというかたちでは行われていることでしょう。しかし、開発の発注者や全体の管理者が試験の具体的な中身を一つ一つ見ていくことは現実的ではありません。そのため、発注者や全体の管理者は、定量的アプローチでマクロな管理を行いつつ、リスクの高いところについては定性的アプローチでミクロな管理を行うということができればベストでしょう。

定量的管理定性的管理
管理内容 試験対象となっているシステムやソフトウェアの規模から、統計データに基づいて適切な試験項目の数を求める。 試験の具体的な中身を見ることで、試験計画が外部仕様として保証しなければならないことを網羅しているかを確認する。
メリット システムやソフトウェアの規模が大きくなっても管理の手間が大幅に増えるということはない。 具体的な試験内容にまで踏み込んだ妥当性の確認が行える。
デメリット 試験項目ごとの具体的な試験内容の妥当性までは行えない。 システムやソフトウェアの規模に比例して試験項目は増えていくため、開発の発注者や全体の管理者が全試験内容について定性的管理を行うことは現実的ではない。
備考 開発の規模と試験項目数に関する統計データを蓄積しておく必要がある。 リスクが高いところに絞って定性的管理を行うということも一つの方法である。

表1. 定量的管理と定性的管理

通信・ネットワークシステム開発の試験においては、異常系やバリエーションケースの確認が十分に行われるかどうかという点がリスクの高い部分です。通信・ネットワークシステムにおいては、本当に細かいものまで取り上げれば異常系やバリエーションケースのパターンが星の数ほど存在します。工数や工期に制約がある状況下では、それらの試験項目はしばしば絞り込みが行われます。この際には、絞り込みが妥当であるかどうかをチェックする必要があるでしょう。

この絞り込みについては具体的な例がないとなかなかイメージがつかめないかもしれませんので、ページ最後の[参考:異常系・バリエーション試験の絞り込みの例]で一例をご紹介します。

進捗状況を統計的に把握する

試験工程における進捗状況の把握は、設計工程や実装工程の進捗状況把握に比べればかなり容易に行えると言えるでしょう。というのも、試験を実施する前には試験計画書(試験仕様書と呼ばれることもある)を作り、どのような試験を行うのかを予めリストアップするからです。試験を行う際に試験項目のリストアップもしないような開発者は論外です。試験項目のリストアップができていれば、試験の進捗状況を「試験消化項目数」÷「全試験項目数」というかたちで管理することができます。

とはいえ、この割り算で出てくる試験消化率を数字そのままに解釈してもよいというわけではありません。例えば、試験の進捗が思いのほか早いという場合、素直に喜んでもよいとは限りません。試験が進んでいるにもかかわらずバグがほとんど出ていないということでしたら、その場合に考えられる可能性は二つあります。一つは、システムやソフトウェアの品質が始めから思いのほか良いという場合。これはとても嬉しいケースですが、滅多にお目にかかることはできない稀なケースでしょう。もう一つの方がありがちなケースで、計画された試験項目の質が低いために、バグが全然検出できてないというケースです。このケースでは計画された試験項目の消化は予定よりも早く終わりますが、試験は終わったにもかかわらずシステムやソフトウェアは多量のバグを抱えたまま・・・という状況に陥ります。そうなる前に、早めに試験項目の見直しを行うことをお勧めします。

試験項目の進捗状況を管理する際には、試験消化率の数字に加えてバグがどれくらい検出できているかについても注意してください。試験進捗状況とバグ検出状況の組み合わせからどのような状況が予想されるかについては、下の表に整理しました。

進捗状況バグ検出予想される状況
想定通り想定通り妥当に試験が行われていて、システム・ソフトウェアの品質も妥当である。
想定より早い想定より少ない試験項目の質が低く、バグが検出できていない。試験項目の見直しが求められる。(試験項目には問題がなく、システム・ソフトウェアの品質が並はずれて高いという可能性もあるが、非常に稀である)
想定より遅い想定通りまたは少ない単純に試験が遅れている状況であると考えられる。
想定通りまたは早い想定より多いバグが多く出ていても試験の進捗に影響を与えていないことから、些細なバグが多数出ている状況であると考えられる。多くの場合、深刻な状況ではない。
想定より遅い想定より多いバグが多く出て試験進捗が滞っており、システム・ソフトウェアが根深い深刻な問題を抱えている状況であると考えられる。

表2. 試験の進捗状況とバグ検出状況の組み合わせによる状況判断

参考:異常系・バリエーション試験の絞り込みの例

異常系やバリエーションケースの試験を妥当に絞り込むための方法としては、設計工程であらかじめ試験の絞り込み容易性を作り込んでおくという方法があります。これが唯一の方法ではありませんが、ご参考までにご紹介いたします。なお、この方法を取り入れるためには設計担当者と試験担当者の連携が必要ですので、開発の発注者・管理者の積極的な関与が望まれます。

一つの例として、あるプロトコルのメッセージ(通信パケット)を受信して、メッセージの内容に応じて何らかの動作を行う通信ノードがあるとします。そして、そのメッセージには100個のデータフィールドがあるとします。ここでこの通信ノードに関する試験計画を愚直に行うと、少なくとも100項目の「データフィールド不正」に関する試験項目が作られることになります。プロトコルに同様なメッセージが20種類あれば、「データフィールド不正」に関する試験項目は2,000項目になるでしょう。データフィールドの値を一つずつ不正な値にしながらパケットを送り付け、通信ノードの動作を確認する。この作業が2,000回繰り返されます。もちろん、2,000項目の試験を実施できることが望ましいことは言うまでもありません。しかし、実際の開発では工数や工期とのトレードオフになってしまうケースも多く見られます。

そういった場合には試験項目の絞り込みを行うことになりますが、設計工程で工夫をしておくことで品質リスクを最小限に抑えた絞り込みが行えるようになります。その方法について、下の図を参照しながら説明します。まず、通信ノードの外部仕様を設計する際に、データフィールドの値が不正なメッセージを受信した場合の動作を、できるだけどのデータフィールドが不正であるかによらず共通になるようにします。考え方としては、始めにデータフィールドが不正なメッセージを受信した際の共通動作(異常系動作ポリシー)を定義して、その後に例外処理が必要なケースのみ個別の動作を定義するとよいでしょう。

それを踏まえて、ソフトウェア設計の工程でも工夫を行います。メッセージの受信処理を行うモジュールから切り離すかたちで、データフィールド不正の検出のみを行うモジュールを作成します。このデータフィールド不正検出モジュールは、共通の動作を行うべきデータフィールド不正に対しては共通の結果コードを、個別の動作を行うべきデータフィールドに対しては個別の結果コードを返します。そして、メッセージ受信処理モジュールは、データフィールド不正検出モジュールから受け取る結果コードに応じて処理を切り替えるようにします。

図2. 試験の絞り込みを容易にするため設計

このような設計を行っておくと、品質上のリスクを抑えつつ、データフィールドの値が不正なメッセージを受信したケースの試験を次のように絞り込むことができます。まず、ノード試験で確認すべき項目は、共通の動作を行うケースが一つと個別の動作を行うケース全てとなります。共通の動作を行うケースを多くできればできるほど、試験項目を減らすことができます。では、共通の動作を行うケースのうちノード試験の項目に挙げられなかったケースはどうするかというと、データフィールド不正検出モジュールのモジュール試験で確認を行います。これらのケースすべてについてデータフィールド不正検出モジュールが共通の結果コードを出力することが確認できれば、その後の処理フローは同じになりますのでノード試験での確認は省略してもさほど品質上のリスクは高まらないと言えるでしょう。データフィールド不正検出モジュールのモジュール試験では全てのケースを試験することになりますが、これはノード試験で全てのケースを試験することに比べれば格段に少ない工数で済み、試験工程全体としての工数は大幅に削減することができます。

図3. どのように試験が絞り込まれるか

試験の絞り込み容易性を作り込む設計のポイントを整理すると、次のようになります。

  1. 外部仕様設計で可能な限り異常系の動作を共通にする。
  2. ソフトウェア設計で異常発生の検出のみを行うモジュールを作成する。
  3. 異常発生検出モジュールは、共通の動作を行うべき以上に対しては共通の結果コードを出力するような仕様とする。

このような設計を行うことで、全ての異常パターンを網羅するようなバリエーション試験を異常発生検出モジュールのモジュール試験のみに限定しても、品質上のリスクを高めずに済むようになるのです。

無料小冊子のお申込みはこちら

株式会社システム計画研究所のオフィシャルサイトはこちら

通信・ネットワークシステム開発に関するご相談はこちら

サーバ監視・ネットワーク監視ツール isNetSentry-S のサイトはこちら

信頼できるITシステムの開発と利用を支援する技術情報提供サイト「信頼のシステム開発.COM」はこちら