More Related Content
Similar to テスト分析入門 -「ゆもつよメソッド」を例に- #wacate
Similar to テスト分析入門 -「ゆもつよメソッド」を例に- #wacate (20)
More from Kinji Akemine (9)
テスト分析入門 -「ゆもつよメソッド」を例に- #wacate
- 2. + 参考文献
ソフトウェア・テストPRESS 総集編
ソフトウェア・テストPRESS Vol.10
特集1:今こそ聞きたいテストの上流設計
Vol.10自体の販売はすでに終了
総集編のPDF収録版は入手可能
http://www.amazon.co.jp/exec/obidos/ASIN/4774147338/wacate-22/ref=nosim/
JIS X 25010:システム及びソフトウェアの品質モデル
http://kikakurui.com/x25/X25010-2013-01.html
マインドマップから始めるソフトウェアテスト
http://www.amazon.co.jp/exec/obidos/ASIN/4774131318/wacate-22/ref=nosim/
2014/06/21WACATE 2014 Summer
2
- 3. + 自己紹介
所属
某豊洲のSIer勤務
〜2014.3
テストプロセスおよびツールの研究開発
2014.4〜
アジャイルプロセスおよびツールの研究開発
WACATE実行委員会
テスト自動化研究会
専門
テスト分析・設計方法論
TOPSE 7期生 修了
JSTQB Foundation Level
テスト設計コンテスト’14 決勝戦3位
スクラム
認定スクラムマスター
2014/06/21WACATE 2014 Summer
3
- 4. + 目次
1. テストケースの再利用
2. テスト分析・設計
3. ゆもつよメソッド
4. ゆもつよメソッドの実践
1. テスト対象分析
2. テスト目的分析
3. テスト条件検討
5. 既存テストケースの分析
6. まとめ
2014/06/21WACATE 2014 Summer
4
- 7. + 1.2. 再利用のポイント
どんな問題があるか?
テストケースしか残っていない
必要十分なテストケースかどうかの判断が難しい
そのまま流用していいのか、仕様変更にあわせて内容を変更しな
いといけないのかの判断が難しい
テストの意図を理解することが重要
テスト分析・設計方法論を活用すると効果的
ある程度コストのかかる作業だが、メリットは大きい
既存資産に対する適切な理解
以降の開発におけるテスト分析・設計の容易化
2014/06/21WACATE 2014 Summer
7
- 9. + 2.1. テストプロセス
ISTQB
国際的なテスト技術者資格認定期間による定義
Test.SSF
日本のテスト技術スキルフレームワークによる定義
タスクは定義されるが細かな実施手順は提供されない
手順を定義した方法論を参考にする
テスト
分析
テスト
設計
テスト
実装
テスト
実行
終了基準
の評価と
レポート
テスト
要求分析
テストアー
キテクチャ
設計
テスト
詳細設計
テスト
実装
テスト
実行
テスト
報告
テスト
評価
2014/06/21WACATE 2014 Summer
9
- 10. + 2.2. テスト分析・設計方法論
様々な方法論が存在
日本において有名な方法論
VSTeP
HAYST法
ゆもつよメソッド…etc
デファクトスタンダードはない
プロジェクト特性などに応じて適宜選択
今回はゆもつよメソッドを扱う
2014/06/21WACATE 2014 Summer
10
- 13. + 3.1. 概要(1/3)
日本HP 湯本剛氏が考案
特徴
テスト観点を2つの側面で整理
何に対して
ゆもつよメソッドでは「機能」と呼ぶ
どこに着眼するか
ゆもつよメソッドでは「テストタイプ」「テストカテゴリ」と呼ぶ
何に対して
どこに
着目するか
2014/06/21WACATE 2014 Summer
13
- 16. + 3.2. 適用手順(1/2)
以下の3ステップで解説
ステップ 本講義におけるプロセス ゆもつよメソッドにおけるプロセス
1 テスト対象分析 機能の整理&再分類
2 テスト目的分析
テストタイプ特定
テストカテゴリ作成
3 テスト条件検討 テスト条件となる仕様項目特定
2014/06/21WACATE 2014 Summer
16
- 17. + 3.2. 適用手順 (2/2)
Process Flow Diagram
機能モデル
テスト目的
分析
テスト対象
分析
テスト条件
検討
品質モデル仕様書
機能一覧 テストカテゴリ一覧
テスト条件一覧
2014/06/21WACATE 2014 Summer
17
- 19. + 4.0. 実践の流れ
1. プロセス概要
2. 手順
3. 考え方
4. 具体例
デジカメを例に
2014/06/21WACATE 2014 Summer
19
- 21. + 4.1.1. プロセス概要
実施事項 仕様書に書かれた内容を構造分解し、テスト対象とすべき機能
を抽出する
入力成果物 仕様書 テスト対象の仕様が書かれた成果物
出力成果物 機能一覧 テスト対象の一覧
2014/06/21WACATE 2014 Summer
21
- 22. + 4.1.2. 手順
1. 仕様書から機能に該当するテスト対象を抽出
し、木構造で整理する
2. 末端のテスト対象を機能一覧として列挙する
2014/06/21WACATE 2014 Summer
22
- 24. + 4.1.4. 具体例(1/2)-仕様確認
準備
− 充電
− メモリ装着
− 電源ON / OFF
操作
− 撮影
・撮影モード設定
・操作パネル
・フラッシュ
・ズーム撮影
・連続撮影
− 再生
・再生モード設定
・ファイルコピー
・表示レイアウト
設定
− メニュー操作
− 撮影設定
その他
− 電源管理
− モニタ表示内容
− リセット
− 画面メッセージ
仕様書目次
2014/06/21WACATE 2014 Summer
24
- 27. + 4.2.1. プロセス概要
実施事項 仕様書および各種モデルから、考慮すべきテストタイプおよび
テストカテゴリを抽出する
入力成果物 仕様書 テスト対象の仕様が書かれた成果物
品質モデル 考慮すべきテストタイプを決定する上で
参考にする品質の考え方
機能モデル 考慮すべきテストカテゴリを決定する上
で参考にするソフトウェアの構造分解の
考え方
出力成果物 テストカテゴリ一覧 テストにおいての着眼点の一覧
2014/06/21WACATE 2014 Summer
27
- 28. + 4.2.2. 手順
1. 品質モデルを参考に、考慮すべきテストタイプ
を決定する
2. 各テストタイプについて、機能モデルを参考に
テストカテゴリを決定する
1. 機能テスト:機能モデルの各構成要素に着目
2. 非機能テスト:機能モデルの構成要素に紐づく観点に
着目
2014/06/21WACATE 2014 Summer
28
- 29. + 4.2.3. 考え方のポイント(1/5)
品質モデルの活用
ソフトウェアが満たすべき品質を網羅した観点集
代表的なものとしてJIS X 25010 「システム及びソフトウェアの
品質モデル」がある
出典:経済産業省 システム/ソフトウェア製品の品質要求定義と品質評価のためのメトリクスに関する調査報告書
システム/ソフトウェア
製品品質
機能適合性 性能効率性 互換性 使用性 信頼性
セキュリ
ティ
保守性 移植性
完全性
正確性
適切性
適切度認識性
習得性
運用性
ユーザエラー
防止性
ユーザインタ
フェースの快
美性
アクセシビリ
ティ
時間効率性
資源利用性
キャパシティ
共存性
相互運用性
成熟性
可用性
障害許容性
回復性
機密保持性
インテグリ
ティ
否認防止性
責任追跡性
真正性
モジュール性
再利用性
解析性
変更性
試験性
順応性
設置性
置換性
2014/06/21WACATE 2014 Summer
29
- 30. + 4.2.3. 考え方のポイント(2/5)
品質モデルの活用
確保したい品質を確認するためのテストを選択
保守性や使用性など、テストでは保証しにくい品質もある
湯本氏による解説では、以下のモデルが用いられている
出典:技術評論社 ソフトウェア・テストPRESS Vol.10
動的テスト システム/ソフトウェア構造の網羅性 構造テスト
機能性 機能テスト
機能組み合わせテスト
シナリオテスト
セキュリティテスト
使用性 ユーザビリティテスト
効率性 ロードテスト
ストレステスト
...
2014/06/21WACATE 2014 Summer
30
- 31. + 4.2.3. 考え方のポイント(3/5)
機能モデルの活用:機能テスト
ソフトウェアの構造を分解したモデル
品質モデルほど普及した考え方ではないため、デファク
トなモデルはない
湯本氏による解説では、以下のモデルが用いられている
出典:技術評論社 ソフトウェア・テストPRESS Vol.10
管理機能
入力
サポート
出力
貯蔵
変換
2014/06/21WACATE 2014 Summer
31
- 33. + 4.2.3. 考え方のポイント(5/5)
機能モデルの活用:非機能テスト
機能モデルの各構成要素に対して、注意すべき観点を付
与したものを活用
湯本氏による解説では、以下のモデルが用いられている
機能テストと同様、扱いやすいようにカスタマイズするとよい
出典:技術評論社 ソフトウェア・テストPRESS Vol.10
管理機能
入力
サポート
出力
貯蔵
変換
• 状態遷移の
タイミング
• 異常モード
• 排他制御
• 同期処理
• 利用メモリ量
• 利用するCPU量
• 異常データ
• 入力データ量
• 入力データサイズ
• 入力タイミング
• 入力方法
• 格納データサイズ
• ストレージ空き要領
• ファイルシステム/
OSの変更
• 接続機器の変更
• 他のソフトウェアと
の調整
• 出力データサイズ
• 出力データ異常
• 出力先 S/W状態
• 出力先 H/W状態
2014/06/21WACATE 2014 Summer
33
- 34. + 4.2.4. 具体例(1/2)-テストタイプ
出典:技術評論社 ソフトウェア・テストPRESS Vol.10
動的テスト システム/ソフトウェア構造の網羅性 構造テスト
機能性 機能テスト
機能組み合わせテスト
シナリオテスト
セキュリティテスト
使用性 ユーザビリティテスト
効率性 ロードテスト
ストレステスト
拡張性テスト
堅牢性テスト
回復性テスト
信頼性テスト
データ互換性テスト
構成テスト
両立性テスト
信頼性
互換性
2014/06/21WACATE 2014 Summer
34
- 37. + 4.3.1. プロセス概要
実施事項 検討したテストカテゴリおよび機能に対して、テストが必要な
組合せを分析し、実施すべきテストのパターンを抽出する
入力成果物 テストカテゴリ一覧 テストにおいての着眼点の一覧
機能一覧 テスト対象の一覧
出力成果物 テスト条件一覧 機能とテストカテゴリの組合せに対して、
具体的に実施すべきテストのパターンの
一覧
2014/06/21WACATE 2014 Summer
37
- 38. + 4.3.2. 手順
1. 機能とテストカテゴリの組合せに対して、テス
トが必要かどうかを判断する
2. テストが必要な箇所に対して、具体的に実施す
るべきテストのパターンを列挙する
2014/06/21WACATE 2014 Summer
38
- 39. + 4.3.3. 考え方のポイント
テスト分析マトリクスの活用
機能とテストカテゴリの組合せを考える際に、マトリク
スを作成することで分析が容易になる
テストカテゴリ1 テストカテゴリ2 テストカテゴリ3
機能
A
○ ○ −
機能B ○ ○ −
機能C − − ○
テストをするべきと判断した箇所について、
実際に実施すべきテストパターンを詳細化
2014/06/21WACATE 2014 Summer
39
- 40. + 4.3.4. 具体例(1/2)-テスト分析マトリクス
機能テスト ロード
テスト
堅牢性
テスト
データ互換
テスト
ボタン
押下
センサー
反応
内部
メモリ
状態
遷移
外部
メモリ
画面
表示
長時間
起動
条件
組合せ
メディア
互換
システム 電源管理 ○ ○ ○ ○ ○ ○
リセット ○ ○ ○ ○ ○
撮影 通常撮影 ○ ○ ○
ズーム撮影 ○ ○ ○
連続撮影 ○ ○ ○ ○
再生 通常再生 ○ ○
設定 撮影設定 ○ ○ ○
再生モード設定 ○ ○ ○
データ メモリ装着 ○ ○ ○ ○ ○
ファイルコピー ○ ○ ○ ○
ここについてテスト条件を詳細化
2014/06/21WACATE 2014 Summer
40
- 41. + 4.3.4. 具体例(2/2)-テスト条件
機能 テストタイプ テストカテゴリ テスト条件
システム 電源管理 機能テスト 画面表示 カメラの電源ON時にシステム起動画面が表示
されること
カメラの電源OFF時にシステム終了画面が表
示されること
...
2014/06/21WACATE 2014 Summer
41
- 42. + 4.4. ゆもつよメソッドのメリット
モデルがシンプル
他の方法論と比較して比較的手がつけやすい
機能とテストカテゴリの2軸による分析
スプレッドシートですぐ試せる
機能分解は実践しやすい
テストカテゴリを考える上での機能モデル例が示されている
2014/06/21WACATE 2014 Summer
42
- 43. + 4.5. 適用上の注意点(1/2)
テストレベルごとに分析が必要
機能を分析軸とするため、機能の粒度ごとに異なる分析
が必要となる
単体テスト用の分析
システムテスト様の分析…etc
機能「間」の表現は工夫が必要
より上位のテストレベルで検討する
「機能連携」というテストカテゴリを作成する
2014/06/21WACATE 2014 Summer
43
- 44. + 4.5. 適用上の注意点(2/2)
考慮しにくいテスト観点がある
モデルからトップダウンでテストカテゴリを検討するた
め、以下のようなものを考慮しにくい
プロダクトリスクを軽減するようなテスト
別途リスク分析を実施
過去に発生したレアケースバグを防ぐテスト
過去バグ情報等をもとにしたボトムアップな分析からもテスト
カテゴリを作成する
2014/06/21WACATE 2014 Summer
44
- 46. + 5.1. 前準備
既存テストケースを簡単に整理
テストケースを一意に特定するIDをふる
各テストケースを以下の要素ごとに整理する
事前条件 (when)
実施動作 (do)
期待結果 (then)
2014/06/21WACATE 2014 Summer
46
- 47. + 5.2. 整理手順(1/2)
Process Flow Diagram
機能モデル
テスト目的
分析
テスト対象
分析
テスト条件
検討
品質モデル
テストケース
機能一覧 テストカテゴリ一覧
テスト分析マトリクス
(テストケースのマッピング)
仕様書
2014/06/21WACATE 2014 Summer
47
- 48. + 5.2. 整理手順(2/2)
1. テスト対象分析
1. 各テストケースの対象となっている機能を列挙
2. 列挙された機能を整理
漏れている機能があれば随時追加
2. テスト目的分析
1. 各テストケースの期待結果に着目し、何を確認するテストなのか
をテストカテゴリとして列挙
不明な箇所は随時関係者に確認
2. 列挙されたカテゴリを整理
漏れているテストカテゴリがあれば随時追加
3. テスト条件検討
1. 各テストケースをテスト分析マトリクスのセルにマップ
マップされていないセルが本当にテスト不要かどうかを検討
2014/06/21WACATE 2014 Summer
48
- 50. + 6.1. テストケースの再利用
なぜ難しいか?
テストケースしか残っていない
必要十分なテストケースかどうかの判断が難しい
そのまま流用していいのか、仕様変更にあわせて内容を変更しな
いといけないのかの判断が難しい
テストの意図を理解することが重要
テスト分析・設計方法論を活用すると効果的
ある程度コストのかかる作業だが、メリットは大きい
既存資産に対する適切な理解
以降の開発におけるテスト分析・設計の容易化
2014/06/21WACATE 2014 Summer
50