ホワイトとブラックのバグ捜査術

こんにちは。ザ・ディープダイブへようこそ。いや、ソフトウェアのバグって本当に厄介ですよね。 大事なプレゼンの直前にアプリが落ちたりとか。ああ、ありますね。 オンラインで買い物してたら決済ボタンが反応しないとか、一度は経験があるんじゃないでしょうか。ええ。 こうした目に見える問題の裏側には、開発者の人たちが日々先頭で戦う、もっとこう根深い原因が隠れてたりするんですよね。 そうなんです。で今回はですね、そのバグという犯人を追い詰めるための2つの基本的な捜査手法について、 あなたから頂いた資料をもとに深く掘り下げていきたいなと。はい。テーマはホワイトボックステストとブラックボックステストです。 もしあなたが探偵だとして、事件を解決するために容疑者の家のなかを隅々まで調べるアプローチと。うん、うん。 家の外から出入りする人物とか行動だけを観察するアプローチ、どちらを選びますか？ 実はこの2つの考え方が今日の話のすべてなんですよね。いや、面白い切り口ですね。 まさにソフトウェアの品質保証って、探偵の仕事にすごく似ているんです。へえ。 私たちはその箱と表現されるプログラムに対して、2つの全く異なる視点からアプローチするんです。はい。 1つは箱を開けて、なかの配線図とか歯車の噛み合わせを1つ1つ確認する方法。 で、もう1つは箱は一切開けずに、外から何かを入れたら期待通りのものが出てくるかだけを確認する方法。 なるほど。どちらが良い悪いっていうことではなくて、それぞれが見つけられる犯人像が全く違うんです。 犯人像が違うと。なるほど。ではまずその家のなかを調べるアプローチ、ホワイトボックステストから見ていきましょうか。ええ。 名前通り白い箱。でも資料を読むと、感覚的にはなかを全部見える透明な箱をイメージした方がなんか分かりやすいみたいですね。 あ、おっしゃる通りです。ホワイトボックステストの核心は資料にもある通り、ソースコードという中身をじっくり見て、 全てのルートが正しく動くか確認すること。はい。つまり、プログラムの内部構造が設計者の意図通りに論理的に動いているか、これを検証するわけです。 内部構造ですか。具体的にはどういうことでしょう。例えばですね、プログラムには「もしAならばXを実行し、そうでなければYを実行する」みたいな、 条件分岐。いわゆるIF文がたくさんあるじゃないですか。ええ、ありますね。 ホワイトボックステストでは、ちゃんとAのときにXが実行されたかな？とか、Aじゃないときに、 きちんとYが実行されたかなっていう、まあ電気回路の通り道を1つ1つテスターで確認していくような作業をします。 へえ。あるいは、この処理を10回繰り返すっていうループがあれば、本当に10回で終わるかな？ 11回やったり無限に回り続けたりしないかな？とか、それをコードレベルでチェックしていくんです。 うわあ、かなり地味な作業ですね。となるとこれをやるのは、やっぱりそのコードを書いた本人、つまり開発者ということになるんですか？ はい。 でもそれって自分が書いたものの間違いを自分で見つけるっていうことですよね。ええ、ええ。なん人間どうしても自分の作ったものには甘くなりがちというか、 客観的に見られるものなんですかね。うん、うん。非常に鋭い指摘ですね。まさにその通りで、自己レビューの難しさっていうのは常に課題としてあります。 あ、やっぱり。ただ、それでも開発初期の単体テストと呼ばれる段階では、開発者自身がホワイトボックステストを行うのが、まあ最も効率的なんですよ。 ほう。なぜなら、そのコードの意図とか複雑なロジックを世界で一番理解しているのは書いた本人ですから。確かに。 建物の設計図を書いた建築家が、基礎工事の段階でこの鉄筋の組み方は設計図通りになっているかな？ってチェックするようなものですね。 なるほど。まずは設計図通りに部品が作られているかを作り手自身が保証する。と、そうです。そうです。 確かに、他の人がいきなり複雑な設計図を見ても、何が正しいのか判断難しいですもんね。そうなんです。 ただおっしゃる通り、作り手には思い込みもあります。うん。だからこそ後の工程でまた別の視点からのテストが必要になるわけですが、まあそれはまた後ほど。 はい。このホワイトボックステストの最大の利点は、ロジックの欠陥とか、特定の条件でしか発生しないような隠れたバグを開発の早い段階で発見できることなんです。 ああ。外から見てるだけだと、なぜか時々計算結果がおかしい、としか分からない問題も、 コードを直接追うことで「あ、この変数の初期化が漏れてたんだな」みたいに根本原因にたどり着きやすいんです。 分かりやすいです。ホワイトボックステストは作り手による、いわば構造上の健全性を確かめるための緻密な内部調査なんですね。 ええ。でもこれだけ徹底的に中を調べれば、もうバグなんて残らなそうに思えますけど。 そこがまた面白いところなんです。実はホワイトボックステストでは絶対に見つけられない種類の問題っていうのも存在するんですよ。 え、そうなんですか？となるともう1つのアプローチの出番ですね。はい。 家の外から観察するブラックボックステスト。中身が全く見えない黒い箱。この探偵は一体何をどうやって調べるんでしょう。 ブラックボックステストの探偵は、家のなかには一切立ち入りません。ほう。つまり資料の言葉を借りると、なかみのコードがどう書かれているかは一切気にしない。 一切。ええ、その代わりに家のドアホンを押したら中から返事があるか、とかポストに手紙を入れたら翌日きちんと配達されるかとか、 そういった機能が正しく果たされるかだけを徹底的にチェックします。なるほど。つまり、入力に対して正しい出力が返ってくるかという点にのみ注目するんです。 なるほど。それって私たちユーザーの視点そのものですね。まさに。スマホのアプリ使うとき、 中のプログラムがどんなに美しく書かれていようが、ボタンをタップして期待通りの画面に切り替わらなければ、それはもう使えないアプリですもんね。 まさにそこなんです。このユーザー視点こそがブラックボックステストの最大の強みです。うん。 ほとんどのユーザーは内部構造なんて知りませんし気にしません。自分がやった操作、つまり入力に対して期待通りの結果、出力が得られるか、それが全てなんです。 はい。資料にあった魔法の箱の例えがすごく秀逸でしたよね。あーありましたね。 箱にりんごを入れたらちゃんとジュースになって出てくるか。箱の中で小人が手で絞ってるのか、超ハイテクな機械が動いてるのか、もう知ったことではないと。 なるほど。りんごからジュースっていう機能が約束通りに果たされているかが重要なんです。 その魔法の箱の例え、すごくしっくりきます。でもそうなると、1つ疑問が湧いてきます。その魔法の箱に何を入れればいいんでしょう。 お。りんごは試したとして、みかんは？スイカは？もしかして、石ころを入れたらどうなるんだろって。ええ、ええ。 考えられるもの全部を試すなんて現実的じゃないですよね。ええ、素晴らしい。そこがブラックボックステストの最も難しく、そして奥深いところです。 はい。テストケースをどう選ぶかという問題ですね。すべての可能性を試す全数テストは、ほとんどの場合、時間的にもコスト的にも不可能ですから。 ですよね。だからこそテスト担当者は、ここを試せばバグが見つかりそうだっていう勘所、つまり効果的なテストケースをいかに効率的に設計するかが腕の見せ所になるんです。 うーん。この話は後でもう少し詳しく触れましょうか。あー、ぜひお願いします。楽しみです。では、このブラックボックステストは開発のどの段階で行われるんですか？ ホワイトボックステストが部品をチェックする初期段階でしたよね。はい。こちらは個々の部品のテストが終わって、 それらをすべて組み合わせて、1つのシステムとして動くようになった開発の後半工程で行われます。あー後半なんですね。 ええ。システムテストとか、最終的にユーザーが受け入れるかどうかを判断する受け入れテストなどが主な舞台です。 時計の部品、歯車とか回路のチェックが終わって、実際に時計として組み上げた後で、ちゃんと時間を刻むか、 とかアラームはセットした時間に鳴るか、といった時計としての機能をテストする段階ですね。ということはテストするのは開発者だけじゃないと。 その通りです。専門のテストエンジニアとか品質保証の担当者、場合によってはそのシステムを実際に業務で使うユーザー自身が参加することもあります。へえ。 作り手の視点から一度離れることで、開発者が見落としがちな問題点。例えば「このボタンの位置は直感的じゃないな」とか。 あ、ありますね。エラーメッセージの意味が専門的すぎて理解できないとか、そういった使いやすさ、ユーザビリティに関する問題を発見することにもつながるんです。 なるほど。ここまでで2つの捜査手法の特徴が見えてきました。ホワイトボックスは内部の構造、ブラックボックスは外から見た機能。 はい。ではここで改めて考えてみたいんですが、やっぱりなかみを隅々まで見られるホワイトボックステストの方が、より完璧なテストのように思えてしまいます。 うんうん。なぜわざわざなかみを見ないブラックボックステストも絶対に必要だと言えるんでしょうか。それはですね、 この2つのテストが検証している正しさの種類が、根本的に違うからなんです。正しさの種類。 ええ。先ほど少し触れました、ホワイトボックステストでは見つけられない問題があるというお話と繋がってきます。以前私が関わった、あるECサイトのプロジェクトでの話なんですけど。 お、実例ですね、ぜひ聞かせてください。あるセールのための割引計算プログラムを開発してたんです。そのロジックが非常に複雑で、 会員ランクがゴールド以上で、かつ購入金額が1万円を超え、さらに特定の商品カテゴリーであれば15%割引、みたいな。うわー複雑ですね。 ええ、で、開発チームは徹底的にホワイトボックステストを行って、コードのすべての分岐をテストして、この計算ロジックは完璧だっていうお墨付きを得たんです。 うーん、内部調査は完璧だったわけですね。はい。しかしリリース直前の受け入れテストで、ユーザー役の担当者が実際に操作してみたところ、問題が発覚したんです。 ほう。あれ、なんでパソコン関連商品が割引されないんですか？今回のセールの目玉なのにと。あらら。 調べてみると、なんとプログラムの仕様を決めた段階で、割引対象のカテゴリーにパソコンを入れるのを忘れていたんです。うわあ。 コードは間違った仕様通りに完璧に作られていただけだったと。それはコードをいくら眺めても絶対に見つからない間違いですね。そもそも設計図が違っていた。 まさに。この一件が2つのテストの役割の違いを象徴してるんです。ホワイトボックステストが保証するのはベリフィケーション、検証ですね。 つまり、製品を仕様書通りに正しく作っているかということです。はい。大工さんが設計図通りに柱を立てているかを確認する作業です。 なるほど。一方で、ブラックボックステストが保証するのはバリデーション、妥当性確認。バリデーション。 えー、つまり、そもそもその製品はユーザーが本当に欲しかったものか？正しい製品を作っているかということです。あー、 家の内覧会に来た住人が、日当たりはいいけど、そもそもこの部屋のドアはこっち側じゃないと使いにくいよって指摘するようなものですね。 ベリフィケーションとバリデーション。なるほど。正しく作ることと、正しいものを作ること。似ているようで全く意味が違う。 そうなんです。ホワイトボックステストで計算ロジックは完璧だと証明できても、ブラックボックステストをしないと、そもそも計算対象が間違っているという致命的な問題を見逃してしまう可能性があるわけですね。 その通りです。構造の正しさを保証するホワイトボックスと、機能の正しさ、いやまあ価値の正しさを保証するブラックボックス。 この両輪があって初めて、ユーザーに安心して使ってもらえる価値のあるソフトウェアが生まれるんです。なるほど。 どちらか片方だけでは探偵の捜査が手落ちになってしまうのと全く同じですね。いやー、すごく腑に落ちました。 作り手の視点と使い手の視点、その両方が不可欠なんだと。では、今回の話を最後にまとめてみましょうか。お願いします。 今回の要点は大きく2つ。まずホワイトボックステスト。これはプログラムの内部構造、ソースコードに注目するテストです。はい。 透明な箱の中身を主に開発者が開発初期の段階でチェックして、製品を正しく作っているか、つまりベリフィケーションを保証する。ええ。 もう1つがブラックボックステスト。こちらはプログラムの機能、つまり入力と出力に注目します。そうですね。 魔法の箱をユーザーの視点で、完成後の工程でテストして、正しい製品を作っているか、バリデーションを保証するわけですね。 完璧なまとめです。ありがとうございます。そして、先ほど宿題になっていたブラックボックステストで何を試せばいいのかという問題。 あ、そうでした。これも少しだけ深掘りしましょうか。お願いします。りんごもみかんもスイカも試せない、という話でした。 ええ。例えばウェブサイトの年齢入力欄に1から100までの整数が入力できる機能があったとします。はい。 これをテストするために1、2、3、てんてんてん100まで全部入力するのは明らかに非効率です。うん、そうですよね。 そこでテスト設計のテクニックが登場します。その代表格が、資料の最後にもちょっとありましたけど、境界値分析という考え方です。 境界値分析。名前からして何かの境界が重要になりそうですね。その通り。プログラムのバグは、なぜか仕様の境界。 つまり端っこで発生することが非常に多いんですよ。へえー。例えば100までオッケー、という仕様なら、100とか101を試したり、 1以上オッケーなら1や0を試したりする。あーなるほど。有効な範囲のど真ん中の数字。例えば50とかを試すよりも、 境界ギリギリの値を狙い撃ちする方が、バグという犯人に出会える確率が格段に高まるんです。へえー面白い。 闇雲に試すんじゃなくて、犯人が潜んでいそうな怪しい場所を重点的に捜査するわけですね。そうなんです。まさに探偵の勘所だ。 この考え方を知っているだけでテストの効率と質は劇的に向上します。ではそのヒントを踏まえて、最後にリスナーのあなたに思考を促す問いで締めくくりたいと思います。 もしあなたがあるシステムの年齢入力欄をテストする担当者になったとします。はい。仕様は18歳から65歳までが有効な入力、と決められています。 はい。限られた時間のなかで、最も効率的にバグを発見するために、あなたなら5つだけ数字を選ぶとしたら、何と何を選びますか？ そしてその数字たちを選んだ理由は何でしょう。良い問いですね。有効な値、無効な値、そして境界をどう攻めるか。 そこにテスト設計の面白さが詰まっています。ただランダムに選ぶのではなくて、その5つの数字にどんな意図を込めるか、ですね。 この問いについて考えてみること、そして自分なりの最強の5つの数字、その理由を組み立ててみることが、 今日お話ししたような、より高度で効率的なテストの世界への素晴らしい第一歩になるはずです。ぜひあなただけの捜査方針を立ててみてください。 今日の深掘りはここまでです。ありがとうございました。ありがとうございました。