リスクベースドテストとは何かー優先順位付けに役立つテスト技法

想定読者

・テストケースを作ったが多すぎてテスト期間内に実行しきれないと困っている人
・テストケースの優先順位のつけ方を知りたい人

本記事のゴール

・リスクベースドテストでテストの優先順位をつける方法を知る
・全てのテストケースをこなせなくとも重要なバグをより確実に検出する方法を知る

なぜリスクベースドテストが求められるのか?

テストマネジメントにおける難題

• テスト条件と、それらの個々の組み合わせは無限通りに近い。
  それらを全てテストケースにして実行することは不可能。
• そのため、適切なテスト内容を選択することが必要だ。
• さらに、各テストケースに割り当てる時間と必要な人員も決める必要がある。
• このように、テストの優先順位付けをすることが求められる。
• この優先順位付けのための方法の1つが、リスクベースドテストだ。

前提

リスクとは、悪い影響を与える可能性のある潜在的な事象。
(対比として、課題は悪い影響を与える現実化/顕在化した事象。)

リスクには2種類ある。
プロジェクトリスクと品質リスクだ。
プロジェクトリスクとは、プロジェクト管理面に影響するリスク。
(例：スケジュールが遅延する、予算がオーバーする)
品質リスクとは、プロダクトやシステム面に影響するリスク。
(例：機能が正常に動かない、応答速度が遅すぎる)

リスクベースドテストのゴール

• 品質リスクのレベルを受け入れ可能なレベルにまで引き下げる
• そのために、テストを通して品質リスクを低減する。
  • テストを通してリリース前にバグを発見すれば、リリース前に修正できる。
  • バグがなければ、テスト条件の下でシステムが正しく動作することを確認できる。
  • これらにより、品質リスクを低減できる。
• プロジェクトマネージャなどのステークホルダは、プロダクトにリスクがどれだけ残っているかを把握できる。

リスクベースドテストのプロセス

フローは以下の通り。
個々のプロセスを見ていく。そのあとで、インプットについて取り上げる。

プロセス

リスクの特定と定義

• ステークホルダを招集する(なるべく広い範囲から)

  • 適切なステークホルダが参加することが重要。なぜなら、ステークホルダごとにニーズや優先したい品質の内容が異なるため、見えるリスクも異なるからだ。

• リスクを特定&定義する。方法は以下の通り。

  • 専門的なスキルのある人へのインタビュー
  • 第三者によるアセスメント
  • リスクのテンプレートを参照
  • プロジェクトの振りかえり
  • リスクに関するワークショップ
  • ブレインストーミング
  • 過去の経験の活用

リスクの分析と評価

リスクの分類

• 品質特性に応じて分類する
• 企業や組織ごとの品質チェックリストを使う

リスクの現実化の可能性を評価する

• 簡易な評価方法の例：
  非常に低い、低い、中程度、高い、非常に高いの5点満点で評価する。
• 可能性を上下する要因は以下の通り。
  • 技術の複雑性 例：複雑であるほど、バグが埋め込まれる可能性が上がる
  • チームの複雑性 例：組織の風通しが悪いほど、リスクがずっと放置される
  • チームメイトの個人的な問題とトレーニングの問題 例：高スキルの人に看病する身内の人がおり、その人のために休むことが多い
  • チーム内の衝突 例：チームメイトの間の仲が悪いため、一方が困っていてももう一方が協力しない。
  • ベンダーとの契約の問題 例：請負契約
  • チームの地理的な分散 例：稼働率が高すぎて病みそうだが、リモートワークだと会話の場が会議しかないため、相談できないまま続く
  • レガシーアプローチ対新しいアプローチ ?
  • ツールと技術が不十分 例：バグの管理アプリを使えない。Excelで管理する必要あり。
  • 劣悪なマネジメント 例：人手が足りない
  • リーダーに技術の知識が足りない 例：プロダクトAを導入するのが目標だが、その知識が全くない
  • 時間、リソース、コスト、マネジメントのプレッシャー 例：「見積もった結果、４か月かかります」「3か月で作ってほしいので全体スケジュールは３か月で♡」
  • 早期からの品質保証活動の欠如 例：バグは早期に発見するほど品質リスクが下がる。システムテストの段階でバグがたくさん発見されると調査が困難になる。
  • 要件変更が多い 例：「テーブル20個をデータベース間で連携すればよい」→「関連するテーブル含めたら80個だった」→見積もりの過小評価が発覚
  • 高い初期欠陥率
  • インタフェースと統合の問題

リスクが現実化した際の影響を評価する

• リスクの発生の影響とは、ユーザ、その他のステークホルダに対する影響の重要度である。
• 簡易な影響の評価法：
  影響度が非常に小さい、小さい、中程度、大きい、非常に大きいの5点満点で評価する
• 影響の種類は次の通り
  • 影響を受ける機能の使用頻度 例：ワードでSUM関数にバグがある方がNUMBERSTRING関数にバグがあるよりもプロダクトリスクが高い
  • ビジネス目標の達成に対する当該機能の重要性 例：マッチングアプリで趣味のあう人をサジェストする機能がないとアプリが成立しない
  • イメージの悪化 例：銀行のサイトは個人的なサイトよりもシステムダウンによるイメージ悪化が重大
  • 業務がストップする 例：み〇〇銀行のシステム障害によりお金のやり取りができなくなる
  • 財政的、環境保護的、社会的損失が発生しうるまたは責任が問われる 例：省庁のシステムがダウンすると国民に影響が出る
  • 民法や刑法に抵触する 例：航空業界のパイロットのスケジュール管理システムの場合、航空法を満たすよう機能する必要がある。航空法などによりパイロットの月の飛行時間の上限があり、それを超えて仕事を割り当てることはできない。
  • ライセンスがなくなる 例：航空会社は国土交通大臣の認可が必要。適確に遂行するに足る能力を有するという要件がある。だが、システム障害でそれを満たせない場合にライセンスがなくなるという問題がある
  • 故障に対して妥当な対処法がない 例：超複雑な計算をするシステムで障害が起きると同じ計算結果を得る方法がない
  • 故障の判明によるレピュテーションリスク 例：み〇〇銀行のシステム障害
  • 安全性が損なわれる 例：航空機の制御システムに障害が起きた場合に人命を危険にさらす

リスク分析の結論について合意

• ステークホルダ間で、リスクの影響と可能性について複数でなく単一の結論に収束させ、かつ合意をとることが必要。
• だが、合意をとるには課題がある。リスク分析で用いる可能性と影響はステークホルダーの主観に基づいて定められる。
• そのリスクに関する主観は異なることがある。例えば、プログラマとビジネスサイドの人物では故障による影響の評価が異なるかもしれない。
• したがって、リスク分析プロセスでは、リスクレベルに関して合意に到達する方法を含める必要がある。 例：管理職の決定に従う、リスクレベルの評価値の平均値に基づき合意する

リスクの対応

• 冒頭でも述べた通り、リスクベースドテストのゴールは、リスクに基づきテストの順序付け、優先度付け、工数の割り当てを最適化することだ。
• そのため、決定したリスクレベルを個々のテストにリンクさせる。
• リスクに合わせてテストを計画、準備する。

テスト実行

• リスクベースドテストの実行方法は2つある。

  • 縦型探索
    高いリスクのテストから低いリスクのものにかけて順番に行う
  • 横型探索。
    すべてのリスクアイテムごとに、サンプルとなるテストを選んで、テストを行う。

• テストマネージャが各ステークホルダが理解できるようなやり方で、テスト結果とリスクを報告する必要がある。

• スケジュールの完了日になってもテストを全て実行しきれなかった場合

  • 残りのリスクレベルについてテスト担当者がマネージャーに報告する
  • マネージャーが方針を決める。すなわち、リスクを軽減するためにテストの期間を延長するか、残りのリスクをユーザー、ヘルプデスク、運用スタッフに移転するかを決定する。

リスク管理

• テストチームは品質リスクとそれらのリスクレベルを変更する新情報に対し、常にアンテナを立てておく必要がある。
• さらに、プロダクトリスク分析の結果の更新を定期的に行うのがよい。更新の機会の一つは、プロジェクトのマイルストンである。
• 更新とは具体的には、新しいリスクの発見、既存のリスクレベルの再評価、リスク軽減活動に効果があったかの評価だ。
• リスクが更新されたら、それをテスト計画・設計にも反映させる。

終了作業

• リスクベースドテストが期待通りの効果があったかを測定する
  その測定のために、以下の質問に答える
  • 重要度の低い欠陥よりも高い割合で重要度の高い欠陥を検出できたか?
  • 重要な欠陥のほとんどをテスト実行期間の初期に検出できたか？
  • テスト結果をリスクの観点からステークホルダに説明できたか？
  • スキップしたテストは、実行したテストよりも紐づけられたリスクレベルが低かったか?

インプット(いまさら)

ステークホルダの知識について補足する。
広範囲のリスクを考慮するためにステークホルダを意識的に区別するのがよいかもしれない。
ステークホルダは、ビジネスステークホルダとテクニカルステークホルダに区別される。

ビジネスステークホルダ	テクニカルステークホルダ
ユーザを理解している	ソフトウェアが故障するメカニズムを理解している
リスクの影響をビジネスの観点から評価できる	・技術的な観点からリスクを特定できる ・リスクの現実化の可能性を評価できる
例：顧客、ユーザー、運用スタッフ、ヘルプデスクスタッフ	例：開発者、アーキテクト、データベース管理者、ネットワーク管理者

さらに、ビジネスとテクニカルの両方の視点を持つステークホルダもいる。
その人々はリスクについて幅広い見識がある。

幅広いステークホルダから意見を吸い上げ、リスクを特定するのがよい。

リスクベースドテストの技法

技法は複数あるので紹介する。

• 簡易な手法。これは柔軟で多様な場面で用いられる。専門的スキルが低い人も使える。

  • 可能性と影響の2要因のみを使う。
  • シンプルで定性的な尺度と使う。

• 公式で重厚な手法(複雑で手間がかかる)

  • ハザード分析
  • エクスポージャーコスト
  • 故障モード影響解析
  • 品質機能展開
  • フォールトツリー解析

プロジェクトへの導入方法

• 長期にわたりリスクベースドテストを使用する場合、提案と導入をする必要がある。
• メンバーはリスク分析の価値を認識することが必要
• メンバーはこの技法を継続的に使用することが必要。
• そのためには、テストマネージャはステークホルダのニーズ、期待、このプロセスを実行するために割ける時間を把握する必要がある。

参考資料

テスト技術者資格制度 Advanced Level シラバス日本語版
テストマネージャ Version 2012.J04