ホワイトボックスと境界値分析_バグの急所を狙え

こんにちは。さて、今日の探究を始めましょう。 あなたが毎日もう当たり前のように使っているスマホのアプリとかウェブサイト。 予約したり、買い物をしたり、友達と連絡を取ったり。 でももし、ある日オンラインストアで99%オフのセールのつもりだったのが、 プログラムのたった一つの記号の間違いで100%オフになっちゃったとしたら。 それで数分で何百万円もの損失が出た、なんて聞いたらどうでしょう。 そういう大惨事って、実はいつでも起こり得るんですよね。 で、それを防ぐために存在するのが今日のテーマ「ソフトウェアテスト」という 非常に知的で戦略的な世界なんです。手元にあるのはこれ。 IT資格の学習教材なんですけど、ここからプロたちがどうやってデジタルの世界の中の、 まぁ、カオスを防いでいるのか、その思考法を抜き出していきましょう。 今回のミッションはですね、テストに対する二つの全く異なる視点。 中を見るか、外から叩くかを理解して、 そしてバグが潜む一番美味しい場所を狙い撃ちするプロの技、これを盗むことです。 ええ、その大惨事の例、全く大げさじゃないんですよ。 やっぱりそうなんですね。はい。多くの人がテストって聞くと、なんかこう、 ひたすらボタンを押し続けるような、根性試しの作業をイメージするかもしれません。 ああ、分かります。でも実際の現場はもっとスリリングで、限られた 時間とリソースの中で、どこに欠陥が潜んでいる可能性が最も高いかを見抜いて、 そこを的確に突く。なんていうか、まるで探偵のような思考が求められるんです。 ほう。今日お話しする「白い箱」と「黒い箱」というのは、そのための 最も基本的でかつ非常に強力な考え方のフレームワークになりますね。 「白い箱」と「黒い箱」。うーん、なんだか対照的で面白いですね。 では早速、その概念から掘り下げていきましょうか。 このソフトウェアっていう目に見えない複雑なものをテストするのに、 まずどうやってアプローチを分けるんですか？はい。 まずプログラムを作った開発者の視点に立つか、 それともそれを使うユーザーの視点に立つか、という大きな違いがあります。 ああ、なるほど。作り手か、使い手か。ええ。で、後者が ホワイトボックステストです。これはですね、中が透けて見える白い箱を想像してみてください。 白い箱？はい。プログラムのソースコード、つまり内部の設計図を 全部見ることができる状態で行うテストなんです。 設計図を見ながら行う、と。というと、具体的には何を確認するんでしょう？ 目的はですね、設計図通りに全ての部品が正しく接続されて、 全ての論理的な経路がちゃんと機能するか、それを確認することなんです。 論理的な経路ですか？ええ。例えばプログラムには、もしユーザーが 20歳以上ならAの処理、未満ならBの処理といった無数の条件分岐があるじゃないですか。 はい、ありますね。ホワイトボックステストは、そのAの道とBの道の両方を 実際に通ってみて、どちらの道もちゃんと舗装されてて行き止まりになってないかを確かめる作業なんです。 ああ、なるほど。言わば建物の建築家が、壁の中の鉄骨とか配線が 設計図通りに配置されてるかをチェックするようなものですね。作り手だからこそできる内部の健全性の検証です。 なるほど。ユーザーからは見えない部分の品質を保証するわけですね。 でも、その全ての道を通ったってどうやって証明するんですか？ なんか勘で大体OKってわけにはいかないですよね。まさにそこが重要なポイントです。 そのために「カバレッジ」、えーと「網羅率」という指標を使います。 カバレッジ。はい。これは今回のテストでプログラムの全コードのうち 何パーセントを実行しましたかを数値で示すものなんです。 例えば「命令カバレッジ100%」と言えば、全ての命令文を少なくとも1回は実行した ということになります。ほう。道路の地図をこう、塗りつぶしていく作業に似てますね。 この町の道路の95%は走り終わりましたというように、テストの進捗と網羅性を客観的に管理するんです。 そういうことか。感覚ではなくて、データで品質を管理してるんですね。 それはよく分かりました。でもそれってあくまで作り手の話ですよね。ええ。 僕たちユーザーは、中のコードがどうなっていようと、ちゃんと動いてくれれば まあそれでいいわけです。そっち側からのテストはどうなるんですか？ それがもう一方の「ブラックボックステスト」です。ブラックボックス。 はい。これはホワイトボックスとは真逆で、中身が全く見えない黒い箱を相手にします。 ほう、中身が見えない。ええ。内部構造は一切無視。知る必要もありません。 我々が注目するのは、ただ一つ。ある入力（インプット）をしたら、 期待した通りの出力（アウトプット）が返ってくるか。もうそれだけです。 中を見ずに入力と出力だけ。この資料にある自動販売機の例えがすごく秀逸ですよね。 ああ、ありましたね。あなたは100円玉を入れるっていう入力をします。 そしてコーラが出てくるという出力を期待する。この時自販機の内部で どんな複雑なメカが動いてるかなんて全く気にしませんよね。まあ確かに、そうですね。 はい。重要なのは100円でコーラが買えるという約束、つまり仕様が守られているかどうか。 これがブラックボックステストの魂なんです。ユーザーの視点に立って、要求された機能が 正しく実装されているかを確認するテストなんですよ。いやー面白いですね。 ホワイトボックスは作り方の正しさを保証して、でブラックボックスは約束が守られているかを保証する。 視点が本当に180度違う。そうなんです。ということはこの二つは どちらか片方だけやればいいっていうものではないんですね。その通りです。両者は 対立するものではなくて、補完し合う関係ですね。開発者がホワイトボックステストで 内部構造の堅牢性を保証して、でテスターがブラックボックステストでユーザーの期待に応えられているかを 確認する。この両輪が揃って初めてソフトウェアの品質は担保されるんです。なるほど。 そしてここからがこの分野のまた面白いところでして。と言いますと？ ブラックボックステストって一見シンプルですけど、よく考えると途方に暮れませんか？ 途方に暮れる？例えば、あるサイトの年齢入力欄をテストする場合、 1歳、2歳、3歳と無限に試し分けにはいかないですよね。ああ確かに。 どこかの企業の業務システムなら、入力パターンの組み合わせは何億、何兆にもなるかもしれない。 とても全部は試せません。確かに。何をいれたら何がでるかを試すといっても、 その何をいれるかの候補が多すぎますもんね。一体どこから手を付ければいいのか。 そこで登場するのがプロの知恵、「境界値分析」。境界値分析？ ええ。これは闇雲に試すんじゃなくて、バグは境目に存在しているっていう 経験則に基づいて、最も効率的に欠陥を見つけ出すためのテクニックです。 境目ですか？なぜまたそんなところにバグが集まるんでしょう。それはですね、 人間が間違いやすいポイントだからなんです。プログラマーが条件を書くとき、 「より大きい」、つまり「大なり記号」と「以上」、「大なりイコール」を本当によく間違えるんですよ。 ああ、なるほど。キーボードでたった一文字、イコールをつけるかつけないかの違いですけど、 これでシステムの振る舞いは全く変わってしまう。で、こうしたミスは仕様の切れ目、 つまり条件が変わるギリギリのところで表面化しやすいんです。ほう。 資料にある「18歳以上が成人として扱われるシステム」を例にしましょう。このテストで、もし 三つの年齢しか試せないとしたら、あなたなら何歳を試しますか？三つだけですか？ うーん、そうですね。じゃあ子供の代表で10歳、ちょうど境目の18歳、 それと大人の代表で50歳、とかでしょうかね。悪くない選択です。でも、 境界値分析の考え方ではもっと鋭く狙いを定めます。もっと鋭く？ はい。最も重要なのは条件が変わるまさにその瞬間、つまり17歳と18歳です。 ああ。もちろん有効な範囲から外れた値、例えば0歳とかあり得ない200歳 なんかもテスト候補になりますが、最優先は17と18。17歳で未成年と扱われて、 18歳で成人と扱われるか、この一点をピンポイントで確認するだけで「以上」を「より大きい」と 書き間違える典型的なバグを驚くほど高い確率で見つけ出せるんです。うわーなるほど。 これはすごいアハ体験ですね。50歳で成人なのは当たり前だから、そこをテストしてもまああまり意味がない。 そうなんです。でも17歳と18歳で結果がくっきり分かれるかどうかは システムの生死を分けるクリティカルな部分だと。無駄な努力をせず一番怪しい急所を突くんですね。 ええ。これは単なる学問の話ではありません。例えばオンラインの金融サービスで 特定のキャンペーン期間だけ金利が優遇されるとします。もしプログラマーが 期間の最終日の設定を1日間違えたらどうなるか。うわー。最終日に取引 した人だけが損をする、あるいは会社が余計な金利を払うことになる。損失は膨大です。 だからこそテスターはキャンペーンの開始日と終了日、そしてその前後の日を周到にテストするんですよ。 なるほど。資料のもう一つの例も今聞くとより深く理解できます。1から100までの 整数を入力できるシステム。これも闇雲に50とか70とか試すんじゃなくて。 そうです。狙うべきは境界。つまり有効範囲の下限ギリギリの1、これはOKなはずですよね。 はい。そしてそのすぐ外側の0、これはエラーになるはず。で上限ギリギリの100、 これもOKなはず。そしてそのすぐ外側の101、これはエラーになるはず。このたった四つの 値をテストするだけで、この入力欄に関する多くの典型的なバグを発見できるんです。たった四つで。 なんかそんなに少なくて大丈夫なのかと少し不安になりますけどね。例えば プログラムがなぜか「42」っていう数字だけ受け付けないみたいな特殊なバグがあったら見逃しちゃいますよね。 いやー、素晴らしい指摘です。その通り。境界値分析は万能ではありません。 あ、やっぱり。はい。おっしゃるような特定の数字だけを弾くようなバグは 見つけられないかもしれません。しかし、ソフトウェアテストというのは確率との戦いでもあるんです。 確率との戦い？ええ。何十年という歴史の中で、バグの8割はこういう場所に潜んでいる というデータが蓄積されている。境界値分析はその最も確率の高い場所を 最初に叩くための極めて洗練された戦略なんです。全てを試すという理想論ではなくて、 現実的なコストの中で最大の結果を出すためのプロの技、と言えますね。よく分かりました。 完璧を目指すんじゃなくて、リスクが最も高い箇所を効率的に潰していくということですね。 いやー、この話を知っていると普段使っているサービスで何か不具合が起きた時の見方がちょっと 変わりそうです。まさに。例えば年末までは使えていたサービスが年が明けた 1月1日になった瞬間に動かなくなった、なんて経験はありませんか？ありますね。 そういう時ってなんかアクセスが集中してるのかな、くらいにしか思ってませんでしたけど。 それも一因かもしれませんが、もしかしたらそれは「2023年」から「2024年」という 日付の境界をプログラムが正しく処理できずに予期せぬバグが発生したのかもしれないと推測 できるようになるんです。あーなるほど。全てのデジタル機器が作動するのでは、と世界中が 大騒ぎした、あの「2000年問題」も突き詰めれば巨大な境界値の問題でしたからね。 そうか、あれも境界値分析の文脈で捉えられるんですね。そして、この ホワイトボックスとブラックボックスという二つの視点は、開発の現場ではどういう関係性になるんでしょう？ 仲良くやってるんでしょうか。そこがまた人間臭くて面白いところなんですよ。ほう。 時には緊張関係が生まれることもあります。開発者は自分の書いた コードをホワイトボックステストで隅々までチェックして、カバレッジも98%だ、完璧なはずだ と自信を持っている。はい。ところがブラックボックスの視点を持つテスターが ユーザーとして当たり前の操作をしてみたら、5分でシステムが止まるような重大な欠陥を 見つけてしまう。うわー、それは気まずいですね。ええ。開発者からすればそんな 使い方は想定していなかった、となりがちですし、テスターからすれば、いやユーザーは普通にこういう操作を する、となる。はいはい。でもこれはどちらが悪いという話ではないんです。 作り手の論理と使い手の現実、その両方の視点からチェックする仕組みがあるからこそ ソフトウェアは頑健になっていく。その健全な衝突こそが、品質向上のエンジンになって いるわけです。なるほど。単なる技術的な話だけじゃなくて、組織論というか 人間の視点の違いをどう乗り越えるか、という話でもあるんですね。いや、深いな。 それでは今日の探究をまとめてみましょうか。僕たちが毎日使うソフトウェアの品質は 決して偶然ではなくて、知的な戦略によって支えられていました。まずテストには大きく 二つのアプローチがありましたね。一つはプログラムの中身の設計図を見て、 論理的な正しさを検証するホワイトボックステスト。開発者視点の、言わば内部監査でした。 もう一つは中身は見ずに約束が守られているか、つまり仕様書通りに 動くかを確かめるブラックボックステスト。これはユーザー視点の完成品チェックでした。ええ。 そしてそのブラックボックステストを闇雲に行うのではなく、プロはバグの巣を狙い撃ちする。 それが境界値分析という考え方でしたね。はい。「18歳以上」なら17歳と 18歳を、「1から100まで」なら0、1、100、101を試す。 最小の労力で最大のリスクを発見するための非常に賢いテクニックでした。はい。 今日の話で、普段何気なく使っているアプリの安定性の裏には、こうした作り手の 論理と使い手の現実、両方からの緻密なチェック体制があるんだな、と感じてもらえたら嬉しいです。 では最後に、いつものようにあなたが少し考えてみるための問いを投げかけて終わりにしましょう。 お願いします。この「箱」と「境界」の考え方。実はソフトウェア以外にも 応用できます。例えばあなたが新しい料理のレシピを試す場面を想像してみてください。 料理ですか？はい。レシピという設計図通りに材料をきっちり量り、手順通りに混ぜて 指定された温度と時間で焼く。これは内部のプロセスをチェックするホワイトボックステスト と言えますよね。あーなるほど。そして完成した料理を実際に食べてみて。 美味しいか、期待通りの味かと最終結果を確認するのがブラックボックステストです。確かに。 では、この料理の世界における境界値分析とは一体何になるでしょうか？ もしかしたらそれは、この料理が塩辛くて食べられなくなるギリギリの塩の最大量と、 逆に味がしなくなる最小量を探すことかもしれません。ほう。 あるいはオーブンで肉がパサパサになる手前の最長焼き時間と、生焼けになる最短焼き時間、その境界を 見極めることかもしれない。あなたの身の回りの仕事や趣味にも、この境界を探す という視点、応用できる場面があるのではないでしょうか。ぜひ、考えてみてください。