オープニングと番組紹介
皆さん、こんにちは。B-Testingのブロッコリーです。 このB-Testing.fmは、QAエンジニアである私、ブロッコリーが、テストや品質に対する私なりの考えを、約10分間で語っていくポッドキャスト番組です。
以前に引き続き、自分が聞いている、ポッドキャストの感想を、このオープニングでは話そうかなと思うんですけれども、今回紹介するのはですね、はすみしょうのリクジャムですね。
これは、ポッドキャストというか、ラジオ番組で、ポッドキャストでも配信しているものなんですけれども、その中で、ちょっと前になるんですけれども、第17回のやつが良かったなと思っていて、この回はですね、水曜日のダウンタウンの企画、ザ・スベリドリームマッチの裏話が色々聞けて良かったなと思っています。
このザ・スベリドリームマッチって何かっていうと、なかなか笑いが取れない、滑り続けている芸人と人気芸人でユニットを組んで、コントや漫才を披露していくっていう企画で、ダウキューマンのはすみさんは、えんじんこうたろうさんというピン芸人さんとユニットを組んだんですね。
その時に、結構即興でコントを作ったとかではなくて、はすみさんがえんじんこうたろうさんの作品を事前に見た上で分析して、えんじんこうたろうさんに合った台本を作ってきたんですね。
その結果、本番でしっかりと笑える良いコント作品になってたなと思っていて、かつすごい良かったなと思うのは、そのユニット1回こっきりだけの関係性ではなくて、結構交流が続いてて、どうやらその後にあったダウキューマンの単独ライブとかにも観覧しに行ってるみたいで、交流が続いてて良い関係性だなというふうに感じましたし、
そういうような裏話、いろいろと詳しく喋っているので、もし水曜日のダウンタウンのザ・スペリー・ドリームマッチをご覧になった方は、ぜひこの放送も聞くと面白いかなと思います。概要欄にリンクを貼っておきます。
ユースケーステストとシナリオテスト
今日は、ユースケーステストの最後になるとは思うんですけども、ユースケース図やユースケース技術を基にどういうふうにテストに使っていくかについて話していきたいと思います。ということで、今回もbtesting.nlmスタートです。
ということで、今回はユースケーステストについて喋っていきたいと思います。ユースケーステストっていうのは何かっていうと、改めて言うとユースケーステストっていうのは、ユースケースで具体的にしたコンポーネントまたはシステムの意図される使われ方をエミュレートするトランザクションベースおよびシナリオベースのテストを可能にするものです。
JCQBのアダバンスレベルのテストアナリストの調査に書かれています。ユースケース図やユースケース技術を基にして、実際にどういうふうに使われるのかっていうのをトランザクションベースとかシナリオベースで書くと言っています。
特にシナリオベースのテストっていう言葉、ちょっと余談なんですけれども、シナリオベースのテストとかシナリオテストとか呼ばれるものについて話していきたいなと思います。このシナリオテストっていうのがちょっといろいろと厄介というか認識が人それぞれによって違うところかなと思っています。
ISTQBの用語集の中のユースケーステストの項目では、こういうふうに説明がされています。ユースケーステストとはブラックボックステスト技法の一つで、ユースケースの動作を実行するようにテストケースを設計する。その同義語としてユーザーシナリオテスト、シナリオテストっていうふうに書かれているんですね。
このシナリオテストっていうのは、これはちょっと自分はISTQB、JSTQBとの解釈が若干違うんですが、これだとユースケーステストと同義語としてシナリオテストを書いていますが、個人的にはシナリオテストっていうのはユースケーステストのようなテスト設計技法っていう捉え方というよりかは、あくまでもそれを記載する形式の一つ。
記載する形式の一つってどういうことかというと、例えばDVDレンタルのテストケースを例にとっていると、例えば実際にマインドマップを書いて、鑑賞番号の入力、鑑賞の有効性確認とかそういうふうなマインドマップを書いて表現してもいいだろうし、過剰書きで表現してもいいと思うんですね。
鑑賞情報の入力っていう過剰書き一つ目で一筋下げした上で鑑賞の有効性確認みたいな、DVDコードの入力っていうのがDVD情報の提示がされてみたいに過剰書きで書いてもいいと思うんですよね。
そういうふうなマインドマップ形式とか過剰書き形式以外の表現の方法としてシナリオの形式での記載方法があるかなと思っています。一番目にこういうことをやってみたいに書くかなと思っています。
よくこのシナリオテストっていうのがテスト設計技法みたいに言われるんですが、個人的にはこういうふうに表現する方法の一つ記載形式の一つかなと思っています。
DVDレンタルで見るテスト作成手順
ということでまずちょっとユースケーステストの話にちょっと戻りたいと思いますが、じゃあ実際にユースケーステストの作り方としてはどういうものかっていうと、これはアスターセミナー標準テキストのちょっと一つ前バージョン3.1.1のところにはこういうふうに書かれています。
ユースケース記述を基に基本フローの1個のテストケースと代替例外フローごとに1個のテストケースを含むように作成するものがユースケーステストですよ。
ユースケーステストっていうのは基本フローを最後まで実施してユースケースの目的を達成するのを確認したりとか、あとは基本フローの各ステップで代替フローや例外フローに寄り道する。
寄り道なので基本フローに戻ってくるっていうのが大体のものではあるんですけれども、っていうのが秋山さんのブログ記事の中には書かれています。
要はユースケース記述を基に前回話しましたが、ユースケース記述の中では基本フローを書くものもあればそこからの代替例外フローも書くことができるって言ってましたけれども、それぞれに対してシナリオ形式で実際の手順を記述するみたいなそういうものがユースケーステストになるかなと思っています。
その作成手順としてはまずはユースケース記述を基に実質するべきフローを考えて、そのフローを基にシナリオ形式のテストを作成するという作成手順になります。
今回ちょっと具体的な例として、前回のユースケース記述で作成したDVDを貸し出すというユースケースの記述に対して考えていきます。
そうするとまず実装するフローとしてはまず正常なパターンとして店員が会員証情報を入力してシステムが会員証の有効性とお客への貸し出し状況を確認して、
DVDコードを店員が入力してシステムが料金を示して店員が入金をしてシステムがレクシートを発行するというような一般的な正常系の基本フローのパターンとか、
あとはいろいろな寄り道のパターンとして、例えば会員証情報を入力して会員証の有効性とお客への貸し出し状況を確認して、
DVDコードを入力してその時に貸し出し中の商品がありますよっていう風な例外フローが発生して、
それを解決したらシステムが料金を示して入金をしてレシートを発行してお客さんにDVDを貸し出しているみたいなこういう寄り道のパターンもあるかなと思っています。
これを実際にユースケーステストとしてどういうふうに書くかっていうのを、この寄り道のパターンを使ってシナリオの例を次のページに書いています。
延滞処理を含むシナリオの記述例
そうするとどうなるかっていうと、まずは流れとして、まず操作としてお客は会員証を持っているという事前条件があって、
その時にまずは操作として会員証のバーコードを入力する。そうすると期待結果として画面に会員証情報が表示されるっていう期待結果があるはず。
これは普通の正しい操作ですね。
続いても正しい操作として店員さんがDVDのバーコードを入力する。そうすると期待結果として画面にDVDのタイトルと料金が表示されるというのが期待結果としてあるんですが、
ここでエラーが発生する。何かというと、貸し出し延滞中のDVDがありますよと。延滞中ありの画面に遷移するという期待結果になるかなと思っています。
この延滞のやつをちゃんと返さないと新しいのを買い入れられませんよみたいなそういう風な画面に遷移する。これも追加で期待結果として書いてもいいかなと思います。
そうすると基本フローから外れて例外フローのリカバリ操作に入ります。
そうすると店員は延滞中のDVDと延長料金をお客さんから受け取ります。
それをシステムに入れることで延滞が解除されて、支払料金に遷移しますと。
そこからまた正しい操作に戻って店員さんが今回のレンタル料金をお客に提示して入金するみたいなことをして、
その結果期待結果として金額、重量、積み金に遷移すると。
そうすることによって成し遂げたい目的であったレシートとともにレンタルDVDを貸し出すという目的が達成されました。
こういう風に書くということになります。
ユースケース記述の時には店員とシステムをそれぞれ交互に書くみたいな話をしていましたけれども、
実際にユースケーステストとしてシナリオ形式で書いていくとあくまでも操作をするのは店員さんが操作して、
そのときのシステムがどういう風なフィードバックをするかというのは期待結果として表現されるみたいなことになる。
業務全体を通したテストのメリット
じゃあ何でユースケーステストを作成すればいいのか。ユースケース記述のところだけでいいじゃないかって思うかもしれませんが、
ユースケーステストを作成するメリットとしては、まずエラーにつながる失敗操作によって例外書類とかに行ったときにリカバリー操作をすることで、
うまくリカバリーできたようで実は完全にはリカバリーできなかったみたいな全体の業務の流れを見たときに初めて気づくようなそういう不具合を発見できます。
これはあくまでもユースケーステストがシステムテストとか受け入れテストで使われることがよくあるっていうのは、
最初前回のときに話したと思うんですけれども、あくまでもこれ前提が単体テストでちゃんと実施済みであることが前提で、
単体ではうまくいくんだけれども、全体の業務を通してやったときにうまくできなかったっていう不具合を見つけたいっていうのが、
ユースケーステストを作成する目的、狙いでもありますし、それがメリットにもなってきます。
なので、一つの画面の中でも単純な不具合を見つけることが目的じゃなくて、業務としてちゃんと流せるかどうかっていうのを大事にしています。
今回の場合、どういう不具合が想定されるかというと、今回の場合は、例えばさっきのリカバリーで延長料金を受け取ったときに、
延滞が解除されて支払い画面に遷移するっていうシナリオっていうふうにさっきほど言ったんですけれども、その後今回のレンタル料金を入金するっていうところで、
今回のレンタル料金に延長料金も今受け取ったはずなのに、その延長料金が加算された金額が提示される不具合がもしかしたら見つかるかもしれない。
っていうような業務流れでやっているときに初めて気づくような不具合にぶつかることがあると思います。
あとは今回のもの、延長料金を受け取ったら延滞を解除されて支払い画面に遷移するっていうシナリオ形式のテストを書きましたが、
システムの単純さと業務効率の選択
もしかしたら延長料金を受け取った段階でそれを業務の続きをさせるんじゃなくて、一旦終了して始めからやり直させるシナリオの方がいいっていうふうに判断するかもしれません。
これはシステムの複雑さとユーザーの使いやすさの天秤をかけることになると思うんですけれども、
延滞の処理をしたらもう一回最初から始めてねっていうふうにやると、多分システムとしてはすごいシンプルにできるわけですよね。
一方で先ほど話していたような延長料金を受け取ったら延滞解除され支払い画面に遷移するっていうのは、
先ほど言ったように料金の加算された金額が提示される不具合とかっていうのが発見される、そういう不具合が出てしまう可能性はあるんですが、
業務としてはまた最初からもう一度やり直すのかっていうふうなことにならずに済むので、業務の効率性は上がるかもしれない。
システムのシンプルさを取るか、業務がいかに効率よくできるかっていうのを取るかっていうのは、
システムとしてどうするかっていう話にもつながってくるので、これがユースケーステストとしてシナリオ形式で記述することの良さの一つかもしれません。
ということで、今回ユースケーステストまで話していきましたけれども、全体を通したまとめとしてはユースケース図でまずざっくりと認識を合わせて、
ユースケース記述のときにはユースケースで表現できない詳細な工程を記述しますと。
例えば会員証が有効期限内かどうかみたいなのはユースケースでは記述しませんっていう話は前回のエピソードでも話しました。
また、このユースケース記述をもとにユースケーステストを書くことで期待値が明確になったりとか、
あとはリカバリできたようでうまくリカバリできていない不具合を見つけ出したりとか、
もしくはシステムをシンプルにするんだったら最初からやり直させたほうがいいのかとか、
そういうふうなシステムとしてどうすればいいのかっていう話にもつながってきます。
実務活用とドメインモデル
個人的にはこのユースケーステストっていうのは今言ったように、
じゃあそもそもシステムとして初めからやり直させるのかとか、そういう話にもつながってきますし、
別にコードの中身の話をしてないんですよね。業務の話を中心にしているので、
コードとかを書く前の段階からこのユースケーステストっていうのは書き始めてもいいんじゃないかなと思っています。
実際にどういうふうな要求とか要件があってとかっていう段階で、
じゃあ今回の業務ってどういうものがあるんだろうっていうので、
最初にプログラムの実装とかする前の段階から、じゃあユースケース図を書いてみんなに認識合わせましょうとか、
そういうふうにやっていくことが大事かなと思います。
それも含めて実際の業務で活用する際には、あくまでユースケースっていうものはUMLの一つなので、
これだけ完結できるわけではありません。実際のいろいろなパターンを全部網羅するっていうのを目的としていないので、
業務ってこういうものだよねっていう認識を合わせるためにユースケースを使ったりする。
なので実際に業務で使うときはユースケースを書く前とか書く後とかに指引き足す言語をまとめた辞書、
ドメイン辞書と呼ばれるような、これってどういうことだろう。
例えば延滞料金とはどういうことかみたいなそういう言語、そのドメインの特徴となる言語を表現したものをまとめた辞書、
ドメイン辞書を作ったりとか、あとは概念を抽象化したドメインモデルっていうのも作成するかなといいかなと思います。
そういうのも含めて書籍ユースケース駆動開発実践ガイドを読むといいのかなと思っています。
あとユースケース駆動開発実践ガイドだけではなくてですね、もう一ついいですね、ユースケース実践ガイドというものもあってですね、
これは今年ですかね、復刻版がちょうど書籍刊行されました。
そちらもぜひこのユースケースを書く上で興味のある方は読んでみるといいかなと思っています。
まとめとエンディング
はい、ということで以上でユースケーステスト3回にわたってお話ししてきましたが、
実際に先ほども言った通り業務を考えるときによく使えるものですので、ぜひ興味のある方は業務で実際に試してみてください。
はい、ではエンディングです。
btesting.fmではリスナーさんからのお便りを募集しています。
エピソードの感想や私に聞いてみたい質問やテストのお悩みなど、どんなことでも構いません。
投稿フォームは番組概要欄にあります。
エピソードの感想は、ハッシュタグbtesting、beanscotestingでxのポストをお願いいたします。
今回まで3回にわたってユースケーステストについて話していきましたが、
ユースケーステストって実際こういう感じなんだとか、
実際業務で使ってみたらうまくいったよとか、そういう話も聞けると嬉しいなと思っています。
もしもこれからも聞きたいという方は、オートモーションポッドキャストアプリで番組のフォローもお願いします。
最新回が上がったときにすぐに気づけます。
最近は結構、もともとのプラン通り毎週月曜日の朝に上げているんですけれども、
とはいえ、月曜日このポッドキャストあるの忘れてたとか、
そういう風になっていつも毎回聞けてなかったとかあるかもしれないですので、ぜひフォローもお願いします。
ということで今回はここまでです。
それではまた次回。バイバイ。
