ソフトウェアの品質を学びまくる

ソフトウェアの品質、ソフトウェアテストなどについて学んだことを記録するブログです。

JSTQB-TTAシラバスのお勉強 ─ 第1章「リスクベースドテスト」

テスト分析 資格

JSTQB-TTAシラバスのお勉強 ─ 第1章「リスクベースドテスト」　ISTQBのAdvancedレベル「テクニカルテストアナリスト」のシラバス日本語訳が出ました。いつ試験が行われるかは微妙なところですが、シラバスの紹介をしてみます。

テクニカルテストアナリストとは何なのか

　実は、ISTQBで定義されているロールの体系を見ても、定義を見つけることはできませんでした。この絵でいう「CORE」で、Advanced Level (AL)はFoundation (FL)の上位に位置付けられており、以下の3つから成っています。

  • Test Manager (テストマネジャー、TM)
  • Test Analyst (テストアナリスト、TA)
  • Technical Test Analyst (テクニカルテストアナリスト、TTA)

　テストマネジャーは一番わかりやすいでしょう。テストの計画・進行・管理・分析を行うロールですね。
　テストアナリストにもマネジメントの知識は要求されますが、どちらかといえばテストマネジャーに対して情報をインプットするという側面が強い。いわゆるテスト技法を駆使したテスト設計であったり、テストツールの導入であったりが仕事の中心と見なされています。

　テクニカルテストアナリストは、（ぱっとシラバスを読んだ限りでは）よりホワイトボックス的な色合いの強いロールのようです。シラバスでは、コードカバレッジや、静的/動的解析が章立てされています。また品質特性については、機能性やユーザビリティなど「ユーザが直接意識する」部分をTAが見るのに対し、TTAはどちらかといえばユーザがあまり意識しない、保守性やセキュリティなどに責任を持つことになっています。第4章の「品質特性」でも明らかになりますが、TTAは開発者側が意識すべき内容が多くなっています。

2018/3/21追記

　確かに、TTAについては、こちらの「概要」にきちんと説明がありました！ 足元がおるすになってますよ。
　TTAの「ビジネス成果」から引用してみましょう。

Advanced Levelテクニカルテストアナリストは次のビジネス成果を達成できる。
TTA1: ソフトウェアシステムの性能、セキュリティ、信頼性、移植性、保守性に関連付けされる代表的なリスクを認識し、分類する。
TTA2: 性能、セキュリティ、信頼性、移植性、保守性のそれぞれのリスクを軽減するためのテストの計画、設計および実行を具体化したテスト計画を策定する。
TTA3: 適切な構造テスト設計技法を選択し適用する。コードカバレッジおよび設計カバレッジに基づいて、テストが適切なコンフィデンスレベル（確信度合い）を提供することを確保する。
TTA4: コードおよびアーキテクチャ内の代表的な間違いに関する知識を、開発者およびソフトウェアアーキテクトとのテクニカルレビューに参加することで効果的に適用する。
TTA5: コードおよびソフトウェアアーキテクチャ内のリスクを認識しテスト計画要素を作成して、動的解析を通してこれらのリスクを軽減する。
TTA6: 静的解析を適用することで、コードのセキュリティ、保守性および試験性への改善を提案する。
TTA7: 特定の種類のテスト自動化を導入することから想定されるコストおよびメリットを概説する。
TTA8: テクニカルなテストタスクを自動化するために適切なツールを選択する。
TTA9: テスト自動化の適用における技術的な概念や課題を理解する。

　9つ中4つに「コード」という言葉が出てくること、またTAに比べて自動化がより詳細になっていることがポイントかと思います。
　上に書いた通り、より実装に近いところにフォーカスされている印象です。

1. リスクベースドテストにおける、テクニカルテストアナリストのタスク

　それでは、今回は第1章を見ていきましょう。まず、リスクベースドテストとは何だったでしょうか。
　用語集での定義は以下の通りです。

リスクベースドテスト（risk-based testing）
プロジェクトの初期段階からプロダクトリスクのレベルを低減させ、ステークホルダにその状態を通知するテストの方法。プロダクトリスクの識別の他、テストプロセスをガイドする際のリスクレベルの活用もこれに含まれる。

TMでも出てくる言葉なので、軽くこちらのエントリも覗いていただければ。

www.kzsuzuki.com

　識別・評価（アセスメント）・軽減というタスクについてはTMと同じですが、TTAは「技術的なリスクについて」の知識の提供が期待されています。
　ALの3つのロールでいうと、ざっくり分けてTMがプロジェクトリスク、TAとTTAがプロダクトリスクの深堀りをすると考えるとわかりやすいでしょう。

　例として挙げられているリスク例は以下です。

  • 性能リスク（例：高負荷状態では応答時間を達成できない）
  • セキュリティリスク（例：セキュリティ攻撃による機密データの漏えい）
  • 信頼性リスク（例：アプリケーションがサービスレベルアグリーメントで規定された可用性を満たせない）

　リスクの識別や評価については、特に目新しいことは書かれていません。専門家へのインタビューや有識者レビューを通じてリスクを洗い出そうとか、発生確率と影響度を評価しようといった一般論です。

Rex Blackさんの説明

　さて、これはプロジェクト管理でなくテストの話なので、テストを通じてこれらのリスクを低減する必要があります。そのリスクに応じてテストの優先度を決めるのが、リスクベースドテストです。

　リスクベースドテストの提唱者であるRex Black氏の資料、Risk-Based Testing - What It Is and How You Can Benefit（pdf）を見てみましょう。
　この資料では、リスクベースドテストの長所が以下のように述べられています。

  • リスクの高い順番にテストを行うことで、深刻な欠陥から順に見つけていける可能性を最大にできる。
  • テストの工数をリスクに基づいて割り当てることで、リリースまでに残った品質リスクをもっとも効率的に最小化できる。
  • テストの結果をリスクに基づいて測ることで、テスト実行期間中にどれだけのレベルの品質リスクが残っているかを組織が把握し、適切なリリース判定を行うことができる。
  • スケジュール上必要であれば、リスクの低い順からテストを割愛することで、品質リスクの増加を最低限に抑えながら、テスト実行期間を短くすることができる。

　このスライドを見ると、品質リスク項目とその品質特性を並べて、それぞれについて発生確率と影響度を記入しています。リスクベースドテストを紹介している他のサイトでは、縦軸に機能モジュールを並べているものもあります。機能×品質特性で、それぞれどんな品質リスクがあるかのマップを作るとわかりやすいでしょう。

たとえば

　例として、「外部I/Fの変更と機能追加の影響で、性能が劣化するリスクがある」ケースを考えてみましょう。
　まず発生確率について、プロジェクト開始当時は「非常に高い」だったとしても、初期段階でのプロトタイプ評価により思ったほど性能影響がないことがわかれば、「中程度」に変更されます。
　影響について、プロジェクト内部で定めた性能目標値を達成していなかったとしても、ユーザはまったく気にしないかもしれません。あるいはシステム全体の前提を満たせなくなり、リリース自体が不可能になるかもしれません。
　「性能が劣化する」と一言で言っても、その度合いによって確率も影響も異なるので、ものによっては別のリスクとして扱うのがよいでしょう。

　リスクの高いものから順に、対応するテストケースを消化していくことになりますが、そのテストケースも有限なので、リスクがゼロになることはありません。許容される工数と時間内で、受け入れられる程度にまでリスクを低減できたかを判断することになります。