54号：テスト分析（前編）

≣ はじめに

「ASTERセミナー標準テキスト」の36ページについての前編です。

「テスト分析」はテストアナリストが行う「難しいこと」と思っていませんか？　そのようなことはありません。上手いヘタは別として誰もが行うことです。

≣ 結論っぽいこと

ずっと以前に、

「テストとは、エラーを見つけるつもりでプログラムを実行する過程である。」 （1979年）　　by G.J. Myers

と書きましたが、この文にある「エラーを見つけるつもりで」はテストをするうえで、本当に（ひょっとしたら１番）大切なポイントではないか？と私は考えています。それは、「何をテストしているのか意識してテストする」ことにつながるから。

「何をテストしているのかなんて、いつも意識しているよ」と仰る方が大勢いると思います。でも、そういう人ばかりではなく、テスト手順書に書かれている操作を実施し出現した画面のスクショを黙々とExcelに貼り付ける人もいらっしゃいます。また、テストケース作成と称して、『機能仕様書』を『テスト仕様書』というタイトルのエクセルにコピペしていらっしゃる方もいます。
日曜日に某アニメのスクショ？をツイートしていることからも分かるように私は単純作業を楽しめますし、なんなら好きと言ってもよいのですが、「仕事で単純作業は勘弁だ」と思われる人が多いことは容易に想像できます。（だって仕事の単純作業は機械に置き換わり、そしたら単純作業しかしていない人は、要らない人になってリストラされてしまいそうだから。その心配ではなく、「そもそも単調な作業は向いていない」という人もいらっしゃるでしょう）

ところで、受け入れテストでは、「テストであることを忘れて、使ってみて。気になったことはメモしておいて、あとで教えてね」などと言われて何も考えずにテスト対象のソフトウェアを使ってみるというテストもあります。でも、それは、特殊なテストです。しかも、そういう特殊なテストでさえ、頼んだ人はきっと「ふだん通りに使って問題のないことをテストしたい」とテスト分析したのだろうと思います。←　ややこしいですね。

結論っぽいことを言えば、テスト分析とは「何をテストするのか」を決定するプロセスことです。初心者はこれで「そーか。『何をテストするのか』なんだね。100%理解した」と思うでしょうし、このnoteの読者なら「そんな言葉には騙されないぞ」と思ったかもしれません。「ダニングクルーガー効果」ですね。そこで、話を続けます。

テスト分析は、プロセスなので、入力と出力があります。
テスト分析に入力されるもののことを総称して「テストベース」と呼びます。「要件リスト」や「仕様書」、「詳細設計書」、、、などなど、テストのもと（基）となるものがテストベースです。

テストベースの「ベース」は"base"ですから「もと（基）」です。"base"には、「もと」の他にも「起点」や「根拠」の意味もあります。なんとなくテストベースの意味が多面的に理解できてきた気がします。
ところで、「ベース基地」という言葉がありますが、「ベース」自体に「基地」の意味がありますから「キチキチ」ですね。（Google翻訳では以下の通りでした。ふふっ。
baseだけ、もしくは、base stationが正しい英訳なのだと思います）

他にも、「マニュアルどおりに動いているかテストをしてくれ」と依頼されたときには「マニュアル」がテストベースとなります。

次に、テスト分析プロセスの出力のほうはJSTQBでは「テスト条件」と呼んでいます。

ところで、この「何をテストするのか」の「何を」、言い換えますと、『テストすべきこと』、『テストケースにより検証できるもの』の呼び方（用語）が混乱しているように思います。
個人的には、『テスト観点』と呼ぶのが一番適切だと思っていますが、JSTQBには『テスト観点』という用語は現れません。近い概念として『テスト条件』という言葉があり、JSTQBでは『テスト条件』という用語を使っています。またJSTQBではテスト分析プロセスのアウトプットをテスト条件としています。「テスト分析とは、テスト条件を見つけるプロセスである」と言ってよいでしょう。

JSTQBでは、テストベース（test basis）とテスト目的（test objective）からテスト条件（test condition）を得ると書いてあります。テストベースとは、テスト対象の要件が書かれた仕様書や設計書のようなものを思い浮かべてください。
JSTQB ALTAのシラバスにある例では、「画面Aの機能性」といった高位レベルのテスト条件をまず識別し、次に、特定のテストケースの基準として、より詳細な条件（たとえば、「画面Aでは、正しい長さよりも一桁足りないアカウント番号を拒否する」など）を識別するとあります。
似た構造として、テスト対象（test object）を分解しテストアイテム（test item）を得るがあります。

≣ テスト分析、その前に

テスト分析を行う前にやっておくこと。それはキャッチイメージの、

テストレベルごとに適切なテストベースを分析する。

です。「テストレベルごとに適切なテストベース」が何かを考える必要があります。

私は、こちらの図を使って説明することが多いです。

これは、もともと、コーバーンという方が「ユースケースと一口に言っても色々あるよ」というために作った図を私が「いらすとや」の絵を使って描いたものです。

この絵の縦軸は、空の天辺の白色から始まり、水面付近の青色、海の中の藍色と続き、最下層は海の底の泥の黒色となっています。
「白→青→藍→黒」です。この色の変化は、「ビジネス（白）→使用者（青）→機能（藍）→部品（黒）」に対応します。つまり、色は着目している「価値」のレイヤーを表しています（もっと細かい場合もあるでしょう……）。
テストは価値を確認する行為ですからビジネスに対してテストするのであれば、そのテスト対象がどのようにビジネス貢献するのかを明らかにする必要があります。

次に、この絵の横軸です。ビジネスレイヤーの白色には「雲」と「凧」が描かれています。「雲」は流れ、集まり、分離し、その形をかえます。つまり形が定まらないモヤっとしたもののメタファーとして描かれています。一方「凧」は輪郭がはっきりし形を変えることがありません。雲は抽象的なビジネス要求、凧は具体的なビジネス要求のメタファーです。他のレイヤーも同様です。表にまとめてみます。

4つのレイヤーに対して抽象・具象がひとつずつありますので、雲・凧・波・船・海・魚・泥・貝の８つの領域となります。でも、「抽象」の列の４つはテストベースとして使いにくいものです。上でベースの意味の一つに「根拠」があると書きましたが、抽象的なものを根拠としても人によって理解が異なるからです。ですから実際には、「具体」列にある「凧」、「船」、「魚」、「貝」をテストベースとすることが多いものです。

これは「抽象」列をテストベースとしてはいけないということではありません。「してもいいけど、難しいので注意してね」ということです。

「テストレベルごとに適切なテストベース」が何かを考えるというのは、この8つの領域のどこを対象としていて、どのような「テストベース」（テストの基、テストの起点、テストの根拠）を入手しているかを確認することです。
「テスト計画書」に書かれるべきものですので、「テスト計画書」の「テストベース」部分の記載を具体的なもの（文書番号や格納先など）を更新します。

≣ 終わりに

今回は、テスト分析の手前までとなってしまいました。次回はテスト分析の方法について書く予定です。