テスト分析入門 -「ゆもつよメソッド」を例に- #wacate

+
テスト分析入門
-「ゆもつよメソッド」を例に-
WACATE実行委員朱峰錦司＠kjstylepp

+ 参考文献
 ソフトウェア・テスト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

+ 自己紹介
 所属
 某豊洲のSIer勤務
 〜2014.3
 テストプロセスおよびツールの研究開発
 2014.4〜
 アジャイルプロセスおよびツールの研究開発
 WACATE実行委員会
 テスト自動化研究会
 専門
 テスト分析・設計方法論
 TOPSE 7期生修了
 JSTQB Foundation Level
 テスト設計コンテスト’14 決勝戦3位
 スクラム
 認定スクラムマスター
3

+ 目次
1. テストケースの再利用
2. テスト分析・設計
3. ゆもつよメソッド
4. ゆもつよメソッドの実践
1. テスト対象分析
2. テスト目的分析
3. テスト条件検討
5. 既存テストケースの分析
6. まとめ
4

+
1. テストケースの再利用
5

+ 1.1. ソフトウェア開発プロジェクトの現状
半分以上が差分／派生／保守プロジェクト
 テストケースの再利用が発生するケースは多い
出典：IPA ソフトウェア産業の実体把握に関する調査
41%
54%
5%
新規
差分/派生/保守
その他
6

+ 1.2. 再利用のポイント
どんな問題があるか？
 テストケースしか残っていない
 必要十分なテストケースかどうかの判断が難しい
 そのまま流用していいのか、仕様変更にあわせて内容を変更しな
いといけないのかの判断が難しい
テストの意図を理解することが重要
 テスト分析・設計方法論を活用すると効果的
 ある程度コストのかかる作業だが、メリットは大きい
 既存資産に対する適切な理解
 以降の開発におけるテスト分析・設計の容易化
7

+
2. テスト分析・設計
8

+ 2.1. テストプロセス
 ISTQB
 国際的なテスト技術者資格認定期間による定義
 Test.SSF
 日本のテスト技術スキルフレームワークによる定義
 タスクは定義されるが細かな実施手順は提供されない
 手順を定義した方法論を参考にする
テスト
分析
テスト
設計
テスト
実装
テスト
実行
終了基準
の評価と
レポート
テスト
要求分析
テストアー
キテクチャ
設計
テスト
詳細設計
テスト
実装
テスト
実行
テスト
報告
テスト
評価
9

+ 2.2. テスト分析・設計方法論
様々な方法論が存在
 日本において有名な方法論
 VSTeP
 HAYST法
 ゆもつよメソッド…etc
 デファクトスタンダードはない
 プロジェクト特性などに応じて適宜選択
 今回はゆもつよメソッドを扱う
10

+ （参考）テスト設計コンテスト
ASTER（ソフトウェアテスト技術振興協会）主催
のテスト分析・設計技術を競うイベント
 http://aster.or.jp/business/contest.html
 2014年の様子
 http://aster.or.jp/business/contest/contest2014.html
2014年優勝チームＴＦＣＫＡ・ＲＩ・ＹＡ（東海代表）
出典：テスト設計コンテスト公式サイト
2日目のモーニングセンッションに
ご登壇いただきますのでお楽しみに！
11

+
3. ゆもつよメソッド
12

+ 3.1. 概要（1/3）
 日本HP 湯本剛氏が考案
 特徴
 テスト観点を2つの側面で整理
 何に対して
 ゆもつよメソッドでは「機能」と呼ぶ
 どこに着眼するか
 ゆもつよメソッドでは「テストタイプ」「テストカテゴリ」と呼ぶ
何に対して
どこに
着目するか
13

+ 3.1. 概要（2/3）
ゆもつよメソッドの全体像
実現したい品質
の具体的把握
テスト箇所の選択
テストの目的設定
テスト対象
アイテム特定
テストタイプ特定
機能の整理
＆再分類
テストカテゴリ
作成
テスト条件となる
仕様項目特定
テスト設計方針
特定
テストケース条件
特定
技法適用
（モデル化）
テストケース作成テスト手順作成
テスト計画テスト分析
テスト設計
テスト詳細設計テスト実装
出典：ソフトウェア・テストPRESS Vol.102014/06/21WACATE 2014 Summer
14

+ 3.1. 概要（3/3）
今回は一部のみを解説
実現したい品質
の具体的把握
テスト箇所の選択
テストの目的設定
テスト対象
アイテム特定
機能の整理
＆再分類
テストカテゴリ
作成
テスト条件となる
仕様項目特定
テスト設計方針
特定
テストケース条件
特定
技法適用
（モデル化）
テストケース作成テスト手順作成
テスト計画テスト分析
テスト設計
テスト詳細設計テスト実装
出典：ソフトウェア・テストPRESS Vol.102014/06/21WACATE 2014 Summer
15

+ 3.2. 適用手順（1/2）
以下の3ステップで解説
ステップ本講義におけるプロセスゆもつよメソッドにおけるプロセス
1 テスト対象分析機能の整理＆再分類
2 テスト目的分析
テストカテゴリ作成
3 テスト条件検討テスト条件となる仕様項目特定
16

+ 3.2. 適用手順 (2/2)
Process Flow Diagram
機能モデル
テスト目的
分析
テスト対象
分析
テスト条件
検討
品質モデル仕様書
機能一覧テストカテゴリ一覧
テスト条件一覧
17

+
4. ゆもつよメソッドの実践
18

+ 4.0. 実践の流れ
1. プロセス概要
2. 手順
3. 考え方
4. 具体例
 デジカメを例に
19

+
4.1. テスト対象分析
20

+ 4.1.1. プロセス概要
実施事項仕様書に書かれた内容を構造分解し、テスト対象とすべき機能
を抽出する
入力成果物仕様書テスト対象の仕様が書かれた成果物
出力成果物機能一覧テスト対象の一覧
21

+ 4.1.2. 手順
1. 仕様書から機能に該当するテスト対象を抽出
し、木構造で整理する
2. 末端のテスト対象を機能一覧として列挙する
22

+ 4.1.3. 考え方のポイント
ただの仕様書目次コピペにならないように
 仕様書の記述粒度がバラバラの可能性
 他のドキュメントにも記述がある可能性
マインドマップの活用
 木構造、および要素間の関連を表現するのに有用
○○システム A機能 A-1機能
A-2機能
B機能 B-1機能
B-2機能
C機能
23

+ 4.1.4. 具体例（1/2）-仕様確認
準備
− 充電
− メモリ装着
− 電源ON ／ OFF
操作
− 撮影
・撮影モード設定
・操作パネル
・フラッシュ
・ズーム撮影
・連続撮影
− 再生
・再生モード設定
・ファイルコピー
・表示レイアウト
設定
− メニュー操作
− 撮影設定
その他
− 電源管理
− モニタ表示内容
− リセット
− 画面メッセージ
仕様書目次
24

+ 4.1.4. 具体例（2/2）-機能整理
設定系を
グルーピング
目次にはなくても
入れる必要がありそう
画面の情報などは除外
25

+
4.2. テスト目的分析
26

実施事項仕様書および各種モデルから、考慮すべきテストタイプおよび
テストカテゴリを抽出する
入力成果物仕様書テスト対象の仕様が書かれた成果物
品質モデル考慮すべきテストタイプを決定する上で
参考にする品質の考え方
機能モデル考慮すべきテストカテゴリを決定する上
で参考にするソフトウェアの構造分解の
考え方
出力成果物テストカテゴリ一覧テストにおいての着眼点の一覧
27

+ 4.2.2. 手順
1. 品質モデルを参考に、考慮すべきテストタイプ
を決定する
2. 各テストタイプについて、機能モデルを参考に
テストカテゴリを決定する
1. 機能テスト：機能モデルの各構成要素に着目
2. 非機能テスト：機能モデルの構成要素に紐づく観点に
着目
28

+ 4.2.3. 考え方のポイント（1/5）
品質モデルの活用
 ソフトウェアが満たすべき品質を網羅した観点集
 代表的なものとしてJIS X 25010 「システム及びソフトウェアの
品質モデル」がある
出典：経済産業省システム／ソフトウェア製品の品質要求定義と品質評価のためのメトリクスに関する調査報告書
システム/ソフトウェア
製品品質
機能適合性性能効率性互換性使用性信頼性
セキュリ
ティ
保守性移植性
完全性
正確性
適切性
適切度認識性
習得性
運用性
ユーザエラー
防止性
ユーザインタ
フェースの快
美性
アクセシビリ
ティ
時間効率性
資源利用性
キャパシティ
共存性
相互運用性
成熟性
可用性
障害許容性
回復性
機密保持性
インテグリ
ティ
否認防止性
責任追跡性
真正性
モジュール性
再利用性
解析性
変更性
試験性
順応性
設置性
置換性
29

+ 4.2.3. 考え方のポイント（2/5）
品質モデルの活用
 確保したい品質を確認するためのテストを選択
 保守性や使用性など、テストでは保証しにくい品質もある
 湯本氏による解説では、以下のモデルが用いられている
出典：技術評論社ソフトウェア・テストPRESS Vol.10
動的テストシステム/ソフトウェア構造の網羅性構造テスト
機能性機能テスト
機能組み合わせテスト
シナリオテスト
セキュリティテスト
使用性ユーザビリティテスト
効率性ロードテスト
ストレステスト
...
30

+ 4.2.3. 考え方のポイント（3/5）
機能モデルの活用：機能テスト
 ソフトウェアの構造を分解したモデル
 品質モデルほど普及した考え方ではないため、デファク
トなモデルはない
管理機能
入力
サポート
出力
貯蔵
変換
31

+ 4.2.3. 考え方のポイント（4/5）
機能モデルの活用：機能テスト
 考えやすいようにカスタマイズ
 構成要素名も直観とあうものに変更してよい
 小演習では以下のような機能モデルを使ってみる
表示
データベース操作
処理
入力
チェック
入力
32

+ 4.2.3. 考え方のポイント（5/5）
機能モデルの活用：非機能テスト
 機能モデルの各構成要素に対して、注意すべき観点を付
与したものを活用
 機能テストと同様、扱いやすいようにカスタマイズするとよい
管理機能
入力
サポート
出力
貯蔵
変換
• 状態遷移の
タイミング
• 異常モード
• 排他制御
• 同期処理
• 利用メモリ量
• 利用するCPU量
• 異常データ
• 入力データ量
• 入力データサイズ
• 入力タイミング
• 入力方法
• 格納データサイズ
• ストレージ空き要領
• ファイルシステム/
OSの変更
• 接続機器の変更
• 他のソフトウェアと
の調整
• 出力データサイズ
• 出力データ異常
• 出力先 S/W状態
• 出力先 H/W状態
33

+ 4.2.4. 具体例（1/2）-テストタイプ
動的テストシステム/ソフトウェア構造の網羅性構造テスト
機能性機能テスト
機能組み合わせテスト
シナリオテスト
セキュリティテスト
使用性ユーザビリティテスト
効率性ロードテスト
ストレステスト
拡張性テスト
堅牢性テスト
回復性テスト
信頼性テスト
データ互換性テスト
構成テスト
両立性テスト
信頼性
互換性
34

+ 4.2.4. 具体例（2/2）-テストカテゴリ
管理機能
入力
サポート
出力
貯蔵
変換
ボタン押下
センサー反応
画面表示
外部メモリ
内部メモリ状態遷移
長時間起動
メディア互換
条件組合せ
機能非機能
35

+
4.3. テスト条件検討
36

実施事項検討したテストカテゴリおよび機能に対して、テストが必要な
組合せを分析し、実施すべきテストのパターンを抽出する
入力成果物テストカテゴリ一覧テストにおいての着眼点の一覧
機能一覧テスト対象の一覧
出力成果物テスト条件一覧機能とテストカテゴリの組合せに対して、
具体的に実施すべきテストのパターンの
一覧
37

+ 4.3.2. 手順
1. 機能とテストカテゴリの組合せに対して、テス
トが必要かどうかを判断する
2. テストが必要な箇所に対して、具体的に実施す
るべきテストのパターンを列挙する
38

+ 4.3.3. 考え方のポイント
テスト分析マトリクスの活用
 機能とテストカテゴリの組合せを考える際に、マトリク
スを作成することで分析が容易になる
テストカテゴリ1 テストカテゴリ2 テストカテゴリ3
機能
A
○ ○ −
機能B ○ ○ −
機能C − − ○
テストをするべきと判断した箇所について、
実際に実施すべきテストパターンを詳細化
39

+ 4.3.4. 具体例（1/2）-テスト分析マトリクス
機能テストロード
テスト
堅牢性
テスト
データ互換
テスト
ボタン
押下
センサー
反応
内部
メモリ
状態
遷移
外部
メモリ
画面
表示
長時間
起動
条件
組合せ
メディア
互換
システム電源管理 ○ ○ ○ ○ ○ ○
リセット ○ ○ ○ ○ ○
撮影通常撮影 ○ ○ ○
ズーム撮影 ○ ○ ○
連続撮影 ○ ○ ○ ○
再生通常再生 ○ ○
設定撮影設定 ○ ○ ○
再生モード設定 ○ ○ ○
データメモリ装着 ○ ○ ○ ○ ○
ファイルコピー ○ ○ ○ ○
ここについてテスト条件を詳細化
40

+ 4.3.4. 具体例（2/2）-テスト条件
機能テストタイプテストカテゴリテスト条件
システム電源管理機能テスト画面表示カメラの電源ON時にシステム起動画面が表示
されること
カメラの電源OFF時にシステム終了画面が表
示されること
...
41

+ 4.4. ゆもつよメソッドのメリット
モデルがシンプル
 他の方法論と比較して比較的手がつけやすい
 機能とテストカテゴリの2軸による分析
 スプレッドシートですぐ試せる
 機能分解は実践しやすい
 テストカテゴリを考える上での機能モデル例が示されている
42

+ 4.5. 適用上の注意点（1/2）
テストレベルごとに分析が必要
 機能を分析軸とするため、機能の粒度ごとに異なる分析
が必要となる
 単体テスト用の分析
 システムテスト様の分析…etc
 機能「間」の表現は工夫が必要
 より上位のテストレベルで検討する
 「機能連携」というテストカテゴリを作成する
43

+ 4.5. 適用上の注意点（2/2）
考慮しにくいテスト観点がある
 モデルからトップダウンでテストカテゴリを検討するた
め、以下のようなものを考慮しにくい
 プロダクトリスクを軽減するようなテスト
 別途リスク分析を実施
 過去に発生したレアケースバグを防ぐテスト
 過去バグ情報等をもとにしたボトムアップな分析からもテスト
カテゴリを作成する
44

+
5. 既存テストケースの分析
45

+ 5.1. 前準備
既存テストケースを簡単に整理
 テストケースを一意に特定するIDをふる
 各テストケースを以下の要素ごとに整理する
 事前条件 (when)
 実施動作 (do)
 期待結果 (then)
46

+ 5.2. 整理手順（1/2）
Process Flow Diagram
機能モデル
テスト目的
分析
テスト対象
分析
テスト条件
検討
品質モデル
テストケース
機能一覧テストカテゴリ一覧
テスト分析マトリクス
（テストケースのマッピング）
仕様書
47

+ 5.2. 整理手順（2/2）
1. テスト対象分析
1. 各テストケースの対象となっている機能を列挙
2. 列挙された機能を整理
 漏れている機能があれば随時追加
2. テスト目的分析
1. 各テストケースの期待結果に着目し、何を確認するテストなのか
をテストカテゴリとして列挙
 不明な箇所は随時関係者に確認
2. 列挙されたカテゴリを整理
 漏れているテストカテゴリがあれば随時追加
3. テスト条件検討
1. 各テストケースをテスト分析マトリクスのセルにマップ
 マップされていないセルが本当にテスト不要かどうかを検討
48

+
6. まとめ
49

+ 6.1. テストケースの再利用
なぜ難しいか？
 テストケースしか残っていない
 必要十分なテストケースかどうかの判断が難しい
 そのまま流用していいのか、仕様変更にあわせて内容を変更しな
いといけないのかの判断が難しい
テストの意図を理解することが重要
 テスト分析・設計方法論を活用すると効果的
 ある程度コストのかかる作業だが、メリットは大きい
 既存資産に対する適切な理解
 以降の開発におけるテスト分析・設計の容易化
50

+ 6.2. テスト分析・設計方法論
様々な方法論が存在
 日本において有名な方法論
 VSTeP
 HAYST法
 ゆもつよメソッド…etc
 ゆもつよメソッドのテスト分析パート
51

+ 6.3. 既存テストケースの整理
 テストケースからテスト分析
マトリクスをリバース
52

+
Let’s Reverse!
2014/06/21 WACATE 2014 Summer

テスト分析入門 -「ゆもつよメソッド」を例に- #wacate

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to テスト分析入門 -「ゆもつよメソッド」を例に- #wacate

Similar to テスト分析入門 -「ゆもつよメソッド」を例に- #wacate (20)

More from Kinji Akemine

More from Kinji Akemine (9)

テスト分析入門 -「ゆもつよメソッド」を例に- #wacate