中岫です。
TEF道メンバーが毎回一人ずつ自分の気になるネタを発表するTEF道勉強会'15。
第8回目は、植村さんによる「テストアナリスト」の勉強会。
テストアナリストとはなんだろう？から始まり、
JSTQBのシラバスの概要解説と内容に関するディスカッション、
そして、最後にサンプル問題（翻訳版）の紹介していただきました。
■テストアナリストとは
植村さんから次のように解説していただきました。
「テストアナリスト」は「テスト」＋「アナリスト」に分解することが出来る。
「アナリスト」は「アナライズ」する人。
「アナライズ」は「分析する人」「解剖学者」などの意味があります。
つまり、「アナリスト」は、専門分野に精通し、様々な情報をもとに多角的な分析・アドバイスなどを行なう役割の人のこと。
「アナリスト」の付く職業はどのようなものがあるか？
というと
証券アナリスト、フードアナリスト、知的財産アナリスト、バレーボールアナリスト、などなど。
「テストアナリスト」とは、
各技法の長所と短所を理解し、プロジェクトの種類、スケジュール、情報へのアクセス、
テスト担当者のスキル、および影響するその他の要因を考慮して、
特定の状況にとって最善の技法または複数の技法を選択できる必要がある。
テストアナリストは、分析できるだけではなく、アドバイスできないといけないので、かなりのエキスパート感がありますね。
「最善の技法または複数の技法を選択できる」というのがミソでしょうか。
また、Advanced Level シラバスによるとテストアナリスト（以下、TA）には次のビジネス成果が期待されるそうです。
期待される成果は次の表のとおりです。
後から気になったのは、TAレベル。このレベルは成果の難度？
| レベル | ビジネス成果 |
|---|---|
| TA1 | 使用中のソフトウェア開発ライフサイクルに基づいて、適切なテスト活動を実施する。 |
| TA2 | リスク分析によって提供された情報に基づいて、テスト活動の的確な優先順位付けを行う。 |
| TA3 | 適切なテスト技法を選択し適用する。定義されたカバレッジ基準に基づいて、テストが適切なコンフィデンスレベル（確信度合い）を提供することを確保する。 |
| TA4 | テスト活動に関連する文書化の適切な度合いを提供する。 |
| TA5 | 実行する機能テストの適切なテストタイプを決定する。 |
| TA6 | 対象プロジェクトの使用性テストに関する責任を負う。 |
| TA7 | 作業プロダクト内の代表的な誤りに関する知識を適用して、ステークホルダとの公式および非公式のレビューに効果的に参画する。 |
| TA8 | 欠陥の分類体系を設計し、実装する。 |
| TA9 | 効率的なテストプロセスを支援するツールを適用する。 |
■シラバスの概要説明
植村さんからは、テストアナリストシラバスで学習時間の多くを占める「テスト技法」、「テストプロセス」をピックアップして解説していただきました。
学習時間は降順ソートすると次のようになります。
| テスト技法 | 825 |
| テストプロセス | 300 |
| レビュー | 165 |
| ソフトウェア品質特性のテスト | 120 |
| 欠陥マネジメント | 120 |
| テストマネジメント | 90 |
| テストツール | 45 |
学習時間を見た時の参加メンバーの反応は、
- テストツールのウェイトが低いのは、テクニカルテストアナリストの役割？
- テストツールといってもいろんな種類がある、どのツールが対象？
- 自動化はテストアナリストではなく、テクニカルテストアナリストの役割？
など、質問がでてきました。
植村さんの回答は、
テストアナリストを勉強するにあたって、テストアナリストだけではなく、
ALのテストマネージャ、テストアナリスト、テクニカルテストアナリストの
3つの役割とビジネス成果を学習すると良いと思います。
とのこと。
■テスト技法
具体的なテスト設計技法の解説は、今回は省略。
そのかわり、植村さんが整理した、テスト設計技法とカテゴリと詳細の表と紹介していただきました。
そして、テストアナリストは、これらの技法に対して次の配慮ができなければいけないと説明されていました。
- 技法の適用、制限／注意事項、およびテストの目標を、カバレッジと検出すべき欠陥の観点から考慮する必要がある。
- 状況によっては、「最善」の技法が1つではないことがある。
- 技法を組み合わせると多くの場合、最も完全なカバレッジを達成するが、それぞれの技法を正しく適用するための十分な時間とスキルが必要になる。
探索的テストが経験ベースのテスト技法なのか？というと引っかかりますが、
これらの技法の特徴を深く理解し、対象のドメインの特徴に合わせて技法の選択、組み合わせができると、かっこいいですね。
| テスト設計技法 | 説明 | 例 |
|---|---|---|
| 仕様ベース | コンポーネントまたはシステムの内部構造を参照することなく、テストベースの分析に基づいてテストケースを導き出すためのテスト条件に適用する。 |
|
| 欠陥ベース | 探す欠陥のタイプをテスト設計の基本として使用する技法であり、欠陥のタイプについて既知の情報からテストを体系的に導き出す。 |
|
| 経験ベーステスト | 担当者のスキルと直感、および類似のアプリケーションや技術での経験を活用する。 |
|
| ベース | 技法の種類 | 制限／注意事項 |
|---|---|---|
| 仕様ベース | 同値分割法 | 最適な分割を決定するために、基になる処理を理解することが重要である。 |
| 境界値分析 | テスト対象の値を正確に決定できるようにするために、有効同値および無効同値の増分に注意する必要がある。 | |
| デシジョンテーブル | すべての相互作用条件を見つけることは、特に要件が適切に定義されていない、または存在しない場合に、困難な作業となる。 | |
| 原因結果グラフ | 法習得するのにより多くの時間と労力を必要とする。ツールによるサポートも必要とする。原因結果グラフは特別な表記方法を使用するため、グラフの作成者および参照者は、この表記方法を理解する必要がある。 | |
| 状態遷移 | テスト状態を決定することは、状態遷移表または状態遷移図を定義する作業の最も困難な部分である。 | |
| 組み合わせテスト技法 | これらの技法の主な制限は、少数のテストの結果がすべてのテストの結果を代表し、それらのテストが期待される使用方法を表すと仮定することである。 | |
| ユースケーステスト | 有効なユースケースは、現実的なユーザトランザクションを反映する必要があり、この情報は、ユーザまたはユーザの代表者から入手する。 | |
| ユーザストーリーテスト | 実現する機能性の一部を実際にテストするために、ドライバおよびスタブを生成する要件が存在することがある。 | |
| ドメイン分析 | 徹底したドメイン分析を実施するには、さまざまなドメインとドメイン間の潜在的な相互作用を識別するために、ソフトウェアを十分に理解する必要がある。 | |
| 欠陥ベース | 欠陥分類法 | 複数の欠陥分類法が存在し、これらを利用することにより、使用性など特定の種類のテストに焦点を当てることができる。 |
| 経験ベース | エラー推測 | カバレッジを評価することは困難であり、テストアナリストの能力と経験に応じて大きく異なる。 |
| チェックリストベースドテスト | 同じチェックリストを使用しても、異なる結果となる可能性がある。これは、より広いカバレッジを可能にするが、再現性が犠牲になることがある。 | |
| 探索的テスト | マネジメントおよびスケジュールが困難になることがある。カバレッジがまちまちでまとまりがなく、再現するのが困難である。 |
■テストプロセス
ALでは、テストプロセスを以下のように分けている。
FLと比較するとプロセスが詳細化されていることがわかります。
| テストプロセス(FL) | テストプロセス(AL) |
|---|---|
| ①計画、モニタリング、コントロール | ①計画、モニタリング、コントロール |
| ②分析と設計 | ②分析 |
| ③設計 | |
| ③実装と実行 | ④実装 |
| ⑤実行 | |
| ④終了基準の評価とレポート | ⑥終了基準の評価とレポート |
| ⑤終了作業 | ⑦終了作業 |
シラバスでは、
「通常テストアナリストの主要な作業は、テストプロジェクト期間中の分析、設計、実装、実行の活動を通して行われる。」
「使用するソフトウェア開発ライフサイクルに関係なく、テストアナリストは関与への期待度とタイミングを理解する必要がある。」
「テストアナリストは多くの場合、関与の適切なタイミングを示すモデルの定義に依存することなく、最も有効な役割を決定し、その役割のために作業する必要がある。」
植村さん曰く、この説明から
テストアナリストはプロジェクトによって主な役割が柔軟に変わる（変える）。
とのこと。
確かに状況やチームメンバーなどで役割が変わりそうですね。
また、シラバスの計画の解説にある
「テストベース、テスト条件、およびテストケースとの間に複雑な関連性が存在することがある。
たとえば、多対多の関連性がこれらの成果物の間に存在することがある。
テスト計画作業とコントロールを効果的な実装をするためにこれらを理解する必要がある。
テストアナリストは通常、これらの関係を最も的確に判断し、依存性を最小限にすることができる。」
というが理解できなかったそうです。
確かにわかりづらい（汗
参加メンバーからは、
テストアナリストが、計画・コントロールするということは、
テストアナリストはチームのリーダー的な人の役割なのでしょうね。
という意見がありました。
この意見に対して、本線からやや脱線しますが、
リーダーってどんな役割の人？マネージャの下働き、補佐？
どうやら、リーダーの定義はその会社によって位置づけが大きく変わってそうですね。
また次のように話題が尽きませんでした。
- テストアナリストは開発プロセスどうかかわるのだろうか？
→次にあげるようにテストするうえで分析する情報があるかどうか（テスト観点の調達）ではないか？- 企画段階、予算会議には入らない
- 類似プロジェクトの分析し、計画の修正
- 仕様のレビュー会議への参加
- テストアナリストはテストマネージャとどう関わるだろうか？
- テストマネージャとプロジェクトマネージャは同義？上下？
- テストをマネジメントしているのか？工程を管理しているのか？
■サンプル問題紹介
ディスカッションが活発なおかげでタイムオーバー。
ちらっと紹介で終了。
残念。
解説していただいて、今の自分には、テストマネージャよりもテストアナリストの方が、必要な知識だと感じました。
そして、今回の勉強会をきっかけにALの勉強を本格的にしようと思いました。
植村さん、ありがとうございました！！
～ 記 ～
* 日時：9/14（月）19:00～21:00
* 担当：植村
* お題：テストアナリストについて
* 場所：東京エレクトロン札幌支社 会議室
* 書記：中岫
