オープニングと番組紹介
みなさん、こんにちは。B-Testingのブロッコリーです。 このB-Testing.fmは、QAエンジニアである私、ブロッコリーが、テストや品質に対する私なりの考えを、約10分間で語っていくポッドキャスト番組です。
オープニングではですね、私ですね、スポーツ観戦が好きなんですけれども、その中の野球観戦は千葉ロッテマリーズファン、ロッテファンでして、最近のロッテ、チーム成績はそこまで良くないんですけれども、ただ最近結構若者人気を狙っていろんな試作をしているなっていうところがあります。
その中でですね、ここ何年かやってですね、ブラックサマーウィークということをしてまして、夏の時期に合わせていろいろな限定ユニフォームを販売したりとか、結構その限定フォームかっこいい感じなんですけれども、あとはそれ以外にも本当に夏フェスに近いような雰囲気作りを作っていますと。
その中の一つですね、ゲームアフターパーティーとして、試合後のグラウンドでDJの音楽に乗ってフェスみたいな感じのことを行っているものがありますと。
YouTubeにもその動画が上がっているので是非見てほしいんですけれども、結構本当に若い人、あとは女性とかそういう人も来てもらえるような雰囲気作りを最近しているなと思っています。
そういうので、実際に入場者数が増えてお金がちゃんと売ろうったら、その分を投資してもらって、是非もう何年も遠ざかっている優勝を目指して、選手層をどんどんどんどん厚くしてもらえると嬉しいなと思っています。
ということで、今回はですね、新しい分野ですね、ユースケーステストについて話していきたいと思います。ということで、今回もbtesting.fmスタートです。
ユースケーステストとは
ということで、新しい分野、ユースケーステストについて話していきます。
今日はユースケーステストの全体像と、その中の最初の方に取り組むユースケース図について話していきます。
まずユースケースとは何かという話なんですけれども、JIS規格のほうではですね、ユースケースはシステム・サブシステムまたはクラスが提供する一貫した機能単位を表現する分類子の一種となるというふうに書いています。
JSTQBのシラバスの中ではですね、ユースケーステストは通常システムテストレベルおよび受入テストレベルで適用するというふうに書かれています。
そういうふうにユースケースを用いたテストになります。
秋山さんのノートの中にはですね、どのように実現するかという設計とか実装ではなくて、何を作るかという要求とか仕様に焦点を当てて表現できる技法ですよというふうに書いています。
今回このユースケーステストを紹介していくんですけれども、実はもともとJSTQBの中ではファンダメーションレベルで紹介されていました。
2018年版まではですね、ブラックボックステスト技法の一つとしてユースケーステストが紹介されていました。
ただし、2023年版のJSTQBのファンダメーションレベルのシラバスから残念ながら削除されてしまいました。
まだJSTQBのアドバンスレベルのテストアナリストには記載が残ってはいるんですけれども、
そういうふうにFLのシラバスから削除されてしまったので、あまり馴染みがない方もいるかもしれませんが、
自分としてはこの手法も知っておいたほうがいいなと思っているので今回紹介しています。
ユースケーステストの全体像とユースケース図
ユースケーステストってどういうふうな全体像があるかというと、まずはユースケース図を作ってざっくりとした認識合わせを行います。
その後、ユースケース記述という手法を使って、ざっくりとした認識合わせから詳細な工程を表現するということをしていきます。
そして、そのユースケース図やユースケース記述をもとにユースケーステストというものを作っていって、
その工程全体を行うテストを考えるという、そんな全体像になっています。
中のユースケース図についても今日話していくわけですけれども、このユースケース図とは何かというと、
アクターおよびユースケースをその関係とともに示す図になります。
今のが実企画で書いてあったものですけれども、秋山さんのブログ記事の中には、
開発者とユーザーが対話しながらシステム境界や必要なユースケースを表現し、こういうものを作ればいいと開発者が理解し、
こういうものが欲しいんだとユーザーが欲しいもののイメージを固めるものですと書いています。
なので目的としては、ざっくりと認識を合わせるということが本当に目的になります。
詳細の網羅というのは目的としていない技法になります。技法というかユースケース図はそういう目的になります。
ユースケース図の具体例：DVDレンタルシステム
具体的な例として、最近は少なくなってきましたけれども、実質店舗のあるDVDレンターのシステムというのを例題として持ってきます。
この時にどういうユースケース図を書くかというとこんな感じになります。
DVDレンターのシステムというものに対してレジ担当とか商品管理係とかがいて、その人たちがこのDVDレンターのシステムを触っていくという形になります。
この時のレジ担当とか商品管理係みたいな人のことをアクターと呼びます。
このDVDレンターのシステムというサブジェクトがあって、その中にこういうこともシステムで行えますよねっていうふうにどんどん書いていくのをユースケースと言います。
これらを書く図のことをユースケース図と呼ぶわけですね。
このポイントとしてはシステムを直接操作する人を記載するということです。
先ほどの最初に示した絵みたいにお客さんがDVDをレンタルするときにお客さんが店員さんにDVDを渡して、それをもとに実際にはレジ担当の人がDVDを貸し出す処理をしたりしますよね。
お客さん自身がDVDレンタルのシステムを触るわけではないので、あくまでもシステムを直接操作する人をアクターに記載するというところがポイントになります。
ユースケース図を作成するメリット
このユースケース図って何でわざわざそういうふうなことを書くのかという話に移るんですけれども、
例えばDVDレンタルのシステムを作ってくださいって言われたときに、各々が考えていることって違ったりするわけですよね。
先ほどみたいに店員さんに渡して店員さんがDVDレンタルの操作をする場合もあれば、もしかしたらセルフレジをイメージする人もいるかもしれません。
これらって実はユースケース図を書くと、こういうふうにお客さんが店員さんに渡す場合は先ほど示したようにレジ担当が商品係がっていうアクターになってきますし、
レジ担当の人はDVDを貸し出すというユースケースがある一方で、セルフレジの場合ですとDVDを借りるという行為をお客さん自身が行うみたいに
ユースケース図を書くことで、実はお互いに考えている、想像しているものが違っているんだっていうのをざっくりとした認識から理解できるというのがメリットになります。
なので、個々人が想像していたシステムのユースケースを具体化して比較して、その結果認識が違うんだっていうふうにわかるというのがメリットです。
エンディングと次回予告
ということで、今回はユースケーステストの最初として全体像、そしてそれとユースケース図についてしゃべっていきました。
次回以降ですね、ユースケース記述であったりとか、実際にそれを基にしたユースケーステストについて語っていきたいと思いますので、
これ以降どういうふうに使っていくのかっていうのを気になる方は次回以降をお楽しみに待っていてください。
はい、ではエンディングです。
btesting.fmではリスナーさんからのお便りを募集しています。
エピソードの感想や私に聞いてみたい質問やテストのお悩みなど、どんなことでも構いません。
投稿フォームは番組概要欄にあります。
またエピソードの感想は、ハッシュタグBテスティングでXのポストをお願いいたします。
今日の話で言うと、ユースケーステストっていう、多分触れたことのない人も多いであろうテスト技法について紹介しました。
実は触ったことあるよとか、初めて聞きましたとか、そういう感想でも構いません。
ぜひ感想をXのポストでお願いします。
あとは毎回ポッドキャスト、このエピソードを上げていると、何人ぐらいの方が聞いてくれているのかなっていうのが数字で見える状態になっているんですけれども、
全くいないというわけではなさそうっていうのはわかっているので、感想とかいただけるとすごい嬉しいなと思います。
そういう方、毎回聞いてくれている方の感想もお待ちしております。
もしもこれからも聞きたいという方は、お手持ちのポッドキャストアプリで番組のフォローもお願いします。
最新回が上がったときにすぐに気づきます。
このユースケーステストも先ほど言ったように、ユースケース技術とかユースケーステストとか、次回以降にも続いていきますので、
そういう最新回が上がったときに気づくためにも、ぜひフォローもよろしくお願いします。
ということで、今回はここまでです。それではまた次回。バイバイ。