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

「テストの種類を分類してみようー！」わんくま同盟＠名古屋 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

東海地域ソフトウエア技術者連携フォーラム主催: 静岡大学地域連携推進プロジェクト協賛: 東海ソフトウエア開発プロセス研究会開催日時: 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

広義のテストと狭義のテスト開発のライフサイクル要求設計実装テスト狭義だとここ？ 14

広義のテストと狭義のテストテストのライフサイクルテストの準備実施テストのライフサイクル全体で見ると。 15

広義のテストと狭義のテストテストのライフサイクル分析テストの準備実装設計実施テストを作る為のいろいろな工程が含まれます。 16

広義のテストと狭義のテスト開発のライフサイクルの一部要求設計実装テストテスト自体のライフサイクル分析設計実装実施話が噛み合わないよ 17

開発のライフサイクルとテストのライフサイクルテストのライフサイクル→ 分析設計実装システム要件定義テストの実施統合基本設計分析設計実装テストの実施単体詳細設計分析設計実装の実施テスト実装18 ETWEST2010

広義のテストと狭義のテスト• 狭義のテスト – テストケース(スクリプト/データ)の作成や実行• 広義のテスト – システムの品質定義からアプローチの選択を含むテスト設計の為の全般的な活動。テストにも開発同様、ライフサイクルがあり、ここを意識して話すのかで会話のギャップが大きく変わります。 19

このセッションのゴール/目的• ～テストという言葉を整理してみましょう。• 立場や開発対象によりテストの考え方/視点が異なってきます。• 皆さんのテストをマッピング、共有していき、俯瞰することで、必要なテストを考えて行きましょう。 21

本日の勉強の流れ1. 皆さんの知っている、xx テストを挙げてみましょう！2. テストの用語について整理しましょう！3. テスト全体を俯瞰し、テストのどの部分についての話なのか区別できるようにしょう！4. まとめ。 22

いきなりワーク 23

本日のワークでの成果物テスト技法ポジショニングマップ http://hayst.com/positioning.aspx 24

個人ワークテストをできるかぎり挙げてみましょう！<ルール>• xxテストと言う名前でなくても良いです。 (テストであると認識できていれば）• 時間の限りがんばりましょう！ 25

このワークの狙いこんなことを感じて頂ければ結構です。• 開発ドメインや組織が異なるとテスト種類も変わる。• テストにより狙う対象や目的が異なる。 26

ピンポイントと網羅的なテスト技法• 網羅的なテスト – 何らかのテストモデルを立ててそのモデルの網羅性をとりながら実施するテスト（主に仕様や構造ベース）・状態遷移図→ 状態遷移テスト・業務分析図→ 運用テスト・フローチャート → 構造テスト• ピンポイントなテスト – 経験や仮説を元にバグがありそうなところを狙い撃ちするテスト。（主に経験ベース）・エラー推定・探索的テスト「どうしたら不具合を起こせるだろう? 」と考える• 欄外：アドホック/モンキーテスト – テスト設計技法を用いず、テスト結果も予測せず、思いつきのまま実施するテスト。 28

縦軸2 Black Box/White Box•ブラックボックステスト(仕様ベースのテスト) – 内部構造を意識せず、システムの入力/出力に着目して実施するテスト。例：同値分割、デシジョンテーブル、ユースケーステスト•ホワイトボックステスト(構造ベースのテスト) – コンポーネントまたはシステムの内部構造の分析を元にして実施するテスト。例：パステスト（分岐/条件/複合条件テスト）•グレーボックステスト – 必要に応じ、構造を見るブラックボックステスト 29

グループワーク• おなじ席の方と、結果を見せ合ってください。• 一人、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

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

by Kenji Okumura on Jan 18, 2012

Accessibility

Categories

Tags

Upload Details

Usage Rights

1 Embed 4

Statistics

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