PR

(2)実現方式

 実現方式とは、スクラッチ開発なのか、パッケージソフトを利用するのかといった、システムやプロダクトを実現・実装していく方式のことだ。実現方式によっても、テスト内容は変わってくる。

 パッケージソフトを利用するのであれば、パッケージソフトの機能をそのまま使う部分と、カスタマイズを加える部分では当然テスト内容が異なる。あまり深く考えないと、カスタマイズ部分は手厚く、パッケージソフトの機能をそのまま使う部分は手薄にとなりがちだ。ただ、本当にそれでよいのだろうか。

 パッケージソフトの機能のロジックにバグがないかどうかは、パッケージソフトベンダーが十分にテストをしているはずだ。しかし、だからテストを実施しなくていいとはならない。ユーザーがやりたいことをパッケージソフトで実現できるかどうかの確認は、ユーザーやそれを支援するSIベンダーの責任で行う必要がある。

 同様のことは、実現方式として、モジュールを再利用した場合にもいえる。再利用したモジュールについてテストで何を確認するのか。安易にテスト不要と考えるのではなく、いったん立ち止まって検討する必要がある。

(3)リスク

 リスクは、プロジェクト管理で取り上げられるリスクのうち、品質に関わるリスクが対象だ。品質に関わるリスクとは「どのようなバグが起こる可能性があるか」「どの領域でバグが起こる可能性があるか」といったことである。これは、品質基準/対応要件、実現方式を整理した後だと洗い出しやすい。

 まず、品質基準/対応要件、実現方式を基に、システムやプロダクトが仕上がっていく様子を想像する。その中で、どのようなバグが起こる可能性があるか、どこの領域でバグが起こる可能性があるか、とリスクを挙げていく。

 続いて、テスト内容を検討する。洗い出したリスクに対して、何を確認すればバグが検知できるのかを考える。なお、リスクの影響度や発生確率などを考慮しておくと、テスト内容の重み付けをしやすくなる。テスト内容の重み付けとは、重点的にテストしないといけない領域とそうでない領域を見極め、重点的なテストが必要な領域は手厚くテストを実施する、といったことである。

(4)システム特性/プロダクト特性

 システム特性やプロダクト特性とは、システムの種別や処理するデータ、利用頻度、利用者の特徴などのこと。この特性に応じて、システムのうち止めてはいけない機能、プロダクトで起こってはいけないバグは異なる。これはテスト内容にも関わってくる。

(5)類似案件実例/バグ情報

 類似案件実例/バグ情報とは、会社が手掛けた類似案件に関する実績データだ。似たような案件で過去に起こったバグは、今回のプロジェクトでも同じ原因があれば再び発生する可能性がある。こうした部分は重点的にテストを行うなど、テスト内容を検討する。



 今回は最低限押さえておくべきプロジェクト特性として5つを取り上げたが、ほかの情報が不要というわけではない。テスト内容に織り込むべきものがあれば、それもインプットとして参考にしよう。

 繰り返しとなるが「マスターテスト計画書の作成では、プロジェクト固有の事情や背景を必ず押さえ、そのうえでテスト内容を決める」。これが今回の記事で最も強調したいポイントだ。スケジュールや体制といったテスト運営面の要素を決めるのは、テスト内容を決めた後にした方がいい。こうした進め方をすると、中身のあるマスターテスト計画書に着実に近づいていけるだろう。

春田 優子(はるた ゆうこ)
SHIFT
ビジネストランスフォーメーション事業本部 サービス事業部
エンタープライズビジネスユニット 銀行1グループ/技術支援グループ ファンクションマネージャー