30号：「バグゼロ」の落とし穴

≣概要

FLシラバスの「テストの7原則」の7個目（ラスト）です。前回の原則6は、「テストは状況次第」でした。利用者のコンテクスト、開発プロセスのコンテクスト等々、「状況によってテスト内容や実行方法は変わる」という原則でした。

さて、今回の原則7の『「バグゼロ」の落とし穴』ですが、「テストって何だろう？」と改めて考えさせられる原則です。最後にこれを持ってきたISTQBのエディタのセンスを感じます。
みなさんは、テストを始めたころに「バグを見つけて！」と言われたことがあるのではないでしょうか？　それはJSTQBのシラバスにある「テストの目的」のひとつの「故障や欠陥を発見する」ことそのものであり、最も重要なテストの目的と言えるでしょう。
また、「故障や欠陥を発見する」ことの上位目的は、プロダクトのQCDを上げるため（言い方を変えれば、リスクをさげるため）です。見つけたバグが修正されればテスト対象物の品質（Q）は上がります。Qが上がれば、CもDも良くなります。（QとC、QとDは短期的視点ではトレードオフに見えがちです。しかし、品質が高ければ運用や保守にかかる費用は減りますし、レビューなどの静的テストによって品質の高い仕様書を作れば、その後の問題は減り、納期短縮に結びつきます。）

ところで、「バグゼロ」になれば、全てハッピーなのでしょうか？　「そこに落とし穴があるかもよ！？」というのが、この原則です。

≣ シラバスの記載

『ISTQBテスト技術者資格制度　Foundation Level シラバス 日本語版 Version 2018.J03』の該当部分を引用します。

7.「バグゼロ」の落とし穴

テスト担当者は可能なテストすべてを実行でき、可能性のある欠陥すべてを検出できると期待する組織があるが、原則2と原則1により、これは不可能である。また、大量の欠陥を検出して修正するだけでシステムを正しく構築できると期待することも誤った思い込みである。例えば、指定された要件すべてを徹底的にテストし、検出した欠陥すべてを修正しても、使いにくいシステム、ユーザーのニーズや期待を満たさないシステム、またはその他の競合システムに比べて劣るシステムが構築されることがある。

≣ 解説（全体）

英語の文章には珍しく、段落の後半「検出した欠陥すべてを修正しても、使いにくいシステム、ユーザーのニーズや期待を満たさないシステム、またはその他の競合システムに比べて劣るシステムが構築されることがある」に主張が書いてあります。
言い換えると、「たとえ、バグゼロを実現できたとしてもユーザーのニーズを満たさないなら、それって意味なくないですか？」ということです。

はい、意味ないですね。

≣ 解説（詳細）

ここからは、FLシラバスの解説をもう少し分解して細かく読み解いていきたいと思います。
まずは、FLシラバスの解説を再掲します。

テスト担当者は可能なテストすべてを実行でき、可能性のある欠陥すべてを検出できると期待する組織があるが、原則2と原則1により、これは不可能である。また、大量の欠陥を検出して修正するだけでシステムを正しく構築できると期待することも誤った思い込みである。例えば、指定された要件すべてを徹底的にテストし、検出した欠陥すべてを修正しても、使いにくいシステム、ユーザーのニーズや期待を満たさないシステム、またはその他の競合システムに比べて劣るシステムが構築されることがある。

■　テストをすべて実行でき、欠陥をすべてを検出できると期待されても、これは不可能

原則２の「全数テストは不可能」から、「テストをすべて実行でき」部分が誤っていることがわかります。ここから「バグゼロ」（ここでは、“欠陥が一つも存在しないソフトウェア”の意味）なんてそもそもあり得ない（少なくとも証明は不可能）ということが分かります。

ところが昔は、、、昔といっても1960年代のことですが、、、著名なソフトウェア品質コンサルタントでさえ、「Zero Defect」（欠陥ゼロは実現可能だから、最初からエラーのない仕事をせよ）なんて言って、「ZD運動」という名前まで付けていました。Crosbyという人なんですが。

Crosbyの業績全てについて否定しているわけではありません。『品質コスト』をはじめ、素晴らしい業績を上げた品質コンサルタントです。説明が分かりやすい点も好きです。
ただ「ハードウェアでの経験を、そのままソフトウェアの世界に当てはめてしまった」か？　と思う活動もあり、それらについては残念だなぁと思っています。

■　大量の欠陥を検出して修正するだけでシステムを正しく構築できると期待することも誤った思い込み

一番身近なのはテストの最終日に見つけた軽微なバグを修正するかどうかでしょう。「バグゼロ」が目的であれば直すべきですが、直す行為に新たなバグ（リグレッション）を作ってしまうリスクがあります。
短時間かつプレッシャーが高いときにデバッグすると、簡単な修正ですらロクなことが起こりませんよね。

デバッグして欠陥が修正されたことを確認する「確認テスト」がPassしても、それ以外の箇所に影響がないことを確認する「リグレッションテスト」がPassするかわかりません。
さらにリグレッションテストがPassしたとしても、完璧なテストを作ることができないように、完璧なリグレッションテストはありえません。したがって、欠陥の修正には、必ずリグレッション（欠陥修正の副作用）が発生するリスクをともないます。

バグの修正だけではありません。昔々のこと、リリースの直前になって、ソースコードのコメントをきれいにしたくなった開発者がいました。
そして、その人は、不要なコメントを削除しているときに、うっかりとプログラムの一部も削除してしまいました。で、それは重篤な不具合の原因となり大騒ぎとなりました。
「なんで動いているコードを編集するんだ」と叱る人もいましたが、私は、コメント文をきれいにしたこと自体は悪くないと思っています。リリース直前に直したくなる気持ちも、とても分かります。リリース後は別の人に引き継ぎますから。
ですからこの件で悪かったのは、リグレッションテストの自動化が不十分だったことです。「バグゼロの落とし穴」とは違う話ですが。

≣ まとめ

『「バグゼロ」の落とし穴』という原則を考えるときに、私たちは「品質」や「品質を実現するプロセスや人間」について考えることになります。
私は、ツイッターに、

それでは、テストとは何かと言えば、
『“どんな人間でも間違えてしまうことがある”ことを事実として認め、そのことを前提とした上で、“開発成果物が利用者に与える価値の最大化”と“開発成果物を作るコストの最少化”という２つの狙いを良いバランスで達成するための活動』
と思っています。

— あきやま🍧 (@akiyama924) November 22, 2018

を固定して、たまに読み返すようにしています。落とし穴にはまらないようにするためです。