• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
テストを分類してみよう!
 

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

on

  • 9,241 views

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

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

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

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

Statistics

Views

Total Views
9,241
Views on SlideShare
9,232
Embed Views
9

Actions

Likes
12
Downloads
0
Comments
0

3 Embeds 9

http://us-w1.rockmelt.com 4
https://twitter.com 4
https://www.chatwork.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

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