第243回： 「ALTAのテキストをつくろう」6 テスト分析3（テスト分析の手順）
◀前の記事へ 次の記事へ▶
≡ はじめに
前回は「テスト条件」について書きました。テスト分析の手順を知り、実務に役立てるためにも、テスト分析で何をアウトプットしたいのかが曖昧では上手くいかないからです。
前回の復習は以下で模擬試験問題の確認を通して行います。
今回はJSTQBのALTAシラバスの「1.3 テスト分析」の後半（標準的な考慮事項）のうちの「テスト分析の手順」について書きます。
≡ 前回の復習
以下は前回の最後の方に出したJSTQB ALTAの模擬試験問題を𝕏にポストした結果です。
アンケートの結果は、ご覧の通り「4. テストケース」が74.4%と最多で、かつ、正解です。
「テストケース」はテスト分析で識別した「テスト条件」をインプットとしてテスト設計で作成するものです（忘れてしまった方は、以前のnoteを復習していただければと思います）。
ところで私は以前、「具体化・詳細化の粒度の差があるだけで、『テスト条件』と『テストケース』は本質的には同じもの」と書きました。（「85号：テストの作り方」）
この考えに変わりはありません。
「ハイレベルのテスト条件」→「具体的なテストケースのベースとなるテスト条件」→「ハイレベルのテストケース」→「ローレベルのテストケース」を考えたときに、それぞれに、厳密な区切りはありません。（順序尺度ではあるけれど、比例尺度ではありません。定量化できませんから、間隔尺度ですらありません。）
本質的には「どんなテストをするの？（したの？？）」に対する答えでしかありません。
ただし、JSTQB ALTAの試験対策としては、「テスト条件」と「テストケース」は別物であり、その違いについて答えられるようにしておく必要があります。
例えば、こんな感じに説明できるようになっていることがALTAの試験では求められるでしょう。
「まず、“どのようなテストをしたいのか＝テスト条件”について、テスト分析のタスクで検討して識別します。
テスト条件が見つかったら、次に、そのテスト条件をどこまで深くテストをするのかを考えて、テスト設計のタスクで（必要に応じてテスト技法なども駆使して）、より具体的なテストケースに変換します。」
なお、次に15.4%と多かった「2. テスト要求」は、ISTQB用語集では「テスト要件（test requirment）」と訳されているものと同じです。要求と要件が英語では、"requirment"で区別していないということはググると色々出てきます。（たとえば、こちら）
また、『要求工学知識体系（REBOK）』にもそう書いてあります。
しかしながら、組織によっては、「お客様の要求のうち、システムに実装する要件を明らかにする」というように、「要求」と「要件」を明確に使い分けていることがあります。注意して使うようにしましょう。
「用語について、いちいちうるさい連載だなあ」と思われているかもしれません。でも、問題が起こってから「用語の認識の齟齬があったね」と反省するよりは、定義が人によって違う用語はそう多くはないのだから、先に確認しておく方が良いと思っています。
例えば、「ニーズと要望と要求と要件と仕様」、「アーキテクチャー」、「単体テスト/結合テスト/統合テスト/システムテスト/総合テスト/受入テストなどのテストレベル」、「機能テスト/性能テスト/リグレッションテスト/負荷テスト/ストレステスト/e2eテストなどのテストタイプ」、「テスト条件/テスト観点/因子と水準/パラメータと値などの“何をテストしたいか”の情報」、「カバレッジ/テストの網羅/カバレッジアイテムと基準値などのテストの深さ」、「テストケースとテストスクリプト」、「テストアイテム」、「検証/妥当性確認」、、、。
あれっ？ 想像以上に多い？？
それから、前回も書きましたが、個人的には「テスト要件」が「テスト条件」というのは、しっくりきません。
テスト設計時にテスト要件を考慮してテストケースの網羅性の深さを決めたいので、私は、テスト条件とテスト要件を一緒にしたくありません。
テスト分析時にテスト要件を文章で定義しておくことは良いことと思います。
復習の最後に、ISTQBの用語集の定義を再掲しておきます。
もっとも、意味を深く考えずに、「テスト条件とは、テストのための根拠となる、コンポーネントやシステムのテストが可能な一部分。」と暗記してしまうのもひとつの手です。プリミティブな概念の一つですから。
ちなみに、以前のJSTQBの用語集（バージョン2）での「テスト条件（test condition）」の定義は、
❝ コンポーネントやシステムのアイテムやイベントで、 テストケースにより検証できるもの。たとえば、機能、トランザクション、フィーチャ、品質特性、構造要素など。 ❞
でした。丸暗記していました。（笑）
復習、長かったな。
≡ テスト分析の手順（概論）
■ テスト目的とともに分析する
ALTAシラバスには、以下の記述があります。
テスト条件を識別するには、通常、テストベースをテスト目的（テスト計画で定義済み）とともに分析する。
図にしてみます。
ALTAシラバスには上で引用したとおり「テスト目的（テスト計画で定義済み）」としれっと何事もないように書いてあります。
各テストレベルやテストタイプごとの大雑把な目的はテスト計画書に書いてある組織が多いと思います。
（それすら、書いていない組織があることは知っていますが、何度も使えるものなので新しくジョインした人向けに書いておくことをお勧めします。）
また、『ASTERセミナー標準テキスト』のテスト計画のページにも「テストの使命を明らかにし、目的を定義する。」と赤文字で強調してあります。
「テスト目的」について、念のため用語集を引いておきます。
「そういうことが知りたかったんじゃない」と言いたくなってしまいました。（いわゆる「空振り」ってやつです。あと、「するため」じゃなくて「する」じゃないの？）
一般的に考えて、「テスト目的」が分からなければ、「どのようなテストをすべきか」を決められませんから、ALTAの以下の記述もわからないではありません。再掲します。
テスト条件を識別するには、通常、テストベースをテスト目的（テスト計画で定義済み）とともに分析する。
実際には、テストベースを入力として、テストベースのひとつである企画書などから、プロダクトの目的を理解して、テストの目的を決めつつ（テスト計画書を直しつつ）、同時にテスト条件を識別していくことが多いのではないかと思います。
それとも、最近は、ALTAシラバスに記載されているように、テスト分析の前にテスト計画でテスト目的が定義済みというほうが普通なのでしょうか？
■ アジャイルソフトウェア開発でのテスト分析
ALTAシラバスには、以下の記述もあります。
アジャイルソフトウェア開発では、ユーザーストーリーの一部として定義されている受け入れ基準が、テスト設計のベースとして使用されることが多い。
ユーザーストーリーが何かについては、以前まとめた資料（以下）を参照してください。
「受け入れ基準」というのは、「AC（Acceptance Criteria）」の事だと思います。
ユーザーストーリーのポイントは、「動きではなく、価値を持った機能のまとまり」という点にあります。
「ストーリー」という単語に引っ張られて、「ユーザーシナリオ」を想像してしまう人がいらっしゃるのですが、
＜ユーザーの役割＞として、＜ゴール＞を達成したい。[それは、＜理由＞のためだ。]
というフォーマットで書くことからも分かる通り、ユーザーストーリー自体にシナリオ（動き）の要素はありません。（その意味でユースケースの方がユーザーストーリーよりも大きい単位となります）
HAYST法のFV表のF（目的機能）について「目的機能が書きにくかったらユーザーストーリーでもいいよ」と言ったときに、Mさんから「なんで？ 流行りものの取り入れ？？」と言われたのですが、どちらも「（開発予定の）機能の価値や目的を明確にしたもの」という点で、同じものと考えたのです。
上で「ユースケースの方が大きい単位」と書きました。自分も、誤解していたのでALTAシラバスの該当箇所をコピペします。
ユーザーストーリーは、このように、「機能（要件やフィーチャーというほうが適切？）」の価値を明確にするものですので、「機能を動かして評価するテスト」のために識別するテスト条件とはちょっと距離を感じます。
実は、「ユーザーストーリーの一部として定義されているAC（Acceptance Criteria）」には、ユーザーストーリーのゴールを満たすシナリオが書かれることが多いものです。
そこで、ACをテスト分析のときに使おうというわけです。
アジャイルソフトウェア開発でのテスト分析では「必ずユーザーストーリーのACを使え」という意味ではなく、「アジャイル開発では、ACがテスト設計のベースとして使用されることが多い。」（から参考にしてね）という情報提供であることに注意してください。
上記の「テスト設計のベース」は「テスト分析のベース」の誤訳かなと思ったのですが、オリジナルのシラバスでも「are often used as the basis for the test design」なので、少なくとも誤訳ではありませんでした。
とすると、オリジナルのシラバスの書き損じでしょうか？
ACに詳細なシナリオが書かれていれば、テスト設計にも使えるのですから、そこは臨機応変に対応していけばよいと思います。
チームの状況に合わせてやりやすい方法を取るというアジャイル開発の流儀にしたがえば良いでしょう。
≡ テスト分析の手順（標準的な考慮事項）
■ テスト条件は、様々な詳細度合いで定義する
今回のnoteでわたしが一番伝えたかったことです。キャッチイメージを再掲します。
ALTAでは、テスト条件を「階層アプローチ」を使って見つけるとしています。つまり、上図のように、まずは、「画面Xというテスト対象に対して、大きく機能性を明らかにするというテスト」（＝ハイレベルのテスト条件）を考えます。
それを段階的に、例えば上図の例のように、大きく抽象的な“機能性”を「正しい長さよりも1桁足りないアカウント番号を拒否する」と具体化・詳細化することで、「どういうテストをするのか」というテスト条件を見つけています。
ALTAシラバスでは「階層アプローチ」に加えて「プロダクトリスクが定義済みの場合、各プロダクトリスクに対処するために必要なテスト条件を識別し、リスクアイテムにまで遡ることができる必要がある。」とリスクからテスト条件を定義するアプローチについての記載もあります。
≡ テスト分析でのテスト技法の使用
ALTAシラバスでは、テスト分析でテスト技法を使用することで、以下の4点が容易になると述べています。
テスト条件の識別
重要なテスト条件が省略される可能性の低減
より明瞭で正確なテスト条件の定義
テスト条件を識別して洗練した後に、これらの条件をステークホルダーと一緒にレビューすることで、要件を明確に理解し、テストをプロジェクトのゴールに一致させることができる。
例えば、デシジョンテーブルテスト（というテスト技法）を使用して、テストすべきルール（列）であるテスト条件を見つけることをイメージすると良いでしょう。
≡ JSTQB ALTA試験対策
試験対策です。「学習の目的」をシラバスで確認します。今回の個所では前回書いたのと同じく、以下の通りです。
TA-1.3.1 （K2）分析の活動を行う際に、テストアナリストにとって適切なタスクをまとめる。
これまで、「学習の目的」に表れている「K2」の意味について説明していませんでした。ISTQBのシラバスでは各単元に求めている知識レベルをK1～K4の指標（“Kレベル”と呼びます）であらわしています。
K1: 記憶 （暗記して思い出せればOK）
K2: 理解 （例を挙げて説明できるように）
K3: 適用 （自分の活動に応用して使えること）
K4: 分析 （適用対象を分析して適切に活用できること）
です。（括弧内は私の解釈です）
数字が大きくなればなるほど、深く理解し実践できることが期待されます。（問題も、そのレベルを確認する問題となります。）
ということで（上記からテスト条件に絞った）模擬問題です。K2なので、理解できたかどうかを問う問題がでます。
（理解できているかどうかを問う問題とは、“ちょっと言い方が変わっていても理解できること、また、何を言っているか推測できるかどうかを試す問題”ということです。）
《例題》
標準的なテスト分析方法について正しいものを下記の選択肢から1つ選びなさい。
1. プロジェクトリスクに対処するために必要なテスト条件を識別する
2. 実績があるテスト条件から選択する
3. 大きなテスト条件を識別し段階的に詳細化する
4. テスト技法を使用してはならない
答えは次回に書きます。
≡ おわりに
今回は、「テスト分析3（テスト分析の手順）」でした。スライドは3ページに分かれていますが。
以下に今回までのテキストを置きます。
15ページまでです。
パワポのノートについても追加しています。
次回は、「1.4 テスト設計」を書きます。1.4はシラバスで4ページ半ありますので、何回かに分けて書くことになります。
