第74号：現場レポート ～ 検証プロセス編 ～

先日、短納期大型案件にテストチームとして参加しました。
今回はその際の活動を検証(VER)の固有プラクティスにマッピングしてご紹介したいと思います。とりわけ革新的な取り組みを行っているわけではありませんが現場で自然にVERを実践できたひとつの事例としてご覧頂ければと思います。
REQM SP1.4のトレーサビリティを自然に活用できたことなど、活動の中で個人的に気づいた点などもご紹介したいと思います。

●VER SP 1.1 検証の対象となる作業成果物を選択する
テストチームとしての検証対象は機能単位のプログラムでした。
機能を構成する個々のプログラムに対する単体テストは開発者が実施し、結合テスト、システムテストは要件や機能間のI/Fに精通した要件定義、基本設計を担当したメンバが実施します。
テストチームでは基本設計に照らしてブラックボックスで検証し、テストチームの検証後は基本設計書とプログラムの実装の整合性を保証します。

●VER SP 1.2 検証環境を確立する
検証環境は開発環境とは独立した環境を用意しました。
日々最新の成果物を構成管理ツールより取得し、検証環境へ配置、ビルドを行うことで、設定関連のスクリプトの作成漏れ等を予防することも狙いとしています。

●VER SP 1.3 検証の手順と基準を確立する
テスト計画書にて、テスト仕様書に基づいた確認の仕方、記録の残し方、障害検出時の対応の仕方などを手順としてまとめました。
検証の基準としてはテスト仕様書の期待結果が該当します。
客観的に適合/不適合が判断できなければ基準として機能しないため、当たり前のことですが、テスト仕様の期待結果の記述として「～が正しいこと」はNGワードとして徹底しています。
テスト仕様を作成する際のインプットは基本設計書です。
複数機能に共通する仕様（要件）はテスト仕様の流用が可能なので、トレーサビリティマトリックスを活用することで、漏れなく効率的に統一されたテスト仕様を作成することができました。
また、基本設計書のどの記載に対して、どのようにテスト仕様を記述するかを決めていたため、基本設計とテスト仕様の間も追跡可能となり、テスト実施担当者には、「設計のどの部分に対するテストなのかが分かりやすい」と評判でした。

--テスト仕様のレビュー等ありますが、テストがメインのため省略します。----
●VER SP 2.1 ピアレビューの準備をする
●VER SP 2.2 ピアレビューを実施する
●VER SP 2.3 ピアレビューのデータを分析する
------------------------------------------------------------------------

●VER SP 3.1 検証を実施する
検証を実施して障害を起票すると、開発者から「ここは基本設計書が間違っていてプログラムの動作は正しい」と報告されることがありました。
どういう経緯で間違った設計から正しいプログラムが生まれるのか、という話はとりあえず置いておきます。
このような場合、プログラム障害とは別で管理してある、基本設計書の修正依頼を起票します。
「我々がテストした後に基本設計とプログラムの動作で不整合はあり得ない」という点に徹底的にこだわりました。

●VER SP 3.2 検証結果を分析する
テストが十分に実施され、障害が検出されているかを確認するためにフェーズの序盤でいくつかのサンプルデータを測定し、分析を行いました。
結果としては、テストケース数は基本設計書のページ数および、開発対象となるパブリックのメソッド数（新規・修正）との相関が強いことが分かりました。
検出される障害数はテストケース数とパブリックのメソッド数（新規のみ）と相関が強いことが分かりました。
これらに対して回帰分析を行い、その後のテスト実績の目安値を設定し、再テストの要否の判断などに使用しました。
あくまでプロジェクト内の実績のみでの判断なので、全体として品質が良いかという基準とはなりませんが、特に弱い機能などを狙って再テストできた点では、良かったのではないかと思います。

■活動を通じて気づいたこと
・VERを意識して実施することで、「何をすべきか」が分かるため、スムーズに 漏れなく進めることができた。
・テスト仕様の作成時にトレーサビリティマトリクスが役に立った。
・計画、手順等を文書化し、取り組みの目的を明確化していたため、活動の終了時に改善点を特定することが容易だった。
・開発チームとは独立してテストを実施する場合、障害の起票時に「おかしい」とか「間違っている」などの表現を使うとチームワークが悪くなる。
「設計と不整合」などの客観的な事実で表現すべき。
・測定のために障害の起票ルールをしっかり決めて説明しても、間違えるケースが意外と多い。測定データを使用するためには日々の活動のなかで測定結果を確認し、不正データを修正することが重要。
・機能によって、障害発生時の危害の程度は異なる。限られた資源制約の中で、最大のパフォーマンスを発揮するためには、規模に応じた品質の平均化だけではなく、リスクに基づいたメリハリのあるテストを実施すべきだったかもしれない。

CMMIを使用してプロセス改善を行っている方は、当然CMMIの実装がプロジェクトや組織の役に立つという信念のもと活動を実施されているかと思いますが、その反面で本当に役に立つのだろうかと不安をお持ちの方もいらっしゃるのではないでしょうか？
今回、テストチームという限られた範囲での経験でしたが、個人的な感想としてCMMIは非常役に立つツールでした。
「何をすべきか」を理解しておくと、私のような未熟者でも先手が打てますし、何より原因不明の不安に苛まれることなく精神衛生上、快適に仕事を進めることができます。
非常に個人的な感想でしたが、現場の声として今後も機会があればご報告させていただければと思います。