Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

14,611 views

Published on

  • Be the first to comment

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

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

×