オープニングと前回の振り返り
皆さんこんにちは、B-Testingのブロッコリーです。 このB-Testing.fmは、QAエンジニアである私ブロッコリーが、テストや品質に対する私なりの考えを約10分間で語っていくポッドキャスト番組です。
そうですね、最近こういう風にポッドキャストを撮っているわけなんですけれども、ポッドキャスト自身、自分もリスナーとしていろいろなのをよく聞いているんですね。
最近はですね、クリームシチューの有田さんがやっている有田農がお気に入りでして、毎回一つテーマに沿った話をフリーで話していくっていう番組なんですけれども、
その一つ前のシーズンでやっていた有田農シーズン3.5の有田農人というシリーズが、最近よく聞き返しているというかですね、
ゲストの方を招いて、特に有田さんに馴染みの深いゲストの方を招いて対談しているという番組ですね。
その中でエピソード5の藤井智史さんの回が特にお気に入りでして、この方何やっているかというと、テレビ朝日のクリームなんとかのプロデューサーだったんですけれども、
このクリームなんとかの立ち上げ話とか、あと当時少しなんとなく疑問には思ってたんですけど、しるしるみしる、これもクリームシチューが出ていた番組ですけれども、
しるしるみしるがなぜ週2で放送していたか、みたいなそういう話を話してくれて、すごい興味深かった、面白かったなと思っています。
期間限定らしいので、気になる方はぜひ聴きに行ってください。リンクも貼っておきたいと思います。
今回はユースケーステストの続きですね。ユースケース記述について話していきたいと思います。
ということで、今回もbtesting.fmスタートです。
ユースケース記述とは
ということで、今回はユースケーステストの続きですね。ユースケース記述について話していきます。
ユースケース記述とは何かっていう話に入っていくんですけれども、
まずユースケーステストの中で前回話したユースケース図の続きとして書かれることが多いものなんですけれども、
ユースケースっていうもの自体が相互作用とアクティビティ、さらには事前条件、事後条件で記述できる。
必要に応じて自然言語でも記述できるというふうにJSTIC-QBのシロバスには書かれていて、
それを実際にやる手法としてユースケース記述というものがありますと。
秋山さんのブログのところにはですね、ユースケース図に書かれているユースケース楕円形のやつですね。
について一つ一つユースケース記述を書くというふうに言っています。
これも具体的な例を一つ持ってきて、今日話したいなと思っています。
どういう例かというと、前回ユースケース図のエピソードの中で話したDVDレンタルのシステムの一つですね。
のユースケース、DVDを貸し出すについてのユースケース記述の例を書いていきたいなと思っています。
これを書くとですね、こんな感じになります。
ユースケース記述の例と基本フロー
ユースケースに対してのサンプルを一つ書いてみているんですけれども、まずユースケース名ですね。
そしてDVDを貸し出す。そしてそのユースケースを使うアクターは誰かというと定員さんですね。
まず事前条件を書きます。これは前提となる条件を書くことになるんですけれども、
今回の場合ですとお客さんが会員証を持っているというのが前提になります。
ユースケースの記述として、まず基本フローを書いていきます。
特に正常形の動作を書きます。
具体的にどういう風な流度で書くかというと、
例えば1番目、定員が会員証情報を入力すると。
そうすると2番目にシステムが会員証の有効性とお客への貸し出し情報を確認する。
その次が定員がDVDのコードを入力する。
4番目がシステムが料金を示す。5番目が定員が入金する。
6番目がシステムがレシートを発行する。
これで基本フローとしておしまいという風になります。
ここでの流度のポイントは内部処理は書かないという感じで、
あくまでも目的を達成するためのフローのみを記載します。
これが基本フローになるわけですけど、
この基本フローを書いた上で、代替フローとか例外フローというのがないかなというのを考えていきます。
代替フローと例外フロー
例えば今回の場合ですと、1番で定員さんが会員証情報を入力する。
2番の時にシステムが会員証の有効性とお客への貸し出し情報を確認するとありましたが、
この2番の時に会員証の有効ギレンギレが発生したらどうなるか。
あとは3番目でDVDのコードを入力するという風にやった時に、
そもそも貸し出し中の商品があるという場合はどうするかみたいな。
そういう風に基本フローから外れるような処理というのをここに記載しています。
その後最後に終了の条件としてお客にDVDを貸し出していることというのが最終的な期待結果になる。
こういう風に書いています。
ユースケース記述のポイントとメリット
このユースケース記述のポイントとしては、
アクターとシステムが基本的には交互に登場するというのがポイントになります。
というのもあくまでもシステムを扱っている人が出てきてユースケースを書くので、
定員が何かしらシステムに対して入力を行って、
そしたらシステムから何かしらのフィードバックが来るはずなんですよね。
なので基本的にはアクターとシステムが交互に登場するはずです。
というのがポイントです。
じゃあなんでこういうユースケース記述を書くのか。
前回話したユースケース図だけでいいんじゃないかという風にも思うかもしれませんが、
これはユースケース図では表現していない情報というのを表現できるのがメリットとしてあります。
例えば今回の場合ですとユースケース図のDVDを貸し出すというユースケースの図の中では表現しきれないような
会員証の有効期限を確認するみたいな詳細な工程を表現しています。
一方でユースケース図の方には会員証の有効期限を確認するというのは、
これは業務として明確にやりたいというところではないし、
あくまでもユースケース図はシンプルさを目指すというところがあるので、
表現しきれていないものとしてあるかなと思います。
つまり流度とか抽象度合いがちょっと違っているということですね。
あともう一つ、このユースケース記述を書くメリットとしては、
要件リストとか使用書の曖昧性とか不備に気づくことができます。
そのためには代替フローとか例外フローがいかに出てくるかということが
すごい大事になってくるかなと思います。
こういう場合になったらどうしようみたいなことを
ちゃんと思い浮かんでやっていくっていうのが大事かなと思います。
ユースケース記述を書くコツとしてなんですけれども、
ユースケース記述を書くコツ
あくまでも現実的なユーザーのトランザクションを書いたほうがいいです。
先ほど言った流度、ユースケース図よりかはちょっと細かい形になるんだけれども、
あくまでも分けることができない一連の情報処理の流度で書くことが大事です。
何を言ってるかというと、良くない例としては、
会員証入力ボタンを押すっていうユースケースの記述の一行を書いたりとか、
あとは会員証の番号を入力するとか決定ボタンを押すとかっていうのは
ユーザートランザクション一連の情報処理にはなってなくて、
一つ一つの操作を変えてしまってるので、少し細かすぎますと。
一方でこれらを現実的なユーザートランザクションとして考えると、
あくまでも会員証情報を入力するみたいな、そういう表現になるといいかなと思っています。
あとは先ほども言ったように、アクターとシステムが基本的には交互に登場するように書くのがコツかなと思います。
先ほど言った会員証番号を入力ボタンを押すとか、会員証の番号を入力して決定ボタンを押すっていうのは、
多分これぐらい細かく書いてしまうと、アクターが連続して出てくると思うんですよね。
会員証の番号を入力するっていう記述の一行に対して、
次にもまたアクターが決定ボタンを押すっていうふうに書いてしまうと思うんですけれども、
システムと交互に登場しないということは、それはユーザートランザクションが現実的じゃない、
細かすぎるルードになっている証拠にもなるかなと思っています。
まとめとエンディング
ということで、今日はこのユースケース記述について紹介していきました。
ユースケース図でざっくりと理解をした上で、
けどこれを実際に業務としてやるときはどういうふうなことをやっていくのか、
その中で代替処理とか例外処理ってどういうのがあるのかっていうのを書き出していくっていうことが大切というのをお伝えしていきました。
ではエンディングです。
btesting.fmではリスナーさんからのお便りを募集しています。
エピソードの感想や私に聞いてみたい質問やテストのお悩みなど、どんなことでも構いません。
投稿フォームは番組概要欄にあります。
またエピソードの感想はハッシュタグBテスティングでXのポストをお願いいたします。
もしもこれからも聞きたいという方はお手持ちのPodcastアプリで番組のフォローもお願いします。
最新回が上がったときにすぐに気づけると思います。
例えば今回はユースケース記述の話をしていきましたけれども、ユースケーステストについては次回また続きとして話していこうと思っていますので、
これ結局どういうふうにテストとして使うのっていうのを気になる方は是非そちらも聞くためにも是非フォローお願いします。
ということで今回はここまでになります。
それではまた次回バイバイ。
