日本のエンタープライズ開発での標準的なテスト工数

今度、10月25日にマイクロフォーカスで講演をさせてもらうにあたり、何を話そうかと考えているのですが、ネタ集めをしようかなと思い、ソフトウェア開発データ白書2016〜2017のデータをいろいろ見てまとめてたので、書いときます。マイクロフォーカスの講演でも使える情報が集まったのかなと思います。（それに、仕事でも使えそう！）

開発プロジェクトの種別

同白書の調査結果によると、新規開発が49.5%と約半分で、それ以外は改修、保守や機能拡張といったもので占められています。感覚的にはもっと新規開発って少ないと思うのですが、それでも約半分ってところなのですね。

テスト工数の比率

同白書では、要件定義と開発5工程（基本設計、詳細設計、制作、結合テスト、総合テスト）と工程を分けています。単体テストは同白書にはでてこないのですが、きっと「制作」の中に含まれているだろうと思います。

要件定義と開発５工程の工数全体の中でのテスト工数（結合テストと総合テスト）が占める割合なのですが、新規開発では28.6％で改良開発では33.2％になります。これはサンプルの中央値の数字ですが、P25の場合は19％と21％、P75で40％と45％になります。同白書は今回業種別（製造業、金融業、通信業といった感じ）にも出していて、一例で金融業界結果を見てみると、中央値で33％と35％、P25で22％と24％、P75で45％と50％でした。金融だとちょっと多めになるみたいです。どちらにしろ、新規開発よりも改良開発のほうがテスト工数がかかるってことが数字からわかります。

また、同白書の2014年〜2015年版は新規と改良の中央値でそれぞれ28.1%と32.1%だったので、だいたいこういう割合はそんな簡単に変わらないのだなということもデータから見て取れます。もっというと、実は何も改善されていなくて、そのため変化しないのかもしれないです。

まぁ、どっちにしろ、開発者自身がコーディングの際に行うレベルの単体テストを抜くと、テスト工数だいたい３割で、テストを効率よくしているところは２割のテスト工数、効率悪いと4割以上テスト工数がかかるって感じです。たかが10％と見くびってはいけません。結構な金額になるはずですから。

テスト期間の比率

テスト期間に関してもだいたい３割の法則が適用できそうで、中央値で見てたときに新規開発が31.3%で、改良開発が33.2%でした。25Pで21%と23.9%、75Pで42%と45.4%でした。

テストケースと工数とバグ

1000FP（ファンクションポイント、FPについてはこのブログがぱっと見でわかりやすかったです）あたりのテスト工数、インシデント数、欠陥数、テストケース数が収集されていたのですが、中央値で見たときの改良開発における、結合テストのテストケース数が3320.6ケース、インシデントが96.9件、テスト工数が951.9時間だそうです。総合テストだとそれぞれが、1224.1ケース 20.9件のインシデント、 682.4時間の工数です。

標準的にどれくらいテストに工数がかかるか？

多分1000FPだと、検索機能、登録機能といった機能が70機能〜130機能くらいのボリュームですが、感覚的には、5人で1日8時間勤務の中で6時間テスト実行して月30時間程度は残業もおこなう、といったイメージでテストを行えばできるかな、と思うので、その前提で見積もってみました、結果は以下のようになります。

期間　
結合テスト　1.5ヶ月、　　総合テスト1ヶ月
日次テストケース消化数 　
結合テスト　20ケース/日、総合テスト10ケース/日
日次インシデント発見数　
結合テスト　3件、　　　　総合テスト　0.9件
テストケース単位検出率（インシデント/テストケース）
結合テスト　2.9%、　　　総合テスト　1.7%
工数単位検出率（インシデント/人日）　
結合テスト　0.61件／人日、　　総合テスト0.18件／人日

私の感覚では、結合テストであればもっと多く、60〜80のテストケースを1日に消化できるのではないかと思うのですが、意外にたくさんできないものだと思いました。総合テストも20ケースは行きたいなぁと。まぁ、エビデンスをとるってことを上手くやるかそうでないか（もしくはやらないとか）では１ケースの実行時間が３〜４倍変わるからそんなものかもしれません。インシデントは１件見つかると2時間〜4時間は平均して余計に工数がかかるので、これだと5人では残業30時間ではすまないかもしれず、6人でやらないと厳しいかもしれないです。それに、このFPあたりの数字はバラツキがすごくてテストケースの標準偏差が結合テストで9,896.3、総合テストで19,718.7と、トンデモナイ数字なので。これはテストケースの粒度の問題で、この問題を感じている人も多いと思います。これは切実だと思っています。全く数字が意味をなさなくなるので。

品質的には超感覚的に言いますが、この標準であればいい部類だと思います。もっと酷いものもたくさんありますし、良いものも当然ありますが。今はあまり語りたくないところです（笑）

あと、ここにはマネジメント工数がきっと全く入っていないので、テストマネジメントをする工数は必ず足しとかないといけないですけど、そういう数字はこの統計にはどうやって出しているんですかね？読み解きが不十分かもしれないです。

現実的なこと

こういう数字があるのは便利なので、IPAには本当に感謝です。ありがとうございます。

ところで、現実的に自分たちの開発で、こういう数字をどれだけ工数をかけずに自然に収集して算出することができるでしょうか？

これがとても大事な話だと思います。テストを効率的にするためにテスト設計を改善する、自動化を推進するということを推進する時も、それがどれだけ効果がでているのかは数字で見せたいところですが、実は数字を見せるためにどうやるかが非常に難しいです。数字に信憑性がないと、その数字をどう分析しても的外れになってしまい使い物になりません。

信憑性を持たせるのに大事なことが２つあります。ひとつが収集元に対して同じ認識をもてることであり、もうひとつが収集したものを同じように全員が見れるようにすることです。

私は幸せなことに、ここ何年も大抵のプロジェクトのテストマネジメントをするのにマイクロフォーカスのALM（旧QualityCenter）を使うことができているため、このツールを使ってやりとげています。実際はコツコツと小さいところからです。セミナーでは、そういう話をしようかなと思います。無料セミナーなので都合のつく方は是非来てください。懇親会では有名なシェフのおいしい料理が食べられるそうです！