上流品質向上のためのテスト
日本で定説化・定型化されている、すべての工程のバグをシステムテストで解決しようとすると、絶対うまくいきません。Capers Jonesという世界的に著名な学者もカオスな状態になると説いていますし、皆さんも体感しているでしょう（図2.1・図2.2）。
なにより製品開発のピークを後半に作ることは（Shift Right）、期日通りに製品を出荷するという意味でもリスクをはらんでいますし、突然最後のフェーズでテスト部隊（たいてい協力会社）が入ってきて、無計画に操作し、バグをたくさん出すというのは健全な製造業として正しい姿ではありません。
工学において機械設計、電気設計もそんな無茶なことはやっていません。たとえば、バイクが設計書通りにできあがっているか否かを、試作のバイクをいきなり乗り回し、「あー、ここ設計通り作られてないですね！」なんていう機械設計製造があったら、あぶなっかしくてしょうがありません。部品一つ一つの信頼性を事前にチェックし、設計書通りにできあがるかを確認していってから、組み立て後のチェックを行います。
しかし、ソフトウェア業界では、下流工程において多量のソフトウェア設計はおろか、簡単なコードも書けない協力会社の人がたくさんやってきて、できあがったものをデタラメに操作し、バグを出すのは日常の光景だったりします。
ほんと日本のソフトウェア開発現場はヤバい。
上流品質活動
まず上流品質を上げるための活動をざっくり見てみましょう。まあイコール本書の目次となるわけですが。
品質向上 = システムテストをちゃんとやる
先に説明したように、あまり成熟しない組織ほど上記のような図式で考えています。本書では、そのような方々のために、上流品質の担保についていくつかの提案をしていきます。
- 要求仕様の明確化
- クラスや関数構造をシンプルに保つ
- 単体・統合テストの実行
- レビューの実施
それらの品質の側面を考慮し素早く実行する！
それだけのことです。それをしっかり実行すれば、出荷間際の休日出勤や、再現できないバグをチーム一丸で苦労して再現させ修正したり、最後の最後で修正したバグがエンバグで再度ビルドしなおして出荷したりなど、いわゆるエンジニアリング作業で嫌なことはかなり減ります。このことを本書で詳しくゆっくり説明していきます。
さぼる・逆らう人のための上流テスト講座
前節を読み、
そうだよねー！、「要求仕様の明確化」「クラスや関数構造をシンプルに保つ」をしなきゃ！
というエンジニアもいると思いますが、
「単体・統合テストの実行」「レビューの実施」、そんなことはわかってるよ、上流でやるのが正しいのは。でも忙しくてできないじゃん！
というエンジニア（逆らうエンジニア）もかなりいます。多くの組織で……。
- マネージメントは上流で品質を担保したいが、部下のエンジニアリング部門が乗り気ではない。すぐ彼らは「忙しい！」と言うので、マネージメントとしてはあきらめかけている。
- エンジニアも上流で品質を改善したいが、忙しくてそれどころではない。
そんなジレンマを多くの組織で抱えているのではないでしょうか？
上流品質と出荷後の品質
忙しいと言って逆らう人々を説得したいので、まず図2.3を見ていただけないでしょうか？
これは独立行政法人情報処理推進機構から出てきた数値で、あきらかに上流で品質を担保したほうが、出荷後の品質は上がると書いてあります。
また、そのゴールとしては上流工程では85%以上のバグを発見できれば、たいていのプロジェクトが大きなスケジュール遅れや、出荷後の致命的なバグの発見はないと筆者は考えます。85%のバグを検出するのは正しいコーディングだけではダメで、要求仕様、さらに設計段階でのバグの検出（正しい設計への熟慮）が必要です。
なにを言わんとしているかというと、いくら後半工程でバグを見つけても、出荷後の不具合が減るかどうかはおのずと限界がある、ということです。ある種の（集合体とも言えるかもしれない）バグというのは、システムテストでは見つからないことが証明されています。表2.1に示すように統合テストで見つかるバグは多くて40%。システムテストで見つかるバグは多くて55%。大規模ベータで60～75%のバグが見つかりますが、大規模ベータなしに（普通の製品は大規模ベータは行わない）、テストだけではかなり広いエリアのバグを見逃します。
上流品質と残バグのリスク
上流でバグをつぶさないと、多くのバグを後半の工程で見つけることになるため、その網の目をくぐり抜けて、出荷後にバグを顧客に見つけられてしまうというリスクがあります。
ソフトウェア工学において、この開発工数と摘出されるバグの関連性は、図2.4のような特性を持つことが多いです。たとえば、Putnamが次のように言っています。
早期のコードインスペクション、レビュー、繰り返し型開発、周期的構築などに重点をおくと欠陥摘出曲線は開発の初期（すなわち左側）に移動する
Lawrence H. Putnam
コーディング工数に比例して、またプログラム量に比例してエラーを作り込み（当然単位行数あたりのバグ混入率はどの組織も同様なので）、最後にレビューやインスペクションを十分に実施することなく、テスト開始し大部分のエラーは統合テストやシステムテストで見つけることになります。ここで怖いのは、次の2点です。
- プロジェクトの後半でバグをつぶすコストは、前半のコストの数倍かかる→効率が悪い=お金がかかる
- プロジェクトの後半でバグをつぶすと、つぶしきれず出荷後のバグになるリスクがある
プロジェクトの後半のシステムテストで多くのバグを見つけると、図2.5のように出荷日以降にバグが出ることがあり、それはラッキーかアンラッキーに依存します。前回うまくいったからって、今回うまくいくとは限りません。
もし単体テストやレビューやインスペクションを十分したらどうなるかというと、図2.6のようになります。
レーリー特性1（図2.4）のグラフの形は、ぱっと見ではこれと変わらないかもしれませんが、実態としてはかなり異なるものです。レーリー特性2（図2.5）の最悪のシナリオが成り立ちません。たとえシステムテストの後半にバグが発見されたとしても、プロジェクト期間内なので、市場バグ発生になりません。Shift leftによる効果です（図2.7）。
さらにバグの修正にかかる工数が開発ステージに依存するのは周知の事実です（図2.8）。
図2.8のKarl Wiegersだけではなく、Capers Jonesも開発ステージが1進むと修正工数が倍になると言っています。単体テストで見つけられるバグが統合テストで見つかればコストは倍になるといったように。
あなたのシステムテストに依存したプロジェクトにレーリー特性を当てはめると、ソフトウェアテスト工学的にも、そして統計学的にも、ある確率で出荷後に確実に致命的なバグが発生します。
まとめ
本章は重要な章なのでまとめを書きます。
理論的に証明されている上流テストをしない = 出荷後のバグが発生する
- 上流テストをしなければ、下流テストをいくらしても大きなリスクを持って出荷することになる
- 上流テストをしなければ、多くのバグを後半でつぶすことになり、出荷日を優先することにより、ある確率でつぶしきれないバグが残る可能性がある
- 同じバグを上流工程でつぶす場合と、下流工程でつぶす場合には下流工程での場合にはコストが数倍になる。プログラムのできないコストの安いテスト担当者をシステムテストフェーズで雇うことのメリットは皆無である。バグ1件あたりの発見・修正コストが高くなる
- 最終段階の致命的バグ、もしくは出荷後のバグによるプロジェクト混乱コストが一番高いのはプロジェクトに関わる全員がわかるはずである
上流でテストしないと、致命的な市場バグが発生し、開発コストが余計かかります。筆者は心理学者ではありませんが、あとにくる痛みを忘れようとするのが人間ではないでしょうか？ 学生の頃なら、まだ試験まで時間があるから、今日はちょっと遊んじゃおうと思って遊んでしまい、試験前に徹夜をするということも。これでうまくすれば乗り切れるかもしれません。しかし、乗り切れる場合もあるけど、乗り切れない場合もあるのです。
出荷後にバグが出るのはわかっているけど、予算もないし、マネージャーも出荷日や機能実装しか考えが及ばず、出荷後のリスク（バグによる売上低下や、市場バグのコスト）について組織全体で目をつぶっていないでしょうか？
そのようなことにならないように、コストを最小限に抑えつつ、市場でのバグを出さないような手法について、本書で説明していきます。
