use-case-testing2016s

WACATE2016夏という勉強会の資料のうち、私が作成した部分（ユースケーステストの説明）を抜粋して少し整えたもの。テスト設計のワークをする前に設けられた、テスト技法のおさらいをする目的のセッションでした。勉強会が終わってまもなく作成した資料です。
別の場所で公開していますが、現状メインで使っているのはこちらのspeakerdeckであるため、アップロードしてみました。
名前が他のスライドと違いますが、同一人物です。
（記 2023年11月）

Transcript

1. ユースケーステストを説明してみた ―WACATE2016夏 勝手に1口おかわり 2016年7月 近江 1
2. この資料について •ユースケーステストについて説明してみた資料。 •ベースは、WACATE2016夏という勉強会の資料。 • 中でも、テスト設計のワークをする前に設けられた、テスト技法のおさらいをする 目的のセッションの資料のうち、筆者が作成した部分。 • 但し、本資料は、 WACATE2016夏のためではなく、筆者個人の思いと判断で作成 したもの。 •ベースとの主な違いは、話しただけの部分や追加情報を補足したこと。 • 1年後の自分でも読める資料にすることを念頭に置いて更新。 • ワークの前提という位置づけではなく、テスト技法の紹介をすると仮定した場合に 書いたであろう情報を追加。 2
3. 対象者 ユースケーステストの具体的なイメージがない人 ＆ ユースケース記述からテストを考えた経験が(ほぼ)ない人 3
4. ユースケーステストとは ユースケースをもとにした、仕様ベースのテスト技法。 関係する人やシステム(役割)が多い場面、 複雑な相互作用がある場面で効果的。 受け入れテスト、統合テストが主。 V字モデルの上の方。 Ｖ 4
5. ここで取り上げること、取り上げないこと 取り上げること ユースケース記述からテストまでをつくる手順 特徴 注意点 取り上げないこと ユースケース図との関係 他のモデル（ UML ）との関係 … 5
6. ユースケースとは ユースケーステストの話の前に… 「ユースケース」 ユーザや他システムとの相互作用を、ユーザ視点で表現したモデル。 利用例やユーザが求める機能が書かれる。 ユースケーステストと密接に関係する「ユースケース記述」 相互作用の内容が、シナリオ（脚本、筋書）のように書かれる。 6
7. 「顧客が映画館のチケットをオンラインで購入する」ユースケース記述(主な部分) 7 1 顧客 映画を選ぶ 2 システム 選択可能なチケット種類を表示する … 7 顧客 購入ボタンを押す 8 システム 購入情報を登録し、決済システムに情報を送信する 9 システム チケット番号をメールで送信する
8. ユースケーステスト 「顧客が映画館のチケットをオンラインで購入する」ユースケース記述(主な部分) …ここから考えられる「顧客が映画館のチケットをオンラインで購入する」テスト ◦ 画面を開いて映画を選択する ◦ →チケット種類が画面に表示されるので、選択する ◦ → … ◦ →購入したチケットの番号をメールで確認できることを検証する 8 1 顧客 映画を選ぶ 2 システム 選択可能なチケット種類を表示する … 7 顧客 購入ボタンを押す 8 システム 購入情報を登録し、決済システムに情報を送信する 9 システム チケット番号をメールで送信する
9. ユースケーステストとは ユースケースをもとにして行うテスト。 ここではユースケース記述からテストを検討するやり方を説明する。 ユーザの視点に立って システムとの相互作用を実際に行ってテストする。 ユーザが達成したいことが達成できるか？ ユーザが避けたいことが避けられるか？ 9
10. 他の技法との比較 「テスト技法ポジショニングマップ」の引用元：http://www.hayst.com/pages/positioning.aspx Black Boxテスト ピンポイントで バグを突くというより (デシジョンテーブルや オールペア程でないが) 比較的網羅的なアプローチ 10
11. 手順 •ユースケース記述が既にある場合 • 要求定義など上流でつくられている場合は、ベースにしてテストを考 える • 但し、更新が必要なこともある • 最新でない場合 • スコープや仕様の変更は反映されているか • テストの検討に使うには過不足がある場合 • 範囲や抽象度がちょうどいいとは限らない •ユースケース記述がない場合 …次ページから手順を説明 • ユースケース記述をつくって、テストを考える 11
12. 手順 映画館のオンラインチケット購入システム チケットを買いたい 座席を予約したい 顧客 劇場の窓口の 受付担当者 システム管理者 … … STEP1：利用例は？ 関わる人やシステム(役割)は？ 人やシステムごとに シナリオが変わる場合も 例：一般ユーザと管理者 人やシステムは役割毎に出す 1人=1役割とは限らない 12
13. 手順 顧客がチケットを購入する 1 顧客 映画を選ぶ 2 システム 選択可能なチケット種類を表示する … 7 顧客 購入ボタンを押す 8 システム 購入情報を登録し、決済システムにデータ送信する 9 システム チケット番号をメールで送信する STEP2：どんなシナリオになる？ 13
14. 手順 顧客がチケットを購入する 購入できるチケットが ないときは？ 決済に失敗する場合は？ メールアドレス未登録なら？ 入力された決済情報に 誤りがあったら？ STEP3：他にフローは？ 中断や、エラーになることは？ … … それぞれのシナリオも考える 14
15. 「顧客がチケットを購入する」3つのフロー １ … 2 7 8 9 9a 8a-2 フロー： 1→2…7→8→9 1→2…7→8a-1→8a-2 1→2…7→9a … 9a メールアドレスが登録されていない 9a システム チケット番号を画面表示する(メール送信なし) 8a 決済に失敗する 8a-1 システム 決済エラーを登録し購入失敗を表示する 8a-2 顧客 トップページに戻る 1 顧客 映画を選ぶ 2 システム 選択可能なチケット種類を表示する … 7 顧客 購入ボタンを押す 8 システム 購入情報を登録し決済システムにデータ送信する 9 システム チケット番号をメールで送信する 8a-1 15
16. 「顧客がチケットを購入する」3つのフロー １ … 2 7 8 9 8a 決済に失敗する 8a-1 システム 決済エラー情報を登録し購入失敗を表示する 8a-2 顧客 トップページに戻る 9a 8a-2 フロー： 1→2…7→8→9 1→2…7→8a-1→8a-2 1→2…7→9a 1 顧客 映画を選ぶ 2 システム 選択可能なチケット種類を表示する … 7 顧客 購入ボタンを押す 8a-1 … 9a メールアドレスが登録されていない 9a システム チケット番号を画面表示する(メール送信なし) 8 システム 購入情報を登録し、決済システムにデータ送信する 9 システム チケット番号をメールで送信する 16
17. 「顧客がチケットを購入する」3つのフロー … １ … 2 7 8 9 8a 決済に失敗する 8a-1 システム 決済エラー情報を登録し購入失敗を表示する 8a-2 顧客 トップページに戻る 9a 8a-2 フロー： 1→2→…7→8→9 1→2→…7→8a-1→8a-2 1→2→…7→9a 9a メールアドレスが登録されていない 9a システム チケット番号を画面表示する(メール送信なし) 9 システム チケット番号をメールで送信する 1 顧客 映画を選ぶ 2 システム 選択可能なチケット種類を表示する … 7 顧客 購入ボタンを押す 8 システム 購入情報を登録し、決済システムにデータ送信する 8a-1 17
18. 手順 事前条件はない？ 事後条件は？ 終わったときにどうなっている？ 顧客がチケットを購入する 事前条件 チケット購入可能な映画があること 事後条件 成功時は採番されたチケット番号が顧客に渡ること STEP2-3とあわせて： 前提になる条件は？ 終了後はどうなるはず？ テスト前の準備、 テスト後の想定結果となる 18
19. 手順 フローごとにテストをする。 顧客がチケットを購入する  チケットが購入できる場合のテスト 映画を選ぶ→…→チケット番号をメールで確認する …  決済に失敗する場合のテスト …  チケットは購入できるがメール送信されない場合のテスト … STEP5：フローごとにテストをする。 19
20. 特徴 実際の相互作用や利用場面に近づけて検証できる。 ユーザ、他システムとの相互関係の問題を検出しやすい。 （ユースケース記述から見た）網羅性を確認できる。 何となく考えるより利用例を挙げやすい。 ガイドされる。 関係する人やシステムをあわせて洗い出す中で気付くことも。 20
21. 注意点 1/2 様々な相互作用やフローを洗い出す必要がある。 みんなで意見を出しあう。 まずは頻繁に発生するシンプルなフローを。エラーや遠回りするフローも忘れずに。 詳細化は徐々に行う。 序盤で抜け漏れがあると影響大。利用例、関係する人やシステムも漏れ無く洗い出す。 最初からすべて詳細に書くと途中で息切れすることも。 もっとシンプルにできるテストで代替できないか、考えてみるとよい。 視点が低すぎないか？ 細かすぎないか？ 先に手間が少ないテストで、できるだけバグを出す。 21
22. 注意点 2/2 ユーザの視点が中心であることをお忘れなく。 粒度が難しい。 映画一覧ファイルをエクスポートする …ユーザが達成したいこと ファイルの書込み開始位置をずらす …？？？ ユースケース記述やテストの過不足を確認するとよい。 仕様が複雑な場合、ユースケース記述つまり文章だけでは抜け漏れが判りにくい。 関係する人やシステムとユースケース記述の紐付けに過不足はないか？ ユースケース記述とテストの紐付けに過不足はないか？ 表形式での情報整理や突合せをして確認するタイミングを設ける。 テストで使う具体的なデータは別途考える必要あり。 入力値など。 22
23. 参考文献 はじめて学ぶソフトウェアのテスト技法, リー・コープランド (著), 宗 雅彦 (翻訳), 日経BP社 (2005/11/3) ユースケース実践ガイド―効果的なユースケースの書き方 (OOP Foundations), アリスター コーバーン (著), Alistair Cockburn (著), ウルシステムズ株式会社 (著), 山岸 耕二 (著), 矢崎 博英 (著), 水谷 雅宏 (著), 篠原 明子 (著) , 翔泳社 (2001/11) 【改訂版】初歩のUML：第8回 顧客の要求をユースケースに反映させる  http://www.itmedia.co.jp/im/articles/0307/05/news002.html テスト技術者資格制度 シラバス  http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2011.J02.pdf  http://jstqb.jp/dl/JSTQB-Syllabus.Advanced_TA_Version2012.J01.pdf テスト技法ポジショニングマップ  http://www.hayst.com/pages/positioning.aspx 第三者評価におけるシナリオテストプロセスの提案  https://www.juse.or.jp/sqip/workshop/report/attachs/2011/SQiP5-B.pdf 特に感謝！：本資料のベースとなった資料をレビューし意見をくださったWACATE2016夏の実行委員とOBの皆さん 23