第244回： 「ALTAのテキストをつくろう」7 テスト設計1（テスト設計のプロセス 前編）
◀前の記事へ 次の記事へ▶
≡ はじめに
前回は「テスト分析の手順」について書きました。
前回の復習は以下で模擬試験問題の確認を通して行います。
今回はJSTQBのALTAシラバスの「1.4 テスト設計」のうちの「テスト設計のプロセス」について書きます。
今回、あらためてALTAシラバスの「1.4 テスト設計」を読み返したのですが、意味が分からない箇所が多かったので、少しずつ読んでいこうと思っています。
逆に言うと、力不足で誤読してしまう可能性も高いので、業界のためと思ってどしどしコメントください。
※ 謙遜などではなく真面目な話です。よろしくお願いします。
≡ 前回の復習
以下は前回出したJSTQB ALTAの模擬試験問題を𝕏にポストした結果です。
投票の結果は、ご覧の通り「1. プロジェクトリスクに対処するために必要なテスト条件を識別する」と「3. 大きなテスト条件を識別し段階的に詳細化する」に二分されました。
正解は「3. 大きなテスト条件を識別し段階的に詳細化する」です。
前回「画面✖機能性」のような大きなテスト条件を識別した後に、それを様々な詳細度合いで階層的に分析していく方法について学びました。ですから「3. 大きなテスト条件を識別し段階的に詳細化する」が正解です。
残りの選択肢についてどこが誤りなのか確認します。
「1. プロジェクトリスクに対処するために必要なテスト条件を識別する」ですが、正解と二分して選ばれました。（投票時間締め切り時刻のギリギリまで、ずっと均衡しつつ、むしろこちらの方が多く選ばれていたので『困ったな』と思っていました。）
合っていそうな答えなのですが、「プロジェクトリスク」のところが違います。「プロダクトリスクに対処するため」であれば正解なのですが……。
あくまでも第一は「プロダクトの品質が悪い可能性」を軽減するために実施すべきテスト（条件）を考えるのがテスト分析です。
結果としてプロジェクトのリスクも軽減されると思います。
次は、「2. 実績があるテスト条件から選択する」です。こちらを選択したひとは一人もいませんでした。
ところが、テストの現場では「良いチェックシートがほしい」であるとか、「ベテランが持っているテスト条件（もしくは、テスト観点）のリストがほしい」と言われます。
テスト初心者でもそのリストを使えば良いテストができるんじゃないか？との思いからです。
過去のテストケースからバグだしの役に立ったものを抽出し、そのテストケースが確認していること（＝テスト条件）を集めて新人や開発者に渡している事例をみます。
この方法が上手くいかない理由は、整理・抽象化されていない膨大なテスト条件を渡されても上手く使えないからです。せめて、「こういうテストアイテムの種類には、このテスト条件をテストする」というように、どこに使えるものかが明らかになって、仕様書をツールに読ませると自動的にテスト条件が出るようなシステムになっていたら良いと思うのですが。
そのようなツールは見たことがないので、現時点では、鈴木三紀夫さん考案の“意地悪漢字”（下図）をテスト分析するときに、チラチラ横眼で見るという方法をお勧めします。
まず、意地悪漢字は、「抽象化度が高い」ので多くのテストアイテム（＝テスト対象を小さく分解したもの）に当てはまります。
また、一見すると多くの漢字があるように見えるのですが、配置がとても工夫されているので、「このテストアイテムなら「略」よりも「欠」から想像を膨らませてテスト条件をみつけよう」という方法がとれるからです。
たとえば、意地悪漢字の「裏」の周りには代表的な意地悪漢字の「略、誤、降、切、隠、滅」の6文字が配置されています。
そして、その6文字の周りには、それぞれの派生形である漢字が構造を持って整理されています。（「略」でいえば「欠、落、除、捨、解」の５文字は「略」に非常に近い概念あるいは言い換えた漢字です。）
意地悪漢字の具体的な使い方ですが、例えば、「ユーザーの登録」という機能に対してテスト分析をするときに、まず、「略、誤、降、切、隠、滅」を順番に当てはめていき、「ユーザーの登録が（省）【略】されるケースはないかな？」とか「ユーザーの登録時に【誤】ってしまったらどうなるんだろう？」、「誤るパターンには、“稀、異、違、不、未”があるけど、“稀”なユーザーとしてアルファベット1文字の名前なんてどうかな？」といったようにテスト条件を見つけていきます。意地悪漢字には「表」もあるので（キャッチイメージ）、そちらについても、同様に行います。
※ 意地悪漢字のように抽象化も構造化も行われていない、単なる「実績があるテスト条件」をたくさん集めても上手くいかないということは、容易に想像できると思います。
（白状しますと、私は、たくさん集めてから使えないことに気が付きました。検索もできるようにしたんですけどね～。www）
最後は、「4. テスト技法を使用してはならない」です。
確かに、テスト技法は主にテスト設計で使用します。しかし例えば原因結果グラフのようなテスト技法はテストベースが「Requirments（要求・要件）」と抽象度が高いので、テスト条件のセットであるデシジョンテーブルを生成します。（原因結果グラフに限らず、どのテスト技法もテスト分析で使用することができます。）
ALTAのシラバスにも「テスト戦略そして／またはテスト計画内で識別されているテスト技法を適用することで、テスト分析活動を促進し」と書かれています。
今回の復習も長かったな。←説明が不足していたという証か……。急ぐ理由もないので、今後はもっと丁寧に書いていこう。
≡ テスト設計のプロセス
今回は、ALTAシラバスの以下の箇所を対象とします。（長文になってしまった関係で全てではありません。）
テストプロセスは、テスト計画時に決定した範囲に従い、テストアナリストがテストケースを設計し、それを実装および実行するテストプロセスが続いていく。テスト設計のプロセスは、次の活動を含む。
・ローレベルテストケースまたはハイレベルテストケースがどのテスト領域で最も適切であるかを判断する。
・ 必要なカバレッジを確保するテスト技法を決定する。使用する可能性がある一連の技法は、テスト計画時に決めてある。
・ 識別したテスト条件をカバーするテストケースおよびテストケースのセットを設計するために、テスト技法を使用する。
・ テスト条件とテストケースに準じた必要なテストデータを識別する。
・ テスト環境を設計し、必要なインフラストラクチャーやツールを識別する。
・ テストベース、テスト条件、テストケースなどの間で双方向のトレーサビリティを確立する。
リスク分析およびテスト計画で識別した優先度基準は、分析や設計の段階から実装や実行の段階に至るまで、プロセス全体を通して適用すべきである。
6つのプロセスにわかれています。それでは順番に見ていきます。
■ テストアナリストがテストケースを設計
箇条書きに入る前に、
テストプロセスは、テスト計画時に決定した範囲に従い、テストアナリストがテストケースを設計し、それを実装および実行するテストプロセスが続いていく。テスト設計のプロセスは、次の活動を含む。
との記述があります。
先日、辰巳さんから、ALTM、ALTA、ALTTAの役割について記載されている場所について、教えていただきました。旧資料なので、ウェブ上に見つからなかったのでいただいた画像をそのままコピペします。
上記には、「テストアナリストがテストケースを設計する」とは書いてありません。
もっとも、「設計しない」とも書いていませんので、これだけの情報から「テストアナリストのやることではない」と決めつけるわけにはいきません。
しかし、FLのシラバスの「テスト担当者の典型的なタスク」（p. 65）に「テストケースとテスト手順を設計し実装する。」とありますので、テスト担当者が主におこなって、テストアナリストは難しいところについて指導するような立場なのではないでしょうか？（もしくは、FLのシラバスにある「テスト担当者」には「テストアナリスト」も含むのかもしれません）
役割設定には、それほどこだわらなくてもよいのかもしれません。
（試験に出たらいやですね。😅）
■ テストケースの抽象度の階層とテスト領域
・ローレベルテストケースまたはハイレベルテストケースがどのテスト領域で最も適切であるかを判断する。
1つ目の箇条書きでは、テストケースの抽象度の階層とテスト領域について述べているようなのですが、意味がわかりません。
原文を見てみます。
Determining in which test areas low-level or high-level test cases are appropriate
「テスト領域に合わせて、ローレベルテストケースまたはハイレベルテストケースのどちらが適切か判断する。」でしょうか？
「テスト領域（test areas）」が何かもよくわからないのですが、用語集にもないので、一般的な意味なのでしょうね。ALTAのシラバスにも2か所しかでてきませんし。
「テストに合わせて、テストケースの細かさを決める」という意味かなあと思いました。
■ カバレッジアイテムとテスト技法
・必要なカバレッジを確保するテスト技法を決定する。使用する可能性がある一連の技法は、テスト計画時に決めてある。
2つ目の箇条書きは、カバレッジの確保のためのテスト技法の選定について書いてあります。
テスト分析のアウトプットはテスト条件ですから、「テストのための根拠となる、コンポーネントやシステムのテストが可能な一部分。」です。
ところが、ここでは、「必要なカバレッジを確保するテスト技法を決定する」とあります。いったいいつ「必要なカバレッジ」を検討したのでしょうか？ そして「必要なカバレッジ」はどういう検討をしたら決めることができるのでしょうか？
以下の図は、山﨑 崇さんの記事からコピーしたものです。
上図のように、ソフトウェアテストの国際標準である、ISO/IEC/IEEE29119-2:2021では、「テストカバレッジアイテムの識別」がタスクの一つとして明確に位置づけられています。
しかもそのまえに「テストモデルの作成」というタスクがあります。テストモデルとは、テスト対象が持つ「ある側面」を抽象化したものです。例えば、状態遷移テスト技法であればテスト対象を「状態という側面」から抽象化した「状態遷移図」がテストモデルとなります。
と、このように考えますと、「必要なカバレッジ」を検討するのは、「テスト設計」のなかで、さらにその前にテストモデルを作成する必要があることがわかります。
テスト設計プロセスについては、JSTQBのシラバスよりも「ISO/IEC/IEEE29119-2:2021」の方を参照することをおすすめします。
JSTQBのシラバスは、29119を参照していますので、今後さらに29119に合わせてくると思います。
テスト設計の6つのプロセスのうち、2つしか説明していないのですが、すでに長文になってしまったので、残りは次回に回します。
≡ JSTQB ALTA試験対策
試験対策です。「学習の目的」をシラバスで確認します。1.4の学習の目的は、以下の通りです。
1.4 テスト設計
TA-1.4.1 （K2）ステークホルダーがテスト条件を理解する必要がある理由を説明する。
TA-1.4.2 （K4）特定のプロジェクトシナリオに対して、テストケースの適切な設計レベル（ハイレベルまたはローレベル）を選択する 。
TA-1.4.3 （K2）テストケース設計で考慮すべき問題を説明する。
K4がある点に注意です。K4は、「分析 （適用対象を分析して適切に活用できること）」ですので、「試験問題で提示されたシナリオを読んで、テストケースの適切な設計レベルを選択する」というような深い問題が出るということです。
ところで、TA-1.4.3に対するシラバスが見当たりません（オリジナルの英語のシラバスも同様です）。たぶん、1.4.2に対する「学習の目的」ということでTA-1.4.3を考えればよいのだろうけど。モヤっとします。
今回は1.4.1の前なので、明確な「学習の目的」はありません。そこで、今回は記載した内容についての全体的な理解を問う問題とします。
《問題》
「ローレベルテストケース（L-TC）」と「ハイレベルテストケース（H-TC）」について正しいものを1つ選べ。
1. L-TCは「具体的テストケース」の同義語
2. H-TCには具体的な入力データ等を含む
3. H-TCは必ずテスト技法を用いて識別する
4. L-TCは「論理的テストケース」の同義語
問題文が偉そうで、ぞんざいなのは、140文字に抑えるためです。
答えは次回に書きます。
≡ おわりに
今回は、「テスト設計1（テスト設計の手順）」の途中まででした。
今回、テキストの追加ページはありません。「テスト設計の手順」で1ページにまとめたいからです。
次回も引き続き、「1.4 テスト設計」を書きます。
