Soumettre la recherche
Mettre en ligne
レビュー方法を実践してみよう20150201
•
2 j'aime
•
1,360 vues
M
Masaki Nakahara
Suivre
関西ソフトウェアテスト勉強会WARAI(2015/2/1)資料 参考文献:間違いだらけの設計レビュー
Lire moins
Lire la suite
Logiciels
Signaler
Partager
Signaler
Partager
1 sur 39
Télécharger maintenant
Télécharger pour lire hors ligne
Recommandé
はじめよう!レビューのいろは
はじめよう!レビューのいろは
scarletplover
レビュー方法を勉強してみよう
レビュー方法を勉強してみよう
Masaki Nakahara
レビュー手法活用による品質の見える化と改善
レビュー手法活用による品質の見える化と改善
Climb CoLtd
ユーザビリティテストをやってみよう
ユーザビリティテストをやってみよう
scarletplover
#wacate 2017 冬 ISONO:REBOOT -評価することにこだわろう-
#wacate 2017 冬 ISONO:REBOOT -評価することにこだわろう-
Kinji Akemine
ソースコードを読んでみよう
ソースコードを読んでみよう
Shun Tsunoda
[JaSST nano] テストケースを作ってもらうときに気を付けていたことをお話するの
[JaSST nano] テストケースを作ってもらうときに気を付けていたことをお話するの
KazukiNishizono1
探索的テスト入門
探索的テスト入門
H Iseri
Recommandé
はじめよう!レビューのいろは
はじめよう!レビューのいろは
scarletplover
レビュー方法を勉強してみよう
レビュー方法を勉強してみよう
Masaki Nakahara
レビュー手法活用による品質の見える化と改善
レビュー手法活用による品質の見える化と改善
Climb CoLtd
ユーザビリティテストをやってみよう
ユーザビリティテストをやってみよう
scarletplover
#wacate 2017 冬 ISONO:REBOOT -評価することにこだわろう-
#wacate 2017 冬 ISONO:REBOOT -評価することにこだわろう-
Kinji Akemine
ソースコードを読んでみよう
ソースコードを読んでみよう
Shun Tsunoda
[JaSST nano] テストケースを作ってもらうときに気を付けていたことをお話するの
[JaSST nano] テストケースを作ってもらうときに気を付けていたことをお話するの
KazukiNishizono1
探索的テスト入門
探索的テスト入門
H Iseri
Jstqb test analyst-chap1
Jstqb test analyst-chap1
Kosuke Fujisawa
テスト設計・テストケース作成 グループ
テスト設計・テストケース作成 グループ
Tomoaki Fukura
ソフトウェアテストことはじめ2016年ver
ソフトウェアテストことはじめ2016年ver
Kosuke Fujisawa
TDDを研ぎ究める
TDDを研ぎ究める
pocketberserker
テスト分析のまとめと技法の決定 グループ
テスト分析のまとめと技法の決定 グループ
Tomoaki Fukura
ソフトウェア開発工程とテスト入門
ソフトウェア開発工程とテスト入門
tadaaki hayashi
チームで行う探索的テスト
チームで行う探索的テスト
Tomonobu Kawakita
STAC 2015 自動家は見た~自動化の現場の真実~ SIDE:マネージャ
STAC 2015 自動家は見た~自動化の現場の真実~ SIDE:マネージャ
Noriyuki Mizuno
第72回名古屋アジャイル勉強会「『検査』、してますか?」
第72回名古屋アジャイル勉強会「『検査』、してますか?」
hiroyuki Yamamoto
テストを分類してみよう!
テストを分類してみよう!
Kenji Okumura
レビューのコツ
レビューのコツ
Yoshiaki Yoneyama
探索的テストはじめの一歩 #wacate
探索的テストはじめの一歩 #wacate
Toshiyuki Kawanishi
テスト分析 個人
テスト分析 個人
Tomoaki Fukura
JaSST'15 Tokyo 初心者向けチュートリアル -初心者からの脱出!-
JaSST'15 Tokyo 初心者向けチュートリアル -初心者からの脱出!-
崇 山﨑
What is exploratory testing?
What is exploratory testing?
Mineo Matsuya
Asian Automation Alliance システムテスト自動化構築時の考え方と進め方の一例
Asian Automation Alliance システムテスト自動化構築時の考え方と進め方の一例
Noriyuki Mizuno
はじめてのScrum
はじめてのScrum
Kenji Morita
アジャイル×テスト開発を考える
アジャイル×テスト開発を考える
yasuohosotani
アジャイルテストを、壮絶に、考える。
アジャイルテストを、壮絶に、考える。
Dai FUJIHARA
アジャイルテスト勉強会
アジャイルテスト勉強会
貴大 平田
#STAC2014 状態遷移を活用した自動テストのテスト戦略とデプロイメントパイプライン
#STAC2014 状態遷移を活用した自動テストのテスト戦略とデプロイメントパイプライン
kyon mm
Kanban pizza game
Kanban pizza game
Dai FUJIHARA
Contenu connexe
Tendances
Jstqb test analyst-chap1
Jstqb test analyst-chap1
Kosuke Fujisawa
テスト設計・テストケース作成 グループ
テスト設計・テストケース作成 グループ
Tomoaki Fukura
ソフトウェアテストことはじめ2016年ver
ソフトウェアテストことはじめ2016年ver
Kosuke Fujisawa
TDDを研ぎ究める
TDDを研ぎ究める
pocketberserker
テスト分析のまとめと技法の決定 グループ
テスト分析のまとめと技法の決定 グループ
Tomoaki Fukura
ソフトウェア開発工程とテスト入門
ソフトウェア開発工程とテスト入門
tadaaki hayashi
チームで行う探索的テスト
チームで行う探索的テスト
Tomonobu Kawakita
STAC 2015 自動家は見た~自動化の現場の真実~ SIDE:マネージャ
STAC 2015 自動家は見た~自動化の現場の真実~ SIDE:マネージャ
Noriyuki Mizuno
第72回名古屋アジャイル勉強会「『検査』、してますか?」
第72回名古屋アジャイル勉強会「『検査』、してますか?」
hiroyuki Yamamoto
テストを分類してみよう!
テストを分類してみよう!
Kenji Okumura
レビューのコツ
レビューのコツ
Yoshiaki Yoneyama
探索的テストはじめの一歩 #wacate
探索的テストはじめの一歩 #wacate
Toshiyuki Kawanishi
テスト分析 個人
テスト分析 個人
Tomoaki Fukura
JaSST'15 Tokyo 初心者向けチュートリアル -初心者からの脱出!-
JaSST'15 Tokyo 初心者向けチュートリアル -初心者からの脱出!-
崇 山﨑
What is exploratory testing?
What is exploratory testing?
Mineo Matsuya
Asian Automation Alliance システムテスト自動化構築時の考え方と進め方の一例
Asian Automation Alliance システムテスト自動化構築時の考え方と進め方の一例
Noriyuki Mizuno
はじめてのScrum
はじめてのScrum
Kenji Morita
アジャイル×テスト開発を考える
アジャイル×テスト開発を考える
yasuohosotani
Tendances
(18)
Jstqb test analyst-chap1
Jstqb test analyst-chap1
テスト設計・テストケース作成 グループ
テスト設計・テストケース作成 グループ
ソフトウェアテストことはじめ2016年ver
ソフトウェアテストことはじめ2016年ver
TDDを研ぎ究める
TDDを研ぎ究める
テスト分析のまとめと技法の決定 グループ
テスト分析のまとめと技法の決定 グループ
ソフトウェア開発工程とテスト入門
ソフトウェア開発工程とテスト入門
チームで行う探索的テスト
チームで行う探索的テスト
STAC 2015 自動家は見た~自動化の現場の真実~ SIDE:マネージャ
STAC 2015 自動家は見た~自動化の現場の真実~ SIDE:マネージャ
第72回名古屋アジャイル勉強会「『検査』、してますか?」
第72回名古屋アジャイル勉強会「『検査』、してますか?」
テストを分類してみよう!
テストを分類してみよう!
レビューのコツ
レビューのコツ
探索的テストはじめの一歩 #wacate
探索的テストはじめの一歩 #wacate
テスト分析 個人
テスト分析 個人
JaSST'15 Tokyo 初心者向けチュートリアル -初心者からの脱出!-
JaSST'15 Tokyo 初心者向けチュートリアル -初心者からの脱出!-
What is exploratory testing?
What is exploratory testing?
Asian Automation Alliance システムテスト自動化構築時の考え方と進め方の一例
Asian Automation Alliance システムテスト自動化構築時の考え方と進め方の一例
はじめてのScrum
はじめてのScrum
アジャイル×テスト開発を考える
アジャイル×テスト開発を考える
En vedette
アジャイルテストを、壮絶に、考える。
アジャイルテストを、壮絶に、考える。
Dai FUJIHARA
アジャイルテスト勉強会
アジャイルテスト勉強会
貴大 平田
#STAC2014 状態遷移を活用した自動テストのテスト戦略とデプロイメントパイプライン
#STAC2014 状態遷移を活用した自動テストのテスト戦略とデプロイメントパイプライン
kyon mm
Kanban pizza game
Kanban pizza game
Dai FUJIHARA
システムテスト自動化標準ガイド第6章
システムテスト自動化標準ガイド第6章
nihon buson
20161218 selenium study4
20161218 selenium study4
Naoya Kojima
20150418 システムテスト自動化 第一章
20150418 システムテスト自動化 第一章
Yuki Fujisawa
テスト自動化のパターンと実践
テスト自動化のパターンと実践
Hiroshi Maekawa
アジャイル開発におけるシステムテストの自動化
アジャイル開発におけるシステムテストの自動化
Toru Koido
キーワード駆動によるシステムテストの自動化について 2015
キーワード駆動によるシステムテストの自動化について 2015
Toru Koido
キーワード駆動テストチュートリアルハンズアウト.03.06
キーワード駆動テストチュートリアルハンズアウト.03.06
Toru Koido
En vedette
(11)
アジャイルテストを、壮絶に、考える。
アジャイルテストを、壮絶に、考える。
アジャイルテスト勉強会
アジャイルテスト勉強会
#STAC2014 状態遷移を活用した自動テストのテスト戦略とデプロイメントパイプライン
#STAC2014 状態遷移を活用した自動テストのテスト戦略とデプロイメントパイプライン
Kanban pizza game
Kanban pizza game
システムテスト自動化標準ガイド第6章
システムテスト自動化標準ガイド第6章
20161218 selenium study4
20161218 selenium study4
20150418 システムテスト自動化 第一章
20150418 システムテスト自動化 第一章
テスト自動化のパターンと実践
テスト自動化のパターンと実践
アジャイル開発におけるシステムテストの自動化
アジャイル開発におけるシステムテストの自動化
キーワード駆動によるシステムテストの自動化について 2015
キーワード駆動によるシステムテストの自動化について 2015
キーワード駆動テストチュートリアルハンズアウト.03.06
キーワード駆動テストチュートリアルハンズアウト.03.06
Similaire à レビュー方法を実践してみよう20150201
Think aloud method
Think aloud method
Heesung Lee
上級ユーザビリティテスト手法
上級ユーザビリティテスト手法
Tarumoto Tetsuya
科学技術コミュニケーション実践の評価Ver.2
科学技術コミュニケーション実践の評価Ver.2
Professional University of Information and Management for Innovation (情報経営イノベーション専門職大学)
DevLOVE関西2012 B-2「メンバーの行動が激変!「ペアふりかえり」ワークショップ
DevLOVE関西2012 B-2「メンバーの行動が激変!「ペアふりかえり」ワークショップ
takepu
体験ふりかえり勉強会
体験ふりかえり勉強会
Fumio Kawakami
GCSアジャイル開発を使ったゲームの作り方
GCSアジャイル開発を使ったゲームの作り方
Hiroyuki Tanaka
オレオレになりがちなテスト計画を見直した話
オレオレになりがちなテスト計画を見直した話
terahide
AgileTourOsaka2011 関係者に理解してもらえるアジャイル開発にむけて
AgileTourOsaka2011 関係者に理解してもらえるアジャイル開発にむけて
Shuji Morisaki
スクラム適用報告
スクラム適用報告
Eiichi Hayashi
事例から見るテスト自動化のポイント
事例から見るテスト自動化のポイント
Hiroshi Maekawa
みんなに役立つ「テスト」を学んでみよう!(20140105版)
みんなに役立つ「テスト」を学んでみよう!(20140105版)
Noriyuki Mizuno
Dev love kansai
Dev love kansai
Takafumi Ikeda
Reflection
Reflection
東京北医療センター
ユーザテスト社内勉強会
ユーザテスト社内勉強会
Ue day
とてか03「「いかす!」のために大事だと思う4つのこと」
とてか03「「いかす!」のために大事だと思う4つのこと」
Tsuyoshi Yumoto
はじめての自己組織化
はじめての自己組織化
Yoshinori Ueda
Reinforcement learning section2
Reinforcement learning section2
KengoInou
第3回すくすく・スクラム 自己組織化Ws
第3回すくすく・スクラム 自己組織化Ws
Kazumasa EBATA
Redmineをつかったスクラム開発のはじめの一歩
Redmineをつかったスクラム開発のはじめの一歩
kiita312
Similaire à レビュー方法を実践してみよう20150201
(19)
Think aloud method
Think aloud method
上級ユーザビリティテスト手法
上級ユーザビリティテスト手法
科学技術コミュニケーション実践の評価Ver.2
科学技術コミュニケーション実践の評価Ver.2
DevLOVE関西2012 B-2「メンバーの行動が激変!「ペアふりかえり」ワークショップ
DevLOVE関西2012 B-2「メンバーの行動が激変!「ペアふりかえり」ワークショップ
体験ふりかえり勉強会
体験ふりかえり勉強会
GCSアジャイル開発を使ったゲームの作り方
GCSアジャイル開発を使ったゲームの作り方
オレオレになりがちなテスト計画を見直した話
オレオレになりがちなテスト計画を見直した話
AgileTourOsaka2011 関係者に理解してもらえるアジャイル開発にむけて
AgileTourOsaka2011 関係者に理解してもらえるアジャイル開発にむけて
スクラム適用報告
スクラム適用報告
事例から見るテスト自動化のポイント
事例から見るテスト自動化のポイント
みんなに役立つ「テスト」を学んでみよう!(20140105版)
みんなに役立つ「テスト」を学んでみよう!(20140105版)
Dev love kansai
Dev love kansai
Reflection
Reflection
ユーザテスト社内勉強会
ユーザテスト社内勉強会
とてか03「「いかす!」のために大事だと思う4つのこと」
とてか03「「いかす!」のために大事だと思う4つのこと」
はじめての自己組織化
はじめての自己組織化
Reinforcement learning section2
Reinforcement learning section2
第3回すくすく・スクラム 自己組織化Ws
第3回すくすく・スクラム 自己組織化Ws
Redmineをつかったスクラム開発のはじめの一歩
Redmineをつかったスクラム開発のはじめの一歩
レビュー方法を実践してみよう20150201
1.
レビュー⽅法を実践してみよう 2015/2/1 WARAI(関⻄SWテスト勉強会) 1
2.
【参考⽂献】 「間違いだらけの設計レビュー」 著者 森崎修司先⽣ 今⽇の勉強会のネライ 前回のWARAI(2014/9/27)にて、 レビュー⽅法を学びました。 今回はこれを実践してみましょう! 2
3.
⽬次 • 1.前回のおさらい • 2.ワーク①: レビュー準備・問題種別とシナリオを考えてみる 〜
休 憩 〜 • 3.ワーク②:実際にレビューを試してみよう • 4.レビュー結果を振り返ってみよう 3
4.
1.前回のおさらい 4
5.
• レビューの⽬的 より早い⼯程で問題を検出し、 後⼯程での修正⼯数を低減させること • レビューについての⼼構え <全員> レビューをみんなが気持ちよく、 円滑に進⾏するために何をすべきかを考える。 →皆がシステムの品質向上活動していることを意識し、 品質につながる指摘をする 1-1.前回のおさらい レビューとは〜第1章〜 皆がこの意識を共有することが⼤切 5
6.
1-1.前回のおさらい レビューとは〜第1章〜 • レビューについての⼼構え <レビューア> ・システムの問題を解決しようとしていることを意識 例)レビューが説明会にならないよう事前に情報収集する <レビューイ・ドキュメント作成者> ・レビュー円滑に進むよう段取りする 例)補助資料の準備など ・指摘を受けたら、問題を早く⾒つけられたことに感謝 レビューの⽬的達成には双⽅の事前準備が必要 6
7.
1-2.前回のおさらい レビューの進め⽅〜2章〜 <ドキュメント作成を含めたレビューの全体フロー> 7 ドキュメント 作成 ドキュメント 修正 レビュー 準備 レビュー 問題検出 レビュー 問題指摘 ドキュメントレビュー
8.
ドキュメント 作成 ドキュメント 修正 レビュー 準備 レビュー 問題検出 レビュー 問題指摘 マインドの誤り ⽅法の誤り 準備 進⾏ 完了 ⼈間関係の 持ち込み 作成者 気分 ⼆兎追い 時間切れ 無計画な 耐久レビュー ケンカ・脱線 の放置 唐突な 終了宣⾔ ⾒栄の 張り合い ⼈格 攻撃 意図的な ⾒逃し ⽬的の誤り
思いつき 数字合わせ つるし上げ レビュー準備の フェーズは存在 しない レビューの構成と間違い要素 8
9.
1-2.前回のおさらい レビューの進め⽅〜2章〜 9 レビューアが作成してもよい
10.
10 1-2.前回のおさらい レビューの進め⽅〜2章〜 レビューで検出すべき問題種別を抽出する (このシステムでは 何を気を付けるべきかを念頭に抽出) 漏れのチェック 曖昧さのチェック 誤りのチェック シナリオを作成(どこをどのように調べるか) ・優先順位をつけて、 抽出する
11.
11 1-2.前回のおさらい レビューの進め⽅〜2章〜 レビューで検出すべき問題種別を抽出する (このシステムでは 何を気を付けるべきかを念頭に抽出) シナリオを作成(どこをどのように調べるか) 対象のシステムによって“問題種別”はさまざま ・短時間に⼤量処理が必要なシステム 問題種別:スループットの低下 ・ユーザの⼊れ替わりが多いシステム 問題種別:利⽤者に分かりにくいUI ≒抽象度の⾼い レビュー観点
12.
12 1-2.前回のおさらい レビューの進め⽅〜2章〜 レビューで検出すべき問題種別を抽出する (このシステムでは 何を気を付けるべきかを念頭に抽出) シナリオを作成(どこをどのように調べるか) レビューでの“問題種別”の導出の⽅法 ・ボトムアップアプローチ 類似プロジェクトからの課題抽出 ※早い段階で検出すると修正⼯数や リスクの低減効果が⼤きい問題種別を優先する ・トップダウンアプローチ プロジェクトメンバの状況 や システム性能から抽出 問題を効率よく検出するには 順番が⼤切!
13.
13 1-2.前回のおさらい レビューの進め⽅〜2章〜 レビューで検出すべき問題種別を抽出する (このシステムでは 何を気を付けるべきかを念頭に抽出) シナリオを作成(どこをどのように調べるか) シナリオの例) ・ 「すべての機能間で⼊出⼒の不整合がないかどうかを 調べるために『機能インターフェイス定義』をチェックする。 ・データをやりとりする機能同⼠の⼊⼒項⽬と出⼒項⽬を 付きあわせて、項⽬名とデータ型が⼀致することを確認する」
14.
シナリオを作成(どこをどのように調べるか) 14 1-2.前回のおさらい レビューの進め⽅〜2章〜 漏れのチェック 曖昧さのチェック 誤りのチェック レビューで検出すべき問題種別を抽出する (このシステムでは 何を気を付けるべきかを念頭に抽出)
15.
15 1-2.前回のおさらい レビューの進め⽅〜2章〜 <漏れ> ドキュメントをチェックする前に “このように書かれているべき“という 想定の上で漏れをチェックする。 <曖昧さ> 説明不⾜を含む。 いずれもドキュメントを読むほど 学習されるため、気づけなくなる。 ドキュメントを読み進めていくほど、 学習が進むために、 漏れ、曖昧さ を検出できなくなる。 学習度 低
⾼ 漏れ 曖昧さ検出 低 ⾼ 誤り検出 低 ⾼
16.
16 1-2.前回のおさらい レビューの進め⽅〜2章〜 シナリオとして、検出対象にしたことについては その部分のみを徹底的にチェックする。 【シナリオなしの場合】 【シナリオありの場合】 エラー処理の漏れがなく、エラーログに ⼀貫性があるかどうかについて 各機能のエラー処理を対象に確認する 半分:とりあえず⼀通りチェック 半分:時間切れ。ざっと⾒るだけ エラー処理 エラー処理 エラー処理 すべてのドキュメントの エラー処理のみを 部分チェックする
17.
17 1-2.前回のおさらい レビューの進め⽅〜2章〜
18.
18 1-2.前回のおさらい レビューの進め⽅〜2章〜
19.
19 1-2.前回のおさらい レビューの進め⽅〜2章〜
20.
20 1-3.みんなのレビューの進め⽅ まとめると、次のページ
21.
21 1-3.みんなのレビューの進め⽅
22.
22 2.ワーク①: レビュー準備・問題種別とシナリオを考えてみる
23.
23 2.ワーク①: レビュー準備・問題種別とシナリオを考えてみる 【お題】 ⾃動販売機の⾃動販売機のユースケース仕様書 (3.1〜3.2)について、 問題種別〜シナリオを検討してみてください
24.
24 【問題種別の例】 対象のシステムによって“問題種別”はさまざま ・短時間に⼤量処理が必要なシステム 問題種別:スループットの低下 ・ユーザの⼊れ替わりが多いシステム 問題種別:利⽤者に分かりにくいUI 【シナリオ例】 ・エラー処理の定義 ・機能間の依存関係 ・リソースの解放漏れ ・画⾯標準との整合性 ・他システムとのI/F 2.ワーク①: レビュー準備・問題種別とシナリオを考えてみる
25.
25 ワーク①:前回のWARAIの結果 レビュー順序(問題種別の順序)の検討結果の例 例) ・規格からの逸脱 ・貨幣の識別を間違えない ・安全である(賠償⾦にならない) <その他> ・製品コンセプトとの整合性 例)24時間稼働
26.
26 ワーク①:今回のWARAIの結果 レビュー順序(問題種別の順序)の検討結果の例 1.故障---全処理に対して、 故障モードの記述があるかをチェック (レビュー時間の効率化を重視) 2.計数を間違えない(前ページと同様) 3.安全(前ページと同様) 4.責任の所在の明確化 注)参加メンバーは前回WARAIと異なる
27.
27 ワーク①:前回と今回のWARAIで分かったこと レビュー順序(問題種別の順序)の検討について 問題種別の導出⽅法が難しいとの意⾒複数あり。 次の順序で検討するのがオススメ ■問題種別を導出できない場合 シナリオ → 問題種別(→
シナリオ → 問題種別・・・) の順に検討する ■問題種別を導出できる場合 問題種別 → シナリオ(→ 問題種別 → シナリオ・・・) の順に検討する いずれの場合も問題種別、シナリオをそれぞれ導出することで 新たなチェックポイントを⾒つけることができる。
28.
28 3.ワーク②: 実際にレビューを試してみよう
29.
29 3.ワーク②: 実際にレビューを試してみよう 【お題】 ワーク①で決定した問題種別、シナリオを使って ⾃動販売機の⾃動販売機のユースケース仕様書 (3.1〜3.2)に対して、問題を指摘してください
30.
30 【参考】前回のWARAI: レビュー⽅法勉強前※の問題指摘結果(1/3) ※問題種別、シナリオ指定なし(前回WARAIはワーク②未実施) 【指摘事項】 曖昧表現に対する指摘 ・故障モードについて、”故障”の定義が必要 例)つり銭不⾜や貨幣詰まりは故障? 例)投⼊⼝でお⾦が詰まった場合、 運⽤会社に通知機能などは故障モードとなるのか? ・点灯していない状態とは?(点滅、消灯どれを指す?) P6 1-5 ・返⾦の意味についてP5 硬貨収納庫容量がMAXになったら、返⾦するとあるが、 全額返⾦?それとも溢れた分だけ返⾦? 硬貨収納庫容量がMAX付近で不当な貨幣を投⼊されたら 不当な貨幣だけを返却?それとも全額返⾦? ・媒体の正当/不当判定はハード、ソフトのどうやって実現するの? (あとでハードの記述があるが・・・ハードだけ?)(3-1)
31.
31 【指摘事項】 仕様⾃体の問題点 ・10分間操作なしの場合は、返⾦する仕様について、 10分後に返⾦しても、既にユーザが⽴ち去っているので、⻑すぎる(P6) ・貨幣処理時の500msの待ち時間について ・⽇常的に使うにも問題があるのでは? ・500msの制約が必要なのは①〜④のどこ?(曖昧) ⾃動販売機 紙幣部 紙幣CPU 紙幣識別CPU 硬貨部 硬貨CPU 硬貨識別CPU メインCPU ① ② ③ ④ 【参考】前回のWARAI: レビュー⽅法勉強前※の問題指摘結果(2/3) ※問題種別、シナリオ指定なし(前回WARAIはワーク②未実施)
32.
32 【指摘事項】 記述⽅法の統⼀ ・インデントの記載⽅法が統⼀されていない ”▷”の記述の仕⽅が、理由と⾏為が混在している 【参考】前回のWARAI: レビュー⽅法勉強前※の問題指摘結果(3/3) ※問題種別、シナリオ指定なし(前回WARAIはワーク②未実施)
33.
33 ワーク②今回のWARAIの結果: レビュー⽅法勉強後の問題指摘結果(1/3) 【レビュー対象として選択した問題指摘】 スライドP24参照 装置故障時の振舞い 【指摘事項】 ⻘字:前回のWARAIでの指摘事項と同⼀の内容 3.1代⾦投⼊ユースケース ・代⾦投⼊ユースケースに故障モードの記載がない ・紙幣処理機が故障/つり銭切れなどが発⽣した場合)縮退運⽤ができるか? ・濡れたお⾦や洗剤を流しても⼤丈夫か? 注)参加メンバーは前回WARAIと異なる
34.
34 ワーク②今回のWARAIの結果: レビュー⽅法勉強後の問題指摘結果(2/3) 【指摘事項】 ⻘字:前回のWARAIでの指摘事項と同⼀の内容 3.2商品選択ユースケース ・ラックの選択通りの商品が出なかった場合の振舞いは? (そもそもラック設定の記述がない) ・商品が出ない/ボタンが故障した場合の振舞いは? ・ボタン1回押下で複数の商品が投出された場合の振舞いは? ・10分間操作なしの場合は、返⾦する仕様について、 10分後に返⾦しても、既にユーザが⽴ち去っているので、⻑すぎる
35.
35 ワーク②今回のWARAIの結果: レビュー⽅法勉強後の問題指摘結果(3/3) 【指摘事項】 ⻘字:前回のWARAIでの指摘事項と同⼀の内容 3.2商品選択ユースケース(つづき) ・装置故障時の現⾦取り扱いシナリオが不⾜している。(②が不⾜) 故障のタイミングによっては、装置内の現⾦取り扱いは2パターンあるはず。 ①購⼊者に返⾦/②販売者で所持(装置内に戻す) →現⾦の取り扱いを間違えれば、売上額と装置内のお⾦が合わなくなる ・同じ種類の商品がすべて適温でなければ、 故障となり、他の適温の商品を購⼊できなくならないか? ・適温でない状態(あたため中/冷却中)は故障? →故障の定義が曖昧 ・適温→適温でない状態
になることはないか? ありえる場合は、適温→適温でない状態に変化するタイミングで 商品選択された場合の振舞いは?
36.
36 4.レビュー結果を振り返ってみよう
37.
37 4.レビュー結果を 振り返ってみよう はじめのワークと課題検出の違いはありますか? シナリオ別にどんな課題が検出されましたか?
38.
38 前回と今回のWARAIのまとめ (前回と今回のWARAIでは参加メンバーが 異なるため、明確な⽐較はできないが、) ・問題種別を使⽤有無により、 レビュー結果が⼤きく異なることが分かった。 →問題種別を “故障”に指定した結果、 (指定なしの場合よりも)“故障”に関する指摘が多く出された。 ・今回のWARAI参加メンバーの意⾒ 問題種別の利⽤により、短時間で特定箇所の レビュー品質を向上させるには⼀定の効果がありそう という意⾒で⼀致した。
39.
39 今⽇はここまで。 ありがとうございました。
Télécharger maintenant