SlideShare a Scribd company logo
1 of 49
Download to read offline
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
HPQualityCenter/ALMの
コンセプト
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.2
HP Application Lifecycle Management / Quality Center
主な機能と特徴
• オールインワンのWebベースのテスト/開発ライフサイクル管理ツール
• リリース管理、要件管理、テストケース管理、テスト実行管理、不具合管理
• ユーザ管理、構成管理(バージョン管理、履歴管理、ベースライン管理)
テスト結果を同一データベースで管理
不具合管理
不具合の詳細
不具合ステータス
テスト実行管理
実行計画、
実行結果
テストケース管理
確認手順と
確認内容
要件管理
機能要件、非機能要件、
テスト要件など
リリース管理
製品リリース毎の
日程と進捗管理
バージョン管理バージョン管理
ダッシュボードによる品質の可視化
情 報 分 析
HPインシデント
管理製品
HPプロジェクト
管理製品
@プロジェクト管理部門 @サービスデスク
HP自動機能
テスト製品
ユーザ管理
100以上の3rd Party製
テスト関連製品
連携
@開発部門 @テストセンター
連携連携連携
Open Test Architecture API
インターネット越しのアクセス
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.3
2つのエディション
HP Application Lifecycle Management
アプリケーションライフサイクルにわたって
クロスプロジェクト、クロスイニシアチブのエ
ンタープライズリリースを管理
• プロジェクト計画&追跡
• クロスプロジェクトレポート
• 資産の共有と再利用
• プロセス標準化(プロジェクトテンプレート)
• 不具合の共有(SyncServer)
• 無制限の高可用性サーバ
• QualityCenterエンタープライズの全機能
– 要件管理
– テスト計画、スケジュール設定、実行
– リリースとサイクルの管理
– 不具合管理
– 進捗と状況のリアルタイムレポート作成
– 開発環境との統合
HP Quality Centerエンタープライズ
一貫した再生可能なテストプロセスを可能に
する単一の拡張性をもったプラットフォーム
• 要件管理
• テスト計画、スケジュール設定、実行
• リリースとサイクルの管理
• 不具合管理
• 進捗と状況のリアルタイムレポート作成
• 開発環境との統合
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.4
HP ALM /QCの変遷
2014
HP ALM/HP QC
12.0 IE以外の対応 / UI刷新
2013
11.5 ラボマネジメント…DevOps
2012
11.0
マネジメントモジュール(KPI),テスト設定
ALM(SCM,IDE,CIツールなどとの連携)対応
2011
2010
QualityCenter
10.0
バージョン管理,ベースライン
エクセルレポート2009
2008
9.0
リスクベースドテスティング
リリースモジュール(日程管理)
エクセルレポート
欠陥間トレーサビリティ
2007
2006
2005
8.0
Javaサーバー
ビジネスプロセステスティング
要件間トレーサビリティ
2004
2003
TestDirectoer
7.0i
Webアプリに刷新
要件管理(要件モジュール)
トレーサビリティ(要件,テスト,欠陥)
Eメール
2002
2001
2000
1999 6.01
Windowsアプリ
自動テストツールとの連携
テスト管理
欠陥管理
1998
4.01997
1996
1.521995
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.5
HP ALM の典型的な設定例
クライアントコンポーネント
初回起動時にサーバから自動ダ
ウンロード
毎回起動時にコンポーネントの読
み込みが走る
.NET およびCOM を使用
HTTP/S を介してサーバと通信
サーバアプリケーション
Jetty(J2EEのアプリケーション
サーバ兼Webサーバ)
RDBとはJDBCで接続
サイト管理スキーマ
ALM システムに関連する
情報( ドメイン,ユーザ,
サイトのパラメータなど)を
格納
システムに対サイト管理
スキーマはひとつだけ
プロジェクトスキーマ
プロジェクト情報( エンティティ・データや
ユーザ・データなど) を格納
作成するすべてのプロジェクトに,別個
のスキーマが存在
プロジェクトリポジトリ
プロジェクトで使用するファイ
ルを格納( .xml ファイル,テン
プレート。添付ファイル)
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.6
HP ALM/ Quality Centerでのテストマネジメントのイメージ
テスト分析
テスト設計・実装 テスト実装
テスト実行&進捗管理
不具合管理
テスト計画(日程)
②要件モジュール
③テスト計画モジュール
⑤テストラボモジュール
⑥不具合管理モジュール
アナリシスモジュール
①リリースモジュール
④テストラボモジュール
トレーサビリティ 構成管理
テストに関する情報の一元管理
1.障害の報告
2.改修依頼
テスト実行日程作成
実行結果記録
ログ、エビデンス保存
テストケース作成
テスト手順作成
グラフ化 報告書作成
全体日程作成
テスト対象理解
テスト要件特定
テンプレートやワークフローで一連のテスト業務の実行を補助
検索やグラフ生成、シミュレーション
で状況判断の情報を提供
他ツール連携
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.7
HP ALM/QCのデモ
基本的な機能と使い方
「はじめてのQC」参照
• http://h30499.www3.hp.com/hpeb/attachments/hpeb/quality-center/21/1/hajimete-
qc01.pdf
HPのIT部門での活用事例 ※投影のみになります
「ALM in HP IT」
三菱電機事例 「システムテストでは管理工数削減が生産性向上のポイント」
• http://www.jasst.jp/symposium/jasst13tokyo/pdf/A4-2.pdf
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
HPQualityCenter/ALMの
コンセプト 概要
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.9
QC/ALMのテスト管理のコンセプト
大きく5つのポイント
• 要件の整理
– 要件の可視化とテスト要件の分析の考え方
• テストの単位、結果の集計の単位
– テストの構造化の考え方
• 進捗など実績の定量的モニタリング
– 実績の収集の考え方
• トレーサビリティ
– 不具合とのトレース
– 要件、テストのトレース
– 実績収集のためのトレース
• リスクベース品質マネジメント
– 優先度をつけるための考え方
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.10
QC/ALMのテスト管理のコンセプト
その他のポイント(今回は触れません)
自動テストツールのスクリプト管理
• バージョン管理
• リソース管理(データ、ユーザ定義関数、環境変数)
• スケジューラ/結果収集
構成管理
• バージョン管理
• ベースライン管理
グラフ・帳票作成機能
• アナリシス/ライブアナリシス/ダッシュボード
– ドリルダウン
• KPI
• Excelレポート(マクロ一元管理)
• Word/PDFへレポート出力(ドキュメントジェネレータ/標準レポート/プロジェクトレポート)
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
要件の整理
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.12
なぜ、要件の階層化をするのか?
要件階層化
アプリケーションはビジネスの活動/プロセスや機能をサポートする。
構造は例外なく一貫しており、命名ルールは意味をもっている。
• 整理することで可視化でき、テスト要件の識別が容易になる
Example 1
Example 2
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.13
要件階層化の機能 QualityCenter
要件タイプ
• 要件の種類毎に一貫したルールを提供する
• 入力フィールドの表示、非表示
• テキストエリアのテンプレート
• 要件カバレッジ対象(あり:テストとの関連をつけることが出来る、なし:カバレッジありの要
件を集計する)
• リスクベース品質管理(評価対象、分析対象、なし)
ツリー構造での登録・表示
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.14
要件を整理して、テストすべきこと(テスト要件)を明確化
問題解決または目的達成の為にユーザが
必要とする条件や能力
システムやコンポーネントが満たす、
または保持しなければならない条件や能力
Application 1
Main Activity 1.1
Activity 1.1.1
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement
Activity 1.1.2
Main Activity 1.2
Activity 1.2.1
Requirement
• 業務要件
• -ユーザ要件
• ---機能要件
• ---非機能要件
• …
これらは階層化され、
関連性をもって管理される
要件ツリーの末端は、その要件に対する
プルーフポイント=「テスト要件」
テスト要件
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.15
要件とテストの関係
Application 1
Main Activity 1.1
Activity 1.1.1
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement
Activity 1.1.2
Main Activity 1.2
Activity 1.2.1
Requirement
要件が「満足」している事を確認する手段/手順が、テストケース
テスト#001
テスト#002
満足・確認
満足・確認
満足・確認
正しいユーザ名とパスワードを
入力した際、正常に
ログオン可能な事
入力条件:Username: foo
Password: bar
操作:ログインボタンを押下
結果:「ようこそ画面-画面
ID#03」が表示される事
テストケース条件 値 操作 結果
テストケース1
テストケース2
テストケース3
テストケース条件 値 操作 結果
テストケース1
テストケース2
テストケース3
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.16
要件とテストの関係 QualityCenter
テストカバレッジ
• 要件に紐付いたテストがどれだけ実行され、合格しているかをトレース
• リリース毎にフィルタリングした集計・全体的な集計を選択可能
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
テストの構造、単位、結果の集計
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.18
なぜ「テストの構造」を設計するのか?
全体像を共有できる(自分の立ち位置がわかる)
早期から段階的にテストを開発(分析、設計、実装)できる
早期から逐次テストを実行したときの無理、ムラが最小限に抑えられる
複数の技術者/チームでの作業分担が容易になる
全体像を共有するために必要なこと
構造に合わせてテストケースを保存する
→フォーマット統一
• 作業中は思考をさえぎらない方法で進めてよいが、最終的には同じ構造で保存する
テストに対する要求とテストスイートを分離する
「テストの構造」はテストそのものの品質を良くする
テストケースの再利用性を高める(無駄な再利用をしない)
テストケースの十分性を高める(テスト要件を満たした度合いを把握する)
テストケースの可読性を高める(テスト設計のレビュー効率をあげる)
テストケースの効率性を高める(テストの自動化すべきところを識別する)
テストケースの機能性を高める(バグが出そうなところをテストできるようにする)
脱スプレッドシート!
作業したら(ワークシートを使ったら)
所定の場所(マネジメントシステム)にし
まう
早期からのテスト開発、リリースにあわせ逐次テスト実行を可能にする!
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.19
テストへの要件とテストスイートを分離
テストの構造を維持して作業するためのベースとなる
• 全体像の理解が容易になる(要件をまずは理解/設計が妥当かを確認)
• 双方の構造が崩れないため保守性/再利用性が高まる
• テスト分析とテスト設計の作業の切り分けが明確になる
– テスト分析とテスト設計の作業分担が明確になる
要件 テストスイート
テスト#001
テスト#002
満足・確認
満足・確認
満足・確認
テスト分析
※ドメイン知識
テスト要件
テスト設計
※テスト設計スキル
Application 1
Main Activity 1.1
Activity 1.1.1
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement
Activity 1.1.2
Main Activity 1.2
Activity 1.2.1
Requirement
テストケース条件 値 操作 結果
テストケース1
テストケース2
テストケース3
テストケース条件 値 操作 結果
テストケース1
テストケース2
テストケース3
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.20
テスト資産の管理と日々の作業の管理を分離
日々の作業の変化で構造が崩れず、保守性/再利用性が高まる
• 段階的にリリースする際にテストを計画的に複数回実行する
• 開発の進捗によってテスト実行順序を見直しする
• 不具合によってブロックになったテストケース後回し or 再実行する
要件 テストスイート
テスト#001
テスト#002
満足・確認
満足・確認
満足・確認
テスト要件
Application 1
Main Activity 1.1
Activity 1.1.1
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement
Activity 1.1.2
Main Activity 1.2
Activity 1.2.1
Requirement
テストケース条件 値 操作 結果
テストケース1
テストケース2
テストケース3
テストケース条件 値 操作 結果
テストケース1
テストケース2
テストケース3
作業日程大計画 テスト実行の割り当て/結果集計
3月21日 Aさん:テスト#001~テスト#020
Bさん:テスト#021~テスト#063
Cさん:テスト#064~テスト#075
・・・
・・・
19/20合格
33/42合格
11/11合格
集計要件1
要件2
要件3
割り当てる 割り当てる
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.21
テスト(テスト項目)の考え方
• 今までとテスト(テスト項目)の管理の仕方が変わります。
• テスト:今までのテスト項目のうち、テスト設計で最初に作る部分が該当します。
• テストインスタンス:テスト項目の中の「テスト実行時に必要となる具体的な内容」を別記したも
のです。これにより、テスト項目の汎用的な部分と、毎回変わる部分を分けて管理できるため、
テスト項目の再利用が容易になります。
• テスト実行:テストの実施結果(合格/不合格)の結果を残すためのものです。複数回テスト実
行した際の履歴を全て確認できます。
テスト(テスト項目) テスト実行
1 対 N
テスト設計で作ったテスト項目 テスト実施結果の登録
1 対 N
テスト項目
今までのテスト項目
HP ALM/Sprinterのテスト項目
ID 確認概要 実施予定日 実施結果手順 期待結果
実施結果
実施予定担当
ID 確認概要
手順 期待結果
いままではひとつの
行に全ての内容を
記載したテスト項目
を作っていました。
今後は、テスト項目作成、
日程/担当に割り当て、実
施でそれぞれに分けて記
載するようになります。
テストインスタンス
テスト日程に割り当てたテスト項目
実施予定日
実施予定担当
テストセット
テストインスタンスを実行単位に束ねる箱
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.22
テストの全体構造 QualityCenter
テスト要件
要件一覧
※資産管理対象
旅行予約サービス
顧客情報管理
セキュリティ
ユーザビリティ
旅行予約
クルージング予約
必須入力
予約登録
予約エラー
ビジネス要件 システム要件
要件(資産)
リリース(進捗管理)
テスト1 テストケース条
件
値 操
作
結
果
テストケース1
テストケース2
テストケース3
テスト2 テストケース条
件
値 操
作
結
果
テストケース1
テストケース2
テストケース3
テストケース4
テスト(資産)
テスト一覧
※資産管理対象
サイクル 第一週 第二週 第三週 第四週
動作確認
旅行予約サービス
その他新機能
非機能要件
シナリオテスト
回帰テスト
リリース1.2
テスト3 テストケース条
件
値 操
作
結
果
テストケース1
リリース1.2
第一週
実行計画
※リリース毎
第二週
テストラボ(実績収集)
動作確認
山田
田中
テスト1
インスタンス
テスト1
インスタンス旅行予約
山田
テスト2
インスタンス
テスト3
インスタンス
日程計画
※リリース毎
集計
どのサイクルでどの要件がテストされるか決める
テストインスタンス
を割り当てる
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.23
テスト資産の構造 QualityCenter
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.24
テスト資産の構造(QC 要件モジュール)
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.25
テスト資産の構造(QC テスト計画モジュール)
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.26
テスト資産の構造(QC ビジネスコンポーネントモジュール)
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.27
テスト資産の構造(QC テストラボモジュール)
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.28
テストセット
テストセット
要件
テスト要件
テスト
テストインス
タンス
テストインス
タンス テストラン
テストラン
ステップ1
ステップ2
ステップ3
テスト
テスト要件 テスト
テストインス
タンス
最新の結果を反映
ここで書き換え可能最新の結果を反映
ここで書き換え可能
テストカバレッジの集計
ここで書き換え可能
ステップの結果を集計
ここは書き換え不可能
テスト要件の集計
ここで書き変え可能
テスト結果の反映のされ方 QC
要件カバレッジ サイクル集計
「テスト」実行ス
テータス
「テストインスタ
ンス」ステータス
「実行」
ステータス
「要件」直接
カバレッジステータス
QC標準機能
QCグラフ機能
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.29
QCのテスト関連部分の構造とあるべきテスト構造の例
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
進捗など実績の定量管理
30
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.31
リリーススコープ
アイテム
リリース
●●システムVer1.5
・性能改善
・●●バグの修正
・●●機能の追加
マイルストーン
システムテスト開始
要件 テスト テストセット 不具合
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---
スコープ
サイクル1:変更箇所
サイクル2:回帰テスト
<スケジュール>
KPI(全スコープアイテムの)
・要求のレビュー合格数が95%以下だとNG
・テストケースの準備数 99%以下だとNG
テスト対象要件毎の
テスト数、不具合数の集計
テスト対象要件毎の
テスト数、不具合数の集計
Β版
KPI(全スコープアイテムの)
・テスト合格数 80%以下NG
GA版
KPI(全スコープアイテムの)
・1日当たりの修正不具合数 5件以下だとNG
・テスト実行数 50以下だとNG
リリース、サイクル、マイルストーン QC
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.32
進捗確認 Quality Center
リリース
KPI
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
トレーサビリティ
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.34
トレーサビリティ(QC 不具合)
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.35
トレーサビリティ(QC 要件間、要件とテスト)
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.36
変更点を通知 QualityCenter
警告ルールを設定することで変更点を通知する
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.37
トレーサビリティ(QC リリース・サイクル)
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
リスクベース品質管理
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.39
品質リスク分析は何に使うのか?
テストの位置づけを変える
いままで:「時間の限り全部を網羅して品質が確保されていることを確認する」
いまどき:「価値達成の度合いを判断する情報ソースの収集手段とする」
品質リスクを分析し、テストの網羅度合いをチューニングする
• 品質リスク (またはプロダクトリスク) とは
– 潜在的な問題の主な影響がリリースした後の製品の品質に及ぶ場合を指す
• リリース後の致命的バグで全品回収かもしれない
– 「価値達成しない可能性=品質リスクあり」と考えて優先度/網羅度合いを決める
リスク 影響 欠陥 テスト方法
在庫量の計算ミスの可能
性
大 中 二機能間網羅
帳票の印刷遅延の可能性 小 小 仕様書記載項目のみ網羅
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.40
リスクベース品質管理-1 QualityCenter
1. 「ビジネス上の危険性」(business criticality)
• 要件単位に設定、危険性の重みづけを実施
• デフォルトでは因子は4つ(後述)
• 重みづけリスクマトリクスでTW(トータルオブウェイト)を決定
2. 「失敗の確率」(failure probability)
• 要件単位に設定、確立の重みづけを実施
• デフォルトでは因子は4つ(後述)
• 重みづけリスクマトリクスでTW(トータルオブウェイト)を決定
3. 「機能の複雑さ」を設定(テスト工数を見積)
• 要件単位に設定(工数を計測のための因子)
• デフォルトでは因子は4つ(後述)
• 工数評価マトリクスを決定
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.41
リスクベース品質管理-2 QualityCenter
4. 「リスク評価」を分析
• リスク評価により、優先度を3つに分類
• 「機能の複雑さ」による工数評価結果と、工数期間までの期間から超過している時間を分析
• 超過している時間がある場合、優先度別で要件のテストをどの程度にするか(テスト程度)、人
員を増やすか、リリースをずらすかといった「リスク回避策、リスク対応策」の方針を検討
5. プロジェクト中のリスク分析アップデート
• 「リスクは生もの」という観点から、リスク分析は一度ではなく設計、開発、テストを通してアップ
デートし続ける
• 「リスク回避策、リスク対応策」の方針もアップデートし続ける
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.42
Application 1
Main Activity 1.1
Activity 1.1.1
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement
Activity 1.1.2
Main Activity 1.2
Activity 1.2.1
Requirement
A
High Risk
B
Medium Risk
C
Low Risk
Type of Process
Calculation /
validation
change of data display
Business Impact legal
wrong
information
none
Frequence of
use
very often often rare
Number of
Customer
affected
large number /
very important
group some
Result
Criteria
1.ビジネス上の危険性(business criticality)
要件に対する関係図
ビジネス上の危険性TW
分類階層化により
管理された要件
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.43
Application 1
Main Activity 1.1
Activity 1.1.1
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement
Activity 1.1.2
Main Activity 1.2
Activity 1.2.1
Requirement
A
High Risk
B
Medium Risk
C
Low Risk
Type of Process
Calculation /
validation
change of data display
Business Impact legal
wrong
information
none
Frequence of
use
very often often rare
Number of
Customer
affected
large number /
very important
group some
Result
Criteria
2.失敗の確率(failure probability)
要件に対する関係図
ビジネス上の危険性TW
Medium
UNIX
or
Windows
Changed
Func.
II
Possible
High
Unix, Windows,
Host
combination
New
Func
I
Likely
LowDefects Rate
HOSTPlattform OS
UnchangedChange Rate
III
Unlikely
Result
Criteria
Medium
UNIX
or
Windows
Changed
Func.
II
Possible
High
Unix, Windows,
Host
combination
New
Func
I
Likely
LowDefects Rate
HOSTPlattform OS
UnchangedChange Rate
III
Unlikely
Result
Criteria
失敗の確率TW
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.44
3.機能的な複雑さでテスト工数を決定
Application 1
Main Activity 1.1
Activity 1.1.1
Requirement
Requirement
Requirement
Requirement
Requirement
Requirement
Activity 1.1.2
Main Activity 1.2
Activity 1.2.1
Requirement
• テクニカルアーキテクトと一緒に機能的な複
雑さを分析する。
• リスクと複雑さを組み合わせてテスト工数を決
定する。
1
High complex
2
Medium complex
3
Low complex
Number of
Objects affected
> 9 4 - 9 < 4
Number of
Objects with
write access
> 3 1 - 3 < 1
Number of
objects with read
access
> 5 3 - 5 < 3
Number of
Windows
affected
> 4 2 - 4 < 2
Complexity
Criteria
機能的な複雑さを分析する
1
High complex
2
Medium complex
3
Low complex
A
Critical
12,5 10,2 8,3
B
Important
6,9 6,3 5,6
C
Nice to have
4,2 3,5 2,8
Complexity
Impact
Effort per Business Function [PD]
テスト工数を決定する
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.45
A
High Risk
B
Medium Risk
C
Low Risk
Type of Process
Calculation /
validation
change of data display
Business Impact legal
wrong
information
none
Frequence of
use
very often often rare
Number of
Customer
affected
large number /
very important
group some
Result
Criteria
4 .「リスク評価」を分析
リスク評価の算出
ビジネス上の危険性TW
Medium
UNIX
or
Windows
Changed
Func.
II
Possible
High
Unix, Windows,
Host
combination
New
Func
I
Likely
LowDefects Rate
HOSTPlattform OS
UnchangedChange Rate
III
Unlikely
Result
Criteria
Medium
UNIX
or
Windows
Changed
Func.
II
Possible
High
Unix, Windows,
Host
combination
New
Func
I
Likely
LowDefects Rate
HOSTPlattform OS
UnchangedChange Rate
III
Unlikely
Result
Criteria
失敗の確率TW
失敗の確率
危険性
高 中 低
致命的 高い(フル) 高い(フル) 普通(66%)
重要 高い(フル) 普通(66%) 低い(33%)
リスクをとる 普通(66%) 低い(33%) 低い(33%)
– 3段階の品質リスクへカテゴライズ
• 「ビジネス上の危険性」と「失敗の確率」
3段階のテストレベルへカテゴライズ
• 高い 本来やるべきテストをフルで実施
• 普通 テストは2/3の労力で実施(66%)
• 低い テストは1/3の労力で実施(33%)
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.46
リスク評価の算出
4 .「リスク評価」を分析
– 3段階のテストレベルに設定した作業時間、合計テスト作業時間を分析しス
ケジュール上割り当てられた時間と比較、超過してるかどうかを可視化
(プロダクトリスクからプロジェクトリスクへの影響を可視化)
作業時間を予定時間
と比較分析(%表示)
分析に利用する
作業時間設定
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.47
対策を実施
4 .「リスク評価」を分析
– 対策方針の例
• サイクルへのテストケース割り当ては優先度の高いものを先に割り当てる
• 回帰テストの数を増やす(自動化対象)
• 既存のテストだけでなく新しいテストを追加する
• テストパラメータのパターンの数を増やす
優
先
度
高
の
配
置
優
先
度
低
の
配
置
システムA
リリース 1.0
外部接続テスト
全機能テスト
リリース 1.5
新機能テスト
回帰テスト
サイクル例
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.48
リスクは変化するもの
5 .プロジェクト中のリスク分析アップデート
– リスク回避の方針
• 影響ある因子をアップデートし、対応策を選定
リスクベースドテスト因子 テスト設計・分析 開発 テスト
イ
ン
パ
ク
ト
プロセス ◎
インパクト ◎
利用頻度 ◎
ユーザ数 ◎
発
生
確
率
変更タイプ ◎
成熟度 ◎
欠陥率 ◎ ◎ ◎
他への影響数 ◎ ◎ ◎
複
雑
度
論理ステップ数 ◎ ◎ △
関連データ量 ◎ ◎ △
他システムとの依存関係 ◎ ◎ △
プロセス内の計算レベル ◎ ◎ △
© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
Thankyou

More Related Content

Similar to HP_almqc_concepts20150701

Testing processqualifylevel 2009
Testing processqualifylevel 2009Testing processqualifylevel 2009
Testing processqualifylevel 2009Shinsuke Matsuki
 
Qc astah 連携について012
Qc astah 連携について012Qc astah 連携について012
Qc astah 連携について012Kei Nakahara
 
Agile at salesforce
Agile at salesforceAgile at salesforce
Agile at salesforceRyoji Osawa
 
19-B-4 開発品質向上のための、ASQ/ALMソリューション
19-B-4 開発品質向上のための、ASQ/ALMソリューション19-B-4 開発品質向上のための、ASQ/ALMソリューション
19-B-4 開発品質向上のための、ASQ/ALMソリューションDevelopers Summit
 
継続的デリバリー読書会 第 5 章 デプロイメントパイプラインの解剖学
継続的デリバリー読書会 第 5 章 デプロイメントパイプラインの解剖学継続的デリバリー読書会 第 5 章 デプロイメントパイプラインの解剖学
継続的デリバリー読書会 第 5 章 デプロイメントパイプラインの解剖学Takuma SHIRAISHI
 
テストを分類してみよう!
テストを分類してみよう!テストを分類してみよう!
テストを分類してみよう!Kenji Okumura
 
アジャイル×テスト開発を考える
アジャイル×テスト開発を考えるアジャイル×テスト開発を考える
アジャイル×テスト開発を考えるyasuohosotani
 
札幌Javaカンファレンス2012 C3「顧客とPMとPGの話は、なぜ噛み合わないのか」
札幌Javaカンファレンス2012 C3「顧客とPMとPGの話は、なぜ噛み合わないのか」札幌Javaカンファレンス2012 C3「顧客とPMとPGの話は、なぜ噛み合わないのか」
札幌Javaカンファレンス2012 C3「顧客とPMとPGの話は、なぜ噛み合わないのか」Yusuke Suzuki
 
なぜソフトウェアアーキテクトが必要なのか - デブサミ2011
なぜソフトウェアアーキテクトが必要なのか - デブサミ2011なぜソフトウェアアーキテクトが必要なのか - デブサミ2011
なぜソフトウェアアーキテクトが必要なのか - デブサミ2011Yusuke Suzuki
 
Netadvantage 2012 volume2 最新情報 Reporting 編
Netadvantage 2012 volume2 最新情報 Reporting 編Netadvantage 2012 volume2 最新情報 Reporting 編
Netadvantage 2012 volume2 最新情報 Reporting 編Daizen Ikehara
 
Continuous delivery-9
Continuous delivery-9Continuous delivery-9
Continuous delivery-9LagerKorone
 
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423Yusuke Suzuki
 
品質検査としてのWebパフォーマンス計測手法
品質検査としてのWebパフォーマンス計測手法品質検査としてのWebパフォーマンス計測手法
品質検査としてのWebパフォーマンス計測手法Yoichiro Takehora
 
その Web サイト、その Web アプリを最新の IE11 に対応しよう
その Web サイト、その Web アプリを最新の IE11 に対応しようその Web サイト、その Web アプリを最新の IE11 に対応しよう
その Web サイト、その Web アプリを最新の IE11 に対応しようOsamu Monoe
 
Istqb : Test automation Engineer
Istqb : Test automation EngineerIstqb : Test automation Engineer
Istqb : Test automation EngineerSadaaki Emura
 
【de:code 2020】 アマダの Azure への取り組みと DevOPS・MLOPS 環境の構築と運用
【de:code 2020】 アマダの Azure への取り組みと DevOPS・MLOPS 環境の構築と運用【de:code 2020】 アマダの Azure への取り組みと DevOPS・MLOPS 環境の構築と運用
【de:code 2020】 アマダの Azure への取り組みと DevOPS・MLOPS 環境の構築と運用日本マイクロソフト株式会社
 

Similar to HP_almqc_concepts20150701 (20)

ITS fidel
ITS fidelITS fidel
ITS fidel
 
Testing processqualifylevel 2009
Testing processqualifylevel 2009Testing processqualifylevel 2009
Testing processqualifylevel 2009
 
Qc astah 連携について012
Qc astah 連携について012Qc astah 連携について012
Qc astah 連携について012
 
Agile at salesforce
Agile at salesforceAgile at salesforce
Agile at salesforce
 
19-B-4 開発品質向上のための、ASQ/ALMソリューション
19-B-4 開発品質向上のための、ASQ/ALMソリューション19-B-4 開発品質向上のための、ASQ/ALMソリューション
19-B-4 開発品質向上のための、ASQ/ALMソリューション
 
Provisioning & Deploy on AWS
Provisioning & Deploy on AWSProvisioning & Deploy on AWS
Provisioning & Deploy on AWS
 
継続的デリバリー読書会 第 5 章 デプロイメントパイプラインの解剖学
継続的デリバリー読書会 第 5 章 デプロイメントパイプラインの解剖学継続的デリバリー読書会 第 5 章 デプロイメントパイプラインの解剖学
継続的デリバリー読書会 第 5 章 デプロイメントパイプラインの解剖学
 
テストを分類してみよう!
テストを分類してみよう!テストを分類してみよう!
テストを分類してみよう!
 
アジャイル×テスト開発を考える
アジャイル×テスト開発を考えるアジャイル×テスト開発を考える
アジャイル×テスト開発を考える
 
札幌Javaカンファレンス2012 C3「顧客とPMとPGの話は、なぜ噛み合わないのか」
札幌Javaカンファレンス2012 C3「顧客とPMとPGの話は、なぜ噛み合わないのか」札幌Javaカンファレンス2012 C3「顧客とPMとPGの話は、なぜ噛み合わないのか」
札幌Javaカンファレンス2012 C3「顧客とPMとPGの話は、なぜ噛み合わないのか」
 
なぜソフトウェアアーキテクトが必要なのか - デブサミ2011
なぜソフトウェアアーキテクトが必要なのか - デブサミ2011なぜソフトウェアアーキテクトが必要なのか - デブサミ2011
なぜソフトウェアアーキテクトが必要なのか - デブサミ2011
 
Netadvantage 2012 volume2 最新情報 Reporting 編
Netadvantage 2012 volume2 最新情報 Reporting 編Netadvantage 2012 volume2 最新情報 Reporting 編
Netadvantage 2012 volume2 最新情報 Reporting 編
 
Continuous delivery-9
Continuous delivery-9Continuous delivery-9
Continuous delivery-9
 
To be sn agile enterprise
To be sn agile enterpriseTo be sn agile enterprise
To be sn agile enterprise
 
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
なぜソフトウェアアーキテクトが必要なのか - Devlove 20110423
 
品質検査としてのWebパフォーマンス計測手法
品質検査としてのWebパフォーマンス計測手法品質検査としてのWebパフォーマンス計測手法
品質検査としてのWebパフォーマンス計測手法
 
その Web サイト、その Web アプリを最新の IE11 に対応しよう
その Web サイト、その Web アプリを最新の IE11 に対応しようその Web サイト、その Web アプリを最新の IE11 に対応しよう
その Web サイト、その Web アプリを最新の IE11 に対応しよう
 
Gamedevenvstudy1
Gamedevenvstudy1Gamedevenvstudy1
Gamedevenvstudy1
 
Istqb : Test automation Engineer
Istqb : Test automation EngineerIstqb : Test automation Engineer
Istqb : Test automation Engineer
 
【de:code 2020】 アマダの Azure への取り組みと DevOPS・MLOPS 環境の構築と運用
【de:code 2020】 アマダの Azure への取り組みと DevOPS・MLOPS 環境の構築と運用【de:code 2020】 アマダの Azure への取り組みと DevOPS・MLOPS 環境の構築と運用
【de:code 2020】 アマダの Azure への取り組みと DevOPS・MLOPS 環境の構築と運用
 

More from Tsuyoshi Yumoto

20170704Wモデル導入の基礎-公開.pdf
20170704Wモデル導入の基礎-公開.pdf20170704Wモデル導入の基礎-公開.pdf
20170704Wモデル導入の基礎-公開.pdfTsuyoshi Yumoto
 
Useful software testing in the latest development – short version
Useful software testing in the latest development – short versionUseful software testing in the latest development – short version
Useful software testing in the latest development – short versionTsuyoshi Yumoto
 
Ja sst19tokyojstqb ctfl2018
Ja sst19tokyojstqb ctfl2018Ja sst19tokyojstqb ctfl2018
Ja sst19tokyojstqb ctfl2018Tsuyoshi Yumoto
 
ゆもつよ博士論文説明資料公開
ゆもつよ博士論文説明資料公開ゆもつよ博士論文説明資料公開
ゆもつよ博士論文説明資料公開Tsuyoshi Yumoto
 
テスト分析についての説明資料公開用
テスト分析についての説明資料公開用テスト分析についての説明資料公開用
テスト分析についての説明資料公開用Tsuyoshi Yumoto
 
WACATE 2010夏 ゆもつよ講演スライド
WACATE 2010夏 ゆもつよ講演スライドWACATE 2010夏 ゆもつよ講演スライド
WACATE 2010夏 ゆもつよ講演スライドTsuyoshi Yumoto
 
とてか03「「いかす!」のために大事だと思う4つのこと」
とてか03「「いかす!」のために大事だと思う4つのこと」とてか03「「いかす!」のために大事だと思う4つのこと」
とてか03「「いかす!」のために大事だと思う4つのこと」Tsuyoshi Yumoto
 
A study on the efficiency of a test analysis method utilizing test-categories...
A study on the efficiency of a test analysis method utilizing test-categories...A study on the efficiency of a test analysis method utilizing test-categories...
A study on the efficiency of a test analysis method utilizing test-categories...Tsuyoshi Yumoto
 
A Test Analysis Method for Black Box Testing Using AUT and Fault Knowledge.
A Test Analysis Method for Black Box Testing Using AUT and Fault Knowledge.A Test Analysis Method for Black Box Testing Using AUT and Fault Knowledge.
A Test Analysis Method for Black Box Testing Using AUT and Fault Knowledge.Tsuyoshi Yumoto
 

More from Tsuyoshi Yumoto (9)

20170704Wモデル導入の基礎-公開.pdf
20170704Wモデル導入の基礎-公開.pdf20170704Wモデル導入の基礎-公開.pdf
20170704Wモデル導入の基礎-公開.pdf
 
Useful software testing in the latest development – short version
Useful software testing in the latest development – short versionUseful software testing in the latest development – short version
Useful software testing in the latest development – short version
 
Ja sst19tokyojstqb ctfl2018
Ja sst19tokyojstqb ctfl2018Ja sst19tokyojstqb ctfl2018
Ja sst19tokyojstqb ctfl2018
 
ゆもつよ博士論文説明資料公開
ゆもつよ博士論文説明資料公開ゆもつよ博士論文説明資料公開
ゆもつよ博士論文説明資料公開
 
テスト分析についての説明資料公開用
テスト分析についての説明資料公開用テスト分析についての説明資料公開用
テスト分析についての説明資料公開用
 
WACATE 2010夏 ゆもつよ講演スライド
WACATE 2010夏 ゆもつよ講演スライドWACATE 2010夏 ゆもつよ講演スライド
WACATE 2010夏 ゆもつよ講演スライド
 
とてか03「「いかす!」のために大事だと思う4つのこと」
とてか03「「いかす!」のために大事だと思う4つのこと」とてか03「「いかす!」のために大事だと思う4つのこと」
とてか03「「いかす!」のために大事だと思う4つのこと」
 
A study on the efficiency of a test analysis method utilizing test-categories...
A study on the efficiency of a test analysis method utilizing test-categories...A study on the efficiency of a test analysis method utilizing test-categories...
A study on the efficiency of a test analysis method utilizing test-categories...
 
A Test Analysis Method for Black Box Testing Using AUT and Fault Knowledge.
A Test Analysis Method for Black Box Testing Using AUT and Fault Knowledge.A Test Analysis Method for Black Box Testing Using AUT and Fault Knowledge.
A Test Analysis Method for Black Box Testing Using AUT and Fault Knowledge.
 

HP_almqc_concepts20150701

  • 1. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. HPQualityCenter/ALMの コンセプト
  • 2. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.2 HP Application Lifecycle Management / Quality Center 主な機能と特徴 • オールインワンのWebベースのテスト/開発ライフサイクル管理ツール • リリース管理、要件管理、テストケース管理、テスト実行管理、不具合管理 • ユーザ管理、構成管理(バージョン管理、履歴管理、ベースライン管理) テスト結果を同一データベースで管理 不具合管理 不具合の詳細 不具合ステータス テスト実行管理 実行計画、 実行結果 テストケース管理 確認手順と 確認内容 要件管理 機能要件、非機能要件、 テスト要件など リリース管理 製品リリース毎の 日程と進捗管理 バージョン管理バージョン管理 ダッシュボードによる品質の可視化 情 報 分 析 HPインシデント 管理製品 HPプロジェクト 管理製品 @プロジェクト管理部門 @サービスデスク HP自動機能 テスト製品 ユーザ管理 100以上の3rd Party製 テスト関連製品 連携 @開発部門 @テストセンター 連携連携連携 Open Test Architecture API インターネット越しのアクセス
  • 3. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.3 2つのエディション HP Application Lifecycle Management アプリケーションライフサイクルにわたって クロスプロジェクト、クロスイニシアチブのエ ンタープライズリリースを管理 • プロジェクト計画&追跡 • クロスプロジェクトレポート • 資産の共有と再利用 • プロセス標準化(プロジェクトテンプレート) • 不具合の共有(SyncServer) • 無制限の高可用性サーバ • QualityCenterエンタープライズの全機能 – 要件管理 – テスト計画、スケジュール設定、実行 – リリースとサイクルの管理 – 不具合管理 – 進捗と状況のリアルタイムレポート作成 – 開発環境との統合 HP Quality Centerエンタープライズ 一貫した再生可能なテストプロセスを可能に する単一の拡張性をもったプラットフォーム • 要件管理 • テスト計画、スケジュール設定、実行 • リリースとサイクルの管理 • 不具合管理 • 進捗と状況のリアルタイムレポート作成 • 開発環境との統合
  • 4. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.4 HP ALM /QCの変遷 2014 HP ALM/HP QC 12.0 IE以外の対応 / UI刷新 2013 11.5 ラボマネジメント…DevOps 2012 11.0 マネジメントモジュール(KPI),テスト設定 ALM(SCM,IDE,CIツールなどとの連携)対応 2011 2010 QualityCenter 10.0 バージョン管理,ベースライン エクセルレポート2009 2008 9.0 リスクベースドテスティング リリースモジュール(日程管理) エクセルレポート 欠陥間トレーサビリティ 2007 2006 2005 8.0 Javaサーバー ビジネスプロセステスティング 要件間トレーサビリティ 2004 2003 TestDirectoer 7.0i Webアプリに刷新 要件管理(要件モジュール) トレーサビリティ(要件,テスト,欠陥) Eメール 2002 2001 2000 1999 6.01 Windowsアプリ 自動テストツールとの連携 テスト管理 欠陥管理 1998 4.01997 1996 1.521995
  • 5. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.5 HP ALM の典型的な設定例 クライアントコンポーネント 初回起動時にサーバから自動ダ ウンロード 毎回起動時にコンポーネントの読 み込みが走る .NET およびCOM を使用 HTTP/S を介してサーバと通信 サーバアプリケーション Jetty(J2EEのアプリケーション サーバ兼Webサーバ) RDBとはJDBCで接続 サイト管理スキーマ ALM システムに関連する 情報( ドメイン,ユーザ, サイトのパラメータなど)を 格納 システムに対サイト管理 スキーマはひとつだけ プロジェクトスキーマ プロジェクト情報( エンティティ・データや ユーザ・データなど) を格納 作成するすべてのプロジェクトに,別個 のスキーマが存在 プロジェクトリポジトリ プロジェクトで使用するファイ ルを格納( .xml ファイル,テン プレート。添付ファイル)
  • 6. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.6 HP ALM/ Quality Centerでのテストマネジメントのイメージ テスト分析 テスト設計・実装 テスト実装 テスト実行&進捗管理 不具合管理 テスト計画(日程) ②要件モジュール ③テスト計画モジュール ⑤テストラボモジュール ⑥不具合管理モジュール アナリシスモジュール ①リリースモジュール ④テストラボモジュール トレーサビリティ 構成管理 テストに関する情報の一元管理 1.障害の報告 2.改修依頼 テスト実行日程作成 実行結果記録 ログ、エビデンス保存 テストケース作成 テスト手順作成 グラフ化 報告書作成 全体日程作成 テスト対象理解 テスト要件特定 テンプレートやワークフローで一連のテスト業務の実行を補助 検索やグラフ生成、シミュレーション で状況判断の情報を提供 他ツール連携
  • 7. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.7 HP ALM/QCのデモ 基本的な機能と使い方 「はじめてのQC」参照 • http://h30499.www3.hp.com/hpeb/attachments/hpeb/quality-center/21/1/hajimete- qc01.pdf HPのIT部門での活用事例 ※投影のみになります 「ALM in HP IT」 三菱電機事例 「システムテストでは管理工数削減が生産性向上のポイント」 • http://www.jasst.jp/symposium/jasst13tokyo/pdf/A4-2.pdf
  • 8. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. HPQualityCenter/ALMの コンセプト 概要
  • 9. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.9 QC/ALMのテスト管理のコンセプト 大きく5つのポイント • 要件の整理 – 要件の可視化とテスト要件の分析の考え方 • テストの単位、結果の集計の単位 – テストの構造化の考え方 • 進捗など実績の定量的モニタリング – 実績の収集の考え方 • トレーサビリティ – 不具合とのトレース – 要件、テストのトレース – 実績収集のためのトレース • リスクベース品質マネジメント – 優先度をつけるための考え方
  • 10. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.10 QC/ALMのテスト管理のコンセプト その他のポイント(今回は触れません) 自動テストツールのスクリプト管理 • バージョン管理 • リソース管理(データ、ユーザ定義関数、環境変数) • スケジューラ/結果収集 構成管理 • バージョン管理 • ベースライン管理 グラフ・帳票作成機能 • アナリシス/ライブアナリシス/ダッシュボード – ドリルダウン • KPI • Excelレポート(マクロ一元管理) • Word/PDFへレポート出力(ドキュメントジェネレータ/標準レポート/プロジェクトレポート)
  • 11. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. 要件の整理
  • 12. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.12 なぜ、要件の階層化をするのか? 要件階層化 アプリケーションはビジネスの活動/プロセスや機能をサポートする。 構造は例外なく一貫しており、命名ルールは意味をもっている。 • 整理することで可視化でき、テスト要件の識別が容易になる Example 1 Example 2
  • 13. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.13 要件階層化の機能 QualityCenter 要件タイプ • 要件の種類毎に一貫したルールを提供する • 入力フィールドの表示、非表示 • テキストエリアのテンプレート • 要件カバレッジ対象(あり:テストとの関連をつけることが出来る、なし:カバレッジありの要 件を集計する) • リスクベース品質管理(評価対象、分析対象、なし) ツリー構造での登録・表示
  • 14. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.14 要件を整理して、テストすべきこと(テスト要件)を明確化 問題解決または目的達成の為にユーザが 必要とする条件や能力 システムやコンポーネントが満たす、 または保持しなければならない条件や能力 Application 1 Main Activity 1.1 Activity 1.1.1 Requirement Requirement Requirement Requirement Requirement Requirement Activity 1.1.2 Main Activity 1.2 Activity 1.2.1 Requirement • 業務要件 • -ユーザ要件 • ---機能要件 • ---非機能要件 • … これらは階層化され、 関連性をもって管理される 要件ツリーの末端は、その要件に対する プルーフポイント=「テスト要件」 テスト要件
  • 15. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.15 要件とテストの関係 Application 1 Main Activity 1.1 Activity 1.1.1 Requirement Requirement Requirement Requirement Requirement Requirement Activity 1.1.2 Main Activity 1.2 Activity 1.2.1 Requirement 要件が「満足」している事を確認する手段/手順が、テストケース テスト#001 テスト#002 満足・確認 満足・確認 満足・確認 正しいユーザ名とパスワードを 入力した際、正常に ログオン可能な事 入力条件:Username: foo Password: bar 操作:ログインボタンを押下 結果:「ようこそ画面-画面 ID#03」が表示される事 テストケース条件 値 操作 結果 テストケース1 テストケース2 テストケース3 テストケース条件 値 操作 結果 テストケース1 テストケース2 テストケース3
  • 16. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.16 要件とテストの関係 QualityCenter テストカバレッジ • 要件に紐付いたテストがどれだけ実行され、合格しているかをトレース • リリース毎にフィルタリングした集計・全体的な集計を選択可能
  • 17. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. テストの構造、単位、結果の集計
  • 18. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.18 なぜ「テストの構造」を設計するのか? 全体像を共有できる(自分の立ち位置がわかる) 早期から段階的にテストを開発(分析、設計、実装)できる 早期から逐次テストを実行したときの無理、ムラが最小限に抑えられる 複数の技術者/チームでの作業分担が容易になる 全体像を共有するために必要なこと 構造に合わせてテストケースを保存する →フォーマット統一 • 作業中は思考をさえぎらない方法で進めてよいが、最終的には同じ構造で保存する テストに対する要求とテストスイートを分離する 「テストの構造」はテストそのものの品質を良くする テストケースの再利用性を高める(無駄な再利用をしない) テストケースの十分性を高める(テスト要件を満たした度合いを把握する) テストケースの可読性を高める(テスト設計のレビュー効率をあげる) テストケースの効率性を高める(テストの自動化すべきところを識別する) テストケースの機能性を高める(バグが出そうなところをテストできるようにする) 脱スプレッドシート! 作業したら(ワークシートを使ったら) 所定の場所(マネジメントシステム)にし まう 早期からのテスト開発、リリースにあわせ逐次テスト実行を可能にする!
  • 19. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.19 テストへの要件とテストスイートを分離 テストの構造を維持して作業するためのベースとなる • 全体像の理解が容易になる(要件をまずは理解/設計が妥当かを確認) • 双方の構造が崩れないため保守性/再利用性が高まる • テスト分析とテスト設計の作業の切り分けが明確になる – テスト分析とテスト設計の作業分担が明確になる 要件 テストスイート テスト#001 テスト#002 満足・確認 満足・確認 満足・確認 テスト分析 ※ドメイン知識 テスト要件 テスト設計 ※テスト設計スキル Application 1 Main Activity 1.1 Activity 1.1.1 Requirement Requirement Requirement Requirement Requirement Requirement Activity 1.1.2 Main Activity 1.2 Activity 1.2.1 Requirement テストケース条件 値 操作 結果 テストケース1 テストケース2 テストケース3 テストケース条件 値 操作 結果 テストケース1 テストケース2 テストケース3
  • 20. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.20 テスト資産の管理と日々の作業の管理を分離 日々の作業の変化で構造が崩れず、保守性/再利用性が高まる • 段階的にリリースする際にテストを計画的に複数回実行する • 開発の進捗によってテスト実行順序を見直しする • 不具合によってブロックになったテストケース後回し or 再実行する 要件 テストスイート テスト#001 テスト#002 満足・確認 満足・確認 満足・確認 テスト要件 Application 1 Main Activity 1.1 Activity 1.1.1 Requirement Requirement Requirement Requirement Requirement Requirement Activity 1.1.2 Main Activity 1.2 Activity 1.2.1 Requirement テストケース条件 値 操作 結果 テストケース1 テストケース2 テストケース3 テストケース条件 値 操作 結果 テストケース1 テストケース2 テストケース3 作業日程大計画 テスト実行の割り当て/結果集計 3月21日 Aさん:テスト#001~テスト#020 Bさん:テスト#021~テスト#063 Cさん:テスト#064~テスト#075 ・・・ ・・・ 19/20合格 33/42合格 11/11合格 集計要件1 要件2 要件3 割り当てる 割り当てる
  • 21. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.21 テスト(テスト項目)の考え方 • 今までとテスト(テスト項目)の管理の仕方が変わります。 • テスト:今までのテスト項目のうち、テスト設計で最初に作る部分が該当します。 • テストインスタンス:テスト項目の中の「テスト実行時に必要となる具体的な内容」を別記したも のです。これにより、テスト項目の汎用的な部分と、毎回変わる部分を分けて管理できるため、 テスト項目の再利用が容易になります。 • テスト実行:テストの実施結果(合格/不合格)の結果を残すためのものです。複数回テスト実 行した際の履歴を全て確認できます。 テスト(テスト項目) テスト実行 1 対 N テスト設計で作ったテスト項目 テスト実施結果の登録 1 対 N テスト項目 今までのテスト項目 HP ALM/Sprinterのテスト項目 ID 確認概要 実施予定日 実施結果手順 期待結果 実施結果 実施予定担当 ID 確認概要 手順 期待結果 いままではひとつの 行に全ての内容を 記載したテスト項目 を作っていました。 今後は、テスト項目作成、 日程/担当に割り当て、実 施でそれぞれに分けて記 載するようになります。 テストインスタンス テスト日程に割り当てたテスト項目 実施予定日 実施予定担当 テストセット テストインスタンスを実行単位に束ねる箱
  • 22. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.22 テストの全体構造 QualityCenter テスト要件 要件一覧 ※資産管理対象 旅行予約サービス 顧客情報管理 セキュリティ ユーザビリティ 旅行予約 クルージング予約 必須入力 予約登録 予約エラー ビジネス要件 システム要件 要件(資産) リリース(進捗管理) テスト1 テストケース条 件 値 操 作 結 果 テストケース1 テストケース2 テストケース3 テスト2 テストケース条 件 値 操 作 結 果 テストケース1 テストケース2 テストケース3 テストケース4 テスト(資産) テスト一覧 ※資産管理対象 サイクル 第一週 第二週 第三週 第四週 動作確認 旅行予約サービス その他新機能 非機能要件 シナリオテスト 回帰テスト リリース1.2 テスト3 テストケース条 件 値 操 作 結 果 テストケース1 リリース1.2 第一週 実行計画 ※リリース毎 第二週 テストラボ(実績収集) 動作確認 山田 田中 テスト1 インスタンス テスト1 インスタンス旅行予約 山田 テスト2 インスタンス テスト3 インスタンス 日程計画 ※リリース毎 集計 どのサイクルでどの要件がテストされるか決める テストインスタンス を割り当てる
  • 23. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.23 テスト資産の構造 QualityCenter
  • 24. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.24 テスト資産の構造(QC 要件モジュール)
  • 25. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.25 テスト資産の構造(QC テスト計画モジュール)
  • 26. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.26 テスト資産の構造(QC ビジネスコンポーネントモジュール)
  • 27. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.27 テスト資産の構造(QC テストラボモジュール)
  • 28. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.28 テストセット テストセット 要件 テスト要件 テスト テストインス タンス テストインス タンス テストラン テストラン ステップ1 ステップ2 ステップ3 テスト テスト要件 テスト テストインス タンス 最新の結果を反映 ここで書き換え可能最新の結果を反映 ここで書き換え可能 テストカバレッジの集計 ここで書き換え可能 ステップの結果を集計 ここは書き換え不可能 テスト要件の集計 ここで書き変え可能 テスト結果の反映のされ方 QC 要件カバレッジ サイクル集計 「テスト」実行ス テータス 「テストインスタ ンス」ステータス 「実行」 ステータス 「要件」直接 カバレッジステータス QC標準機能 QCグラフ機能
  • 29. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.29 QCのテスト関連部分の構造とあるべきテスト構造の例
  • 30. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. 進捗など実績の定量管理 30
  • 31. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.31 リリーススコープ アイテム リリース ●●システムVer1.5 ・性能改善 ・●●バグの修正 ・●●機能の追加 マイルストーン システムテスト開始 要件 テスト テストセット 不具合 --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- スコープ サイクル1:変更箇所 サイクル2:回帰テスト <スケジュール> KPI(全スコープアイテムの) ・要求のレビュー合格数が95%以下だとNG ・テストケースの準備数 99%以下だとNG テスト対象要件毎の テスト数、不具合数の集計 テスト対象要件毎の テスト数、不具合数の集計 Β版 KPI(全スコープアイテムの) ・テスト合格数 80%以下NG GA版 KPI(全スコープアイテムの) ・1日当たりの修正不具合数 5件以下だとNG ・テスト実行数 50以下だとNG リリース、サイクル、マイルストーン QC
  • 32. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.32 進捗確認 Quality Center リリース KPI
  • 33. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. トレーサビリティ
  • 34. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.34 トレーサビリティ(QC 不具合)
  • 35. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.35 トレーサビリティ(QC 要件間、要件とテスト)
  • 36. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.36 変更点を通知 QualityCenter 警告ルールを設定することで変更点を通知する
  • 37. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.37 トレーサビリティ(QC リリース・サイクル)
  • 38. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. リスクベース品質管理
  • 39. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.39 品質リスク分析は何に使うのか? テストの位置づけを変える いままで:「時間の限り全部を網羅して品質が確保されていることを確認する」 いまどき:「価値達成の度合いを判断する情報ソースの収集手段とする」 品質リスクを分析し、テストの網羅度合いをチューニングする • 品質リスク (またはプロダクトリスク) とは – 潜在的な問題の主な影響がリリースした後の製品の品質に及ぶ場合を指す • リリース後の致命的バグで全品回収かもしれない – 「価値達成しない可能性=品質リスクあり」と考えて優先度/網羅度合いを決める リスク 影響 欠陥 テスト方法 在庫量の計算ミスの可能 性 大 中 二機能間網羅 帳票の印刷遅延の可能性 小 小 仕様書記載項目のみ網羅
  • 40. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.40 リスクベース品質管理-1 QualityCenter 1. 「ビジネス上の危険性」(business criticality) • 要件単位に設定、危険性の重みづけを実施 • デフォルトでは因子は4つ(後述) • 重みづけリスクマトリクスでTW(トータルオブウェイト)を決定 2. 「失敗の確率」(failure probability) • 要件単位に設定、確立の重みづけを実施 • デフォルトでは因子は4つ(後述) • 重みづけリスクマトリクスでTW(トータルオブウェイト)を決定 3. 「機能の複雑さ」を設定(テスト工数を見積) • 要件単位に設定(工数を計測のための因子) • デフォルトでは因子は4つ(後述) • 工数評価マトリクスを決定
  • 41. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.41 リスクベース品質管理-2 QualityCenter 4. 「リスク評価」を分析 • リスク評価により、優先度を3つに分類 • 「機能の複雑さ」による工数評価結果と、工数期間までの期間から超過している時間を分析 • 超過している時間がある場合、優先度別で要件のテストをどの程度にするか(テスト程度)、人 員を増やすか、リリースをずらすかといった「リスク回避策、リスク対応策」の方針を検討 5. プロジェクト中のリスク分析アップデート • 「リスクは生もの」という観点から、リスク分析は一度ではなく設計、開発、テストを通してアップ デートし続ける • 「リスク回避策、リスク対応策」の方針もアップデートし続ける
  • 42. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.42 Application 1 Main Activity 1.1 Activity 1.1.1 Requirement Requirement Requirement Requirement Requirement Requirement Activity 1.1.2 Main Activity 1.2 Activity 1.2.1 Requirement A High Risk B Medium Risk C Low Risk Type of Process Calculation / validation change of data display Business Impact legal wrong information none Frequence of use very often often rare Number of Customer affected large number / very important group some Result Criteria 1.ビジネス上の危険性(business criticality) 要件に対する関係図 ビジネス上の危険性TW 分類階層化により 管理された要件
  • 43. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.43 Application 1 Main Activity 1.1 Activity 1.1.1 Requirement Requirement Requirement Requirement Requirement Requirement Activity 1.1.2 Main Activity 1.2 Activity 1.2.1 Requirement A High Risk B Medium Risk C Low Risk Type of Process Calculation / validation change of data display Business Impact legal wrong information none Frequence of use very often often rare Number of Customer affected large number / very important group some Result Criteria 2.失敗の確率(failure probability) 要件に対する関係図 ビジネス上の危険性TW Medium UNIX or Windows Changed Func. II Possible High Unix, Windows, Host combination New Func I Likely LowDefects Rate HOSTPlattform OS UnchangedChange Rate III Unlikely Result Criteria Medium UNIX or Windows Changed Func. II Possible High Unix, Windows, Host combination New Func I Likely LowDefects Rate HOSTPlattform OS UnchangedChange Rate III Unlikely Result Criteria 失敗の確率TW
  • 44. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.44 3.機能的な複雑さでテスト工数を決定 Application 1 Main Activity 1.1 Activity 1.1.1 Requirement Requirement Requirement Requirement Requirement Requirement Activity 1.1.2 Main Activity 1.2 Activity 1.2.1 Requirement • テクニカルアーキテクトと一緒に機能的な複 雑さを分析する。 • リスクと複雑さを組み合わせてテスト工数を決 定する。 1 High complex 2 Medium complex 3 Low complex Number of Objects affected > 9 4 - 9 < 4 Number of Objects with write access > 3 1 - 3 < 1 Number of objects with read access > 5 3 - 5 < 3 Number of Windows affected > 4 2 - 4 < 2 Complexity Criteria 機能的な複雑さを分析する 1 High complex 2 Medium complex 3 Low complex A Critical 12,5 10,2 8,3 B Important 6,9 6,3 5,6 C Nice to have 4,2 3,5 2,8 Complexity Impact Effort per Business Function [PD] テスト工数を決定する
  • 45. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.45 A High Risk B Medium Risk C Low Risk Type of Process Calculation / validation change of data display Business Impact legal wrong information none Frequence of use very often often rare Number of Customer affected large number / very important group some Result Criteria 4 .「リスク評価」を分析 リスク評価の算出 ビジネス上の危険性TW Medium UNIX or Windows Changed Func. II Possible High Unix, Windows, Host combination New Func I Likely LowDefects Rate HOSTPlattform OS UnchangedChange Rate III Unlikely Result Criteria Medium UNIX or Windows Changed Func. II Possible High Unix, Windows, Host combination New Func I Likely LowDefects Rate HOSTPlattform OS UnchangedChange Rate III Unlikely Result Criteria 失敗の確率TW 失敗の確率 危険性 高 中 低 致命的 高い(フル) 高い(フル) 普通(66%) 重要 高い(フル) 普通(66%) 低い(33%) リスクをとる 普通(66%) 低い(33%) 低い(33%) – 3段階の品質リスクへカテゴライズ • 「ビジネス上の危険性」と「失敗の確率」 3段階のテストレベルへカテゴライズ • 高い 本来やるべきテストをフルで実施 • 普通 テストは2/3の労力で実施(66%) • 低い テストは1/3の労力で実施(33%)
  • 46. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.46 リスク評価の算出 4 .「リスク評価」を分析 – 3段階のテストレベルに設定した作業時間、合計テスト作業時間を分析しス ケジュール上割り当てられた時間と比較、超過してるかどうかを可視化 (プロダクトリスクからプロジェクトリスクへの影響を可視化) 作業時間を予定時間 と比較分析(%表示) 分析に利用する 作業時間設定
  • 47. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.47 対策を実施 4 .「リスク評価」を分析 – 対策方針の例 • サイクルへのテストケース割り当ては優先度の高いものを先に割り当てる • 回帰テストの数を増やす(自動化対象) • 既存のテストだけでなく新しいテストを追加する • テストパラメータのパターンの数を増やす 優 先 度 高 の 配 置 優 先 度 低 の 配 置 システムA リリース 1.0 外部接続テスト 全機能テスト リリース 1.5 新機能テスト 回帰テスト サイクル例
  • 48. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.48 リスクは変化するもの 5 .プロジェクト中のリスク分析アップデート – リスク回避の方針 • 影響ある因子をアップデートし、対応策を選定 リスクベースドテスト因子 テスト設計・分析 開発 テスト イ ン パ ク ト プロセス ◎ インパクト ◎ 利用頻度 ◎ ユーザ数 ◎ 発 生 確 率 変更タイプ ◎ 成熟度 ◎ 欠陥率 ◎ ◎ ◎ 他への影響数 ◎ ◎ ◎ 複 雑 度 論理ステップ数 ◎ ◎ △ 関連データ量 ◎ ◎ △ 他システムとの依存関係 ◎ ◎ △ プロセス内の計算レベル ◎ ◎ △
  • 49. © Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. Thankyou