ソフトウェアのテストカバレッジ

どうも、こんにちは。ソフトウェア開発に携わっていると、まあ誰もが一度はぶつかる大きな壁がありますよね。そう、テストです。 で、今日はですね、このテストをいったいどこで終わりとすればいいのか、その大事な指標になるテストカバレッジについて、ちょっと面白い例え話をしながらわかりやすく見ていきたいと思います。 さて、いきなりですけど、一番大事な質問をしますね。テストって、いつ終わったって言えるんでしょうか。もちろん機能がちゃんと動くことを確かめるのは前提なんですけど、 よし、これでま完璧だ。すべてのテストが終わったぞって胸を張って言える瞬間って、いったい、いつなんでしょうね。 実はですね、このちょっと難しい問題を解くための、すごくいい考え方があるんですよ。それがこちら。プログラムという「迷路」でのスタンプラリー。 そう、ソフトウェアのテストって、要はスタンプラリーみたいなものだって考えると、今日の話、めちゃくちゃ分かりやすくなるはずです。 はい、というわけで、ソフトウェア・スタンプラリーですね。じゃあ、このスタンプラリーっていうのが具体的にどういうことなのか、見ていきましょう。 まず、この「迷路」。これは何かというと、プログラムのコードそのものです。で、集めていくスタンプ、これがテストで実行したコードの部分、というわけですね。 そして、このスタンプラリーをどれくらい頑張ったか。その達成度を数字で表したものが、今日のテーマであるテストカバレッジなんです。 つまり、迷路全体のうち、どれだけの範囲を歩き回ってスタンプを集めることができたか。その割合のことなんですね。 さあ、ここからが本番ですよ。3つのカバレッジレベル。そう、スタンプラリーと一口に言っても、実は色々なルールがあるんです。 全部のスタンプを集めなきゃいけない厳しいルールもあれば、まあ、主要なところだけでOKみたいな、ゆるめのルールもある。そんな感じで、どれだけ徹底的にやるか、そのレベルの違いを見ていきましょう。 まずはレベル1、命令網羅、通称C0ですね。これはもうルールはめちゃくちゃシンプルです。 迷路に引かれている道は全部、最低1回は通ってくださいねっていう、ただそれだけ。プログラムで言えば、コードの一行一個を全部、最低1回は実行するっていうことです。 これ、どうでしょう。一見すると、これで十分な感じしませんか？だって、プログラムのコードを全部実行したわけですからね。 もうバグなんてないだろうって思っちゃいますよね。でも実はここにね、結構大きな落とし穴があるんですよ。 ちょっと具体的な例で見てみましょうか。例えば、こんなルールがあったとします。「もし、雨が降っていたら、傘を持って行く」。 まあ、日常生活でも当たり前の、すごくシンプルな条件ですよね。じゃあ、このプログラムをテストしてみましょう。 はい、テストケースです。今日は雨が降っている、と。そうすると、プログラムは「傘を持って行った」。うん、ちゃんと動いてますね。 素晴らしい。これで、このプログラムに書かれているコードは全部実行されたことになりますから、なんと、命令網羅率は100％を達成です。 さて、本当にこれでテスト完了で、いいんでしょうか。 そうなんですよ。ここがミソなんです。「待って、晴れの日にどうなるか一度もテストしてない！」ってことなんですね。 僕らは雨が降った場合はテストしましたけど、雨が降らなかった場合。つまり、晴れの日にプログラムがどう動くかは、全く見てないんです。 もしカンカン照りの晴れの日にまで、傘を持って行っちゃう、なんていうおかしなバグが隠れていても、これじゃ絶対に見つけられないわけです。 で、この問題を解決するのが、次のレベル。レベル2の判定条件網羅。通称C1です。 これはどういうルールかというと、プログラムの中にある全ての分かれ道。つまり「もし〜なら」っていう分岐点で、YESの場合の道と、NOの場合の道、その両方を必ず通りましょうねというルールなんです。 さっきの例で言えば、雨の日のテストだけじゃなくて、晴れの日のテストも、ちゃんとやりましょうってことです。 ここで、ちょっとレベルを比較して整理してみましょうか。まず命令網羅C0は、とにかく全部のコード行を1回は実行する。 で、今やった判定条件網羅C1は、すべての分岐を、TrueとFalseの両方でテストする。 で、表には複数条件網羅っていうのもありますけど、これはさらに厳しくて、条件の組み合わせを全部試す、みたいな感じです。 当然、やればやるほどテストは強力になるんですが、その分ものすごく大変になる。 だから、多くの実際のプロジェクトでは、このC1あたりが品質とコストのバランスが取れた、ちょうどいい目標地点とされることが多いんですね。 さあ、ここで「100％のジレンマ」という話です。カバレッジを上げれば上げるほど品質が良くなるんだったら、もう常に100％を目指せばいいじゃんって普通は思いますよね。 でも、残念ながら世の中そんなに単純じゃないんです。そこにはとても現実的な問題、そう、コストとのトレードオフが待っているんです。 まさにそうなんです。テストのコストっていうのは、カバレッジの目標を上げていくと、もう本当に雪だるま式に増えていくんですよ。 坂道を転がる雪だるまみたいに、最初は小さくても、どんどん、どんどん大きくなって、手が付けられなくなっちゃうんです。 このグラフを見ると、その関係がすごくよくわかりますよね。労力と信頼性の関係です。 左から命令網羅C0、判定条件網羅C1、そして、もっと厳しい「100％複数条件網羅」と並んでいます。 カバレッジのレベルを上げていくと、確かに信頼性は上がっていきます。でも見てください。それ以上に、この「労力」。つまり時間とかお金といったコストが、もう爆発的に増えていっているのが一目瞭然ですよね。 ということはですよ、テストカバレッジっていうのは、ただの技術的な数字じゃないんです。 どこまでのカバレッジを目指すのか、それを決めるっていうことは、プロジェクト全体の成功を左右する、すごく重要な「戦略」なんです。 そうなんです。どのカバレッジレベルを選ぶかっていうのは、まさにプロジェクトマネージャーの腕の見せ所なんですよ。 そのソフトウェアがどれくらい重要で、どんなリスクがあるのか。そして、使える予算と時間はどれくらいか。それらを全部天秤にかけて、 「よし、これは人命に関わるシステムだからコストをかけてでも徹底的にやろう」とか、「こっちの機能はまあおまけみたいなものだからC0で十分だ」とか。 そういう判断を下していく。これこそが賢いプロジェクト管理なんですね。 はい、それでは最後に、今日の重要なポイントをまとめておきましょう。 まず、すべてのコード行を実行するのが、命令網羅C0。そして、すべての分岐のTrueとFalseをテストするのが判定条件網羅C1。 でも100％のカバレッジを目指すのは、多くの場合コストがかかりすぎて現実的じゃない、というジレンマがありましたよね。 だから一番大切なことは何か。それは、プロジェクトのリスクに見合ったカバレッジレベルを「戦略的に」選ぶこと。これが今日の最大のメッセージです。 というわけで、最後に皆さんにこの質問を投げかけて、終わりにしたいと思います。 スタンプラリーの目標は、果たしてすべてのスタンプをコンプリートすることなんでしょうか。 それとも、本当に価値のある、正しいスタンプだけを賢く集めることなんでしょうか。 ソフトウェアテストの面白さ、そして奥深さっていうのは、きっとこの戦略を考えるところにあるんでしょうね。