第２部 事例編
4 東京海上日動システムズ
4.3 ソフトウェアテストの品質評価とテスト見積もりの取り組み
（３）開発期間の予実績と品質
開発期間全体の予実績で予定より期間が長くなったもの・ほぼ同じ・少ないものに 3 分類して工 程別期間の割合の予実績とシステムテストの障害密度の相関を分析した。（表 4.2）工程別期間の予 定はほぼ同じであるが、期間延長となったものは、要件検討とシステムテスト期間の実績が予定よ り長くなり、工程の重なりも多いことがわかる。
さらに、期間延長となったものはシステムテスト工程での障害摘出密度も高い。
表 4.2 合計期間に対する工程別期間の割合予実績と、システムテストの障害密度
期間短縮
（予定）（実績）
ほぼ予定通り
（予定）（実績）
期間延長
（予定）（実績）
平均
（予定）（実績）
要件検討 33% 31% 29% 34% 30% 43% 30% 34%
設計・製造 38% 34% 37% 38% 35% 30% 37% 37%
システムテスト 40% 36% 39% 38% 40% 45% 40% 38%
のべ期間※１ 111% 102% 106% 111% 106% 117% 107% 109%
障害密度※２ 85% 102% 170% 100%
※1：のべ期間 各工程毎の割合の合計。100%より大きいほど工程の重なりが多い。
※2：障害密度（システムテスト） 全体を 100%とした場合の開発規模あたり障害検出割合
（４）全体として
当初の見積もり時は平均的な工数で計画することが多いため、テスト工程の品質が悪いものほど、
プロジェクトの最終局面で工数超過・費用超過が発生しやすく、プロジェクト管理上のリスクが高 まる。システムテスト工程は全開発工程の中で大きなウェイトを占める部分であり、全体の見積・
実績に影響が大きい。
テスト工程での品質の低下の回避の取り組みはもちろん重要であるが、ばらつきのあるプロジェ クト 1 つずつについて、品質低下の兆候を早期に把握し、その後の計画見直し（見積もりの見直し）
につなげ、プロジェクトを成功に導くことの重要性があらためて明らかになった。
123
会社名 案件名 規模（Ｋｓｔｅｐ） 作成日
所属名 本番予定日 工数（人月） 開発主担当
案件Ｎｏ 子案件Ｎｏ 発注Ｎｏ 開発主担当ＴＥＬ
全体評価 信頼度成長曲線
前回 今回
１ テスト密度 ＳＴ 34.0 （件／Ｋｓｔｅｐ）
OT 6.0 （件／Ｋｓｔｅｐ）
テストケース数／Ｋｓｔｅｐ。テストケース設定の十分性評価 合計 40.0 （件／Ｋｓｔｅｐ）
２ テストケース消化 残数 ／ 総数 残割合
0 ／ 1000 0%
テストケース数消化件数。消化見通しを評価
３ 障害密度 ＳＴ 1.2 （件／Ｋｓｔｅｐ）
OT 0.2 （件／Ｋｓｔｅｐ）
障害件数／Ｋｓｔｅｐ。問題摘出の過不足を評価 合計 1.4 （件／Ｋｓｔｅｐ）
４ 障害率 ＳＴ 3.5%
OT 2.7%
障害件数／テストケース×１００｡テストケース設定内容の妥当性評価 合計 3.4%
５ 収束率 ＳＴ 100.0% 目標値→ 30
OT 80.0% 目標値→ 5
累積摘出件数／推定障害総数（摘出目標値）×１００。問題摘出十分性評価 合計 97.1% 最終週バグ数 0
６ 仕様変更収束率 残数 ／ 総数 残割合
(対応必須の要件変更残存数 0 ／ 12 0%
要件追加・変更未解決件数／総発生件数。仕様ＦＩＸ度評価
７ 未解決バグ件数 残数 ／ 総数 残割合
1 ／ 34 3%
残対策問題点件数／総発生件数。Ｃ／Ｏへの影響評価
８ ペンディング件数 残数 ／ 総数 残割合
1 ／ 3 33%
未解決懸案事項／総発生件数。Ｃ／Ｏへの影響評価 ９ 総合評価
上記評価項目の平均
（中間品質評価・スポット品質評価） ４点：このままテストケースを消化し品質確保可能 ３点：品質確保可能だが若干の軌道修正が必要 ２点：品質確保不安有り。追加テスト要 １点：品質確保不十分。工程見直し要
（最終品質評価） ４点：品質確保十分。懸案無し ３点：品質確保したが調整懸案有り ２点：品質確保不安有り。追加テスト要 １点：品質確保不十分。やり直し ZZZZZZ XXXXXXXXYY
中間：６０～７０％
最終：１００％
見 解
ｘｘ～ｘｘ件／Kstep
（システム毎に設定）
ｘｘ～ｘｘ％
（システム毎に設定）
中間：残数／総数 最終：残数（０）／総数
3 4
3 4
4.0 3.0
4 4
3 4
2 4
4 4
2 4 ｘｘ～ｘｘ件／Ｋｓｔｅｐ
（システム毎に設定）
3 4 中間：残数／総数（残４０％）
最終：残数（０）／総数
項番 評価指標
評価点 評価指標
指標 実績値
中間品質評価 最終品質評価
Ｘ月Ｘ日実施 Ｘ月Ｘ日実施
XXXXXXXX （Tel：1234）
あああああああああ 25.0
2008年2月1日 25.0 フルネーム
タイトル
信頼度成長曲線
0 100 200 300 400 500 600 700 800 900 1000
10月1日 10月8日10月15日 10月22日 10月29日11月5日11月12日 11月19日 11月26日12月3日12月10日 12月17日 12月24日 12月31日 1月7日 1月14日
テストケース数
0 5 10 15 20 25 30 35 40
累積バグ数
・平均値より少ないが、単純改訂が多いためであり問題ないと判断する。
・平均値より多いがテスト初期で環境不備によるものが多発したため。バグ数としては平均的。
・平均値より多いのはXX機能の品質不足と判断し、品質向上施策を追加実施し改善。
・当初のケースの挙げ方では機能による偏りがあったため、中間評価時に見直しを行った。その結果、テ スト密度は標準実績値より高くなったが、十分なテストが出来たと評価する。
・中間評価時は障害率が1%と低かったが、テストの観点を見直しケースを追加してテストを実施した結果、
標準的な数値となった。
・障害発生率が低いためﾃｽﾄｹｰｽを見直したが、内容・範囲とも問題なし。単純改訂によるものと判断。
・テストケースの消化に応じて障害検出も収束しており、問題はない。
・X月X日の週前後に山があるが、テストケース内容の見直しを行ったためであり、問題ない状況と判断す る。
・バグ摘出目標値はⅡ期実績値2 0件/Ｋｓ×開発規模とした
・オーナテスト時に帳票のレイアウトについて、仕様変更が発生。全体への影響は少ないと判断し、対応 を行い完了しており、問題はない。
・未対応の障害はない。
・未対応の障害は１件あるが、本番稼働はＣ／Ｏの２Ｗ後であり、対応は完了する見込。
・画面項目の誤字があるが、社内利用であり次回対応でオーナ了解済み。
・ペンディング事項は別紙記載のX件。いずれもＣ／Ｏ直後には影響なし。
・テスト内容、障害検出状況ともに問題ないと判断する。
・テスト段階でXX機能に要件変更がいくつか発生し、その分障害の収束も遅れた。追加テストを実施し、
問題ないレベルに達したと判断する。
全体評価レーダーチャート
0.0 1.0 2.0 3.0 4.0 総合評価
テスト密度
テストケース消化
障害密度
障害率 収束率
仕様変更収束率 未解決バグ件数
ペンディング件数
今回
前 回
・中間評価時は想定より早いペースでテストケース消化していたが、障害摘出率が低かった。テストケースの挙げ方に 問題があると判断し、ケース見直しを実施し、ケースを追加した。残ケースは大量テスト、性能テスト、プレ本番環境で のリモメン対象画面の確認のXケースであり、現在最終確認中。X月X日に完了予定。
図 4.3 品質評価報告書
表 4.3 8 つの評価指標
評価指標 指標の意味
テスト密度 テストケース数／開発規模（Ｋｓｔｅｐ）。
テストケース設定の十分性を評価。
テストケース消化 テストケース残消化数／総テストケース数。
テストケースの消化見通しを評価。
障害密度 摘出障害件数／開発規模（Ｋｓｔｅｐ）。
問題摘出の過不足を評価。
障害率 摘出障害件数／テストケース数×100。
テストケース設定内容の妥当性を評価。
収束率 摘出障害件数／推定障害総数×100。
問題摘出十分性を評価。
対応必須の要件変更残存数 要件追加・変更未解決総数／総発生件数。
仕様ＦＩＸ度を評価。
未解決バグ数 未解決障害件数／摘出障害件数。
サービスインへの影響評価。
ペンディング件数 未解決懸案事項件数／総懸案事項件数。
サービスインへの影響評価。
（２）評価のタイミング（図 4.4）
ａ．テスト計画時
前工程までの品質状況と今後の見込みを勘案し、予定数を見積もる。予定ケース数や障害予 測をふまえて、テストの期間・工数の見積もりを確認し、必要であれば見直しを行いテスト 計画レビューを実施して承認を得る。
前工程までで特に品質が低いところや、要件変更・追加が多いところは、今後のテストでの 障害件数も増加することが見込まれるため、特に配慮が必要である。
ｂ．中間評価
テストケースを 50～60％程度消化した時点で、テストの進捗や品質を評価する。
想定以上に障害が検出されている、逆にほとんど障害が検出されないなど、プロジェクトに よって、この時点でかなりばらつきが発生することが多い。
後戻りのリスクを軽減するとともに、過剰な分析ロードがかからないよう、ある程度テスト の状況が見えたところで評価を行うこととしている。
ｃ．スポット評価
テストの進捗状況が悪い場合、想定外に障害が検出される場合にはさらにスポット評価を行 う。長期にわたるプロジェクトなどでは、進捗確認時に障害検出状況も確認し、プロジェク トの見積もりへの影響が懸念される場合には、早急に評価・対応を行うことが必要である。
ｄ．最終評価
中間評価と同様に実施するが、テストケースは 100％消化、障害も収束し、対応も完了して いることが必要。
図 4.4 評価のタイミング
125