第286回： 「ALTAのテキストをつくろう」41 （ユースケーステスト／前編）
◀前の記事へ 次の記事へ▶︎
≡ はじめに
前回は、「3. テスト技法」の「3.2 ブラックボックステスト技法」の「3.2.6 ペアワイズテスト」の後編として、「ペアワイズテストのカバレッジ、検出できる欠陥の種類」について書きました。
前回の復習は以下で模擬試験問題の確認を通して行います。
今回はJSTQBのALTAシラバスの「3.2.7 ユースケーステスト」の前編として、「ユースケーステストの定義」について書きます。
≡ 前回の復習
以下は前回出題したJSTQB ALTAの模擬試験問題を𝕏にポストした結果です。
投票の結果、選択肢1の「2つのパラメーターの値の組み合わせに関連する欠陥」が76.9%と最も多く、正解も1です。
他の選択肢については、それぞれ別のテスト技法が得意な「欠陥のタイプ」なのですが、わかりますでしょうか。
問題を出す側からすると、この形式（項目対比の形式）はとても出しやすい問題です。
「2. 特定の条件の組み合わせに基づく論理的な処理が正しく行われず想定外の結果となる欠陥」はデシジョンテーブルテスト、「3. 提示された条件の誤った処理」は今回からのユースケーステスト、「4. 正しくないイベントタイプまたは値」は状態遷移テストです。消去法でも正解に辿り着くことができそうですね。
選択肢2を選んだ方が19.2%いらしたのですが「有則」（デシジョンテーブルテスト）と「無則」（ペアワイズテスト）で区別されると良いと思います。
正答率が高かったので、復習は以上とし、今回のnoteのテーマに移ります。
≡ ユースケーステストの定義
JSTQBのALTAシラバスより該当箇所の全文を引用します。
ユースケーステストは、ユースケースで具体的にした、コンポーネントまたはシステムの意図される使われ方をエミュレートするトランザクションベースおよびシナリオベースのテストを可能にする。何らかのゴールを達成するために、アクターと、コンポーネントまたはシステムとの間の相互作用の観点でユースケースを定義する。アクターとしては、ユーザー、外部ハードウェア、またはその他のコンポーネントやシステムを挙げることができる。
ユースケースの共通規格は、[OMG-UML]で提供している。
用語集も引いてみます。シナリオテストが同義語となっています。
上のシラバスの抜粋に記載している通り、トランザクションベース（システムへの入出力の対応を確認するだけ）のユースケーステストがあります。
例えば「ユーザー名とパスワードを入力してログインできる事（ユースケース/コンポーネント）だけを確認する」ようなユースケーステストのことです。
したがってユースケーステストとシナリオテストが同義語というのはちょっと無理があるのですが、後で述べる使用者のユースケースのテストはシナリオ形式で作ることが多いことを言っているものと思います。
そうそう、ISTQB/JSTQBが技法の用語を説明する時に「ブラックボックステスト技法の一つ」とよく書いているのですが、気にしないほうが良いです。
たとえば、同値分割法はホワイトボックステストでも使われますので、「同値分割法をホワイトボックステストで使ってはいけない」と言い出す人が出たら嫌だなといつも思います。
もっとも、ユースケーステスト技法はブラックボックステスト技法と限定してもよいでしょう。ユースケース図のなかに構造はほとんど書かないからです。たまに≪include≫と言った実装時にも使えるアドバイスが描かれることもありますが、ユースケース本来の目的である「ユーザーの要求を明らかにすること」に対しては余計な情報だなと思います。
それで、シラバスの解説ですが、すでに知っている人にしかわからないざっくりとした説明ですよね。
ALでわからなくなったときには、FLのシラバスを読み返してみるといいのですが、FL 4.0からは「ユースケーステスト」が無くなってしまっています。
仕方がないので、前のバージョンの方を読みます。（FLシラバスの「Version 2018V3.1.J03」は、まだ公開中ですので、手元に保存しておくことをお勧めします）
以下は以前のFLの記載です。
ユースケースは、ソフトウェアアイテムとの相互作用の設計方法であり、テストケースは、ユースケースから導出可能である。ユースケースには、ソフトウェア機能の要件が盛り込まれている。ユースケースは、サブジェクト（ユースケースが適用されるコンポーネントまたはシステム）とアクター（ユーザー、外部ハードウェア、その他のコンポーネントやシステム）をつないでいる。
各ユースケースは、1つのサブジェクトと1つ以上のアクターとの相互作用による振る舞いを明確にする（UML 2.5.1 2017）。ユースケースは、相互作用とアクティビティ、さらには事前条件、事後条件で記述できる。必要に応じて自然言語でも記述できる。アクターとサブジェクトとの相互作用で、サブジェクトの状態が変化する場合がある。相互作用は、ワークフロー図、アクティビティ図、またはビジネスプロセスモデルを使用して視覚的に記述できる。
ユースケースには、基本的な振る舞いのバリエーションである、例外的な振る舞いおよびエラー処理を含むことができる。エラー処理には、プログラミング、アプリケーションおよびコミュニケーションのエラーに対するエラーメッセージの表示といった、システムの応答や回復の処理がある。テストは、定義した振る舞い（基本、例外または代替処理、およびエラー処理）を実行するように設計する。カバレッジは、テストしたユースケースの振る舞いをユースケースの振る舞いの合計数で除算して計測する（パーセンテージで表すことが多い）。
ユースケーステストのカバレッジ基準の詳細については、『ISTQBテスト技術者資格制度Advanced Level シラバス 日本語版 テストアナリスト』を参照されたい。
こちらの方が詳しく書いてありますので、初級者の方にも参考になると思います。
ちなみに、UMLに興味を持たれた方は以下の書籍がおすすめです。
旧シラバスの話に戻ります。
大事な点は、太字にした、「各ユースケースは、1つのサブジェクトと1つ以上のアクターとの相互作用による振る舞いを明確にする」と、「ユースケースには、基本的な振る舞いのバリエーションである、例外的な振る舞いおよびエラー処理を含むことができる」の所です。
ユースケースと混同しやすいユーザーストーリーのほうには、「誰がどんなことを達成したいのか」を書きます。ユーザーストーリーの関心ごとは「要求を知ろう！」ということだからです。
たまに、ユーザーストーリーを「機能を連鎖したシナリオっぽいもの」で書く人もいますが、ユーザーストーリーを書くときには機能を考えずに、純粋に「（ユーザーが）何をしたいのか」を理解することに焦点を当てるほうが良いです。要求工学の本に書いてあったと思います。
一方でユースケースの方はユーザーストーリーと同じく要求（要件）を理解するためのものですが、太字にした「サブジェクト」（つくるもの、システムとユーザーとの境界）を考えている点が異なります。
利用者の要求を、これから開発するもので、どう叶えるのかについて明らかにするもの（難しく書けばモデル）がユースケースです。
二つ目の太字部分の「ユースケースには、基本的な振る舞いのバリエーションである、例外的な振る舞いおよびエラー処理を含むことができる」というのは、ユーザーの要求はしたいことが中心に語られるけど、例外処理とかエラー処理も必要ということです。
さて、「ユースケーステストの定義」に話を戻しますと、ユースケースを確認するテストがユースケーステストです。
定義が広いです。広すぎです。
ユーザーの要求をアクターとサブジェクトとの関係を中心に確認するテストといった程度の定義なので、広いです。←しつこい。
広いと言うことを説明する絵がこちらです。コーバーンという人が言い始めたものです。たぶん『ユースケース実践ガイド』という本にも書いてあると思います。
ユースケースにも色々あるということを示す絵と表です。同じものを意味していますので、表の方で説明します。
まず、レイヤーに違いがあります。ビジネスの話をしているユースケースなのか、使用者がシステムを動かすユースケースなのか、一つひとつの機能の使い方の話なのか、機能を作っている部品の話なのかの軸がレイヤーと言っているものです。
また、もう一つの軸として抽象的なものなのか、具体的なものなのかの軸があります。
一般的にユースケーステストと言えば、使用者のレイヤーで、できるだけ具体化したもの、絵では「船」🚢を対象としたものとなります。
ただし、ときには具体化出来ていない「波」🌊もユースケーステストしなければならないこともありますし、隣接したビジネスや機能のレイヤーのユースケーステストをすることもあります。
その場合でも、できるだけ「船」に近づける努力をする方がいいです。
ちょっと抽象的な話になってしまいましたが次回と次々回で出てくることの前振りとして。
≡ JSTQB ALTA試験対策
いつものことですが、まずは、「学習の目的」を確認します。
TA-3.2.7 （K4）ユースケーステストを適用して、特定の仕様アイテムを分析しテストケースを設計する 。
「K4」なので「理解」して「適用」できるだけではなく「分析」まで求められる重要な項目ということです。試験問題には、ユースケーステストをつくることができるかどうか、あるいは、（定義が広いので）ユースケーステストではないものを選ばせる問題が出ると思います。
《問題》
ユースケーステストでは【ないもの】どれですか。
1. カーナビで道を外れたときの動作の確認
2. 期限切れのクレジットカードが使えないことの確認
3. 150円入力して150円の缶コーヒーを購入できることの確認
4. システムの導入で残業時間が削減されることの確認
答えは次回に書きます。
≡ おわりに
今回は、「ユースケーステストの定義」がテーマでした。
定義と言っても「ユースケースを確認するテストがユースケーステスト」といったものなので、「ユースケースって何？」が分かればOKですし、ユーザーシナリオテストとかユーザーストーリーレビューとの違いを理解してもらえると更に良いです。
次回は、「3.2.7 ユースケーステスト」の中編として、「ユースケーステストの適用、制限／注意事項」について書きます。
この記事が気に入ったらサポートをしてみませんか？