「ソフトウェアテスト」と「振り込め詐欺」の関係：山浦恒央の“くみこみ”な話（14）

「自分が想像できないバグは摘出できない」――バグの“想像力”とバグの“知識・経験”は、高品質なソフトウェア作りに欠かせない

[山浦恒央 東海大学 大学院 組込み技術研究科 准教授（工学博士），＠IT MONOist]

　前回のコラム「開発するのに30分、テストするのに10万年」では、7つの「基本的な出荷基準」を挙げ、「3．未実行コードがない」について解説しました。今回は、その続き、「4．エラー・ゲシング（Error Guessing）を実施した」を紹介します。

　まずは、7つの基本的な出荷基準について再掲します。

1. 全機能をテストした　
   ブラックボックス／ホワイトボックス・テストで同値分割を実施した。
2. 境界条件をテストした　
   ブラックボックス／ホワイトボックス・テストの境界値分析を実施した。
3. 未実行コードがない　
   ホワイトボックス・テストのC0パス網羅を満足した。
4. エラー・ゲシング（Error Guessing）を実施した　
   バグを想定し、それを摘出するためのテスト項目を設計・実施した。
5. 長時間耐久テスト、過負荷テストを実施した　
   48時間の連続運転や、過負荷状態での稼働テストを実施した。
6. バグの発生が頭打ちになった　
   いわゆる「バグ摘出曲線」がフラットになった。
7. 未修正のバグが残っていない　
   摘出したバグは全件修正した。

　それでは、「4．エラー・ゲシング（Error Guessing）を実施した」について詳しく見ていきましょう。

ソフトウェアのバグは、何に似ているのか？

　ソフトウェア開発と品質の関係、あるいは、品質とバグの関係は、直感で感じるほど単純なものではありません。いわゆる“高品質ソフトウェア”とは、必ずしも、“バグがゼロ”のプログラムではないのです！

　例えば、

• 1万ステップ以上のプログラムをバグなしで作るのは（ほぼ）不可能である。
• バグがあっても、高品質のプログラムはいくらでもある。

は、日ごろ、誰しもが感じていることだと思います。

　では、どうすれば高品質のソフトウェアを開発できるのか？

　この問いに対し、明快な解決策は簡単には出てきません。これは、対象が漠然としていることや、大き過ぎるため、問題の本質を容易には把握できないためです。そのような場合、強力な“解決ツール”となるのが「アナロジー」です。

　アナロジーとは、対象が大き過ぎて複雑な場合や、理解するのが容易ではない場合、現実にある別の単純なモノやモデルに置き換え、そちらを分析することで、本体の課題や問題点を解決する方法です。

犯罪とバグの類似性

　筆者は、ソフトウェア開発における課題や問題点について、取り組みはじめてから30年以上になりますが、いつも感じているのは、「ソフトウェアのバグは、社会の犯罪者に似ている」ということです。

　ちょっと不謹慎な気もしますが、例えば、犯罪者を考えると、以下のような特徴や傾向があります。下記で、「社会」を「ソフトウェア」に、「犯罪者」を「バグ」に置き換えても、ちゃんと成り立ちますし、身近なモデルですので、考えやすくなります。

ある規模以上の社会には、犯罪者がいる

　100ステップ程度のプログラムをバグなしで作ることは可能でしょうが、100KLOCのプログラムでは、不可能でしょう。大規模プログラムの開発では、「バグを減らす」と同時に、「バグはあるもの」との前提で対策する必要があります。

犯罪者がいても、社会は正常に機能する

　高品質プログラムは、バグがあっても、正常に機能します。逆に、バグがあっても、ソフトウェアが正常に機能するよう、リスク管理の考え方を取り入れて（すなわち、重要な機能はしっかりとテストし、重要度の低い機能はテストをある程度割愛する「トリアージュ的」な戦略を導入する）、品質管理を進める必要があります。

駐車違反レベルから、社会全体を破壊する犯罪者までいろいろ

　バグにより、システムに与える影響度は異なります。メッセージの誤字脱字のような軽微なものから、システムを破壊する深刻なバグまで、いろいろあります。システム破壊が“最悪のバグ”と思われがちですが、これより重大なバグがあります。

　それは、「自システムの範囲外まで破壊するバグ」であり、例えば、無関係の他銀行のデータベースを破壊したり、ミサイルが勝手に発射されて人や建物に大きな被害を与えたり、原子力発電所の制御プログラムのバグで周囲の環境が放射能汚染されたりなど、第三者に被害を及ぼすプログラム不良は、何がなんでも避けねばなりません。

犯罪者の検挙だけでは、犯罪を撲滅できない。犯罪防止の教育、犯罪の原因を取り除くなどの予防策が必要

　これは、ソフトウェアの品質管理における“永遠の真実”です。開発時に、まず、バグを作り込まないような工夫をし、その網を潜って入り込んだバグをデバッグやテストで摘出するのが、本当の品質管理です。

　「まずは、作るだけ作って、後でまとめてテストして品質を確保する」という方法では、時間がいくらあっても高品質ソフトウェアはできません。その意味で、「設計ドキュメントの作成を必要最低限に抑え、なるべく速くコーディングし、品質向上はテスト・フェイズで実施する」というアジャイル系の開発方法には、品質の不安を覚えざるを得ません。

犯罪をなくすための「予算」「時間」「人員」は限られている

　前回のコラムで、「開発するのに30分、テストするのに10万年」の話をしました。開発よりも、テストや検証作業にはるかに多くの時間がかかりますが、現実のソフトウェア開発プロジェクトでは、多くても開発時間の半分程度しかテストやデバッグに割けません。この少ない時間で、いかにして重大なバグをたたき出すかが勝負になるのです。

デバッグと犯罪の検挙

　犯罪の場合、テストやデバッグに相当するのが、「取り締まり」や「捜査」でしょう。犯罪者を検挙する場合、犯罪者が集中している可能性の高い場所を集中的にパトロールする必要があります。

　この「目的意識」が非常に重要で、密輸を取り締まる場合、幹線道路から1本中へ入った道路をパトロールしても、駐車違反は大量に捕まえることができるでしょうが、密輸を挙げることはできません。テストやデバッグでも同様で、以下を実施する必要があります。

• どんなバグを検出するのかを明確に認識する。
• そのバグを摘出するには、どうすればよいのかを考える。

　例えば、「境界・限界にはバグが最も多く存在する」と予想し、「境界・限界系のバグを摘出したい」と考え、境界値や限界値を分析して、テスト項目を作成するのが、“テストのあるべき姿”なのです（「バグの王様」が、境界・限界関連の不良なので、「7つの出荷基準」の中に「2．境界条件をテストした」を入れているのです）。

　アメリカのソフトウェア開発技術者は、ランダムにキー入力して、エンターを押す、いわゆる「モンキー・オペレーション」を異常に好みます。実際、デバッグというと、「モンキー・オペレーションしかやらない」というプログラマを何人か知っています。

　この「ランダム・テスト」は、操作が派手で、いかにもバグをたたき出せそうに見えますが、たたき出すバグを絞り込んでいないため、効率の良いテストはできません。警官が、漫然とパトロールしているだけでは、犯罪者を効率よく検挙することは不可能です。

　ソフトウェアのデバッグやテストを効率よく推進するには、以下のステップが必須になります。

（1）開発者は、こんな間違いやエラーを犯す可能性があると想像する。

⇒例えば、「メモリの解放漏れ」を起こす可能性があるなど。

（2）その場合、プログラムに、こんな不都合が起きるはずと想像する。

⇒何時間、何日間も連続稼働させると、メモリを食いつぶしてシステムがダウンするなど。

（3）その不都合を検出するテスト項目を設計する。

⇒長時間稼働させるテスト項目を設計するなど。

想像を超えた犯罪は検挙できない

　「どんなバグを検出するかを明確にする」ということは、裏を返せば、「自分が想像できないバグは摘出できない」ということです。

　犯罪の場合も同様で、「想像を超えた犯罪は、犯罪の被害を受けていることにも気が付かない」ことになります。いまでこそ、「振り込み詐欺」は、一般の認知度が上がって引っ掛かる人も減りましたが、そんな犯罪がまったくなかった20年前だと、被害に遭ったことも認識できない人が多かったと思われます。

　考え付かないバグは摘出できないのですから、いかに「バグの想像力」を駆使するか、どれだけ「バグの知識と経験」を備えているかは、テストやデバッグでは非常に重要です。「ソフトウェアは開発するよりも、テストする方が格段に難しい」といわれる理由の1つがこれです。

　この“バグの想像力”が、「エラー・ゲシング（Error Guessing）」であり、テストやデバッグでは非常に強力な武器になるのです。（次回に続く）

【 筆者紹介 】

山浦 恒央（やまうら つねお）
東海大学 大学院 組込み技術研究科 助教授（工学博士）

1977年、日立ソフトウェアエンジニアリングに入社、2006年より、東海大学情報理工学部ソフトウェア開発工学科助教授、2007年より、同大学大学院組込み技術研究科助教授、現在に至る。

主な著書・訳書は、「Advances in Computers」 （Academic Press社、共著）、「ピープルウエア 第2版」「ソフトウェアテスト技法」「実践的プログラムテスト入門」「デスマーチ 第2版」「ソフトウエア開発プロフェッショナル」（以上、日経BP社、共訳）、「ソフトウエア開発 55の真実と10のウソ」「初めて学ぶソフトウエアメトリクス」（以上、日経BP社、翻訳）。