第97回：　ユースケーステスト（前編）

≡ はじめに

「ASTERセミナー標準テキスト」の115ページ付近です。

前回は、状態遷移テストの実践について書きました。今回はユースケーステストの基礎について書きたいと思います。ASTERセミナーテキストに出てくるブラックボックステスト技法は、この「ユースケーステスト」と、その次の「組み合わせテスト」で終わりです。そのあとは、非機能のテストについて考えたのち、ホワイトボックステスト技法、経験ベースのテスト技法と続きます。

今回と次回に書くテスト技法について、「それはユースケーステストではありません」という人がいると思います。言わずに心の中で「私が習ったユースケーステストと違う」と思う人はもっといらっしゃるに違いありません。
私が社会人になった昔（1985年）には、少なくとも私の周りでは、「（明確に）“利用”にフォーカスしたテスト」はしていませんでした。近いテストとして、社内で使いそうな人にリリース前のソフトウェアを配って使ってもらう“αテスト”と、その後、社外（協力的なお得意様）に使ってもらう“βテスト”しかしていなかったように思います。

ところで、“αテスト”や“βテスト”はテストレベルでしょうか？ それともテストタイプでしょうか？？ JSTQB FLのシラバスには、「受け入れテストの一般的な形態」との記載がありますので、“αテスト”や“βテスト”はテストレベルのようです。

今の“αテスト”には、「開発者自身が開発中のソフトウェアを使う」ことを指す“ドッグフーディング”（Eating your own dog food.とも）も含むように変わってきていると思います。また、“βテスト”も、企業側が広く一般にβテストユーザーを募るようになってきました。

何が“ユースケーステスト”で、何が“シナリオテスト”で、何が“ユーザーシミュレーションテスト”で、何が“ユーザーストーリーテスト”なのか。
私も、できるだけ標準に則ったことを書きたいのは山々なのですが、ISTQBのFLがいうユースケーステストと、ISO/IEC/IEEE 29119がいう「シナリオテスト」とは、いったいどれほど違うのか、、、？ と思います。
私の理解は、“29119のシナリオテストで行う（複数の）シナリオテストの1つのシナリオを取り出したときに、そのシナリオテストをユースケーステストと呼んでいる”ですが、確信度はfifty-fiftyです。
ISTQBではISTQBの辞書で、“ユースケーステスト”のところに、「Synonyms: シナリオテスト（scenario testing）, ユーザシナリオテスト（user scenario testing）」と書いてありますので、「ユースケーステストとシナリオテストとユーザシナリオテストの意味はほとんど同じ」（同意語・類義語）としています。

余談ですが、山々の「々」って漢字ではないそうです。ご存知でした？ 私はついこの間知りました。
読点「、」や句点「。」と同じ記号の仲間で、“同の字点（どうのじてん）”というそうです。
ちなみに、「ゝとヽ」は“一の字点”、「〻」は“二の字点”、「〱」は“くの字点”、とそれぞれ名前が付いています。（“くの字点”は端末によっては文字化けしているかもしれません）
なお、かな漢字変換で、「々」を出したいときには、「おなじ」や「どう」で変換できます。

それから、辞書には「山々」が載っていないのもびっくりです。「山山」で載っています。堂々も堂堂です。今、辞書を引いて確認してみたところなので、ついでに「山山」の意味を書き写します。（山山って書くと山岳地帯をイメージしてしまうなあ）
『熱望するが実際にはそうできない時にいう』・・・うまい説明だなあ（辞書だから当然とはいえ、こういうように、平易な言葉で正しく説明したいといつも思っています。平易に説明したいのは山々なんです、、、笑）。

ということで、このノートでは、“ユースケーステスト”と書いていますが、正確に書けば、“ユースケースの周辺のテスト”です。

強いてこのノートで言っているユースケーステストを定義するなら、「UMLなどで言うユースケースをもとにして、利用者の立場からテスト対象の利用の流れをテストする技法」でしょうか。
ということで、このnoteでは、「ユースケース」、「利用者の立場」、「利用の流れ（≒シナリオ）」あたりのテストを作ろうとしたときに参考になる話を書きたいなあと思います。
今回は、その基礎となるユースケースのことについて書きます。

≡ ユースケースとは

ユースケースもよく分からない用語ですよね。まずはISTQB FLシラバスを読んでみます。

各ユースケースは、1つのサブジェクトと1つ以上のアクターとの相互作用による振る舞いを明確にする（UML 2.5.1 2017）。ユースケースは、相互作用とアクティビティ、さらには事前条件、事後条件で記述できる。必要に応じて自然言語でも記述できる。

こちらを読んで「よし、分かった」という人は少ないんじゃないかな？ と思います。少しずつ読んでいきましょう。

各ユースケースは、

ユースケースの概念が無い人に向けて、いきなり「各」です！ 怒りが湧いてきます（笑）が、ぐっと堪えて読み進めましょう。前半の1文は、

各ユースケースは、1つのサブジェクトと1つ以上のアクターとの相互作用による振る舞いを明確にする（UML 2.5.1 2017）。

説明なしにサブジェクトとアクターが出てきますが、英語圏の人には一般用語なのかもしれませんので、そこは許します。←えらそう（笑）
よく読むと、「1つのサブジェクトに1つ以上のアクターが存在する（アクターゼロはあり得ない）」ことと、「サブジェクトとアクターとの相互作用による振る舞いを明確にするものが各ユースケース」であると読み取れます。

ということで、「サブジェクト」と「アクター」と「ユースケース」について説明します。

こちらは、日本のWikipediaのユースケース図のページに載っていた図です。（日本語で描けばいいのに……）
英語版のWikipediaの方がゴチャゴチャしていますが、内容はほぼ同じです。

シンプルなユースケース図のほうで説明します。

ユースケース図を再掲します。

この図の四角形をサブジェクト、左右にある人の形をしたものをアクター、四角形の中にある4つの楕円形をユースケースと呼びます。

ユースケース図は作成する物（システムやサービス）の要求をユーザーと対話しながら聞き出して理解するときに使われます。

2005年のJaSST '05に「クイズ100人に聞きました」というセッションがありました。
テス太郎が誕生したのは、このセッションです。（本家の「クイズ100人に聞きました」というTV番組の百太郎マーク部分がテス太郎でした）
上記リンクから会場の様子を見ることができますが、答えが隠されたパネル画面が投影されています。

司会（関口宏役）は榊原さんで、裏方のナレーション（橋本テツヤ役）はにしさんで、得点の合計計算はシステムではなく宮崎大の片山先生が暗算で行ったというドリームチームでした。もちろん私は客席から、「あるー！ あるー！！」って叫んで楽しむ係でした。
解答が伏せられたパネルをめくるシステムは大月美佳先生（みかまま）が開発しました。
開発前に、みかままが「何をつくったらええのん？」という相談を榊原さんにしているところに偶然居合わせました。
そのときに、榊原さんは、テーブルの端にあった紙ナプキンのようなもの（普通にレポート用紙の切れ端だったかも、、、複数枚だったことは覚えているのですが……）に、ササッとユースケース図を描いて大月先生に説明されていました。で、大月先生も「ふむふむ、了解した」と仰っていて。
ああ、いいもの（神々のやり取り）を見せてもらったなーって思いました。

※ 上で「得点の合計計算はシステムではなく片山先生が暗算で行った」と書きましたが、榊原さんが描いたユースケース図のサブジェクト枠の中には「得点の合計計算を実施する」というユースケースが抜けていたのかもしれませんね。

閑話休題、この図の読み方の説明をします。

まず、サブジェクトに“Restaurant”と書いているのは、「検討対象のシステムはレストランで、開発する範囲はこの四角の中」ということを表しています。「サブジェクト」のことを「システム境界」と呼ぶことがあります。（Twitterアンケートによると、私の周りの人は、システム境界と呼ぶ方が多いです。ユーザー（アクター）とシステムとの境界を明らかにすることは、何を作るのかを明白にするうえでとても大切ですから）

次に、アクターですが、向かって左のアクターは“Food Critic”、criticは批評家とか評論家の意味ですから“Food Critic”は、「食リポーター」（料理評論家？）でしょうか（英語のWikipediaではClientですので単に顧客を表しているだけかもしれません）。右のアクターは“Chef”ですから「シェフ（料理人）」ですね。

アクターは人の形で表現しますが、このマークのことを「スティックマン」と呼びます。日本語では「棒人間」と呼ぶことが多いです。
「棒男」ではないのですね。😉

最後に4つのユースケースですが、上から「食べ物を食べる」、「食事代を支払う」、「ワインを飲む」、「料理を作る」です。そして、食リポーターから上の3つに線が引かれ、シェフから「料理を作る」に線が引かれています。この線を「関連線」といいます。関連線は「ユースケースと、それを使うアクター」と結びつけるものです。

「関連線」にはクラス図のように多重度を書くこともあります。でも、私はユースケース図の良さが失われるような気がするので、ユーザーが多重度について言及しなければ書きません。

人と言わずにアクターと言っているのは、他のシステムなど「人以外のアクター」もあるからです。

ここまでくれば、「レストランシステムとは、食リポーターが、食べ物を食べ、食事代を支払い、ワインを飲み、シェフが調理する範囲を取り扱うもの」ということがわかります。

これで、「各ユースケースは、1つのサブジェクトと1つ以上のアクターとの相互作用による振る舞いを明確にする（UML 2.5.1 2017）」までは納得していただいたのではないかと思います。

細かいことですが、ここで、【ユースケースは実行順序を表していない】ことに注意してください。実行順序なら、「料理を作る」、「食べ物を食べる」、「ワインを飲む」、「食事代を支払う」の順番に並びますが、そうなっていません。関心の強い順番に並んでいることが多いように思います。
また、私がこのnoteの本文で書いたユースケースの名前がすべて「〇〇を××する」という構文になっているのは偶然ではありません。ユースケースには、「〇〇を××する」と実現したいことをシンプルに書いてください。最初のうちは、フローチャートのように実装の情報（制御の流れの詳細）を書きがちですが、そうならないように気をつけてください。

ユースケースをシンプルに描くコツの一つに、「『CRUD』はそれぞれのユースケースに分けずに『XXを管理する』と１つにまとめてしまう」方法があります。
電話帳のアプリケーションのユースケースを作るときに、「電話番号を登録する（Create）」、「電話番号を検索する（Read）」、「電話番号を更新する（Update）」、「電話番号を削除する（Delete）」の4つのユースケースを作らずに、この4つを、「電話番号を管理する」という一つのユースケースにまとめてしまうというやり方です。図はどうしても面積を取りますので、とてもお勧めのテクニックです。

後半の1文に続きます。

ユースケースは、相互作用とアクティビティ、さらには事前条件、事後条件で記述できる。必要に応じて自然言語でも記述できる。

「ユースケースは」と書いてありますので、先ほどの例で言えば、「食べ物を食べる」、「食事代を支払う」、「ワインを飲む」、「料理を作る」のそれぞれの話です。
ここでは、最後の「必要に応じて自然言語でも記述できる」に着目してください。ユースケースを自然言語で記述したものを「ユースケース記述」と呼びます。

自然言語で記述するとはいえ、「ユースケースは、相互作用とアクティビティ、さらには事前条件、事後条件で記述できる」とあるように、記述する項目が概ね決まっています。そこで、その項目をテンプレート化すれば、ユースケース記述の十分性が上がります。これまで識者が作成したユースケース記述のテンプレートが何種類かあります。

こちらは、私が使っているテンプレートです。このテンプレートの右端の「サンプル」列をテスト対象のユースケースに書き換えます。

さて、ユースケースといいますと、ユースケース図があまりに有名なので、ユースケース図から直接ユースケーステストを作ろうとする人が多いのですが、それはお勧めできません。図はシンプルに描いてあるからです。
ユースケース図を作った本人なら問題ないのかもしれません。でも、別の人がテストを作るには情報が少なすぎます。
ユースケース図に描かれているユースケース（楕円形）について、一つずつ（上記のテンプレートを使って）「ユースケース記述」を書き、その「ユースケース記述」からテストを作るようにします。そうしませんと、ユースケーステスト設計レビューも意見が発散してしまうのでやりにくいです。

「ユースケース図から直接テストを作るな、ユースケース記述から作れ」と言われても、そもそも、開発者が「ユースケース記述」を書いていないとおっしゃるかもしれません。さらに言えば、ユースケース図すら作らない組織の方が多いかもしれません。その時は、テストエンジニアが作ってください。

テストでは「ユーザーの視点」が大切といわれます。異論のある人はいないと思います。開発者が「仕様書通りに動くことを完璧に確認した」あとに「それでは利用者の立場で動かして問題が出ないことを確認する」のがテストの役割の一つです。
であれば、テスターには、利用者の要求を熟知していることが求められます。そして、利用者の要求を熟知しているかどうかは、「ユースケース図」と「ユースケース記述」がスラスラ書けるかでわかります。

先に書いた通り、ユースケースには、「フローチャートのように実装の情報（制御の流れの詳細）」は書きません。「どのように実現するか（設計・実装）」ではなく「何を作るか（要求・仕様）」に焦点があたっているのがユースケースです。
集めたテストベースから、「ユースケース図」と「ユースケース記述」を書く過程で、要件リストや仕様書の曖昧性や不備に気が付くことも多いと思います。要件リストや仕様書のレビュー時にテスターが、「ユースケース図」と「ユースケース記述」を書けば、良いパースペクティブレビューとなることを請け合いです。（ついでに書くと、この時に「原因結果グラフ」も描くことをお勧めします）

≡ 様々なユースケース

ユースケースは、スウェーデン生まれのヤコブソン（Ivar Hjalmar Jacobson）が、エリクソン社でソフトウェアの機能的要求を特定するために考案した振る舞いを把握するための技法で、1986年に発表されました。

機能的要求や振る舞いなので、「非機能要求」についてはユースケースにはほとんど表現されません。←注意点です。

ユースケースは、その後、1990年代にコーバーン（Alistair Cockburn）らによって改良が進められました。その一つとして、コーバーンが描いた絵があります。

こちらは、コーバーンが「ユースケースと言っても色々ある」という説明で使った絵の要素を描いたものです。タイトルにあるように、雲・凧・波・船・海・魚・泥・貝の8つの要素が1枚に収められています。

8つの要素に加え、空の上の方は白く、段々と青みが濃くなり、海底は黒色となっています。

絵の左側にある「雲・波・海・泥」は刻々と形を変えるものの象徴で、右側の「凧・船・魚・貝」は形がしっかり決まっているものの象徴です。

上からビジネスレイヤー（雲・凧）、ユーザーレイヤー（波・船）、機能レイヤー（海・魚）、部品レイヤー（泥・貝）を象徴しています。
上に行けば行くほど「なぜこのソフトウェアが求められるのか」に答えるユースケースを書く必要があり、下に行けば行くほど「どのように作られていて、それで欠陥はないのか？」という問いに答えるユースケースを書く必要があります。

ユースケーステストをするときにも、「（テストレベルに合わせて）どのレイヤーのユースケーステストをしようとしているのかを考える」ことが大切です。さらに、テストは実際に手を動かして結果を記録するものですから、抽象的な「雲・波・海・泥」よりも、具体的な「凧・船・魚・貝」のユースケース記述が望ましいものです。

≡ 終わりに

今回は、今回はユースケーステストの基礎編についてでした。一言でまとめれば、「ユースケース図からではなくユースケース記述からテストを作ること」です。約束だよ。（笑）

次回は「ユースケーステスト」の実践編となります。ユースケース記述からどうやってテストを作るのかについて書く予定です。