プロジェクトファシリテーターのじゅんです。
今回はシステム開発を行う際に必ず実施するテスト工程に関するお話です。
ユーザー企業様、システム開発企業様、どちらの企業様ともお仕事をする機会がありますが、情報システムを導入する場合に、相談されることの一つに、「どこまでテストしたらいいんですかね？」という内容があります。
私は、金融業界のシステム開発における品質保証に関する部門の立ち上げやシステム開発における標準化の取り組みを行った経験から、目安となる基準をご紹介することがあるので、その内容を今回はブログとしてまとめます。
スポンサーリンク
情報システムのテストってどのくらいやればいいの？ちゃんとできてるのかな？
情報システムを開発する際に必ず「テスト」を実行します。
「テスト」とだけ書くと何か特別なことをするとイメージする方もいらっしゃるかおしれませんが、
例えばわたしのブログだったら、
①「リンクを押したら想定しているページに飛ぶかな？」とか
②「問い合わせページのメールアドレス欄が空白だったら、＜メールアドレスが入力されていません＞って表示してくれるかな？」
と、いったことを試してみるのが「テスト」です。
情報システムのテストを実行する際は、テストケースと呼ばれるテストを行うためのパターンを用意します。
先程の例でいえば、
①、②と書かれた内容がテストケースです。
情報システムが大きくなればなるほど、このテストケースは膨大な量になります。そして、テストを実行するとバグと呼ばれるシステム上の不具合が発見されます。
テスト実行で必ず出てくる悩み
テストを実行していると以下のような悩みがでてきます。
１．作ったテストケースってこの量でいいのかな？少なすぎない？多すぎない？
２．バグは見つかったけど、見つけた数少ないのかな？多いのかな？
これは意外と多くの企業で抱えている悩みです。テストのスペシャリストやベテランテスターの人が経験と勘でこの悩みを解決している場面をわたしは何度も見てきました。
しかし、経験が少ない方やシステム開発を行ったことのない企業からすればあまり納得感は無いはずです。
今日はこの悩みに対する解決策を紹介します。
解決策｜データ取れ！分析して行動を起こせ！
解決策は、
データを取得して、
バグ密度・テストケース密度を計算して、
ゾーン分析をしろ！
です。
一つ一つ具体的にどのようにするか解説します。
１．必要なデータを取得する
妥当なテストケース数かバグの出方は妥当なのかという悩みを解決するためには、何はともあれデータを取らなければ始まりません。
データは以下の４つを揃えましょう。
①ソフトウェアの規模（KSLOC or FP）
②テストケース数
③バグ数
④基準となる評価データ（テストケース密度（上限値、基準値、下限値）、検出バグ密度（上限値、基準値、下限値））
①ソフトウェアの規模（SLOC or FP）
SLOCとFPとはソフトウェアの規模を把握する際に活用されている計測方法です。どちらか一方で、対象とするソフトウェアの規模データを用意しましょう。
後述している基準となる参考データは、IPAが提供しているソフトウェアデータ白書からの抜粋ですが、こちらではSLOCとFPによるデータが提供されています。ソフトウェアの規模を計測する際にFP法やSLOC法に賛否はありますが、他プロジェクトとのデータ比較を行う際は、ソフトウェアデータ白書の数値を比較することは参考になるのでどちらかの計測方法を適用することは有効です。
また、単にSLOC、FPとだけ記載すると計測方法が異なることで、意味の無い比較になってしまうため、ソフトウェアデータ白書より、SLOCとFPの数値の定義を抜粋しておきます。
SLOCの定義（実効SLOC実績値）
コメント行、空行を除いたSLOC 値。
すなわち、
SLOC 値（5004_SLOC実績値SLOC、改良開発の場合は以下定義）から、コメント行比率（10086_SLOC実績値コメント行比率）、空行比率（10087_SLOC実績値_空行比率）をもとに算出した行数を除いた値。なお、本書で使用しているSLOC、実効SLOC値も同意。
KSLOCは実効SLOC実績値を1,000行単位で表現したもの。
改良開発の場合のSLOC値：
開発プロジェクトの種別がｂ：改修・保守又はｄ：拡張で、母体を含まないSLOC値。具体的には下記の条件で算出する。
（1）11004_SLOC実績値（追加・新規）、11005_SLOC実績値（変更）、11006_SLOC実績値（削除）に全て記載がある場合は、SLOC値（改良開発）＝11004_SLOC実績値（追加・新規）＋
11003_SLOC実績値（変更）＋11004_SLOC実績値（削除）（2）11017_SLOC母体包含有無＝1（母体含まない） の場合は、
SLOC 値（改良開発）＝5004_SLOC実績値_SLOC
（注意）
11003 ～ 11006 の詳細値がなく、
11017_SLOC母体包含有無＝0又は2で母体含む可能性がある場合は算出の対象とならない。
FPの定義
データファンクション
IFPUG手法で計測された5057_ILF実績値_FP＋5065_EIF実績値_FPの値
トランザクションファンクション
IFPUG手法で計測された5053_EI実績値_FP＋5041_EO実績値_FP＋
5049_EQ 実績値の値
②テストケース数
前述したようにテストを実行する際は、テストケースを作成すると思いますので、テストケース数を用意しましょう。
テスト工程ごとに実行するテストケースが分かれていると思いますので、プロジェクトを通した総数ではなく、工程ごとのテストケース数を用意しましょう。
③バグ数
バグ数は、検出バグや不具合などと表現されますが、テストケースとは別にバグの数がプロジェクト内で管理されているはずです。エクセルで管理していたり、BTSと呼ばれるシステムで管理したり、しているはずですのでそちらの数値を取得しましょう。
こちらもテストケース数と同様に工程ごとに検出されたバグ数を取得しましょう。このときの検出工程は、バグを検出したときの工程で構いません。
例えば総合テストを実施しているときに、単体テストで検出すべきバグを見つけた場合であっても、総合テストに計上して構いません。
④基準値となる評価データ
・テストケース密度（上限値、基準値、下限値）
・検出バグ密度（上限値、基準値、下限値）
この評価データですが、自社内で蓄積してきたデータを品質管理部門などから取得してください。
できるだけ今回分析する対象と類似したプロジェクト（開発規模、新規／既存、業界、システム特性）の数値データが良いです。
しかし、このページをご覧になる方の中には、自社にデータが存在しないという場合も多くあるかと思いますので、後半に参考となるデータ集を記載させていただきます。
そちらを参考にしてください。
２．テストケース密度・検出バグ密度を計算する
必要なデータを取得したら以下の計算式を参考に、検出バグ密度とテストケース密度を算出してください。
検出バグ密度【件／KSLOC】【件／KFP】
検出バグ数【件】 ÷ システム規模【KSLOC】 ＝ 検出バグ密度【件／KSLOC】
検出バグ数【件】 ÷ システム規模【KFP】 ＝ 検出バグ密度【件／KFP】
テストケース密度【件／KSLOC】【件／KFP】
テストケース数【件】 ÷ システム規模【KSLOC】 ＝ テストケース密度【件／KSLOC】
テストケース数【件】 ÷ システム規模【KFP】 ＝ テストケース密度【件／KFP】
３．ゾーン分析しろ！
これで、必要なデータが用意できました。いよいよ分析に入ります。ゾーン分析という手法を使用します。
ゾーン分析は、検出バグ密度（上限、下限）、テストケース密度（上限、下限）の４つの数値を使用し、９つのゾーンに分類し、対象のプロジェクトのテスト状況が妥当かどうかを分析する手法です。
以下のプロジェクト例を使用してグラフ上にプロットすると以下のようになります。
プロジェクト例｜新規開発 SLOCにて集計 結合テスト
以下のようなプロジェクトの場合を考えてみます。
| KSLOC | 400 |
| テストケース数 | 16,000 |
| バグ数 | 800 |
| テストケース密度 | 40.0 |
| バグ密度 | 2.0 |
このプロジェクトをゾーン分析すると以下のようになります。
上図９つのゾーンにはそれぞれ評価ポイントがあります。
以降では、ゾーンごとにどのように分析・評価をして、どのように対応すればよいかをご紹介します。
このゾーンにプロットされた情報と実際に発生しているバグの内容から改善ポイントを見つけ出してテスト効率を上げましょう。
ゾーン①
テストケース数、検出バグ数ともに妥当な数字です。
ゾーン分析としては問題ない数値なので、このまま進めましょう。
実施するアクションがあるとすれば、検出したバグの内容を詳細に分析しましょう。今回の対象システム特有のバグの場合は、大幅な改修や対応が必要なケースも考えられるので、安心せずに注意してプロジェクトを進めましょう。
ゾーン②、④
テストをしてるにもかかわらず、抽出されるバグの数が少ないです。
同じようなテストを何度も実施していない。
ゾーン⑤、⑥
実行するテストケース数は妥当ですが、発生しているバグの数が多いです。
設計工程で不具合があるか、製造（コーディング）工程で何か問題が発生しているはずです。
テスト実行を止めて、前工程（設計、製造）での問題に関する原因追及をすることをお勧めします。
ゾーン⑦、⑧
実施するテストケースが不足しています。
さらに、テストケースが不足しているにもかかわらず、バグの数が多く発生しているので設計工程で不具合があるか、製造（コーディング）工程で何か問題が発生しているはずです。
また、ゾーン⑧にある場合は、1つのテストを実施したときに２つや３つもバグが見つかる状態になっているのではないでしょうか？
ゾーン⑦、⑧にある場合は、テスト実行を止めて、前工程（設計、製造）での問題に関する原因追及をすることをお勧めします。
さらに、作成するテストケース数が十分かどうかの見直しも行いましょう。
ゾーン⑨
実施するテストケースが不足しています。不足しているため検出するバグ数も少ないです。
この場合は、テストケースがそもそも不足しているので、テストケースが網羅されているかをまずは確認してください。同じカテゴリや機能でもパターンが足りていないかどうかを確認してみましょう。
ゾーン分析はテスト工程終了後に行うのではなく、理想は日次で行う！
ゾーン分析を行うことで、テストの量は適切なのか、バグの発生量は適切なのかということを知ることができたと思います。全くこの分析を行ったことがない場合は、まずは１回データを収集してプロットしてみましょう。
分析に慣れてきたら次に移りましょう。
分析して終わり、評価して終わり、となってはそれ自体がもつ意味は減少してしまいます。
テスト工程が終わってから、やシステムリリース直前にゾーン分析の報告を聞いて、ゾーン⑨でした。
という報告をしたらどうでしょう？
「なんでいまさら？」
「わかってるならテストもっとやれよ！」
「リリース直前だからテストする時間ないよ」
となってしまいます。
分析や評価をする最大の目的は、行動を変えることにあります！
テスト工程が始まる前から分析できる仕組みを作っておき、テスト工程に入ったら、毎日ゾーン分析を行い、適切なテスト消化量とバグ検出ができているかを見ながら実行していきましょう。
①のゾーンから外れてきた場合は、テストのやり方を変えたり、テストを中断してバグ改修をしたり、と次のアクションを変えるような判断をしましょう。
あなたが、実行者であれば、リーダーやマネージャに話してプロジェクトの進め方を相談するのも良いです。
もっとも大事なのは、分析・評価のあとに行動を変えることです！
どの数値を基準値にすれば良い？データがなければIPAを使え！
先程データを収集するところで軽く書きましたが、経験や実績が無かったり、データを取り始めたばかりだったり、とする初期の頃は全く基準がなくて困る場合もあるはずです。
そんな時にわたしがお勧めしているのは、IPAが公開している「ソフトウェア開発データ白書」のデータです。このソフトウェア開発データ白書は、毎年発行されており、3,000～4,000プロジェクトものデータを集計した情報が掲載されています。
その中には、検出バグ密度やテストケース密度も掲載されています。今回お話した内容に該当するデータを以降に抜粋しているので、該当するデータを使用して分析に活用してください。
また、ソフトウェア開発データ白書には、業界別のデータも存在するので、より細かく見たい場合はそちらのデータも参考にするのも良いです。
出典：IPA ソフトウェア開発データ白書 2018-2019
表中の（）は、ソフトウェア開発データ白書内の表記です
FP（ファンクションポイント）法で開発規模を計測する場合
全開発プロジェクト
結合テスト
| 下限値（P25） | 基準値（中央値） | 上限値（P75） | |
| テストケース密度 | 875.5 | 2054.8 | 4,977.5 |
| 検出バグ密度 | 36.8 | 97.9 | 178.2 |
総合テスト
| 下限値（P25） | 基準値（中央値） | 上限値（P75） | |
| テストケース密度 | 252.4 | 586.6 | 1445.3 |
| 検出バグ密度 | 7.0 | 24.9 | 52.7 |
新規開発プロジェクト
結合テスト
| 下限値（P25） | 基準値（中央値） | 上限値（P75） | |
| テストケース密度 | 739.5 | 1790.5 | 2811.9 |
| 検出バグ密度 | 67.6 | 123.7 | 268.6 |
総合テスト
| 下限値（P25） | 基準値（中央値） | 上限値（P75） | |
| テストケース密度 | 204.1 | 441.0 | 958.2 |
| 検出バグ密度 | 10.0 | 32.7 | 54.3 |
改良開発プロジェクト
結合テスト
| 下限値（P25） | 基準値（中央値） | 上限値（P75） | |
| テストケース密度 | 1656.3 | 3346.9 | 6407.3 |
| 検出バグ密度 | 30.0 | 57.8 | 102.4 |
総合テスト
| 下限値（P25） | 基準値（中央値） | 上限値（P75） | |
| テストケース密度 | 574.2 | 1242.9 | 3018.2 |
| 検出バグ密度 | 5.8 | 23.3 | 67.7 |
SLOC（Source Lines of Code：ソースコードの行数）法で開発規模を計測する場合
全開発プロジェクト
結合テスト
| 下限値（P25） | 基準値（中央値） | 上限値（P75） | |
| テストケース密度 | 23.5 | 50.5 | 114.4 |
| 検出バグ密度 | 0.541 | 1.301 | 2.548 |
総合テスト
| 下限値（P25） | 基準値（中央値） | 上限値（P75） | |
| テストケース密度 | 6.2 | 14.8 | 40.2 |
| 検出バグ密度 | 0.060 | 0.248 | 0.724 |
新規開発プロジェクト
結合テスト
| 下限値（P25） | 基準値（中央値） | 上限値（P75） | |
| テストケース密度 | 17.85 | 35.70 | 64.27 |
| 検出バグ密度 | 0.943 | 1.600 | 2.626 |
総合テスト
| 下限値（P25） | 基準値（中央値） | 上限値（P75） | |
| テストケース密度 | 3.92 | 9.31 | 17.94 |
| 検出バグ密度 | 0.112 | 0.320 | 0.833 |
改良開発プロジェクト
結合テスト
| 下限値（P25） | 基準値（中央値） | 上限値（P75） | |
| テストケース密度 | 32.98 | 65.72 | 171.76 |
| 検出バグ密度 | 0.308 | 1.101 | 2.425 |
総合テスト
| 下限値（P25） | 基準値（中央値） | 上限値（P75） | |
| テストケース密度 | 8.70 | 24.80 | 69.85 |
| 検出バグ密度 | 0.033 | 0.183 | 0.721 |
本日の提案｜システムテストで不安になったらデータを集めてゾーン分析しましょう！
・自社のデータを収集しましょう！
・検出バグ密度とテストケース密度を算出してゾーン分析しましょう！
・基準データが自社になかったらIPAのソフトウェア開発データ白書のデータを使いましょう
本記事で紹介したデータは以下の資料より抜粋しております。
出典：IPA ソフトウェア開発データ白書 2018-2019
投稿者プロフィール
- プロジェクトファシリテーター
-
フリーランスのITコンサルタント として、CIO代行サービスで多くの企業をサポートしています。
企業のIT戦略 立案・実行支援を行い、
ITを活用した情報システム の導入・マネジメント支援しています。
IT利活用 に関して気軽な相談から経営に関わる支援まで幅広く受け付けています。
普段私が仕事をする時にお客様やプロジェクトチームの方々に実際に話している内容をたくさんの方々に届けます。
DX（デジタルトランスフォーメーション）が好きすぎるので「DX王子」と呼ばれています。
最新の投稿
仕事術2024年8月29日面談前に職務経歴書などの提出をお願いする理由を解説します！
フリーランス2024年3月22日フリーランス年収1000万を目指すなら「誰の言葉か？」が重要
仕事術2024年3月19日なぜオンラインミーティングを録画するのか！？メリットしか無いからです！
フリーランス2024年3月4日50歳以上のエンジニアに送る！あなたに仕事がない理由
