テスト分析・テスト設計入門

Size: px

Start display at page:

Download "テスト分析・テスト設計入門"

のぶあきはかまや
5 years ago
Views:

1 JaSST 2013 四国テスト分析テスト設計入門富士ゼロックス株式会社ソリューションサービス開発本部秋山浩一

モデル研究会主査 (2011 年 7 月 ~) 電通大西康晴先生 NEC 吉澤智美氏 MRT 鈴木三紀夫氏 ISO/IEC JTC 1/SC7 WG26 委員 (2009~) ソフトウェアテストの国際標準

2 自己紹介 1985 年 4 月富士ゼロックス入社現在は HAYST 法のコンサルティング業務に従事 NPO ソフトウェアテスト技術振興協会 (ASTER) 理事 JaSST 東京実行委員 (2003 年 ~) 日本最大のテストシンポジウム 1600 名の動員 JSTQB ステアリング委員 (2006~) テスト技術者資格認定を行う国際組織日本支部日科技連 SQiP 研究会委員長 (2011 年 ~) W モデル研究会主査 (2011 年 7 月 ~) 電通大西康晴先生 NEC 吉澤智美氏 MRT 鈴木三紀夫氏 ISO/IEC JTC 1/SC7 WG26 委員 (2009~) ソフトウェアテストの国際標準 ISO29119 策定中共著書ソフトウェアテスト HAYST 法入門 ( 日科技連出版社 ) (2008 年度日経品質管理文献賞受賞 ) 著書ソフトウェアテスト技法ドリル ( 全国の勉強会で活用 ) 博士 ( 工学 ) 2

3 本コースの狙いとアジェンダテストの作り方を理解することが狙いソフトウェアテストとはテストプロセス演習 6W2Hで分析ユーザーストーリーで価値を理解 FV 表で整理ラルフチャートで因子を発見まとめ 3

4 ソフトウェアテストとはソフトウェアテストの目的従来のテスト方法 ( 初期テスト )

5 V 字モデルによる信頼性マップ User Requirements Design Validation Software Validation 参照保田勝通著ソフトウェア品質保証の考え方と実際 P36 図 1.10 不良低減のための方針 (1995 年 11 月 ) ユーザー要求の分析品質機能展開プロダクトリスク分析 Product 1 不具合を作り込まない努力不良入り込み分布設計努力要求分析 UML 構造化分析レビュー, インスペクション Software 機能設計 Verification システムテスト 2 プロセスで抑える努力 Software Life Cycle Process Verification 内部設計詳細設計 Verification Verification 単体テスト結合テストテストプログラミングコーディングルールコードインスペクション静的コードテストメトリクス分析 3 不具合を摘出する努力不良摘出分布レビュー, インスペクション統計分析不具合データベース不具合発生対策曲線各種テスト摘出努力 5

6 ソフトウェアテストの目的欠陥を摘出する定義 ( 要求仕様設計 ) された通りに動くことを確認する未定義部分で何が起こるか分からないので網羅的に確認する ( ) 対象ソフトウェアの品質レベルが十分であることを確認する品質を保証するためのエビデンス ( 証拠 ) を残す ( ) 実際のデータを用いて擬似的に動作確認を行いメトリクスを確認する意思決定のための情報を示すテスト計画時にリスクがどれだけ減るか示すテスト結果報告時に残リスクを示す ( ) 欠陥の作り込みを防ぐドキュメントやソースコードのレビューを実施する本質的なバグの知識をきちんと考え蓄え開発に活用する ( ) は特にテストで重要なこととして電気通信大学の西康晴先生が主張されました 6

7 テスト技法の位置づけ ( テスト技法の種類 ) 構造 ( 技術作り方 ) 経験 ( バグの知識 ) カバレッジエラー推測探索的テスト業務シナリオフローデータ C0, C1, MC/DC CRUD テスト技法単機能同値分割境界値分析仕様 ( モデル ) 組合せ ( 条件 ) 有則無則状態遷移図表デシジョンテーブル直交表 Pairwise 原因結果グラフ CFD 法タグチメソッド HAYST 法状態 ( 振る舞い ) N- スイッチカバレッジ PathCombo 機能図式並行並列 ( プロトコル ) ペトリネット並行状態グラフ様々な技法がありこれを適用することが大切 7

8 テスト技法の時間的適用初期テスト (JSTQB テストの 7 原則の 3 ) 早く欠陥を見つけるためにテストはソフトウェア開発もしくはシステム開発のライフサイクルのなるべく早い時期に開始しあらかじめ定義した目的に集中すべきである関数ができたら構造のテストを行う少しでも動くようになったら単機能テストを行ういくつか動き始めたら組合せテストを徐々に広げていくシステムとして動くようになってきたら状態遷移テストをする全部ができたら経験ベースのテストを行う品質保証のため各種計測を行う ( 非機能要件を含む ) 8

9 出来上がるにつれて構造機能振る舞い並行順にテスト構造 (1:1) 機能 ( 多 :1) 振る舞い (1: 多 ) 並行並列 ( 多 : 多 ) C0, C1, MC/DC, CRUD 単機能 DT, CEG/CFD, HAYST 状態遷移図表, N-switch, ユースケース, カバリングアレイ White Box Testing Gray Box Testing Black Box Testing ペトリネット, シナリオ, Model Checking テスト観点が異なっている全てのテストが必要片岡雅憲ソフトウェアモデリングより 9

10 テストプロセスなぜ従来のテストではだめなのか智美塾や Test.SSF が提案するテストプロセス HAYST 法のテストプロセス

11 従来のテストの問題点三遊間が漏れる機能拡張では上手くいくが新規機能追加では上手くいかない新技術が入った場合に何をテストしたらよいか分からないテストの全体が開発に依存するので分かり難いテストの重複が発生するテストの抜けが発生する要求に対しての確認が不十分で使えない機能が生まれる非機能のテストが不足しやすいユーザーの観点が少ない市場導入後基本的な問題が出る ( やりたいことができない ) 市場の変化に対応できずすぐに陳腐化してしまう 11

12 智美塾や Test.SSF のテストプロセス智美塾のテストプロセステスト要求分析テストアーキテクチャ設計テスト詳細設計テスト実装テスト実施 Test.SSF のテストプロセス業務要件定義受け入れテストのテストライフサイクル要求分析アーキ設計詳細設計実装実行報告評価受け入れテストシステム要件定義システムテストのテストライフサイクル要求分析アーキ設計詳細設計実装実行報告評価システムテスト基本設計統合テストのテストライフサイクル要求分析アーキ設計詳細設計実装実行報告評価結合テストテスト要求分析テストアーキテクチャ設計テスト詳細設計が必要 ( 具体的には?) 詳細設計コンポーネントテストのテストライフサイクル要求分析アーキ設計詳細設計実装実行報告評価実装単体テスト 12

13 HAYST 法のテストプロセス ( 智美塾や Test.SSF の具体例の一つ ) テスト戦略は必ず開発戦略と同期を取る戦略 6W2H FV 表テスト分析テスト設計ラルフチャートノイズと状態 FL 表 < ツール > Matrix Tester PICT などテスト実装テスト実施 < ツール > データ駆動型自動テスト QTP など HAYST 法は初めは直交表を用いたテスト実装 ( 赤枠 ) 部分を意味していたそれでは三遊間問題が起こるのでテスト全体のプロセスを考えた今では全体を HAYST 法と呼んでいる HAYST 法はシステムテストが対象コンポーネントテスト統合テストは ABC( 当たり前のことをぼんやりせずに菅野文友先生 ) で良いつまり TDD/C1 カバレッジ / 境界値分析 / デシジョンテーブル / 自動化 13

HAYST 法のテストプロセステスト要求分析テスト設計テスト実装テスト実施仕様書設計書マニュアルテスト要求分析 6W2H テスト観点ツリー画面オブジェクトのキャプチャーによる DHC_G 因子水準の抽出 : プロセス : 成果物 FV 表 ( 目的機能分析 ) 組合せテストアーキテクチャー設計 DHC_G ( ラルフチャート ) 入力ノイズ

14 HAYST 法のテストプロセステスト要求分析テスト設計テスト実装テスト実施仕様書設計書マニュアルテスト要求分析 6W2H テスト観点ツリー画面オブジェクトのキャプチャーによる DHC_G 因子水準の抽出 : プロセス : 成果物 FV 表 ( 目的機能分析 ) 組合せテストアーキテクチャー設計 DHC_G ( ラルフチャート ) 入力ノイズ目的機能を表す図 FL 表 ( 因子水準 ) No F V T F L1 L2 L3 状態変数出力 OdbEditor ツール HAYST 法ツール本体状態遷移図 DHC_G 順序テストアーキテクチャー設計リスク分析結果 No F Risk A MatrixTester ツールテストケース (HAYST 法による直交表 ) No. F1 F2 F3 X-Graph ツール 14

15 HAYST 法のテストプロセス前半の詳細テスト要求分析 (TRA: Test Requirements Analysis) < ノイズ > 要求の変化 / 追加要求技術の変化への対応の要求 < 入力 > 要求の源泉文書 / ビデオ / 対話 < 参照 / ノウハウ > 過去のテストタイプや成果物 / テスト標準スキル / 当該テスト対象の経験リソース ( コスト / 人数 / スケジュール ) < アクティブノイズ > 機密漏洩 < アクティビティ > テスト対象 / テスト目的 / 制約の分解と理解関係を体系化 :is-a, has-a, property リスクの識別 < 使用技法 / ツール > 6W2H < 出力 > テスト要求 6W2H ツリーリスク分析結果テストアーキテクチャ設計 (TAD: Test Architecture Design) < ノイズ > 寝不足 / 割り込み ( 電話他 ) 情報を整理する紙が小さい < 入力 > テスト要求 < アクティブノイズ > 機密漏洩具体的成果物の報告プレッシャー < アクティビティ > 機能を目的機能へ書換える : FV 表作成複雑な目的機能の分析 : ラルフチャートの作成ラルフチャート間の関係性の整理 / 体系化 < 参照 / ノウハウ > 過去のテストタイプや成果物 / テスト標準スキル / 当該テスト対象の経験リソース ( コスト / 人数 / スケジュール ) < 使用技法 / ツール > FV 表ラルフチャートラルフチャート関連図 < 出力 > FV 表ラルフチャート RC 関連図 15

16 演習 6W2H で分析ユーザーストーリーで価値を理解 FV 表で整理ラルフチャートで因子を発見

17 従来のテスト方法で解いてみましょう (10 分間 ) 下記の内線電話番号検索システムに対してこれまでの経験からテストケース ( 自分ならどんなテストをするか?) をあげなさい確認したいこと ( 仕様等 ) があった場合はメモしておくこと内線電話番号検索システム名前 : ふりがな : 所属部門 : 検索 17

18 テスト要求分析 : 6W2H 企画書要求書開発 Why( 要求 ) What( 仕様 ) Whom (C of C) How much ( 価格 ) How( 設計 ) 仕様書 6W2H When( 何時 ) 顧客 Where( 何処 ) 設計書 Who( 誰 ) 18

19 6W2H を書くコツ書く順番仕様 (What) の枝から書き始める残りは自由に上から書く書く言葉書くときにその他や非 A という名前は NG これらは分類を放棄しているから書く言葉は基本的に単語仕様書のノードを書くときには仕様の各文を単語に分解しながら ~ でつなぎ単語がノードになる例 ) 名前 ~ 0 文字以上 ~ 20 文字以下 ~ 漢字 ~ 受け付ける最初は MECE は考えない (2 つ上以上のノードは見ない ) 要素を増やすそれぞれの単語に対して例示間対称類推外側破壊を増やす 19

20 補足 : 例示間対称類推外側破壊について ( 階乗計算を例に ) 例示を行う階乗計算の例示 ( 数値 n を 3, 5, 10, と具体的な値に置き換える ) 3! = = 6 10! = = 3,628,800 ピンポイントの 5 個の視点間 : 間について考える 3.5 は入力できないだろうか?? 対称 : 引っ繰り返してみる 3 を引っ繰り返して -3 や 1/3 が見つかる類推 : 似たものを探してみる 10 から 0 を類推する外側 : 集合の外側を考える数値の外側は? 文字を入力してみる破壊 : 入出力の関係を乱したり負荷をかけるなどの意地悪条件を科す 1000 などの大きな数を入力してみる表示桁あふれの確認そ ( 外側 ) れ ( 例示 ) は ( 破壊 ) あ ( 間 ) た ( 対称 ) る ( 類推 ) と覚える 2012 Fuji Xerox Co., Ltd. All rights reserved. 20

21 6W2H を書くコツ ( 続き ) チェックの仕方全体をチェックする (MECE: 漏れなくダブリなくを意識する ) ぶら下がっているノードに漏れダブリがないこと上下関係に矛盾がないことツリーを下から追って子ノードをまとめて親ノードになっているといえるかツリーを上から辿って子ノードに違和感のあるものはないか離れた場所に同じ概念のノードは無いか ( 同じ名前で違う概念のものはよくあるこれは OK) HAYST 法ではチェックは重視しないチェックよりもノードを出し尽くすことに注力する 6W2H はあくまでもテスト要求を理解するためのツール 21

22 内線電話番号検索システムの 6W2H(10 分間 ) 仕様を読みながら 6W2H でまとめてください分からないところはこれまでの経験で想像して書きましょう 22

23 テストアーキテクチャ設計 : FV 表テストの十分性を確保するためテストベースを整理する表テスト対象物のリストアップテストできなくても良い見落とさない FV 表の作成 ( 目的機能でテストの十分性を確保する ) 目的機能 (F): お客様は何をしたいのか?(Why?) 検証 (V): 何を確認したら機能したといえるのか?(What?) テスト技法 (T): どのテスト技法でどこまで検証するのか?(How?) FV 表は GQM( ビクターバシリ先生提唱 ) に対応する目的機能 (F): Goal 層 ( 概念レベル ): 目的の定義検証 (V): Question 層 ( 運用レベル ): 評価すべき質問テスト技法 (T): Metric 層 ( 定量レベル ): 測定可能なメトリクス 23

24 目的機能で整理する理由仕様書の機能で整理することの問題点正しく動作しているかの確認しか出来ない仕様書には機能の動きしか書いていないコンテキスト ( 使用の文脈 ) の理解が重要仕様書には暗黙の仕様 ( 前バージョンの仕様開発者の常識 ) は書かれない本来は正しい動作をしているかの確認がテストの目的要素還元的な見方しか出来ない分解した小さな機能が全て動けば全体が問題なく動くと思ってしまう組合せの視点が欠ける機能から導き出した目的機能で整理する意義必ずユーザの使用目的や市場条件を考えることになる ( 動的 ) 非機能要件のテストが楽になる目的機能単位に非機能要件のメトリクスを計測する性能信頼性セキュリティ要件は目的ごとに異なる ( カプセル化 ) 24

25 目的機能がなぜ必要か用語定義対応技術対応英語テスト合格 / 不合格を決める行動モデルベースドテスト : モデルを明確にする網羅基準検証仕様通りか? CFD 法 : 機能が動作することエラー処理がされること妥当性確認評価ユーザー要求通りか? 将来にわたって多くのユーザーの期待に応えられるか? USDM: 要求と仕様の対応理由の記述 FV 表 : 目的機能の記述予測する目的機能仕様 ( ドキュメント化 ) 要求 ( 個々のユーザーの要求に対する理由 ) Testing Verification Validation Estimation (not evaluation) 25

26 目的機能ユーザーストーリーユーザーストーリーとはアジャイルなゲーム開発スクラムによる柔軟なプロジェクト管理よりフィーチャーや機能の価値をユーザーに伝え会話を引き出すために Kent Beck によって 2000 年にその概念が作られたユーザーストーリーのテンプレート (Mike Cohn:2004 年 ) < ユーザーの役割 > として < ゴール > を達成したい [ それは < 理由 > のためだ ] ユーザーの役割 : ゴールの達成により恩恵を受けるユーザーの役割ゴール : ユーザーストーリーのゴールであるフィーチャーや機能理由 : ゴールを達成した時にユーザーが得られる利益や利点ユーザーストーリーの評価軸 (INVEST) 独立していること (Independent) 交渉可能であること (Negotiable) 価値があること (Valuable) 見積もり可能であること (Estimatable) 適切なサイズであること (Sized appropriately) テスト可能であること (Testable) ユーザーに直接接点を持つ目的機能はユーザーストーリーで表現できる 26

27 内線電話番号検索システムのユーザーストーリー (10 分間 ) 内線電話番号検索システムのユーザーストーリーを書きましょう 27

28 内線電話番号検索システムの FV 表 (10 分間 ) 内線電話番号検索システムの FV 表を 2 行書きましょう No. Fr( 目的機能ユーザストーリー ) V( 検証どんな評価をするか ) T( テスト技術どの技法を使うか )

29 ラルフチャートとはラルフチャートとは FV 表で抽出された目的機能の一行に対してそれが複雑ですぐにテスト詳細設計に移れない場合に目的機能を図示して因子水準を抽出しさらにテスト技法を発見するチャート <FV 表 > No. 目的機能検証テスト技法 < ラルフチャート > ノイズアクティブノイズ入力目的機能を表す図出力仕様書の項番でテスト対象の網羅性を確保する目的機能とは機能に果たすべき目的を書き加えたもの状態変数 29

30 ラルフチャートのフォーマットラルフチャートのフォーマットと抽出する因子入力 ( 使用者の意思 ) 出力 ( 目的 = 得たい結果 ) 状態変数 ( システムの状態 ) プログラムが動作中に参照または書き換える変数ノイズ ( 市場環境の状態システムの外部であり制御不可能な要因 ) ノイズ ( 入出力の関係を妨げる要因 ) アクティブノイズ ( 人がわざと行う要因たとえば犯罪やいたずら要因 ) ノイズアクティブノイズ入力目的機能を表す図出力状態変数 30

31 ラルフチャートノイズ誤差因子 z {z 1, z 2, z 3 } 入力信号因子 M {M 1, M 2, M 3, } 対象出力 y ( レスポンス ) read write 内部変数の組合せ (= 状態 ) 信号因子 m {m 1, m 2, m 3, } 31

32 ラルフチャートの具体例 : 電気ポットのラルフチャート < ノイズ > 外気温外気圧設置場所 ( 台所車の中傾いている台倒れている ) 停電 ( コードが抜ける瞬間停電 ) < アクティブノイズ > 子供のいたずら ( 傾けて出そうとする蒸気孔にシールを貼る給湯口に指を突っ込む ) ボタンの連打 < 入力 > 内容物 ( 水洗浄剤氷水 + 固形物 ) 水量 ( 空満水 ) 水温 ( ) 蓋の状態 ( 閉開 ) 保温エラーアイドル沸騰 < 出力 > 100 度のお湯カルキ抜きモード (3 分間 ) 沸騰ランプ点灯保温ランプ消灯温度表示独立したテストが必要? 豆カップラーメンコーンスープ read write < 状態 > 状態 ( アイドル保温 ) 目標温度 ( 高温節約ミルク ) エラー状態? 組合せテストパフォーマンス ( 沸くまでの時間 ) 異常系テスト操作性テストシナリオテスト状態遷移テスト ( タイミング含む ) 32

33 内線電話番号検索システムのラルフチャート (10 分間 ) 従業員として A さんと連絡を取ることを達成したいそれは予約済み会議室を譲って欲しいためだ read write 33

34 従来のテスト方法と比較スライド 17 で最初にテストケースを考えましたその時に書いたテストケースとテスト要求分析テストアーキテクチャ設計を行った後にテストしようとしている内容を比較しなさい内線電話番号検索システム名前 : ふりがな : 所属部門 : 検索 34

35 まとめ本講座のまとめ

36 まとめテスト分析とはテスト対象を理解する製品 ( 仕様 ) をしっかり理解するテスト目的 ( 制約含む ) を理解するユーザーをしっかり理解するテストアーキテクチャ設計とはテストを構築する目的機能 ( ユーザーストーリー ) で整理するテストで確認すべき価値が明らかになるテストがきれいに分割できるラルフチャートで複雑な目的機能の因子を発見する結果に影響を与える要因のなかでテストすべきものを見つける 36

37 37

Microsoft PowerPoint - Wmodel( ) - 配布用.pptx

Microsoft PowerPoint - Wmodel( ) - 配布用.pptx SEA SPIN Meeting May 2012 配布用 W モデル 2012/06/08 1 2 はじめに 3 目次 4 メモ 5 W モデルって何ですか? 6 現在の状況 7 現在の状況 8 現在の状況 9 W モデルの定義 10 Andreas Spillner の W モデル Requirements Executing Accept. Tests Specification Executing