第98回：　ユースケーステスト（後編）

≡ はじめに

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

前回は、ユースケーステストの基礎について書きました。今回はユースケーステストの実践編として、ユースケース記述からどうやってテストを作るのかについて書きたいと思います。

前回の復習となりますが、ユースケーステストでは、

「ユースケース」、「利用者の立場」、「利用の流れ（≒シナリオ）」

の3つをおさえることが大切です。

今回は“いつも以上にゆっくり読む”ことをお勧めします。サラッと読んで判るように書けなかったからです。

≡ 最小限のユースケーステスト

ユースケーステストの作り方については、キャッチイメージに書いてあります。

テストケースの作り方
基本フローの1個のテストケースと、代替・例外フローごとに1個のテストケースを含む。

「たったこれだけ？」と思われたかもしれませんが、基本はこれだけです。ただ、「代替・例外フローごとに1個のテストケース」を「代替フローで１つと例外フローで1つ」と勘違いしないでください。

具体例を見てみましょう。

こちらは、キャッチイメージの「前ページ」です。キャッチイメージを抜粋します。

前ページのユースケース記述の場合：
テストケース１：基本フロー 1→2→3→4→5→6→7
テストケース２：代替フロー 1→2→2A
テストケース３：例外フロー 1→2→3→3A

※　キャッチイメージにあるASTERセミナーテキストでは上記引用の「例外フロー」部分が「代替フロー」となっていますが、ASTERセミナーテキストの誤記です。（すみません。テキスト作成時の私のミスです。レビューでも見つからず、このテキストでセミナーした時にも見逃してしまっていました。すみません 🙇‍♂️）

基本フローは、ユースケース記述の5行目にある、1から7の利用の流れを指していますので、テストケース1となります。

代替フローは、「2. システム：会員証の有効性を確認する。」のときに、3以降のフローが、「2A. 会員証の有効期限が切れていた場合、貸し出しできない。」というフローに置き換わるので、テストケース2となります。

例外フローは、「3. システム：客への貸し出し状況を確認する。」のときの例外のフローである、「3A. 返却期限を過ぎて貸し出し中の商品がある場合、新規商品を貸し出しできない。」というフローに置き換わるので、テストケース3となります。

※ ここで、代替フローと例外フローはテキストでは一つずつしか書いていませんが、普通は一つずつではなく、どちらも複数（多数）あることに注意してください。

基本フロー（ハッピーパスと呼ぶ人もいます）は1つだけですが、代替フローと例外フローは複数あることが普通です。（テキストでは1つしか書いてありませんが、イレギュラーな出来事はたくさんありますので、代替フローと例外フローはたくさんあります。）← 大切なことなので2度書きました。

実際に、商品開発では、いわゆる正常系の処理の実装よりも、異常系の処理の実装の方が多くて面倒なものです。

例えば、スーパーのレジは例外処理の塊です。お客様は、3本90円のキュウリをレジ打ちし終わった後に、「やっぱ2本でいいや」と言い出すことがあります。3本90円のキュウリは1本30円かというと、そんなことはありません。ばら売りでは、1本35円かもしれません。「2本ということですね。70円となります」と訂正処理をした瞬間に、「なんか、損した気がするから、やっぱり3本ください」というかもしれません。😢

他にも、スーパーのチラシとスマホのLINE広告割引とその店のカードに付くポイントと株主優待との関係、そして軽減税率処理等々。

レジ打ちは人がしているので“例外について際限なく店側が引き受けている”のです。
（今後はセルフレジの普及が進み、例外処理は激減する方向に変わってくると思います）

セルフレジ以外では、これらの例外処理や特殊ロジックについて、レジに並んでいるお客様を待たせることなく処理できるソフトウェアが望まれてきたことはいうまでもありません。

単純にバーコードから商品IDと金額を読み取り合計を求め、消費税率を掛けて請求金額を通知して入金に対するお釣りとレシートを発行する基本フローだけなら1週間もあればレジのテストは完了すると思いますが、それだけでは済まないことが伝わりましたでしょうか。

「基本フローの1個のテストケースと、代替・例外フローごとに1個のテストケースを含む」というユースケーステストの作り方の手順は簡単だけれど、実際にテストを作るのは難しいと思います。

また、全ての代替・例外フローが仕様書に記載されることは期待できません。というのは、代替フローと例外フローについて、お客様に「代替フローと例外フローにはどのようなものがありますか？」と質問しても、代表的な例をいくつか答えてくれるだけだからです。

うまく聞き出す方法があります。それは、「（状況を提示して）この状況で何か例外処理をしたことがありませんか？」というヒアリング方法です。
レジなら、「秋に何か例外処理をしたことがありませんか？」というように聞くと、「そう言えば、秋祭りに町内会が発行したクーポンの対応に困ったことがあったっけ」と思い出してもらえることがあります。

要件（＝ユースケース）として拾えず、リリース後に「こんなこと」、「あんなこと」と、たくさんの未検討のユースケースが見つかるのが普通です。先に例として挙げた「3本90円のキュウリをレジ打ちし終わった後に、2本でいいやと言い出すお客様」は滅多にいないからです。
ところが、たとえ、月に1回であってもそういう例外事象が100個もあれば、平均すれば、1日に3回発生します。そのような商品は品質が悪いと思われますし、逆に、例外事象に上手く対応できるソフトウェアであればお客様の満足度が爆上がりします。

例外フローについては、「職場のノウハウ集」がないか聞いてみるのも手です。
特に事務系（総務・人事・経理）や営業では、作っていることが期待できます。人が関わると良く言えば「臨機応変」に対応しているものですから。

≡ 私がしているユースケーステストの考え方

具体例で考えてみます。先に、

代替フローは、「2. システム：会員証の有効性を確認する」のときに、3以降のフローが、「2A. 会員証の有効期限が切れていた場合、貸し出しできない」というフローに置き換わるので、テストケース2となります。
テストケース２：代替フロー 1→2→2A

と書きました。

ここで考えてほしいのですが、「1→2→2A」のテストでよいのでしょうか？
文章で書けば、

1. 店員：会員証を入力する。
2. システム：会員証の有効性を確認する。
2A. 会員証の有効期限が切れていた場合、貸し出しできない。

です。
冒頭に、「ユースケーステストでは『ユースケース』、『利用者の立場』、『利用の流れ（≒シナリオ）』の3つをおさえることが大切です」と書きました。

考えてほしいことは、

「（レンタルビデオ店で）DVDを貸し出す。」というユースケースに対して、利用者の立場で、「1→2→2A」の利用の流れ（≒シナリオ）

のテストで良いか？

 という点です。
私はマズイと考えます。その理由は「ユースケースの目的を達成していない」からです。

このユースケースの目的は、ユースケース記述の「ユースケース名」にあるとおり「（レンタルビデオ店で）DVDを貸し出す」です。しかし、この代替フローは2Aで終わっています。
2Aは「2A. 会員証の有効期限が切れていた場合、貸し出しできない」です。
「DVDを貸し出す」ことが目的なのに、「貸し出しできない」で終わっては目的を達したシナリオとはいえません。

実際のレンタルビデオ店のシーンを想像してみてください。
会員証の有効期限が切れていた場合、「貸し出しできない」で終わるでしょうか？
私はそうは思いません。有効期限が切れていたなら、会員証の有効期限の延長もしくは新規会員証の発行をして問題を解決したうえで、基本フローの「3. 客への貸し出し状況を確認する」というステップに移行すると思うからです。

ですからユースケーステストは、
　・　基本フローを最後まで実施し、ユースケースの目的を達成する
　・　基本フローの各ステップで代替フローや例外フローに寄り道する
　・　寄り道なので、基本フローに戻ってくる
方法が良いと考えます。

≡ 私がしているユースケーステストの作り方

上に書いた考え方に基づいて、私は次のテンプレートを使ってテストシナリオを作っています。

最初にユースケース記述に書かれている「事前条件」をセットします。
あとは、基本フローを順番に実行するのですが、「正しい操作」→「エラー発生」→「リカバリ操作」のセットでシナリオを描いていきます。
「エラー発生」部分が代替シナリオや例外シナリオの入り口となります。
そして、エラーはリカバリ操作により解決され、利用の流れは、基本フローに戻ってきます。

「リカバリ操作」として「リブート」や「リセット」はできるだけ行わないようにしてください。「リカバリ操作でシステムのどこかにゴミが残る」イメージを持ってください。リブートやリセットは「リカバリ操作で発生したゴミ」も掃除して、きれいにしてしまう（若化してしまう）からです。

そして、基本フローの最後のステップが成功し、ユースケースの目的が達成されたら終わりです。
基本フローの1つのステップに対して複数回のエラー発生による分岐が望まれます。

できあがったユースケースシナリオテストは以下の通りです。

≡ 終わりに

今回は、今回はユースケーステストの実践についてでした。

「ユースケースの目的を達成するまで、エラーを発生し、寄り道フローを通るシナリオを作る」ことがポイントでした。

次回は「組み合わせテスト」の基礎編となります。組み合わせテストはどういう順番で説明すると分かりやすいかいつも悩みます。自分の専門領域ですし、ゆっくり書こうかなと思っています。