前回の「テストの管理Vol.4 ~テストの構成管理~」では、構成管理の定義と目的、テストにおける構成管理がなぜ必要なのか、テストにおける構成管理の対象や、実際の手順をご紹介しました。今回は、ソフトウェアテストにおいて考慮すべき2つのリスクについて、プロジェクトリスクとプロダクトリスクに分けて解説していきます。
テストにおける「リスク」とは
リスクの定義は文献や規格などによってさまざまなものが存在するため、ここではJSTQBで定義されているリスクについて見ていきたいと思います。JSTQBでは、テストにおけるリスクを以下のように定義しています。
引用:イベント、危険、脅威、発生する状況等の見込みと、その望ましくない結果、すなわち可能性のある問題
分かりやすくいえば、リスクには以下の2つの特性があります。
- リスクとは不確実である
100%バグの無い製品を作ることが不可能であるように、リスク自体も100%発生するわけではなく、起きたり起きなかったりする。
- リスクの裏には損失がある
仮にリスクが現実になった場合、望まれていない結果や損失が発生することになる。
これは有形、無形のどちらにも当てはまる。
また、上記のリスクによる影響度(レベル)については以下のように定義されています。
引用:リスクのレベルは、不利なイベントが起きる見込みとそのインパクト(イベントによる結果がもたらす損害)で決まる
実際の現場では、上記のように「リスクが発生する可能性」と「リスクの影響度」をもとに、優先順位を設けて対処していくことになります。
テストにおけるプロジェクトリスク
ひとことでプロジェクトリスクといっても、先程と同様に定義は文献などによってさまざまです。JSTQBでは、プロジェクトリスクを以下のように定義しています。
引用:開発プロジェクトを遂行する際に影響を与えるリスク
つまり、経営の三要素とも言われる「ヒト、モノ、カネ」に潜んでいるリスクのことを指します。では、それぞれの中身について見てみましょう。
ヒト
テストにおけるプロジェクトリスクのうち、ヒトの要素は大きく「テストを行うチームや組織(内側)」と「テストに関わる他のチームや組織(外側)」の2つに分けることができます。
・テストを行うチームや組織
実際にテストを行うテストエンジニアや、それらを管理するマネージャーなどが当てはまります。
・テストに関わる他のチームや組織
プロジェクト管理、開発、サポートなど、テストそのものを行うことはなくても、テストの結果を報告したり、テスト項目を決定するうえで確認が必要なチームや組織が当てはまります。また、プロジェクトのステークホルダーとなる経営陣、管理層、企画部門、お客様なども、関わることがあります。
モノ
テストにおけるプロジェクトリスクのうち、モノの要素は主に「テストウェア」を指します。つまり、テストに関わるソフトウェア・ハードウェア・ドキュメントのことです。
・ソフトウェア
テスト対象となるソフトウェアやアプリケーションから、テストで使用するソフトウェアやアプリケーションなどがあげられます。他にも、OS、ミドルウェア、ドライバなどが当てはまります。
・ハードウェア
テスト対象となるソフトウェアやアプリケーションを動かすデバイスや、テストを実行する際に使用するデバイスなどの、いわゆる「テスト環境」のことを指します。
・ドキュメント
テストで使用するドキュメントには、仕様や設計、ソースコードなどが記載された「テスト設計用ドキュメント」や、テストケース、テスト手順などが記載された「テスト実施用ドキュメント」、またテスト結果をなどが記載された「テストログ、テスト報告書、バグ報告などの成果物」などがあげられます。また、テストスクリプトや、テストで使用するテストデータなどもドキュメントに含める場合があります。
カネ
テストにおけるプロジェクトリスクのうち、カネの要素には予算や実績コスト、それらを管理するための見積もりや、スケジュールなどが当てはまります。直接、テストを実施するための人件費以外にも、トレーニング費用や、環境整備・維持費用、通信費などの間接コストについても考慮しておかないと、想像以上にコストが膨らむ可能性があるため注意しましょう。
テストにおけるプロダクトリスク
テストにおけるプロダクトとは、テスト対象そのものであり、テストにおけるプロダクトリスクとは、テスト漏れにより発生しうる損失や損害に対するリスクとなります。例えば、以下のようなものが考えられます。
バグを含んだソフトウェアの出荷
出荷したあとにソフトウェアがエラーを起こしたり、バグが見つかった場合、改修を行わなければならず、それらにかかるコストはそのまま企業にとっての損失に繋がります。
ソフトウェアが個人や企業に損害を与える
出荷したソフトウェアが直接、もしくは間接的に個人や企業に対して損害を与えてしまった場合、損害賠償が発生する場合があります。その場合もソフトウェアの改修費用がかかったり、最悪の場合は出荷停止となることもあります。
品質特性が低いソフトウェアの出荷
品質特性とは、機能性・セキュリティ・信頼性・使用性・性能など、ユーザーの満足度に影響する特性のことで、これらが低いことによる製品の信頼・魅力低下なども、プロダクトリスクのひとつに含まれます。
まとめ
ここまで、ソフトウェアテストにおける、プロジェクトリスクとプロダクトリスクについてご紹介しました。
・リスクは起こりうるものとしてテストを実施する
・プロジェクトリスクとは、「ヒト、モノ、カネ」に関するリスク
・プロダクトリスクとは、テスト対象そのものが抱えているリスク
■テスト・検証に関する課題解決はお任せ下さい
弊社は、webサイトやスマホアプリ、クラウド製品、業務システムなどのソフトウェアにおけるテスト・検証を支援する、第三者検証サービス を提供しております。テスト管理に限らず、テスト・検証に関する課題がございましたら、お気軽にお問い合わせください。
■テストの管理に関するその他の解説記事
テストの管理Vol.1 ~テスト計画のレベルと内容を知る~テストの管理Vol.2 ~テストの見積もり~
テストの管理Vol.3 ~テストの進捗管理~
テストの管理Vol.4 ~テストの構成管理~
テストの管理Vol.5 ~テストで考慮すべき2つのリスク~【本記事】
テストの管理Vol.6 ~インシデント管理~
【参考文献】:
『ソフトウェアテスト教科書 JSTQB Foundation 第3版』