第242回： 「ALTAのテキストをつくろう」5 テスト分析2（テスト条件）
◀前の記事へ 次の記事へ▶
≡ はじめに
前回は「TAのタスク」について書きました。
前回の復習は以下で模擬試験問題の確認を通して行うとして、今回はJSTQBのALTAシラバスの「1.3 テスト分析」の後半（標準的な考慮事項）のうちの「テスト条件」について書きます。標準的な考慮事項とは、JSTQBがイメージしている標準的なテスト分析方法のことです。
テスト分析方法の規格という意味ではありません。（そちらはISO/IEC/IEEE 29119を読みましょう）
≡ 前回の復習
以下は前回の最後の方に出したJSTQB ALTAの模擬試験問題を𝕏にポストした結果です。
アンケートの結果は、ご覧の通り「3. テスト開始基準が満たされていることを確認する」が63.4%と最多です。ですが、正解は「4. 必要なカバレッジを確保するテスト技法を決定する（19.5%）」のほうを想定していました。
4を正解と考えた理由ですが、「テスト技法を決定すること」はTAの役割ではありますが、テスト分析ではなくテスト設計時に実施するためです。
問題文は、「TAがテスト分析で実施するタスクではないものを選びなさい。」ですので、4を正解と考えていました。
気になるのは3を選んだ多くの方の意図です。ALTAのシラバスを読み直したところ、「テスト開始基準が満たされていることを確認する」については、「テスト分析を効果的に進めるための確認（シラバスより）」となっています。厳密に言えば「テスト分析」そのものではありませんでした。
「テスト開始基準が満たされていることを確認する」ことについて、「テスト分析」そのものではないといっても、他のJSTQBのテストプロセスに当てはまるということでもないので、大きくとらえればテスト分析と考えても良いのかなとも思います。（前回のnoteについては、選択肢3をまぎれのないものに書き直しておきました）
以上のことから4に加えて3も正解としたいと思います。もしくは、4択問題なのに、2つ選ぶ必要があるので出題ミスでノーカウントでしょうか。
みなさんのアンケート投票結果を見て考え直すことができました。ありがとうございます。
≡ テスト分析 in Japan
まず、日本でテストに熱心な組織がしていそうなテスト分析の様子について書きます。
● 各自の知識の棚卸
「テスト分析を始めまーす。付箋紙を配るので、”自分ならこんなテストをしたいな”と思うことを10個書き出してください。」、
「終わりましたね。」、
● マインドマップの作成とブラッシュアップ（自由連想法）
「それでは回収して、マインドマップをつくっていきましょう。」、
「いい感じですねー」、
「あらためて、できあがったマインドマップをみてつけ加えたい“テスト観点”があれば教えてください。」、
● マインドマップへのテスト観点の追加（強制連想法）
「この辺の枝、ちょっと寂しい感じですね〜。何かないかなぁ。」、
「○○さん、これまで経験したバグを思い出してみて。何かテストしておいた方が良さそうなことはありませんか？」、
「あっ、そういえば前にこんなことがあったから、、、」
このような感じで、まずは個人ワークでしっかり15分程度考えてもらった後に、個人ワークの結果として引き出した知見を集めてブラッシュアップ（つまり、みんながバラバラに持っている経験やノウハウを出し合って一つのマインドマップにまとめてブラッシュアップ）して、最後に強制連想法で知恵を絞りだす。
とても良い方法だと思います。次回に書く予定のJSTQBのALTAシラバスに書いてある方法より、ずっと良い方法だと思います。
日本には鈴木三紀夫さんと池田暁さんの『マインドマップから始めるソフトウェアテスト』という本（読んでいない人は下記リンクへ）をはじめとして、にしさんの”テスト観点”と“NGT/VSTeP”など、テスト分析について真剣に取り組んできた歴史と成果があります。
ですから、今回と次回のnoteは、「JSTQBのALTAシラバスに書いてある方法をしよう」という話ではありません。
「折角だからJSTQBのテスト分析方法も知っておいて、使えそうなところは使ってやろうか」といった上から目線でいいと思います。
「日本人は「舶来もの」に弱い傾向がある」からこのくらい書いておかないとね。せっかく良いものを持っているのに退行してしまうから。
（日本が諸外国と比較して、10年遅れているテスト技術もあるので、謙虚でいることはよいことだけど。）
≡ テスト条件
ようやく、ALTAのテスト分析の話になります。まずは、今回のテーマの（「テスト分析」プロセスのアウトプットである）「テスト条件」についてです。
私がISTQBの用語集で何度もなんども引いた用語は「テスト条件」です。今回も確認してみます。
日本語で引いた後に、右上にある言語のプルダウンメニューを「JAPANESE」から「ENGLISH」に切り替えると同じ用語の英語版がでます。
用語の定義のところを抜き出します。
テストのための根拠となる、コンポーネントやシステムのテストが可能な一部分。
A testable aspect of a component or system identified as a basis for testing.
「一部分」という単語が気になります。
なぜ気になるのか。
私は、翻訳サイトで、用語の定義の日本語を英語に翻訳し直してみるからです。
今回は、「A testable piece of a component or system that provides a basis for testing」と翻訳されました。
「一部分」は「piece」と訳されています。
ここで、「piece」でなく「aspect」という単語が選ばれている意味を理解しないと「テスト条件」を理解したことにならないんだろうなと思いました。
英語のほうでは「aspect」という単語が選ばれています。コウビルド英英辞典（Collins Online Dictionary）でaspectを引いてみます。
An aspect of something is one of the parts of its character or nature.
一部分（one of the parts of）には違いないけれど、「its character or nature」とあることから、「特徴（性質）または本質」の一部分（側面）ということのようです。
また、同義語として、「テストシチュエーション（test situation）, テスト要件（test requirement）」が挙げられている点も気になります。
situationを「状況」といった日本語にしていないということは、「状況」を含む広い意味の「シチュエーション」なんだろうと思います。
あと、「テスト要件」が「テスト条件」と同義語と呼ばれても変な感じがします。こちらもどんな要件を指しているのか（テストリソースのことか？それとも〇〇技法を使って網羅率100%でテストしてほしいという要件か？ どちらもか？？）
ALTAの後の方を読むと、デシジョンテーブルの列はテスト条件とのことです。テスト条件の例として、デシジョンテーブルのルールを示すことはわかりやすいと思います。
≡ JSTQB ALTA試験対策
試験対策です。「学習の目的」をシラバスで確認します。今回の個所では前回書いたのと同じく、以下の通りです。
TA-1.3.1 （K2）分析の活動を行う際に、テストアナリストにとって適切なタスクをまとめる。
ということで（上記からテスト条件に絞った）模擬問題です。
《例題》 テストアナリストはテスト分析でテストベースからテスト条件を識別する。テスト条件ではないものを下記の選択肢から1つ選びなさい。
1. テストシチュエーション
2. テスト要件
3. テスト対象のテストが可能な側面（特徴や本質）
4. テストケース
答えは次回に書きます。
≡ おわりに
今回は、「テスト分析2（テスト条件）」でした。
以下に今回までのテキストを置きます。
12ページまでです。今回は1ページしか進みませんでした。
パワポのノートについても追加しています。
次回は、「テスト分析3（テスト分析の手順）」を書きます。
