はじめに
はじめまして！株式会社HRBrainでQAエンジニアをしていますmonです。
今回はHRBRainに入社前、QAエンジニアとしての道を歩み始めた際に最も嫌いだったバグ報告をバグ密度を知ることで気が楽になったという話を記事にしようと思います。
バグ報告が嫌いだった理由
IT未経験でQAエンジニアになった当初、テスト実施を通してバグを発見した瞬間は成果が出せた！と嬉しかった私ですが、いざバグ報告になると憂鬱でたまりませんでした。
当時、私の中ではバグ=出てはいけないのも、エンジニアの方のミスという印象を持っていました。
そのためバグ報告=面と向かってミスを指摘させられている様な気持ちになり、コードの書き方も知らないのに指摘なんて、、、と思っていました。
そんな中、QAを完了した際に１つもバグが検出されないということがありました。
てっきり『良かったね』と言われると思っていた私に上司が言った言葉は『テスト設計から見直して再実施して下さい』でした。
そこで聞いたのがバグ密度による分析です。
バグ密度ってなに？
バグ密度とは、開発の規模とバグの量を示す指標のことです。
一般的には『バグ数／規模』で算出され、開発規模に対して検出されたバグの量が適切かを判断するのに使われています。
第一の壁、開発の規模
『バグ数／規模』と言っても、バグ数は数えれば良いけれど規模はどうやって算出すれば良いのかという課題がまず第一の壁として出てきます。
開発規模の算出方法には大きく分けて『FP法』と『SLOC法』の２つがあります。
FP法（Function Point）
ファンクションポイント法の略でざっくり説明すると、機能単位で規模を算出する方法です。
開発するすべての機能に難易度（点数）をつけることで、より正確な開発規模を算出することが可能です。
上記の点から、分析や工数見積だけでなく開発依頼が来た際の見積りを出す際にも利用されています。
SLOC法（source lines of code）
機能ごとに算出しているFP法と異なり、SLOC法はソースコードの行数によって規模を算出する方法です。
難易度や機能ごとに難易度を振らなければならないFP法と比べて、行数を出すだけで規模が算出が可能なため、スピーディーに開発規模を出すことが出来ます。
その反面、難易度に対する工数差が考慮されていないため、分析結果の精度についてはFP法よりも劣ると言えます。
FP法とSLOC法どちらがおすすめ？
私個人的には分析のためだけなら『とりあえずSLOC法からはじめてみる』ことをおすすめします。
理由としては
・FP法は分析までにかかる工数が多い
・ざっくりとした傾向や対策方針はSLOC法でも決めることが出来る
ためです。
分析はあくまで目標に達するまでの障害を洗い出すためのものであり、目的ではないのでいきなりハードルを上げるよりはまず、動き出してみることが大事です。
SLOC法に限界を感じてきた時にFP法を検討してみると良いと思います。
バグ密度のゾーン分析
バグ密度が算出出来たら、それが適した検出数なのかの判断をします。
下記画像はゾーン分析と言って、バグ密度とテスト密度（テストケース数）を元に開発工程とテスト工程の分析をする為の図になります。
基準値を決める
基準値の設定にも大きく2つ方法があります。
・過去のデータを元に中央値、平均値を算出して比較する方法
・他社のデータを参考にする方法
過去のデータを元に中央値、平均値を算出して比較する方法
すでに過去のデータが潤沢にある場合はバグ密度の計算方法を利用して比較することが出来ます。
ですが、基準にすべきデータがない場合や現状を改善する必要がある際には過去のデータを利用しても適切かどうかの判断が付きません。
そこで使えるのが他社のデータを参考にする方法です。
他社のデータを参考にする方法
他社のデータについてはIPAが『ソフトウェア開発分析データ集』にて公開しています。
IPAが公開している結合テスト検出バグ数（原因)の中央値
| 開発種別 | 中央値［件/KSLOC］ |
|---|---|
| 全開発種別 | 1.042 |
| 新規開発 | 1.154 |
| 改良開発 | 0.996 |
となっており、HRBrainではさらに対応策を明確にする為、バグの発生要因（仕様漏れ，実装ミスなど）を加えた3要素でバグ分析を行っています。
バグ密度が示していること
このバグ密度を知った時に私は開発がある以上、一定数のバグは存在する（バグの存在しない開発はない）んだということを認識しました。
バグと言うと=ミス、出てはいけないものというマイナスなイメージをついつい抱いてしまいます。
ですが、開発におけるバグとは一定数検出されるべきものであって、出てはいけないものではないんだと理解するとバグに対するマイナスイメージが取れ、嫌いだったバグ報告も気が楽になりました。
さいごに
この記事を読んで今まさにバグに一喜一憂しているQAエンジニアや若手エンジニアの方にバグに振り回されない一つの考え方として参考になればと思います。