第7回システム検証セミナー 「その先の検証へ」 ∼ 品質をつくりこむために∼ Problem Problem Reportの分析による Reportの分析による プロダクト/プロジェクト品質の改善 プロダクト/プロジェクト品質の改善 ~ 品質改善へのアプローチの原点回帰~ 2007年 9月 7日 株式会社ベリサーブ 技術推進部 佐々木 方規 2007/9/25 Copyright (C) 2005-2007 VERISERVE. All Rights Reserved. 1 プレゼンタの自己紹介 株式会社 ベリサーブ 技術推進部 佐々木 1985年 株式会社CSK入社 エミューレータのテスト業務に従事 1993年 株式会社CSKで、第三者検証の検証サービスの確立 テストマネジメントを従事 2001年 同年7月 株式会社ベリサーブがCSKより分社。転籍 2004年 技術開発部門に異動 2005年 IPA(ソフトウェアエンジニアリングセンター) 組込領域の開発力強化委員会に参加 参加団体 JSTQB テクニカル委員会 IT検証産業協会(IVIA) 委員長 教育・研修部会 主査 組込みソフトウェア開発スキル標準領域 スキル・キャリア基準部会委員 ソフトウェアテスト技術振興協会 品質管理学会 著書 2007/9/25 JSTQB認定テスト技術者 教科書 Copyright (C) 2005-2007 VERISERVE. All Rights Reserved. 2 本日のセミナーの概要 正しく作成されたProblem Reportには、不具合の現象と不具 合の原因(欠陥)が記述してあります。改善活動の基本に基づき、 Problem Reportを蓄積・分析・管理することで、様々なシーンで 利用することができます。 「プロブレム・レポート(不具合報告書)」を利用した2つの改善活動 プロダクト品質の改善 プロジェクト品質の改善 テスト計画 テスト設計 テスト計画 テスト設計 不具合改善 2007/9/25 テスト実行 エラー改善 テスト実行 不具合分析 欠陥分析 Problem Report Problem Report Copyright (C) 2005-2007 VERISERVE. All Rights Reserved. 3 プロダクト品質とプロジェクト品質 本セミナーでは、プロダクト品質とプロジェクト品質を下記 のように定義して解説しています。 プロダクト品質 テスト対象となる製品・アプリケーションそのものの (出荷)品質 プロジェクト品質 企画・開発・検証、それぞれの製品開発に伴うプロ ジェクトの業務品質 テスト 要件定義 テスト 計画 テスト アイテム設計 テスト ケース設計 テスト 実行 テスト評価 /報告 成果発表 /反省会 不具合 情報収集 VSMethod(ベリサーブテストプロセス標準) 2007/9/25 Copyright (C) 2005-2007 VERISERVE. All Rights Reserved. 4 本日のセミナーの流れ 1.Problem Reportについて 2.現象と欠陥 3.Inside/Outside View 4.Problem Reportの応用 2007/9/25 Copyright (C) 2005-2007 VERISERVE. All Rights Reserved. 5 セクションー1 Problem Reportについて 2007/9/25 Copyright (C) 2005-2007 VERISERVE. All Rights Reserved. 6 正しくProblem (*1) Reportを書いていますか Problem Report作成のポイント (ルールとして)1つの不具合は、1つのProblem Reportにします。 第3者(開発者やテスト管理者)を意識して作成します。特に、不具合のサ マリー(*2)や再現手順には気を付けて記述します。 Problem Report分析のポイント Problem分析によって、不具合発生の条件を調査します。これによって、 開発者のデバッグの手間を大幅に短縮させることができます。 Problem分析によって、不具合の重要度(Severity)を明らかにします。こ の指標によって製品開発の管理者は、重要な問題から順にデバッグ・修正 を指示することが可能になります。重要度は、ユーザーの視点での基準を 決めてから考えて判断します。また、ここで重要度が高いと判断しても、開 発側でもそのとおりに受け取るとは限りません。 (*1)弊社では、 Problemを不具合と呼びます。 を不具合と呼びます。 (*1)弊社では、Problem (*2)不具合のサマリー(概要)は、他の不具合との違いを判別できるように記述します。 (*2)不具合のサマリー(概要)は、他の不具合との違いを判別できるように記述します。 ベリサーブ教育資料 テスト実行カリキュラムより抜粋 2007/9/25 Copyright (C) 2005-2007 VERISERVE. All Rights Reserved. 7 現象の発見(例) とある、検索エンジンで 半角 Go-hoo! (仮想の検索エンジンです。) カタカナ文字 Japon (最新検索エンジン) ベリサーブ Go 関連検索:株 ベリ■ ■ブ, 検証 ベリ■ ■ブ,ベリ■ ■ブ Wi-Fi 第三者検証のベリサーブ 携帯電話やカーナビ・デジタル家電などの各種デジタル製品やWEBシステムなどの ソフトウェアを第三者立場でシステム検証を行う専門企業です。 www.veriserve.co.jp/ - 8k - キャッシュ - 関連ページ 会社概要 - www.veriserve.co.jp/company/index.html ソリューション - www.veriserve.co.jp/solution/index.html 開発支援検証サービス|... - www.veriserve.co.jp/.../development.html IR情報 - www.veriserve.co.jp/cgi-bin/jp/ir_whats_new.pl www.veriserve.co.jp との他の一致 ≫ IRトップページ|株式会社ベリサーブ 2007/9/25 表示の現象 おや!こんなところにも リンクが無い!ですね。 Copyright (C) 2005-2007 VERISERVE. All Rights Reserved. 8 Problem Reportが提出されるまで 現象の発見 Problem(障害) の評価 Problem(障害) の判定 Problem Report の作成 発生条件の特定 Problem Report の提出へ 再現の手順化 ベリサーブ教育資料 テスト実行カリキュラムより抜粋 2007/9/25 Copyright (C) 2005-2007 VERISERVE. All Rights Reserved. 9 現象の発見 現象の発見とは? ・テストケースやテスト項目に従ってテストを実施(実行)し、正しくな い振る舞い(動作や表示など)を発見します。 ・現象は、テストの最終結果(期待値)だけではなく、操作の途中に 現れる不正な動作や表示についても確認します。 ・発見した現象が、過去に発生していないかを、過去のProblem Reportを読み返し、調べます。過去に同じ現象が発生している 場合は、条件が同じであるかを調べ、同じであれば同じ問題が発 生しているということをテストの結果として報告します。条件が異な る場合、例えばOSやパッチの種類が異なるという、新しい発生条 件を、その不具合報告書に追記します。 ベリサーブ教育資料 テスト実行カリキュラムより抜粋 2007/9/25 Copyright (C) 2005-2007 VERISERVE. All Rights Reserved. 10 障害の判定 障害の判定とは? ・発見した現象が仕様の通りであるのか、操作ミスであるのか、テス トケースに問題がないか、製品やシステム構成によって発生してい るのかを分析し判定します。 ・障害であると判断された場合は、どの部分(テスト対象? 利用す るソフトウェア? ハードウェア?)がどのような条件や範囲・環境 で発生するのかを調査します。 現象を発見しても、直ぐに障害とはいえません。 ベリサーブ教育資料 テスト実行カリキュラムより抜粋 2007/9/25 Copyright (C) 2005-2007 VERISERVE. All Rights Reserved. 11 発生条件の特定 発生条件の特定とは? ・現象(この段階で「Problem(不具合)」と呼びます)が、テスト対 象に依存して(テスト対象自体で)発生しているのか、それともテス ト対象のプラットホーム(構成物)やその他の環境など、テスト対象 を構成するものに依存して発生しているのかを調査します。 ベリサーブ教育資料 テスト実行カリキュラムより抜粋 2007/9/25 Copyright (C) 2005-2007 VERISERVE. All Rights Reserved. 12 再現の手順化 再現の手順化とは? ・現象が発生するまでの流れをできるだけ少ない操作手順にまとめ ます。手順化のポイントは、下記の通りです。 具体的な名称を使うこと 起動から現象が発生するまでの操作手順は省略しないこと 次のような前提条件もまとめます。 使用したテストウェアの情報 製品をどのようにインストールしておくか(テスト初期値) データの状態 制約は少なくする これらに注意してProblem Reportに記入します。 ベリサーブ教育資料 テスト実行カリキュラムより抜粋 2007/9/25 Copyright (C) 2005-2007 VERISERVE. All Rights Reserved. 13 Problem(不具合)の評価 Problem(不具合)の評価とは? ・不具合の重要度をテスト担当者基準で記入します。 ・不具合の重要度は、不具合がテスト対象や利用者に与える影響の 大きさや、範囲や発生頻度などを元に判断します。例えば影響の 範囲の目安として、他のテスト環境でも発生するか、他の関連製 品との組合せでも発生するかなどを調べます。 ・判断基準は事前に決めておきます。 ベリサーブ教育資料 テスト実行カリキュラムより抜粋 2007/9/25 Copyright (C) 2005-2007 VERISERVE. All Rights Reserved. 14 Problem Report(不具合報告書)の作成 Problem Report(不具合報告書)の作成とは? ・これまでの手順で分析した内容を報告書にまとめます。 *障害が発生したスクリーンショット やイメージデータ(写真)を添付して おくと、よりベターです。 ベリサーブ教育資料 テスト実行カリキュラムより抜粋 2007/9/25 Copyright (C) 2005-2007 VERISERVE. All Rights Reserved. 15 セクションー2 現象と欠陥 2007/9/25 Copyright (C) 2005-2007 VERISERVE. All Rights Reserved. 16 現象と欠陥、エラーおよび仕様と非機能要求の関係 現象は、欠陥によって発生します。欠陥は、エラーによって混入され ます。 プロダクト品質に影響 プロジェクト品質に影響 現象 欠陥 エラー incident problem defect fault error これがProblemです Problemには、 ・要求に起因する問題 ・エラーに起因する問題 Problem の原因です Problemを 作り込んだ原因です プロダクト品質に影響 仕様 spec 非機能 要求 に大別されます 仕様の可能性 もあります 2007/9/25 改善項目(要求)に なる可能性があります Copyright (C) 2005-2007 VERISERVE. All Rights Reserved. 17 欠陥を取り除くこと、エラーの混入を防ぐこと プロダクト/プロジェクト品質を改善するためには、 プロダクト品質の改善は ・現象を原因となる欠陥を取り除く ・仕様に記載のない問題を管理する (仕様の管理) プロジェクト品質の改善は ・欠陥の混入要因のエラーを防止する 2007/9/25 Copyright (C) 2005-2007 VERISERVE. All Rights Reserved. 18 プロダクト品質を改善するために Problem Reportは、一般的に プロダクト品質の改善に利用される Open 現象の報告(対策依頼) 担当変更 Assigned ①Problem Reportを 改修管理(トラフィック管理) に利用する。 対応者のアサイン 処理 Reopened 再対応 ②仕様に関する問題を 記録にする。 (仕様の改善管理) 対策の完了 確認 Verified 対策確認の完了 Closed 対策の完了 2007/9/25 Copyright (C) 2005-2007 VERISERVE. All Rights Reserved. 19 Problem Report(不具合報告書)に記述されている事 テスト担当者が記述する部分 現象 欠陥 開発担当者が記述する部分 2007/9/25 Copyright (C) 2005-2007 VERISERVE. All Rights Reserved. 20 プロジェクト品質を改善するために エラーの排除によるプロジェクト品質の改善 ・工程別エラーの混入 設計工程 :設計漏れ 製造工程 :実装問題 ・原因別エラーの混入 難易度 :スキル問題 :仕様問題 プロジェクト品質に影響 エラー error Problemを 作り込んだ原因です 詳しくは、セクション−3、4で 排除 2007/9/25 Copyright (C) 2005-2007 VERISERVE. All Rights Reserved. 21 セクションー3 Inside/Outside View 2007/9/25 Copyright (C) 2005-2007 VERISERVE. All Rights Reserved. 22 Problem ReportのInSide/OutSide View 仕様 事象が発生 設計(デザイン)の問題 不具合 として特定 オペミス 不具合の原因分析 不具合の傾向分析 テストケース の問題 どのテストで 見つかった? 実装の問題 プログラム (構造)ミス? タイミング 類似の 不具合は? 不具合の現象が 特定される どの 機能で? デグレード? 不具合の欠陥が 特定される 不具合解析 インプリメントの問題 要求仕様の問題 コーディング ミス? どこに 影響する? 仕様ミス? スキル不足 難易度 発生した機能や影響度、不具合の種類 や発生のタイミングを分析し、テスト対象 不具合の原因分析 の脆弱部分の想定を行う。 不具合が作り込まれた原因の追究によって不具合パターンを抽出し、 OUTSIDEのアプローチ 抽出された不具合パターンを利用することで、不具合の作り込 みを防ぐアプローチ 2007/9/25 Copyright (C) 2005-2007 VERISERVE. All Rights Reserved. INSIDEのアプローチ 23 Outside View(外的視点) Outside Viewでは、現象の影響(脆弱)度を分析します 現象の分析 機能に依存 影響する範囲/環境の分析 機能ツリー/アイテムツリーから、影響度の分析 コンディション(条件)に依存 テストマトリクスから、影響度を分析 コンフィグレーション(環境)に依存 プラットフォームおよび環境から、影響度を分析 タイミングの分析 影響する品質の分析 不具合の発見(抽出)時期から、テスト対象の品質への 影響度を分析 不具合発生時期 デグレードの分析 同じ不具合の調査 不具合の修正による問題の調査 2007/9/25 プロセスの問題や変化点分析から、テスト対象の品質への 影響度を分析 開発の難易度や確認時間から、開発品質の確認 (但し、不具合対策から分析) Copyright (C) 2005-2007 VERISERVE. All Rights Reserved. 24 Outside View(外的視点) 機能ツリー/アイテムツリーからの影響度分析 機能に依存 テスト対象 FuncーX Status Trans. CE−A CE−B CE−A1 CE−A2 F11 F12‘ Func−Z F12 F113 F21 F112 F212 F22‘ F122 階層構造で影響 F22 F23 F122 F222 F132 単機能で影響 2007/9/25 Copyright (C) 2005-2007 VERISERVE. All Rights Reserved. 25 Outside View(外的視点) テストマトリクスからの影響度分析 不具合発生 コンディション(条件)に依存 2007/9/25 Copyright (C) 2005-2007 VERISERVE. All Rights Reserved. 機能依存型不具合 条件依存型不具合 26 Inside View(内的視点) Inside Viewでは、欠陥の混入原因のエラーを分析します 設計工程 仕様に起因する問題 ①仕様書にあるが、設計漏れ ②(上位の)仕様書に記述がない 仕様漏れ 仕様の間違い 仕様の記述が曖昧 仕様不備 製造工程 2007/9/25 仕様書が間違っている インプリメントに起因する問題 コーディングミス 仕様書に記載されているが、コードの記述を誤っている コーディング漏れ 仕様書に記載されているが、コーディング時に実装を考慮 していない コーディング想定外 仕様書に記載されていない事による、コードの未実装 (仕様の定義が曖昧で、コードの未実装) デグレード 他の不具合を修正した為に、新たに発生した不具合 Copyright (C) 2005-2007 VERISERVE. All Rights Reserved. 27 Inside View(内的視点) 設計工程のエラー分析 仕様の設計漏れ 仕様漏れ 見逃し易い仕様 No 働きすぎ (技術者のストレス) Yes (上位の) 仕様書 特徴のある仕様 X No Yes 他と混同し易い この仕様だけ特殊 仕様書 OK 2007/9/25 OK 実装 設計書 読み難い仕様 ・統一記述無視 ・記述が曖昧 ・ : ・ : : X 実装 設計書 仕様のチェックミス 設計ミス 設計 ミス X エラーの内容 が異なる 設計 漏れ Copyright (C) 2005-2007 VERISERVE. All Rights Reserved. 28 Inside View(内的視点) 製造工程のエラー分析 コーディングミス 実装 仕様書 OK 各種問題が異なる Proc A(){ More = Miss + Trouble end } 仕様書に記述はあるが 実装 X コード記述ミス Proc N(){ More + Miss + Trouble end } 難易度 働きすぎ (技術者のストレス) 仕様書に記述はあるが 実装 X コード実装漏れ 漏れ 仕様が読み難い デグレード ・先祖帰りバグ ・コード修正 影響バグ 間違え易い仕様 X 実装 想定外 ? 2007/9/25 仕様書に記述なし 仕様書が曖昧 Copyright (C) 2005-2007 VERISERVE. All Rights Reserved. 29 セクションー4 Problem Reportの応用 2007/9/25 Copyright (C) 2005-2007 VERISERVE. All Rights Reserved. 30 不具合(Problem Report)DBの活用フロー ソフトウェア開発ライン 要件定義 基本設計 詳細設計 不具合モードレビュー インスペクション 不具合モード分析 トランザクション デバッグ プログラム製造 単体試験 結合試験 総合試験 不具合モード分析 (分析抽出・蓄積) リリース VeriSource レポート 不具合モード 分析 不具合モード分析 (上流設計支援) 不具合 DB 不具合 報告書 動的検証サービス 要求分析 スクリーニング 抽象度解析 テスト計画 アイテム設計 ケース設計 テスト実行 評価・報告 成果反省 不具合収集 不具合クラス化 ソフトウェア検証ライン 不具合モード テスト設計 モデル分析 不具合 モードDB モードDB 不具合クラス 不具合モード分析 (テスト設計適用支援) 2007/9/25 Copyright (C) 2005-2007 VERISERVE. All Rights Reserved. 31 不具合モード分析とは バグが多いところを狙ってテストするための手法 バグが多いところを狙ってテストするための手法 (狙い) ・テスト項目が膨大になるため、全てを網羅的にテストすることは不可能 ・バグの偏在している部分を狙ってテストし、テスト精度を向上する プロジェクトが異なっても、似たような原因によるバグが多い 経験の豊富なテスト技術者は偏在しているバグを推測してテストしている ・不具合モードを整理しておき、水平展 開してバグを狙いテスト精度を上げる 製品にとってリスクの高い順に バグを見つけることができるよう になる 少ない手間で早くたくさん危険 なバグを見つけることができるよ うになる 2007/9/25 不具合モード分析のフロー(ご紹介) Copyright (C) 2005-2007 VERISERVE. All Rights Reserved. 32 不具合(Problem Report)DBの活用シーン テストリポジトリとして利用する活用シーン デバッグ プログラム製造 単体試験 レポート 不具合 DB VeriSource アイテム設計 ケース設計 不具合 報告書 不具合 モードDB テスト実行 テストケース DB テストカバレージ (デシジョンテーブル) エクステンド実装 不具合モード抽出 不具合 モードDB 最適テスト設計 最適テスト実行計画 効率の良い テスト指示 スクリーニング 抽象度解析 不具合クラス化 モデル分析 単体テストパターン:不具合モード 2007/9/25 Copyright (C) 2005-2007 VERISERVE. All Rights Reserved. 33 不具合(Problem Report)DBの活用ソリューション フルライン検証サービス Outside View Inside View 2007/9/25 Copyright (C) 2005-2007 VERISERVE. All Rights Reserved. 34 Q & A 2007/9/25 Copyright (C) 2005-2007 VERISERVE. All Rights Reserved. 35
© Copyright 2024 ExpyDoc