バグ数

f:id:kate-san:20210408222652p:plain

組込みソフトウェア開発における品質向上の勧め[バグ管理手法編]

 https://www.ipa.go.jp/files/000027629.pdf

 

f:id:kate-san:20210408222740p:plain

ソフトウェア品質データ分析を通じた組織的改善の促進

https://www.ipa.go.jp/files/000036714.pdf

 

f:id:kate-san:20210408223637p:plain

「ソフトウェア開発データ白書」シリーズに関するよくある質問と回答

https://www.ipa.go.jp/sec/qa/whitepaper.html#chap06

 

 

バグ数の数え方は、IPAばかりに資料がありました。

 

 

テストをしていて、エラーが発生すると、一応周りに聞いてみて、新規っぽい(=いままでとは違う現象など)とバグ票を起票します。

 

基本的には、「バグと思われる現象」をバグ票に記載することになります。

 

「バグと思われる現象」を調べて、原因がわかると、その原因である設計書やソースを修正します。設計書やソースは複数にまたがることがあります。原因が複数であることもあります。原因が別の事象を発生させることもあります。

 

それぞれ、バグを、何個とカウントしますか?

 

例① 原因が複数ある場合

ユーザIDとパスワードを入れて、ログインしようとしたら、エラーと表示された(現象)

テーブル上のパスワードは暗号化しているが、入力されたパスワードを平文で照合していた。(原因)

ログインボタンに別の処理が紐づいていた。(原因)

 

例② 原因が別の現象を発生させる場合

テーブル上のパスワードは暗号化しているが、入力されたパスワードを平文で照合していた。(原因)

 ↓

ユーザIDとパスワードを入れて、ログインしようとしたら、エラーと表示された(現象)

パスワード照会画面で、入力したらエラーと表示された。(現象)

 

 

原因に注目すると

例① バグ数2個

例② バグ数1個

 

現象(=バグ票の数)に注目すると

例① バグ数1個

例② バグ数2個

 

原因に注目する方が良いっぽい。なぜなら、現象はテスト量に比例して増えていく気がするから。原因は、増えることはない。

 

「ログインボタンに別の処理が紐づいていた。(原因)」という原因を、深堀してみると、A社が作成したAPIに、B社が作成した画面からパラメータを渡しているようだが、A社のAPI自体に問題があるし、B社が渡したパラメータにも間違いがあった。原因は2になる。

さらに、A社のAPIは、田中さんと鈴木さんが開発しており、それぞれの部分で、全く違うような問題があった。A社のバグは、2つに増える。

 

原因で、バグ数を数えると、原因の粒度により、バグ数が変わる。

 

原因の粒度の定義を作るのは難しいし、定義を作ったとしてもその人の感覚に依存することが多い気がする。

 

そうなると、もはや難しいことは考えず、バグ票の中で、明らかに誰が見ても同じ現象や同じ原因のみ重複排除して、バグ票の数=バグ数として、取り扱うことが良いと思います。