第241回： 「ALTAのテキストをつくろう」4 テスト分析1（TAのタスク）
◀前の記事へ 次の記事へ▶
≡ はじめに
前回は「ソフトウェア開発ライフサイクルにおけるテスト」について書きました。
前回の復習は以下で模擬試験問題の確認を通して行うとして、今回はJSTQBのALTAシラバスの「1.3 テスト分析」の前半（TAのタスク）について書きます。
≡ 前回の復習
以下は前回の最後の方に出したJSTQB ALTAの模擬試験問題を𝕏にツイートした結果です。
アンケートの結果は、ご覧の通り「テスト戦略を定義するとき（82.1%）」と「テスト分析を開始するとき（17.9%）」が二分しました。
正解は「テスト戦略を定義するとき」の方です。多くのみなさん正解です。
「テスト戦略」は、組織に複数持っていて、テスト対象に合わせてその中から1つ選択し、さらにその戦略をテーラリング（プロジェクトの特性に合わせて微調整）して「（テスト対象に特化した）テストアプローチ」をつくるのですから、アンケートの選択肢は厳密には、「テストアプローチを定義するとき」とすべきと思いますが、この選択肢のなかでは、「テスト戦略を定義するとき」が最も近いものです。
≡ テスト分析1（TAのタスク）
「テスト分析」はJSTQBのFLでも学びました。
前に書いた、FLレベルのnoteはこちらです。JSTQBのALTAシラバスで言うと以下の１文がFLシラバスで述べていることに対応します。
テスト分析の活動が完了したとき、テストアナリストは、その領域に対してどのような仕様のテストケースを設計しなければならないかが分かるようになっているべきである
上記を要約すれば、「テスト分析はテスト条件を見つけるプロセス」です。テスト条件のことをALTAシラバスでは「その領域に対してどのような仕様のテストケースを設計しなければならないかが分かるようになっている（もの）」と書いています。簡単に言えば、テスト条件とは、「何をテストするか」です。
ALTAでは、テスト分析（テストベースからテスト条件を見つけるプロセス）の方法について、FLのシラバスよりも具体的に説明してあるのでテスト分析のイメージがより湧くようになっているのですが、そこは次回となります。
今回は、テスト分析でテストアナリスト（TA）が行うこと（＝ TAのタスク）に焦点が当たっています。
キャッチイメージを再掲します。こちらがTAが実施するタスクです。
テスト分析におけるTAのタスクには、大きく「テストプロジェクト範囲の定義」と「テスト開始基準が満たされていることの確認」の2つがあります。
2つ目の「テスト開始基準が満たされていることの確認」については、テスト分析そのものではありません。テスト分析を効果的に進めるための確認です。
「テストプロジェクト範囲の定義」とは、テスト分析そのものの活動です。
「TAがテスト分析のタスクをリーディングする」ということです。
「テスト開始基準が満たされていることの確認」とは、「TAが“テストを開始してしまってよいかどうか”の確認（＝ 技術的な判断）を行う」ことです。
それでは、それぞれの中身について確認していきます。
≡ テストプロジェクト範囲の定義
TAが「テストプロジェクト範囲の定義」で実施することの細目は、以下の5点です。
テストベースを分析する。
テストベースのさまざまな種類の欠陥を識別する。
テスト対象のテスト条件とフィーチャーを識別し、優先度を割り当てる。
テストベースの各要素と関連するテスト条件の間に双方向のトレーサビリティを確立する。
リスクベースドテストに付随するタスクを実行する。
順に説明します。
■ テストベースを分析する
いきなりですみません。こちらは次回のテーマですのでここでは書きません。FLレベルのnoteの内容を復習いただけると次回、スッと理解できるはずです。
■ テストベースのさまざまな種類の欠陥を識別する
マイヤーズの三角形問題に対して、「有効な二等辺三角形で、3種類の辺の組合せ」という解答例があります。
これは、三辺a, b, cがあったときに、「a=b」だけではなく、「b=c」と「c=a」も確認しようというものです。
「3, 3, 2」の入力では「二等辺三角形」と出力するのに、「3, 2, 3」だと「不等辺三角形」と出力してしまう欠陥を想定（識別）し、二等辺三角形のテストにおいては「辺の組合せ」までテストしようということです。
余談ですが、先日、某氏から「『有効な不等辺三角形』のテストでは、『辺の組合せ』はテストしなくても良いのですか？（マイヤーズの三角形問題の解答例にはないのですが……。）」という質問を受けました。
私の回答は以下の通りです。
「普通のプログラマーなら、正三角形、二等辺三角形のどちらでもない（else）なら不等辺三角形を出力するように作るだろうから、不等辺三角形については、そうなる条件を１回だけテストしたら良いですが、超新米プログラマーなら何をするかわからないので、テストしてもよいです。テストは条件次第です。」
今回の文脈で言えば、「テストベースから欠陥を識別」してテストするかどうかを判断していることになります。
■ テスト対象のテスト条件とフィーチャーを識別し、優先度を割り当てる
前半の「テスト対象のテスト条件とフィーチャーを識別し」は次回のテーマなので、ここでは省略します。
後半の「優先度を割り当てる」ですが、実務では、「テスト対象のテスト条件とフィーチャーを識別し」を実施した段階で「必要なテスト条件」しか残っていないことがほとんどですから、それに対してさらに「優先順位をつける」ということはしません。
テストの終了基準も「テストケースを全て実施した」になっていることが多いので、全部実施するなら優先順位は関係ありません。
リスクベーステストが嫌いなので、この話はこのへんで……。詳しく書くものもありませんし……。
もしも、ユーザーと優先順位の合意ができるのなら、優先順位をつけても良いと思います。ただ、その場合は「ユーザーと優先順位を合意する」ようにしましょう。（ユーザーから、“そんなことを聞かれたって分からない”と言われてしまうかもしれませんが。）
■ テストベースの各要素と関連するテスト条件の間に双方向のトレーサビリティを確立する
「どこの仕様のテストをしているのか」の情報を残すことは非常に重要です。
しかし、そんなものを残さなくても「仕様変更やバグがなけれは問題ない（＝ トレーサビリティマトリックスを使う機会がない）」のはその通りです。
さらに、テスト管理ツールがないと「双方向トレーサビリティの確立」は、面倒でやり切ることができないというのも事実です。
ですから、逆に考えれば、テスト管理ツールはテストに必須のツールです。テスト規模が小さく一度きりのテストならExcelでも良いと思いますが、テスト規模がある程度大きく、今後、バージョンアップも予定しているなら、テスト管理ツールを導入して双方向トレーサビリティを確保することをお勧めします。
■ リスクベースドテストに付随するタスクを実行する
こちらはALTAのシラバスに「第2章を参照」とありますので、そちらに書きます。
≡ テスト開始基準が満たされていることの確認
TAが実施する「テスト開始基準が満たされていることの確認」は、以下の3点です。
上にも書きましたが、「テスト開始基準が満たされていることの確認」については、テスト分析そのものではありません。テスト分析を効果的に進めるための確認です。
テストベースがある。
テストベースがレビューに合格している。
残りのテストタスクを完了するために適切な予算とスケジュールが確保されている。
順に説明します。
■ テストベースがある、テストベースがレビューに合格している
1と2は、「レビューに合格しているテストベースがある」と、まとめることができます。
開発者から「仕様書はあとで（納品までにテストと並行して）書くからテストをはじめてほしい」と言われることがあります。
開発者は開発物に熟知していますし、「画面をみたらわかるように開発した」自負がありますから、上記の要求に悪気はありません。
スケジュールも押していると、本当に断りにくいものです。
しかし、検証とは「作ると決めたものを正しく作れたかを確認すること」です。
「作ると決めたもの」とは、「レビューに合格済みの仕様書」のことです。
「レビューに合格済みの仕様書」が無ければ、正しく作れた事の検証は不可能です。
仕様書が無くても、テスターの頭の中にある“正しい動き”との比較検証は出来ます。しかし、“それで良いのか？”という話です。
それで良い場合はテスターが仕様書を書いて、その仕様書のレビュー承認を取ってください。
仕様書が無いという問題の解決策は、テスト計画書の「テスト開始条件」のところに、「レビューに合格済みの仕様書があること」と書いておくことです。
そして、どんな場合にも例外なく「レビューに合格済みの仕様書がないとテストできません」と突っぱねることです。そうすることで、「仕様書をつくることが当たり前」という文化ができます。
立派な文書を作れということではありません。チケットでも良いですし、ホワイトボードを写真に撮ったものでも構いません。
レビューだって、ハンコが欲しいわけではなく、レビューすべき人の合意を取れていればOKです。
でも、テスト担当者が、「仕様書が無いとテストできません」とは言いにくいですよね。実際に仕様書が無くても出来ることはありますから。
そこでテストアナリストの出番です。レビューに合格済みの仕様書が全体最適の観点から、大切であることを論理的に説明し説得してください。
■ 残りのテストタスクを完了するために適切な予算とスケジュールが確保されている
CMMIでいうと、「実装のインフラ(II)」プラクティスにあたります。CMMIのプラクティス領域と適用効果についてはちょうど、小林さんがまとめてくださったものがあります。
こちらの「実装のインフラ(II)」には、以下の記載があります。
組織にとって重要なプロセスが、習慣的かつ持続的に用いられ改善されるようにする。
・良いやり方が定着し、人が変わった後に廃れたり、忙しい場合にスキップされたりせず、確実に続き、かつ継続的に改善されるようにするためのポイントを理解できる。
「良いやり方が定着し、人が変わった後に廃れたり、忙しい場合にスキップされたりせず、確実に続き、かつ継続的に改善されるようにするため」に必要不可欠なものは、「適切な予算とスケジュールを確保すること」です。
言い換えれば、「予算とスケジュールが不足すると、良いやり方がスキップされたり手抜きされる」ということです。
至極当たり前のことです。でも、全てが終わった後のふりかえりの場で「予算がなかったから仕方がなかった」、「スケジュール的に仕方がなかった」という言葉を何度聞いたことでしょう。
プロフェッショナルとして、手抜きできないところは手抜きしちゃダメです。
リソースについては、“分かってはいるけれど、テスト担当者から偉い人に言いにくいこと”の一つです。『自分の力不足』と萎縮してしまうからです。
確かに力不足なのかもしれませんが、力不足については、プロジェクト開始までに組織によるトレーニングで解決すべきことです。
プロジェクトが始まってしまった上は、力不足があれば、それを前提条件としてプロジェクトの成功に努めるしかありません。テストアナリストが頑張って伝えましょう。
≡ JSTQB ALTA試験対策
試験対策です。「学習の目的」をシラバスで確認します。今回の個所では以下の通りです。
TA-1.3.1 （K2）分析の活動を行う際に、テストアナリストにとって適切なタスクをまとめる。
ということで模擬問題です。
《例題》 テストアナリストがテスト分析で実施するタスクではないものを下記の選択肢から1つ選びなさい。
1. テストベースのさまざまな種類の欠陥を識別する
2. テストベースとテスト条件のトレーサビリティを確立する
3. テスト対象のテスト条件とフィーチャーを識別し、優先度を割り当てる
4. 必要なカバレッジを確保するテスト技法を決定する
答えは次回に書きます。
≡ おわりに
今回は、「テスト分析1（TAのタスク）」でした。
以下に今回までのテキストを置きます。
11ページまでです。
パワポのノートについて、前回のnoteの記載をコピペしています。
次回は、「1.3 テスト分析2（テスト分析の標準的な考慮事項）」を書きます。