685KB - ベリサーブ

第７回システム検証セミナー
「その先の検証へ」
∼ 品質をつくりこむために∼
Problem
Problem Reportの分析による
Reportの分析による
プロダクト／プロジェクト品質の改善
プロダクト／プロジェクト品質の改善
~ 品質改善へのアプローチの原点回帰~
２００７年９月７日
株式会社ベリサーブ
技術推進部佐々木方規
2007/9/25
Copyright (C) 2005-2007 VERISERVE. All Rights Reserved.
1
プレゼンタの自己紹介
株式会社ベリサーブ技術推進部佐々木
１９８５年
株式会社ＣＳＫ入社
エミューレータのテスト業務に従事
１９９３年
株式会社ＣＳＫで、第三者検証の検証サービスの確立
テストマネジメントを従事
２００１年
同年７月株式会社ベリサーブがＣＳＫより分社。転籍
２００４年
技術開発部門に異動
２００５年
ＩＰＡ（ソフトウェアエンジニアリングセンター）
組込領域の開発力強化委員会に参加
参加団体
ＪＳＴＱＢ
テクニカル委員会
ＩＴ検証産業協会（ＩＶＩＡ）
委員長
教育・研修部会主査
組込みソフトウェア開発スキル標準領域スキル・キャリア基準部会委員
ソフトウェアテスト技術振興協会
品質管理学会
著書
2007/9/25
ＪＳＴＱＢ認定テスト技術者教科書
Copyright (C) 2005-2007 VERISERVE. All Rights Reserved.
2
本日のセミナーの概要
正しく作成されたＰｒｏｂｌｅｍＲｅｐｏｒｔには、不具合の現象と不具
合の原因（欠陥）が記述してあります。改善活動の基本に基づき、
ＰｒｏｂｌｅｍＲｅｐｏｒｔを蓄積・分析・管理することで、様々なシーンで
利用することができます。
「プロブレム・レポート（不具合報告書）」を利用した２つの改善活動
プロダクト品質の改善
プロジェクト品質の改善
テスト計画
テスト設計
テスト計画
テスト設計
不具合改善
2007/9/25
テスト実行
エラー改善
テスト実行
不具合分析
欠陥分析
ＰｒｏｂｌｅｍＲｅｐｏｒｔ
ＰｒｏｂｌｅｍＲｅｐｏｒｔ
Copyright (C) 2005-2007 VERISERVE. All Rights Reserved.
3
プロダクト品質とプロジェクト品質
本セミナーでは、プロダクト品質とプロジェクト品質を下記
のように定義して解説しています。
プロダクト品質
テスト対象となる製品・アプリケーションそのものの
（出荷）品質
プロジェクト品質
企画・開発・検証、それぞれの製品開発に伴うプロ
ジェクトの業務品質
テスト
要件定義
テスト
計画
テスト
アイテム設計
テスト
ケース設計
テスト
実行
テスト評価
／報告
成果発表
／反省会
不具合
情報収集
VSMethod（ベリサーブテストプロセス標準）
2007/9/25
Copyright (C) 2005-2007 VERISERVE. All Rights Reserved.
4
本日のセミナーの流れ
１．ＰｒｏｂｌｅｍＲｅｐｏｒｔについて
２．現象と欠陥
３．Ｉｎｓｉｄｅ／ＯｕｔｓｉｄｅＶｉｅｗ
４．ＰｒｏｂｌｅｍＲｅｐｏｒｔの応用
2007/9/25
Copyright (C) 2005-2007 VERISERVE. All Rights Reserved.
5
セクションー１
ＰｒｏｂｌｅｍＲｅｐｏｒｔについて
2007/9/25
Copyright (C) 2005-2007 VERISERVE. All Rights Reserved.
6
正しくProblem （*1） Reportを書いていますか
ＰｒｏｂｌｅｍＲｅｐｏｒｔ作成のポイント
（ルールとして）１つの不具合は、１つのＰｒｏｂｌｅｍＲｅｐｏｒｔにします。
第３者（開発者やテスト管理者）を意識して作成します。特に、不具合のサ
マリー（*2）や再現手順には気を付けて記述します。
ＰｒｏｂｌｅｍＲｅｐｏｒｔ分析のポイント
Ｐｒｏｂｌｅｍ分析によって、不具合発生の条件を調査します。これによって、
開発者のデバッグの手間を大幅に短縮させることができます。
Ｐｒｏｂｌｅｍ分析によって、不具合の重要度（Severity）を明らかにします。こ
の指標によって製品開発の管理者は、重要な問題から順にデバッグ・修正
を指示することが可能になります。重要度は、ユーザーの視点での基準を
決めてから考えて判断します。また、ここで重要度が高いと判断しても、開
発側でもそのとおりに受け取るとは限りません。
(*1)弊社では、
Problemを不具合と呼びます。
を不具合と呼びます。
(*1)弊社では、Problem
(*2)不具合のサマリー（概要）は、他の不具合との違いを判別できるように記述します。
(*2)不具合のサマリー（概要）は、他の不具合との違いを判別できるように記述します。
ベリサーブ教育資料テスト実行カリキュラムより抜粋
2007/9/25
Copyright (C) 2005-2007 VERISERVE. All Rights Reserved.
7
現象の発見（例）
とある、検索エンジンで
半角
Ｇｏ-ｈｏｏ！
（仮想の検索エンジンです。）
カタカナ文字
Ｊａｐｏｎ
（最新検索エンジン）
ベリｻｰブ
Ｇｏ
関連検索:株ベリ■ ■ブ, 検証ベリ■ ■ブ,ベリ■ ■ブ 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が提出されるまで
現象の発見
Ｐｒｏｂｌｅｍ（障害）
の評価
Ｐｒｏｂｌｅｍ（障害）
の判定
ＰｒｏｂｌｅｍＲｅｐｏｒｔ
の作成
発生条件の特定
ＰｒｏｂｌｅｍＲｅｐｏｒｔ
の提出へ
再現の手順化
ベリサーブ教育資料テスト実行カリキュラムより抜粋
2007/9/25
Copyright (C) 2005-2007 VERISERVE. All Rights Reserved.
9
現象の発見
現象の発見とは？
・テストケースやテスト項目に従ってテストを実施（実行）し、正しくな
い振る舞い（動作や表示など）を発見します。
・現象は、テストの最終結果（期待値）だけではなく、操作の途中に
現れる不正な動作や表示についても確認します。
・発見した現象が、過去に発生していないかを、過去のＰｒｏｂｌｅｍ
Ｒｅｐｏｒｔを読み返し、調べます。過去に同じ現象が発生している
場合は、条件が同じであるかを調べ、同じであれば同じ問題が発
生しているということをテストの結果として報告します。条件が異な
る場合、例えば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
発生条件の特定
発生条件の特定とは？
・現象（この段階で「Ｐｒｏｂｌｅｍ（不具合）」と呼びます）が、テスト対
象に依存して（テスト対象自体で）発生しているのか、それともテス
ト対象のプラットホーム（構成物）やその他の環境など、テスト対象
を構成するものに依存して発生しているのかを調査します。
ベリサーブ教育資料テスト実行カリキュラムより抜粋
2007/9/25
Copyright (C) 2005-2007 VERISERVE. All Rights Reserved.
12
再現の手順化
再現の手順化とは？
・現象が発生するまでの流れをできるだけ少ない操作手順にまとめ
ます。手順化のポイントは、下記の通りです。
具体的な名称を使うこと
起動から現象が発生するまでの操作手順は省略しないこと
次のような前提条件もまとめます。
使用したテストウェアの情報
製品をどのようにインストールしておくか（テスト初期値）
データの状態
制約は少なくする
これらに注意してＰｒｏｂｌｅｍＲｅｐｏｒｔに記入します。
ベリサーブ教育資料テスト実行カリキュラムより抜粋
2007/9/25
Copyright (C) 2005-2007 VERISERVE. All Rights Reserved.
13
Ｐｒｏｂｌｅｍ（不具合）の評価
Ｐｒｏｂｌｅｍ（不具合）の評価とは？
・不具合の重要度をテスト担当者基準で記入します。
・不具合の重要度は、不具合がテスト対象や利用者に与える影響の
大きさや、範囲や発生頻度などを元に判断します。例えば影響の
範囲の目安として、他のテスト環境でも発生するか、他の関連製
品との組合せでも発生するかなどを調べます。
・判断基準は事前に決めておきます。
ベリサーブ教育資料テスト実行カリキュラムより抜粋
2007/9/25
Copyright (C) 2005-2007 VERISERVE. All Rights Reserved.
14
ＰｒｏｂｌｅｍＲｅｐｏｒｔ（不具合報告書）の作成
ＰｒｏｂｌｅｍＲｅｐｏｒｔ（不具合報告書）の作成とは？
・これまでの手順で分析した内容を報告書にまとめます。
*障害が発生したスクリーンショット
やイメージデータ（写真）を添付して
おくと、よりベターです。
ベリサーブ教育資料テスト実行カリキュラムより抜粋
2007/9/25
Copyright (C) 2005-2007 VERISERVE. All Rights Reserved.
15
セクションー２
現象と欠陥
2007/9/25
Copyright (C) 2005-2007 VERISERVE. All Rights Reserved.
16
現象と欠陥、エラーおよび仕様と非機能要求の関係
現象は、欠陥によって発生します。欠陥は、エラーによって混入され
ます。
プロダクト品質に影響
プロジェクト品質に影響
現象
欠陥
エラー
incident
problem
defect
fault
error
これがＰｒｏｂｌｅｍです
Ｐｒｏｂｌｅｍには、
・要求に起因する問題
・エラーに起因する問題
Ｐｒｏｂｌｅｍ
の原因です
Ｐｒｏｂｌｅｍを
作り込んだ原因です
プロダクト品質に影響
仕様
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
プロダクト品質を改善するために
ＰｒｏｂｌｅｍＲｅｐｏｒｔは、一般的に
プロダクト品質の改善に利用される
Open
現象の報告（対策依頼）
担当変更
Assigned
①ＰｒｏｂｌｅｍＲｅｐｏｒｔを
改修管理（トラフィック管理）
に利用する。
対応者のアサイン
処理
Reopened
再対応
②仕様に関する問題を
記録にする。
（仕様の改善管理）
対策の完了
確認
Verified
対策確認の完了
Closed
対策の完了
2007/9/25
Copyright (C) 2005-2007 VERISERVE. All Rights Reserved.
19
ＰｒｏｂｌｅｍＲｅｐｏｒｔ（不具合報告書）に記述されている事
テスト担当者が記述する部分
現象
欠陥
開発担当者が記述する部分
2007/9/25
Copyright (C) 2005-2007 VERISERVE. All Rights Reserved.
20
プロジェクト品質を改善するために
エラーの排除によるプロジェクト品質の改善
・工程別エラーの混入
設計工程：設計漏れ
製造工程：実装問題
・原因別エラーの混入
難易度
：スキル問題
：仕様問題
プロジェクト品質に影響
エラー
error
Ｐｒｏｂｌｅｍを
作り込んだ原因です
詳しくは、セクション−３、４で
排除
2007/9/25
Copyright (C) 2005-2007 VERISERVE. All Rights Reserved.
21
セクションー３
Ｉｎｓｉｄｅ／ＯｕｔｓｉｄｅＶｉｅｗ
2007/9/25
Copyright (C) 2005-2007 VERISERVE. All Rights Reserved.
22
ＰｒｏｂｌｅｍＲｅｐｏｒｔのＩｎＳｉｄｅ／ＯｕｔＳｉｄｅＶｉｅｗ
仕様
事象が発生
設計（デザイン）の問題
不具合
として特定
オペミス
不具合の原因分析
不具合の傾向分析
テストケース
の問題
どのテストで
見つかった？
実装の問題
プログラム
（構造）ミス？
タイミング
類似の
不具合は？
不具合の現象が
特定される
どの
機能で？
デグレード？
不具合の欠陥が
特定される
不具合解析
インプリメントの問題
要求仕様の問題
コーディング
ミス？
どこに
影響する？
仕様ミス？
スキル不足
難易度
発生した機能や影響度、不具合の種類
や発生のタイミングを分析し、テスト対象
不具合の原因分析
の脆弱部分の想定を行う。
不具合が作り込まれた原因の追究によって不具合パターンを抽出し、
ＯＵＴＳＩＤＥのアプローチ
抽出された不具合パターンを利用することで、不具合の作り込
みを防ぐアプローチ
2007/9/25
Copyright (C) 2005-2007 VERISERVE. All Rights Reserved.
ＩＮＳＩＤＥのアプローチ
23
Outside View（外的視点）
ＯｕｔｓｉｄｅＶｉｅｗでは、現象の影響（脆弱）度を分析します
現象の分析
機能に依存
影響する範囲／環境の分析
機能ツリー／アイテムツリーから、影響度の分析
コンディション（条件）に依存
テストマトリクスから、影響度を分析
コンフィグレーション（環境）に依存プラットフォームおよび環境から、影響度を分析
タイミングの分析
影響する品質の分析
不具合の発見（抽出）時期から、テスト対象の品質への
影響度を分析
不具合発生時期
デグレードの分析
同じ不具合の調査
不具合の修正による問題の調査
2007/9/25
プロセスの問題や変化点分析から、テスト対象の品質への
影響度を分析
開発の難易度や確認時間から、開発品質の確認
（但し、不具合対策から分析）
Copyright (C) 2005-2007 VERISERVE. All Rights Reserved.
24
Outside View（外的視点）
機能ツリー／アイテムツリーからの影響度分析
機能に依存
テスト対象
ＦｕｎｃーＸ
ＳｔａｔｕｓＴｒａｎｓ．
ＣＥ−Ａ
ＣＥ−Ｂ
ＣＥ−Ａ１ＣＥ−Ａ２
Ｆ１１
Ｆ１２‘
Ｆｕｎｃ−Ｚ
Ｆ１２
Ｆ１１３
Ｆ２１
Ｆ１１２
Ｆ２１２
Ｆ２２‘
Ｆ１２２
階層構造で影響
Ｆ２２
Ｆ２３
Ｆ１２２
Ｆ２２２
Ｆ１３２
単機能で影響
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（内的視点）
ＩｎｓｉｄｅＶｉｅｗでは、欠陥の混入原因のエラーを分析します
設計工程
仕様に起因する問題
①仕様書にあるが、設計漏れ
②（上位の）仕様書に記述がない
仕様漏れ
仕様の間違い
仕様の記述が曖昧
仕様不備
製造工程
2007/9/25
仕様書が間違っている
インプリメントに起因する問題
コーディングミス
仕様書に記載されているが、コードの記述を誤っている
コーディング漏れ
仕様書に記載されているが、コーディング時に実装を考慮
していない
コーディング想定外
仕様書に記載されていない事による、コードの未実装
（仕様の定義が曖昧で、コードの未実装）
デグレード
他の不具合を修正した為に、新たに発生した不具合
Copyright (C) 2005-2007 VERISERVE. All Rights Reserved.
27
Inside View（内的視点）
設計工程のエラー分析
仕様の設計漏れ
仕様漏れ
見逃し易い仕様
Ｎｏ
働きすぎ
（技術者のストレス）
Ｙｅｓ
（上位の）
仕様書
特徴のある仕様
Ｘ
Ｎｏ
Ｙｅｓ
他と混同し易い
この仕様だけ特殊
仕様書
ＯＫ
2007/9/25
ＯＫ
実装
設計書
読み難い仕様
・統一記述無視
・記述が曖昧
・
：
・
：
：
Ｘ
実装
設計書
仕様のチェックミス
設計ミス
設計
ミス
Ｘ
エラーの内容
が異なる
設計
漏れ
Copyright (C) 2005-2007 VERISERVE. All Rights Reserved.
28
Inside View（内的視点）
製造工程のエラー分析
コーディングミス
実装
仕様書
ＯＫ
各種問題が異なる
Proc A()｛
More = Miss + Trouble
end
｝
仕様書に記述はあるが
実装
Ｘ
コード記述ミス
Proc N()｛
More + Miss + Trouble
end
｝
難易度
働きすぎ
（技術者のストレス）
仕様書に記述はあるが
実装
Ｘ
コード実装漏れ
漏れ
仕様が読み難い
デグレード
・先祖帰りバグ
・コード修正
影響バグ
間違え易い仕様
Ｘ
実装
想定外
？
2007/9/25
仕様書に記述なし
仕様書が曖昧
Copyright (C) 2005-2007 VERISERVE. All Rights Reserved.
29
セクションー４
ＰｒｏｂｌｅｍＲｅｐｏｒｔの応用
2007/9/25
Copyright (C) 2005-2007 VERISERVE. All Rights Reserved.
30
不具合（ＰｒｏｂｌｅｍＲｅｐｏｒｔ）ＤＢの活用フロー
ソフトウェア開発ライン
要件定義
基本設計
詳細設計
不具合モードレビュー
インスペクション
不具合モード分析
トランザクション
デバッグ
プログラム製造単体試験結合試験
総合試験
不具合モード分析
（分析抽出・蓄積）
リリース
VeriSource
レポート
不具合モード
分析
不具合モード分析
（上流設計支援）
不具合
ＤＢ
不具合
報告書
動的検証サービス
要求分析
スクリーニング
抽象度解析
テスト計画アイテム設計ケース設計
テスト実行
評価・報告
成果反省不具合収集
不具合クラス化
ソフトウェア検証ライン
不具合モード
テスト設計
モデル分析
不具合
モードＤＢ
モードＤＢ
不具合クラス
不具合モード分析
（テスト設計適用支援）
2007/9/25
Copyright (C) 2005-2007 VERISERVE. All Rights Reserved.
31
不具合モード分析とは
バグが多いところを狙ってテストするための手法
バグが多いところを狙ってテストするための手法
（狙い）
・テスト項目が膨大になるため、全てを網羅的にテストすることは不可能
・バグの偏在している部分を狙ってテストし、テスト精度を向上する
プロジェクトが異なっても、似たような原因によるバグが多い
経験の豊富なテスト技術者は偏在しているバグを推測してテストしている
・不具合モードを整理しておき、水平展
開してバグを狙いテスト精度を上げる
製品にとってリスクの高い順に
バグを見つけることができるよう
になる
少ない手間で早くたくさん危険
なバグを見つけることができるよ
うになる
2007/9/25
不具合モード分析のフロー（ご紹介）
Copyright (C) 2005-2007 VERISERVE. All Rights Reserved.
32
不具合（ＰｒｏｂｌｅｍＲｅｐｏｒｔ）ＤＢの活用シーン
テストリポジトリとして利用する活用シーン
デバッグ
プログラム製造単体試験
レポート
不具合
ＤＢ
VeriSource
アイテム設計ケース設計
不具合
報告書
不具合
モードＤＢ
テスト実行
テストケース
ＤＢ
テストカバレージ
（デシジョンテーブル）
エクステンド実装
不具合モード抽出
不具合
モードＤＢ
最適テスト設計
最適テスト実行計画
効率の良い
テスト指示
スクリーニング
抽象度解析
不具合クラス化
モデル分析
単体テストパターン：不具合モード
2007/9/25
Copyright (C) 2005-2007 VERISERVE. All Rights Reserved.
33
不具合（ＰｒｏｂｌｅｍＲｅｐｏｒｔ）ＤＢの活用ソリューション
フルライン検証サービス
ＯｕｔｓｉｄｅＶｉｅｗ
ＩｎｓｉｄｅＶｉｅｗ
2007/9/25
Copyright (C) 2005-2007 VERISERVE. All Rights Reserved.
34
Ｑ＆Ａ
2007/9/25
Copyright (C) 2005-2007 VERISERVE. All Rights Reserved.
35

Download Report