JSTQB試験の3値BVAに惑わされるな！

DaoCuong
5月23日
読了時間: 8分

もしあなたがテスターであるか、あるいはソフトウェアテスト業界に興味を持っている方なら、JSTQB試験について一度は聞いたことがあるでしょう？

でも、ちょっと言わせてください。JSTQBの試験に騙されないでくださいね。

この試験は難しくはありませんが、「正しい選択肢を選んだと思った？残念、0点です！」という独特な精神で有名なんです。

そしてその精神のせいで、再受験するためにもう一度200ドル払うハメになるかもしれませんよ...。

この試験は受験者をどのように惑わせるのでしょうか？

ある疲れた日のこと、上司から一つの資料ファイルをポンっと渡されて、こう言われました。「この要件に対して、3値の境界値分析（3-value BVA）でテストケースを作っておいてね。」

私は「はいはい〜」と返事しつつ、重い足取りでファイルを開きました。あのクルクル回るローディングアイコンが頭痛をさらに悪化させるのです…。

ファイルの中身はというと、特に目新しいものではなく、誰かがほぼ完成させたテスト観点表が1枚。ただ、最後の一部だけが未記入のまま残されていました。

その未記入部分の内容というのが、ざっくり言うとこんな感じ：「18歳以上のユーザーにはチケット販売ページを表示し、子供たちは購入できません！」

どういう意味かって？つまりこういうことです：アカウント情報に年齢が18歳以上と記載されていれば、システムは購入ページに進ませてくれる。逆に、17歳以下であれば、システムは真っ赤な文字で『あなたは年齢が足りません！』と返してくる、というわけです。

上司は「3値の境界値分析（3-value BVA）でチェックしてね」と指示してきたわけで、それを表にまとめると、まあこんな感じになります：

No.	入力値	期待結果
1	17	「年齢が足りません」
2	18	「チケット購入ページへ」
3	19	「チケット購入ページへ」

簡単でしょ？

私はこの表を1分30秒でさくっと作成して、そのまま上司に送信、PCをシャットダウンして疲れた体をベッドに投げ出しました。

「よし、明日の朝は『早くて優秀だな！』って褒められるかも…」そう思っていた私がバカでした。

朝になって返ってきたのはまさかのダメ出し。 上司はこうコメントしてきたのです：

「入力値16が抜けてるよ。」

……は？ 「なんで16？ 3値の境界値テストって言ってたじゃん？」 頭の中で私はつぶやきました。

「もしかして、あの人の『3値』って 16・17・18 のことだったのか……？」 と、自分でも混乱する始末。

でも、上司のコメントには「16が抜けている」とは書いてあったけど、「19は余計だよ」とは一言も書いてなかったんですよね。

……そこで私はふと思いました。 「これ、もしかして自分の読解力に問題があるのか？」 いや、上司の方かも？ とも思いつつ。

なんだかモヤモヤしてきて、「これはおかしいぞ」と違和感を覚えた私は、すぐさまChatGPTに相談してみました。

すると、返ってきた答えは

つまり、私の考え方は間違ってなかったんです！

悪いのは、どう考えても上司の方！！（断言） もうこうなると、修正する気力なんて湧きませんよ。完全に萎えました。

「もういいや。あとは上司が来てから直接バトるしかないな…」

そんな感じで、私はモニターの前で腕を組みながら、静かに「戦闘モード」に入ったのでした。

ここまで読んで「あるある…」と思った方も多いのではないでしょうか。

実はこの話、現実でもよくあるシチュエーションなんです。確かに、「3値の境界値分析（3-value BVA）」では「境界値」「境界値－1」「境界値＋1」の3つの値を使うのが基本です。

でも、今回のケースで間違っていたのは、「18歳」という年齢が条件に書かれている＝それが唯一の境界値だと思い込んでしまったことなんです。

以下の図を見れば、より分かりやすいでしょう：

要求を2つの領域に分けられる：

🟢 購入可能パーティション（18歳以上）
🔴 購入不可パーティション（17歳以下）

それぞれのパーティションには独立した境界値があります。（もちろん、年齢がマイナスだったり、0歳だったり、999歳だったり、∞歳だったり…っていう極端な例もあるかもしれませんが、今回は無視します。フォーカスすべきは中心の範囲です）

つまり：

要求仕様に「18歳から」と書いてあっても、実際には17歳（未満パーティションの上限）と18歳（購入パーティションの下限）という2つの境界があるんです。

境界値が17と18、2つあることが分かったので、ここで基本の公式「境界値、境界値－1、境界値＋1」を使って考えると：

3値のBVAはこうなります：

17のBVA → 16, 17, 18
18のBVA → 17, 18, 19

この(1)と(2)を組み合わせると、今回のテスト入力に使うべき値は：

16, 17, 18, 19

となるわけです。

ちなみに、この内容はJSTQB CTFL 4.0のシラバス、4.2.2節「境界値分析」でも触れられています：https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J02.pdf

ただし、この資料でも3値BVAの具体的な使い方や、分かりやすい例はあまり載っていません。なので、読んでみたけど「イマイチ腑に落ちないな…」という人（はい、私です）も多いはずです。

先ほどのストーリーに戻ると、あの登場人物は「18」が境界値だとだけ思い込んで、(2)の「17, 18, 19」だけを選んでテスト表に書きました。

だからこそ、上司に「16が抜けてる」とコメントされても、「16ってどこから来たんだよ！？」と分からなかったのです。

これ、試験でも同じことが起こり得ます。「3値BVAだから、とりあえず境界の値を中心に3つ…」と機械的にやってしまい、 「境界が1つとは限らない」ということを理解していないと簡単に間違った選択肢を選んでしまいます。

しかも、選んだ後に「えっ、なんでこれ間違いなの？？」と、自分でも理由が分からない。そう、それがJSTQBの「トリッキーな罠」なのです。

ここで少し話を広げて、「なぜ今回の要件では18歳以上と書かれているのに、17という境界値も必要なのか？」という点について掘り下げてみましょう。

引用：JSTQB - 1.2.3 エラー、欠陥、故障、および根本原因より：

「人間は、時間的なプレッシャー、作業成果物、プロセス、インフラ、相互作用の複雑度、あるいは単に疲れていたり、十分なトレーニングを受けていなかったりなど、さまざまな理由でエラーを起こす。」

ここで「プログラミング」の観点から考えてみましょう。

プログラミング言語における代表的な比較演算子は次の通りです：

> 大きい
< 小さい
>= 以上（大きいか等しい）
<= 以下（小さいか等しい）
== 等しい
!= 等しくない（≠）

今回の要件「18歳以上ならチケットを購入できる」をコードで表現すると、プログラマーは次の2通りの書き方のどちらかを選ぶことになります：

方法①：

if (age >= 18) {

allowBuyTicket();

} else {

printUnderageMessage();

}

※ 「年齢が18以上なら、チケット購入を許可。そうでなければ、“年齢が足りません”と表示」

方法②：

if (age > 17) {

allowBuyTicket();

} else {

printUnderageMessage();

}

※ 「年齢が17より大きければ、チケット購入を許可。そうでなければ、“年齢が足りません”と表示」

さて、プログラマーはどちらを選ぶでしょうか？

実際のところ、どちらの方法でもプログラム的には正しく動きます。

でも私たちはテスターです。テスターはソースコードを読むことができませんし、開発者がどちらの方法（>=18 か >17）を使ったのか知ることもできません。だからこそ、17と18の両方の境界値をテストしなければならないのです。

ここで、もし開発者が方法②（age > 17）を使ったとして、 しかも前日の飲み会で酔っ払っていた結果、うっかり「>」（より大きい）と「 !=」（等しくない）を間違えて、次のように書いてしまったら……？

if (age != 17) {

allowBuyTicket();

} else {

printUnderageMessage();

}

※「年齢が17じゃなければチケット購入OK。17歳だけは“年齢が足りません”と表示」

コメント：プログラマーがどれほど酔っていたのか分からないけど、[>] を [!=] と書き間違えるなんて、本当に不思議だ。でもまあ、人間だもの、誰だってミスをすることはあるよね。

つまり、17以外ならすべて通ってしまうというとんでもない欠陥の完成です。

さて、ストーリーの主人公のように、テスト値を 17, 18, 19 の3つに絞ってテストを行った場合、テスト表はこうなります：

No.	入力値	期待結果	実際結果
1	17	「年齢が足りません」	「年齢が足りません」
2	18	「チケット購入ページへ」	「チケット購入ページへ」
3	19	「チケット購入ページへ」	「チケット購入ページへ」

見た目は完璧です。

期待される動作と、実際の結果がすべて一致しているように見えます。

なので、

「よし、この機能は問題なし！」

と結論づけてしまう… これが大きな間違いです。

このように、境界値17を基準にした3値BVA（16, 17, 18）を使うことで、さきほどの欠陥にもしっかり対応できるというわけです。

ここで値「16」が登場します。本来であれば16歳は当然「購入不可」なはずですが、例の欠陥によって16歳でもチケットが買えてしまうという恐ろしい事態に。

以下のテスト結果をご覧ください：

No.	入力値	期待結果	実際結果
1	16	「年齢が足りません」	「チケット購入ページへ」
2	17	「年齢が足りません」	「年齢が足りません」
3	18	「チケット購入ページへ」	「チケット購入ページへ」
4	19	「チケット購入ページへ」	「チケット購入ページへ」

はい、値16が欠陥を見つけてくれました！これがまさに、3値BVAの真価というものです。

ここまで読んでいただいた方は、もうお分かりですよね？

3値BVAの考え方だけでなく、「どこが本当の境界なのか」を正しく見極める力
現場やJSTQB試験で“よくある落とし穴”をどう回避するか

が、実践的に理解できたのではないでしょうか。

結論：

JSTQBの試験対策資料がバージョン4.0に更新されてから、さまざまな変更がありました。その中でも、Boundary Value Analysis（境界値分析）の部分は、シラバスの改定に伴い、大きく変更された箇所の一つです。

参考までに過去のバージョンでの「同値分割」や「境界値分析」で説明した内容を紹介します。(JSTQB FL v3.1)

私個人としては、こちらの技術でも、先ほどのストーリーに登場したケースに対応できることに変わりはないと考えています（参考リンク）。

新しい知識を学ぶことや、古い知識を適用することは確かに頭を悩ませることですよね。ですが、どちらの方法でも、重要なのはテスト手法や技術をしっかり理解することだと思います。 正しく理解することで、資料をより正確に分析でき、製品の品質向上にもつながり、その結果として、テスト分野における自信と能力向上に繋がるのではないでしょうか。