Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

テストを分類してみよう!

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige

Hier ansehen

1 von 89 Anzeige

テストを分類してみよう!

当資料は、2012/1/14に開催された、以下の勉強会で発表した資料です。

わんくま同盟 名古屋勉強会 #20 & 第39回 名古屋アジャイル勉強会 & TEF東海 勉強会
http://www.wankuma.com/seminar/20120114nagoya20/

1/19 ・当日のワークの結果を追加した
    ・TEFの紹介部分を微修正
    ・P1タイトル誤字を修正
1/23 ・WACATEのリンクを追加
    ・テスト設計関連の参考リンクを追加
・P18の図にライフサイクルの補足を追加
・P16の表示が変だったのを直したよ

当資料は、2012/1/14に開催された、以下の勉強会で発表した資料です。

わんくま同盟 名古屋勉強会 #20 & 第39回 名古屋アジャイル勉強会 & TEF東海 勉強会
http://www.wankuma.com/seminar/20120114nagoya20/

1/19 ・当日のワークの結果を追加した
    ・TEFの紹介部分を微修正
    ・P1タイトル誤字を修正
1/23 ・WACATEのリンクを追加
    ・テスト設計関連の参考リンクを追加
・P18の図にライフサイクルの補足を追加
・P16の表示が変だったのを直したよ

Anzeige
Anzeige

Weitere Verwandte Inhalte

Diashows für Sie (20)

Andere mochten auch (20)

Anzeige

Ähnlich wie テストを分類してみよう! (20)

Aktuellste (20)

Anzeige

テストを分類してみよう!

  1. 1. 「テストの種類を分類してみようー!」 わんくま同盟 @名古屋 KENさん(TEF東海) 1
  2. 2. 自己紹介 • 名前 KENさん(@krsna_crespo) – 組込み開発のシステムテスト担当 • 主な出没場所 – ソフトウェアテスト技術者交流会(TEF)所属 • 上記の東海地域分科会がTEF東海 – JaSST(ソフトウェアテストシンポジウム)東海実 行委員 – WACATE実行委員 – 浜松JSTQB勉強会 補佐 – 名古屋アジャイル勉強会 末端 2
  3. 3. ソフトウェアテスト技術者交流会 TEF(Test Engineer's Forum) • TEF – 情報交換や技術向上を目指した、ソフトウェアテス ト技術者の交流会です。ソフトウェアテストに携わっ ている技術者の方なら、どなたでも入会できます。 • TEF東海 – TEFの地域部会です。 – MLでの意見交換、定期的な勉強会 • メトリクス勉強会 • テスト技法勉強会 TEFに興味ある方はこちらから↓ http://www.swtest.jp/ 3
  4. 4. 忘れないうちに宣伝。 4
  5. 5. 5
  6. 6. 6
  7. 7. 東海地域ソフトウエア技術者連携 フォーラム 主催: 静岡大学 地域連携推進プロジェクト 協賛: 東海ソフトウエア開発プロセス研究会 開催日時: 2012年1月20日(金) 15:00〜 開催場所: アクトシティ コングレスセンター53, 54会議室 招待講演 1040を超える運賃計算の組合せ、無停止でのプログラム更新、自動改札機に求め られる厳しい要求と組込みソフトウエアの開発 幡山 五郎氏(オムロンソーシアルソリューションズ株式会社) パネルディスカッション 〜 組込みソフトウエア開発の課題と今後(パネル概要) http://ese.inf.shizuoka.ac.jp/events/rp-120120.html 7
  8. 8. WACATE(ワカテと読みます) 「Workshop for Accelerating CApable Testing Engineers」 の略 参加頂いている方々 ソフトウェア開発や品質に関わる全ての技術者。 <主な活動> 年二回(夏/冬)でのソフトウェアテストに関する ワークショップを1泊2日で開催。 フリーペーパー WACATE Magazineの発行 同人誌 Software testing maniaxの発行 WACATEに興味のある方はこちらから↓ http://wacate.jp/ 8
  9. 9. ここから本編。 9
  10. 10. 本日の資料について 本日のワークショップはWACATE2010冬で 鈴木三紀夫氏が実施した「技法を勉強する前 に」のミニミニワークを、 Agile Japan2011名古屋サテライト用に再編集し さらに、このイベント用に解説を加え再編集し ています。 10
  11. 11. はじめに 11
  12. 12. XXテストという用語は多く、ステークホルダや 組織、チームの中で会話をしづらい事はあり ませんか? <理由> • イメージするテストの認識範囲が違う。 • 用語の意味がわからない 12
  13. 13. XXテストという用語は多く、ステークホルダや 組織、チームの中で会話をしづらい事はあり ませんか? <理由> • イメージするテストの認識範囲が違う。 • 用語の意味がわからない 13
  14. 14. 広義のテストと狭義のテスト 開発のライフサイクル 要求 設計 実装 テスト 狭義だとここ? 14
  15. 15. 広義のテストと狭義のテスト テストのライフサイクル テストの準備 実施 テストのライフサイクル 全体で見ると。 15
  16. 16. 広義のテストと狭義のテスト テストのライフサイクル 分析テストの準備実装 設計 実施 テストを作る為のいろいろ な工程が含まれます。 16
  17. 17. 広義のテストと狭義のテスト 開発のライフサイクルの一部 要求 設計 実装 テスト テスト自体のライフサイクル 分析 設計 実装 実施 話が噛み合わないよ 17
  18. 18. 開発のライフサイクルと テストのライフサイクル テストのライフサイクル→ 分析 設計 実装 システム 要件定義 テスト の実施 統合 基本設計 分析 設計 実装 テスト の実施 単体 詳細設計 分析 設計 実装 の実施 テスト 実装 18 ETWEST2010
  19. 19. 広義のテストと狭義のテスト • 狭義のテスト – テストケース(スクリプト/データ)の作成や実行 • 広義のテスト – システムの品質定義からアプローチの選択を 含 むテスト設計の為の全般的な活動。 テストにも開発同様、ライフサイクルがあり、ここ を意識して話すのかで会話のギャップが大きく変 わります。 19
  20. 20. XXテストという用語は多く、ステークホルダや 組織、チームの中で会話をしづらい事はあり ませんか? <理由> • イメージするテストの認識範囲が違う。 • 用語の意味がわからない 20
  21. 21. このセッションのゴール/目的 • ~テストという言葉を整理してみま しょう。 • 立場や開発対象によりテストの考 え方/視点が異なってきます。 • 皆さんのテストをマッピング、共有 していき、俯瞰することで、必要な テストを考えて行きましょう。 21
  22. 22. 本日の勉強の流れ 1. 皆さんの知っている、xx テストを挙げてみま しょう! 2. テストの用語について整理しましょう! 3. テスト全体を俯瞰し、テストのどの部分につ いての話なのか区別できるようにしょう! 4. まとめ。 22
  23. 23. いきなりワーク 23
  24. 24. 本日のワークでの成果物 テスト技法ポジショニングマップ http://hayst.com/positioning.aspx 24
  25. 25. 個人ワーク テストをできるかぎり挙げてみましょう! <ルール> • xxテストと言う名前でなくても良いです。 (テストであると認識できていれば) • 時間の限りがんばりましょう! 25
  26. 26. このワークの狙い こんなことを感じて頂ければ結構です。 • 開発ドメインや組織が異なるとテスト種類も 変わる。 • テストにより狙う対象や目的が異なる。 26
  27. 27. テスト技法ポジショニングマップ 顧客要求 Black Box 要件 ピンポイント 網羅的 付箋紙の例 付箋紙の例 対象成果物や 仕様 テストの実施者 設計モデル 必要なスキル テストの名称 テストの名称 設計 White Box Copyright(C)2011 Kenji Okumura All rights reserved 27
  28. 28. ピンポイントと網羅的なテスト技法 • 網羅的なテスト – 何らかのテストモデルを立ててそのモデルの網羅性をとり ながら実施するテスト(主に仕様や構造ベース) ・状態遷移図→ 状態遷移テスト ・業務分析図→ 運用テスト ・フローチャート → 構造テスト • ピンポイントなテスト – 経験や仮説を元にバグがありそうなところを狙い撃ちするテ スト。(主に経験ベース) ・ エラー推定 ・ 探索的テスト 「どうしたら不具合を起こせるだろう? 」と考える • 欄外:アドホック/モンキーテスト – テスト設計技法を用いず、テスト結果も予測せず、思いつき のまま実施するテスト。 28
  29. 29. 縦軸2 Black Box/White Box •ブラックボックステスト(仕様ベースのテスト) – 内部構造を意識せず、システムの入力/出力に着目 して実施するテスト。 例:同値分割、デシジョンテーブル、ユースケース テスト •ホワイトボックステスト(構造ベースのテスト) – コンポーネントまたはシステムの内部構造の分析を 元にして実施するテスト。 例:パステスト(分岐/条件/複合条件テスト) •グレーボックステスト – 必要に応じ、構造を見るブラックボックステスト 29
  30. 30. テスト技法ポジショニングマップ 顧客要求 Black Box 要件 ピンポイント 網羅的 付箋紙の例 付箋紙の例 対象成果物や 仕様 テストの実施者 設計モデル 必要なスキル テストの名称 テストの名称 設計 White Box Copyright(C)2011 Kenji Okumura All rights reserved 30
  31. 31. グループワーク • おなじ席の方と、結果を見せ合ってください。 • 一人、2分 31
  32. 32. これまでのワークの結果 32
  33. 33. WACATE2010冬での結果 33
  34. 34. Agile Japan2011名古屋サテライト 34
  35. 35. Agile Japan2011名古屋サテライト 35
  36. 36. 並べてみた。 All Pare法 リグレッションテスト 受け入れテスト 非機能要件テスト システムテスト CFD 正常系テスト 環境テスト デシジョンテーブル ランダムテスト 高負荷テスト 境界値テスト パステスト 排他制御テスト 受け入れテスト 単体テスト 機能確認テスト 異常系テスト 表示テスト 排他制御テスト 顧客運用テスト プレテスト 表示テスト 埋め込みテスト 疎通テスト 障害訓練テスト 疎通テスト ユーザオペレーション 設計レビュー 状態遷移テスト 移行リハーサル 仕様レビュー 静的チェック 直交表 コードレビュー 埋め込みテスト 36
  37. 37. 並べてみた。 All Pare法 リグレッションテスト 受け入れテスト 非機能要件テスト システムテスト CFD 正常系テスト 環境テスト デシジョンテーブル ランダムテスト よくわからない 高負荷テスト 境界値テスト パステスト 排他制御テスト 受け入れテスト 単体テスト 機能確認テスト 異常系テスト 表示テスト 排他制御テスト 顧客運用テスト プレテスト 表示テスト 埋め込みテスト 疎通テスト 障害訓練テスト 疎通テスト ユーザオペレーション 設計レビュー 状態遷移テスト 移行リハーサル 仕様レビュー 静的チェック 直交表 コードレビュー 埋め込みテスト 37
  38. 38. 分類してみた。 動的テスト 静的テスト 受け入れテスト 機能テスト タイミングテスト コードレビュー ランダムテスト 静的チェック 顧客運用テスト 環境テスト シナリオテスト 設計レビュー システムテスト 高負荷テスト パステスト 仕様レビュー 単体テスト 排他制御テスト デシジョンテーブル 表示テスト 境界値テスト 非機能要件テスト 埋め込みテスト 疎通テスト 状態遷移テスト 正常系テスト 機能確認テスト 直交表 異常系テスト プレテスト All Pare法 排他制御テスト CFD 障害訓練テスト ランダムテスト 表示テスト ユーザオペレーション パステスト ユーザ観点のテスト 移行リハーサル リグレッションテスト 38
  39. 39. 動的テストを分類してみた。 テストレベル テストタイプ テスト技法 受け入れテスト 機能テスト タイミングテスト 顧客運用テスト 環境テスト ランダムテスト シナリオテスト システムテスト 高負荷テスト パステスト 単体テスト 排他制御テスト デシジョンテーブル 移行リハーサル 表示テスト 境界値テスト 埋め込みテスト 疎通テスト 状態遷移テスト 非機能要件テスト 機能確認テスト 直交表 正常系テスト All Pare法 プレテスト 異常系テスト CFD 障害訓練テスト ランダムテスト 排他制御テスト ユーザオペレーション パステスト 表示テスト リグレッションテスト ユーザ観点のテスト 39
  40. 40. こんな感じで分類できそう。 • テスト設計技法 • テストタイプ • テストレベル 40
  41. 41. せつめい 41
  42. 42. テスト技法 42
  43. 43. テスト技法 • 必要なテスト条件やデータを選択しテスト ケースを作成していく為の技法。 43
  44. 44. テスト(設計)技法 設計モデルベース 網羅基準 状態遷移図 状態遷移テスト テストケース テスト手順 網 フロー図 パステスト テストケース 期待結果 羅 的 業務シナリオ シナリオテスト テストケース テスト条件 テストデータ ユースケース ユースケーステスト テストケース 仕様ベース 機能テスト テストケース 機能仕様 テストケース 経験ベース 境界値テスト ピ ドメイン知識 探索的テスト テストケース ン ポ デバッグ経験 イ エラー推定 テストケース ン 過去の失敗体験 ト 的 悪夢とか不安 44
  45. 45. テストタイプ 45
  46. 46. テストタイプ コンポーネントまたはシステムに相関する品質特性に向 けたテスト活動の分類。各テストタイプは、特定のテスト の目的にフォーカスしている。(JSTQBシラバスより) 例えば、 • 機能テスト • 非機能テスト • 信頼性テスト • 回帰テスト • … etc 46
  47. 47. 品質特性 テストタイプの種類 品質特性と紐付され分類されている物。 湯本さんの分類 主特性 副特性 東芝の分類 IBM岡崎さんの分類 ソフトウェアテストPressVol10参照 機能性 合目的性 機能テスト(仕様と合致-正確性) 機能テスト 機能部分テスト 正確性 機能組み合わせテスト 構成テスト 手続きテスト 相互運用性 シナリオテスト(要求と合致-合目的性) インストールテスト 機密保護テスト セキュリティ セキュリティーテスト 説明書テスト 標準的合成 適合性テスト 信頼性 成熟性 ロバストネス(堅牢性)テスト 信頼性テスト 負荷テスト 障害許容性 回復性テスト 負荷テスト 大容量テスト 回復性 信頼性テスト 回復テスト 信頼性テスト 標準的合成 回復テスト 使用性/利用性 理解性 ユーザビリティーテスト ユーザビリティテスト 有用度テスト 習得性 マニュアルテスト 導入テスト 運用性 魅力性 標準適合性 効率性 時間効率性 ロードテスト 性能テスト 性能テスト 資源効率性 ストレステスト 記憶域テスト 標準適合性 拡張性テスト 保守性 解析性 保守性/保全性テスト 保全性テスト 変更性 安定性 試験性 標準適合性 移植性/互換性 環境適応性 データ互換性テスト 互換性/変換テスト 環境(構成)テスト 設置性 構成テスト 共存性 両立性テスト 47 置換性 引用元は最後のページを参照
  48. 48. ソフトウェア品質特性 • 開発対象となるシステムの品質に影響を与える機能や特 性のことを言います。 • 品質特性には以下のようなものがあります。 – 機能性:目的から求められる機能の実装度合い – 信頼性:機能が正常動作し続ける度合い – 使用性:分かりやすさ、使いやすさの度合い – 効率性:目的達成の為に使用する資源の度合い – 保守性:保守(改訂)作業に必要な努力の度合い – 移植性:別環境へ写した歳、そのまま動作する度合い 詳細はこちらを参照ください。「Software Quality.com」 http://sw-quality.com/swcharast.aspx 48
  49. 49. テストタイプ 抽象度のばらつき有り 機能性 機能テスト 信頼性 非機能テスト 信頼性テスト 高負荷テスト 使用性 大容量テスト ユーザビリティ テスト 効率性 性能テスト xxx性能 保守性 保守性テスト 移植性 互換性テスト 環境構成テスト 49
  50. 50. テストタイプ • そのテストの目的を示すのがテストタイプ。 と理解してよさそう。 • 逆に言うと、具体的な実現方法は示してい ない。(実装方法等) • 組織独自の名前が付いている場合が多いと 感じる。 • 既にあるテストケースを同じ目的にまとめて 名前をつけてみよう! 50
  51. 51. テストタイプとテスト技法の関係を 見てみる。 51
  52. 52. テストの構造の一例 機能性 テストタイプ テスト技法 テストケース テスト手順 機能/仕様 テストデータ 信頼性 テストタイプ テスト技法 テストケース テスト手順 使用性 テストデータ テストタイプ 効率性 テスト技法 テストケース テスト手順 テストデータ 保守性 テストタイプ テスト技法 テストケース テスト手順 移植性 テストデータ テストタイプ 機能/仕様 52
  53. 53. テストのライフサイクル 分析 設計 実装 実行 53
  54. 54. テストのライフサイクル トップダウンアプローチ ボトムアップアプローチ 54
  55. 55. テストレベル 55
  56. 56. テストレベル テストレベル:組織的に管理されるテスト作業のグループ。テス トレベルはプロジェクトの責任に対応する。(JSTQBシラバスより 抜粋) • テスト作業をテスト対象(開発ドキュメント、 開発対象)や責任範囲単位に分割したもの。 • テストレベル毎に検出される欠陥の種類が 異なる 56
  57. 57. テストレベル テスト対象 テストベース コンポーネントテスト モジュール、プログラム、オブジェクト、ク 詳細設計書 ラス、など。 データモデル ユニットテスト、モジュール テスト、単体テスト 統合テスト コンポーネント間のインターフェース I/F仕様 結合 システム設計 書 システムテスト システム構成・構成データなど システム要求 仕様 αテスト、βテスト 機能仕様 受け入れテスト 非機能要件の確認や、運用面のテストなど ユーザ要件 業務プロセス 57
  58. 58. テストレベルと分割単位 俺のところ 俺とお前のところ うちの会社と他の会社 あたしのGpとあんたのGp システム全体 58
  59. 59. んで、 59
  60. 60. テストレベルを 全部無視するのが ビッグ・バン テストー!! ! 60
  61. 61. • ビッグバンテスト – 統合テストの一形式。ソフトウェアの構成要素、 ハードウェアの構成要素、または両方を、段階的に ではなく、一挙にコンポーネントやシステムに結合 して実施する。 • リスクベースドテスト – プロジェクトの初期段階からプロダクトリスクのレベ ルを低下させ、当事者にその状態を通知するテスト の方法。プロダクトリスクの識別の他、テストプロセ スをガイドする際のリスク活用もこれに含まれる。 – プロダクトリスク・プロジェクトリスク、発生確率/イン パクトの面からアセスメントを行う。 61
  62. 62. これって何? ビッグバンテスト リスクベースドテスト • テストの作業単位や段階を示すものではな さそう。→テストレベル • テストの目的を示すものでもなさそう。 → テストタイプ • テストケースに落としこむ手法でもなさそう。 → テスト設計技法 62
  63. 63. テスト/戦略・アプローチ テスト戦略:実施するテストレベルと書くテストレベルでのテスト 内容を高位レベルで説明したもの テストアプローチ:テストタイプの適用、テスト技法の選択、開 始・終了基準の定義を行う為の出発点 (JSTQBシラバスより抜粋) • 分析的アプローチ (リスクベーステスト) • モデルベースアプローチ (故障率など統計的情報を使 う確率テストなど) 探針テスト、オペレーションプロファ イルとか? • 方法論的アプローチ(ビッグバンここ?) • 動的、経験則的に基づいたアプローチ • ・・・etc 63
  64. 64. テスト戦略 テスト テスト テスト テスト アプローチ レベル タイプ 技法 テストレベル テストタイプ テスト技法 テストケース 機能/仕様 テストタイプ テスト技法 テストケース 機能/仕様 テストレベル テストタイプ テスト技法 テストケース テストタイプ テスト技法 テストケース 機能/仕様 テストレベル テストタイプ テスト技法 テストケース テストタイプ テスト技法 テストケース 機能/仕様 テストレベル テストタイプ テスト技法 テストケース テストタイプ テスト技法 テストケース 64
  65. 65. テスト戦略・アプローチ • テスト戦略やアプローチは、開発するシステ ムの重要度やリスク、開発方法などによりよ り適切なものを選んでいきます。 65
  66. 66. テスト リスクベースだったり テスト テスト テスト アプローチ レベル タイプ 技法 テストレベル テストタイプ テスト技法 テストケース リスク テストタイプ テスト技法 テストケース リスク テストレベル テストタイプ テスト技法 テストケース テストタイプ テスト技法 テストケース リスク テストレベル テストタイプ テスト技法 テストケース テストタイプ テスト技法 テストケース リスク テストレベル テストタイプ テスト技法 テストケース テストタイプ テスト技法 テストケース 66
  67. 67. 直感だったり 67
  68. 68. 探索的なアプローチだったり 68
  69. 69. ビッグ・バーン だったり!! 69
  70. 70. • テスト戦略やアプローチを決めていくことで、 プロジェクトのテストを俯瞰することができま す。 • また、テストイメージをプロジェクトメンバー やステークホルダと合わせることで、コミュニ ケーションが円滑になります。 70
  71. 71. テスト テスト テスト テスト アプローチ レベル タイプ 技法 テストレベル テストタイプ テスト技法 テストケース 機能/仕様 テストタイプ テスト技法 テストケース 機能/仕様 テストレベル テストタイプ テスト技法 テストケース テストタイプ テスト技法 テストケース 機能/仕様 テストレベル テストタイプ テスト技法 テストケース テストタイプ テスト技法 テストケース 機能/仕様 テストレベル テストタイプ テスト技法 テストケース テストタイプ テスト技法 テストケース 71
  72. 72. まとめ <やったこと> • たくさんのテストの用語があることを共有で きました。 • 用語の区別がなんとなくできました。 • テストの俯瞰ができるようになりました。 72
  73. 73. ご清聴ありがとう ございました。 おわり 73
  74. 74. <引用/参考> • JSTQB シラバス/用語集 http://jstqb.jp/syllabus.html • ソフトウェア・テストPRESS Vol.10 「今こそ聞きたい テストの上流設計」 湯本氏 http://bit.ly/xiBOyA • テスト技法ポジショニングマップ 秋山氏 http://hayst.com/positioning.aspx • 「ソフトウェア品質技術の開発と適用」 森氏、櫻庭氏、中野氏 http://www.toshiba.co.jp/tech/review/2006/01/61_01pdf/a06.pdf • 「ソフトウェア品質特性に基づいたシステム・テスト設計」岡崎氏 http://ci.nii.ac.jp/naid/110002945746 • 鈴木三紀夫氏(@mkoszk)との議論 74
  75. 75. <参考> ・高信頼化ソフトウェアのための開発手法ガイドブック http://sec.ipa.go.jp/reports/20100915.html ・テストスキル標準(JaSST’11Tokyo) http://jasst.jp/archives/jasst11e.html#project1 ・ テスト開発方法論(JaSST’11Tokyo) http://jasst.jp/archives/jasst11e.html#project2 ・ テスト設計コンテスト(JaSST’11Tokyo) http://jasst.jp/archives/jasst11e.html#project4 75
  76. 76. (おまけ) 当日のワーク結果 76
  77. 77. 77
  78. 78. 78
  79. 79. 79
  80. 80. 80
  81. 81. 81
  82. 82. 82
  83. 83. 83
  84. 84. 84
  85. 85. 85
  86. 86. 86
  87. 87. 87
  88. 88. 88
  89. 89. 89

×