Slide 1

Slide 1 text

ユースケーステストを説明してみた ―WACATE2016夏 勝手に1口おかわり 2016年7月 近江 1

Slide 2

Slide 2 text

この資料について •ユースケーステストについて説明してみた資料。 •ベースは、WACATE2016夏という勉強会の資料。 • 中でも、テスト設計のワークをする前に設けられた、テスト技法のおさらいをする 目的のセッションの資料のうち、筆者が作成した部分。 • 但し、本資料は、 WACATE2016夏のためではなく、筆者個人の思いと判断で作成 したもの。 •ベースとの主な違いは、話しただけの部分や追加情報を補足したこと。 • 1年後の自分でも読める資料にすることを念頭に置いて更新。 • ワークの前提という位置づけではなく、テスト技法の紹介をすると仮定した場合に 書いたであろう情報を追加。 2

Slide 3

Slide 3 text

対象者 ユースケーステストの具体的なイメージがない人 & ユースケース記述からテストを考えた経験が(ほぼ)ない人 3

Slide 4

Slide 4 text

ユースケーステストとは ユースケースをもとにした、仕様ベースのテスト技法。 関係する人やシステム(役割)が多い場面、 複雑な相互作用がある場面で効果的。 受け入れテスト、統合テストが主。 V字モデルの上の方。 V 4

Slide 5

Slide 5 text

ここで取り上げること、取り上げないこと 取り上げること ユースケース記述からテストまでをつくる手順 特徴 注意点 取り上げないこと ユースケース図との関係 他のモデル( UML )との関係 … 5

Slide 6

Slide 6 text

ユースケースとは ユースケーステストの話の前に… 「ユースケース」 ユーザや他システムとの相互作用を、ユーザ視点で表現したモデル。 利用例やユーザが求める機能が書かれる。 ユースケーステストと密接に関係する「ユースケース記述」 相互作用の内容が、シナリオ(脚本、筋書)のように書かれる。 6

Slide 7

Slide 7 text

「顧客が映画館のチケットをオンラインで購入する」ユースケース記述(主な部分) 7 1 顧客 映画を選ぶ 2 システム 選択可能なチケット種類を表示する … 7 顧客 購入ボタンを押す 8 システム 購入情報を登録し、決済システムに情報を送信する 9 システム チケット番号をメールで送信する

Slide 8

Slide 8 text

ユースケーステスト 「顧客が映画館のチケットをオンラインで購入する」ユースケース記述(主な部分) …ここから考えられる「顧客が映画館のチケットをオンラインで購入する」テスト ◦ 画面を開いて映画を選択する ◦ →チケット種類が画面に表示されるので、選択する ◦ → … ◦ →購入したチケットの番号をメールで確認できることを検証する 8 1 顧客 映画を選ぶ 2 システム 選択可能なチケット種類を表示する … 7 顧客 購入ボタンを押す 8 システム 購入情報を登録し、決済システムに情報を送信する 9 システム チケット番号をメールで送信する

Slide 9

Slide 9 text

ユースケーステストとは ユースケースをもとにして行うテスト。 ここではユースケース記述からテストを検討するやり方を説明する。 ユーザの視点に立って システムとの相互作用を実際に行ってテストする。 ユーザが達成したいことが達成できるか? ユーザが避けたいことが避けられるか? 9

Slide 10

Slide 10 text

他の技法との比較 「テスト技法ポジショニングマップ」の引用元:http://www.hayst.com/pages/positioning.aspx Black Boxテスト ピンポイントで バグを突くというより (デシジョンテーブルや オールペア程でないが) 比較的網羅的なアプローチ 10

Slide 11

Slide 11 text

手順 •ユースケース記述が既にある場合 • 要求定義など上流でつくられている場合は、ベースにしてテストを考 える • 但し、更新が必要なこともある • 最新でない場合 • スコープや仕様の変更は反映されているか • テストの検討に使うには過不足がある場合 • 範囲や抽象度がちょうどいいとは限らない •ユースケース記述がない場合 …次ページから手順を説明 • ユースケース記述をつくって、テストを考える 11

Slide 12

Slide 12 text

手順 映画館のオンラインチケット購入システム チケットを買いたい 座席を予約したい 顧客 劇場の窓口の 受付担当者 システム管理者 … … STEP1:利用例は? 関わる人やシステム(役割)は? 人やシステムごとに シナリオが変わる場合も 例:一般ユーザと管理者 人やシステムは役割毎に出す 1人=1役割とは限らない 12

Slide 13

Slide 13 text

手順 顧客がチケットを購入する 1 顧客 映画を選ぶ 2 システム 選択可能なチケット種類を表示する … 7 顧客 購入ボタンを押す 8 システム 購入情報を登録し、決済システムにデータ送信する 9 システム チケット番号をメールで送信する STEP2:どんなシナリオになる? 13

Slide 14

Slide 14 text

手順 顧客がチケットを購入する 購入できるチケットが ないときは? 決済に失敗する場合は? メールアドレス未登録なら? 入力された決済情報に 誤りがあったら? STEP3:他にフローは? 中断や、エラーになることは? … … それぞれのシナリオも考える 14

Slide 15

Slide 15 text

「顧客がチケットを購入する」3つのフロー 1 … 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

Slide 16

Slide 16 text

「顧客がチケットを購入する」3つのフロー 1 … 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

Slide 17

Slide 17 text

「顧客がチケットを購入する」3つのフロー … 1 … 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

Slide 18

Slide 18 text

手順 事前条件はない? 事後条件は? 終わったときにどうなっている? 顧客がチケットを購入する 事前条件 チケット購入可能な映画があること 事後条件 成功時は採番されたチケット番号が顧客に渡ること STEP2-3とあわせて: 前提になる条件は? 終了後はどうなるはず? テスト前の準備、 テスト後の想定結果となる 18

Slide 19

Slide 19 text

手順 フローごとにテストをする。 顧客がチケットを購入する  チケットが購入できる場合のテスト 映画を選ぶ→…→チケット番号をメールで確認する …  決済に失敗する場合のテスト …  チケットは購入できるがメール送信されない場合のテスト … STEP5:フローごとにテストをする。 19

Slide 20

Slide 20 text

特徴 実際の相互作用や利用場面に近づけて検証できる。 ユーザ、他システムとの相互関係の問題を検出しやすい。 (ユースケース記述から見た)網羅性を確認できる。 何となく考えるより利用例を挙げやすい。 ガイドされる。 関係する人やシステムをあわせて洗い出す中で気付くことも。 20

Slide 21

Slide 21 text

注意点 1/2 様々な相互作用やフローを洗い出す必要がある。 みんなで意見を出しあう。 まずは頻繁に発生するシンプルなフローを。エラーや遠回りするフローも忘れずに。 詳細化は徐々に行う。 序盤で抜け漏れがあると影響大。利用例、関係する人やシステムも漏れ無く洗い出す。 最初からすべて詳細に書くと途中で息切れすることも。 もっとシンプルにできるテストで代替できないか、考えてみるとよい。 視点が低すぎないか? 細かすぎないか? 先に手間が少ないテストで、できるだけバグを出す。 21

Slide 22

Slide 22 text

注意点 2/2 ユーザの視点が中心であることをお忘れなく。 粒度が難しい。 映画一覧ファイルをエクスポートする …ユーザが達成したいこと ファイルの書込み開始位置をずらす …??? ユースケース記述やテストの過不足を確認するとよい。 仕様が複雑な場合、ユースケース記述つまり文章だけでは抜け漏れが判りにくい。 関係する人やシステムとユースケース記述の紐付けに過不足はないか? ユースケース記述とテストの紐付けに過不足はないか? 表形式での情報整理や突合せをして確認するタイミングを設ける。 テストで使う具体的なデータは別途考える必要あり。 入力値など。 22

Slide 23

Slide 23 text

参考文献 はじめて学ぶソフトウェアのテスト技法, リー・コープランド (著), 宗 雅彦 (翻訳), 日経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