1. B-Testing.fm
  2. #27 自然言語に境界値分析を適..
#27 自然言語に境界値分析を適用する:仕様の曖昧さをあぶり出す技術
2026-05-04 11:31

#27 自然言語に境界値分析を適用する:仕様の曖昧さをあぶり出す技術

前回の「境界値分析(BVA)」の基本に続き、今回は一歩踏み込んで「数値ではないデータ」や「自然言語(日本語)」にこの技法をどう適用するかを深掘りします。

「〜まで」「〜から」といった日常的な言葉に潜む曖昧さが、いかにして不具合の種になるのか。テスト技法を単なる「確認作業」としてではなく、仕様の不備を見つける「議論のツール」として活用するための考え方をお届けします。


📌 今回のエピソードのポイント

  • 数値でなくても「順序付け」ができれば境界値分析は活用できる
  • からまで」の「ちょうど」は稼働時間か、休止時間か?
  • 同じ「新横浜駅まで」でも、文脈によって意味が変わる日本語の怖さと面白さ
  • テスト設計技法を使って、開発の早い段階で仕様の曖昧さを指摘するメリット
  • 【質問コーナー】開発者がテストを行う際に、絶対に落としてはいけない「テストの意図」



📕 参考文献



🕒 チャプター

  • () オープニング

  • () 境界値分析(BVA)の定義を再確認する

  • () 自然言語(数値以外)への適用例:背の順で並ぶクラス

  • () 「以上・以下」「から・まで」に潜む境界の曖昧さ

  • () 東海道新幹線の例で考える、文脈による境界値の変化

  • () テスト技法を「仕様の曖昧さを指摘する」ために使う

  • () 質問コーナー:開発者がテストの一部を担う際に気をつけること

  • () エンディング


📢 あなたのご意見をお聞かせください

皆さんは、仕様書の「〜まで」という表現に悩まされた経験はありませんか?あるいは、数値以外の項目にテスト技法を当てはめてみた事例などがあれば、ぜひ教えてください。

感想

まだ感想はありません。最初の1件を書きましょう!

サマリー

このエピソードでは、境界値分析(BVA)を数値データだけでなく自然言語にも適用する方法を探求します。順序付け可能なものであれば、たとえそれが「背の順」のようなものであってもBVAが活用できることを示します。「〜から」「〜まで」といった日常的な表現に見られる曖昧さが、いかにして不具合の原因となりうるかを、新幹線の例などを交えて解説します。テスト技法を単なる確認作業ではなく、仕様の曖昧さを指摘し、より良いプロダクト開発につなげるための議論のツールとして活用する重要性を強調しています。

オープニングと境界値分析の再確認
皆さんこんにちは、B-Testing のブロッコリーです。この B-Testing.fm は、QA
エンジニアである私 ブロッコリー が、テストや品質に対する私なり
の考えを約10分間で語っていく ポッドキャスト番組です。ここまで
聞いていただいている皆さんは 分かるかと思うんですけれども、
今回、この B-Testing.fm を始める にあたって、収録用に毎回スライド
を作っているんですね。このスライド を作るっていうのが結構自分の中での
考え方の整理につながっている かなと思っています。特に今回の
内容っていうのは、QA エンジニア を始めた当初は意識していなかった
ところなんですね。境界値分析 の続きがあたるんですけれども、
このスライドを作ることで、自分が 最初は意識していなかったところ
だからこそ、ちゃんときちんと 伝えていきたいなと考えている
結構思い入れのある内容の回になっています。 ということで、今日は前回の続きですね、
境界値分析のさらに奥深いところ について語っていきたいと思います。
ということで、今回も B-Testing.fm スタートです。ということで、
今回は境界値分析の続きですね。 自然言語に境界値分析を適用する
というお話をしていきます。 まず境界値分析とは何かっていう
のを改めて定義というか、JSTCB のアドバンスドレベルテストアナリスト
のシラバスを引用して紹介します と。境界値分析っていうのは順序
づけられた同値パーティション の境界上に存在する値を適切に
処理することをテストするために 使用数と書かれていますと。ポイント
は前回も言ったので省略します が、今回は特にポイントとなる
のは順序づけられたという部分 にまずはなります。これって実は
自然言語への境界値分析の適用:順序付けの重要性
自然言語でも境界値分析を使うことが できますよと。そのときにポイント
は順序づけというところで、例えば いきなり20人いて、じゃあこの20人
の境界値を考えていても、20人を どう境界値で考えるのっていう
ふうになると思います。ここのとき 重要なのが順序、順序づけという
話ですね。例えば20人のクラスが いて、それを背の順に並べたときに
前から10人目までは組体操で上に 上る人、11人目以降は下で土台になる
人みたいにそういうふうに分け ますよっていうことができると思います。
今回の場合ですと背の順っていう ふうに何らかのルールで順序づけ
ができれば、これは実際にその値 が数値ではなくても境界値分析
っていうのが適用可能になってくる 例だと思います。こういうふうに
曖昧な境界表現:「以上・以下」「から・まで」の例
自然言語でも境界値分析を使うことが できます。この自然言語っていう
のが厄介でして、境界が曖昧になり がちです。特に以上とか以下とか
からとかまでとかっていう単語 に注目をしてほしいです。一つ例
として稼働時間は8時から22時まで で休止時間が22時から8時までです
っていうようなサービスがあった とします。このときにポイント
として8時ちょうどとか、もしくは 22時ちょうどっていうのは稼働時間
なんですかね。それとも休止時間 なんですかね。曖昧ですよねっていう
のが出てきます。他にもう一つ例 を紹介します。例えば東海道新幹線
文脈による境界値の変化:新幹線の例
で名古屋駅から新横浜駅まで乗車 したっていう言葉があったとします
と。この文章で東海道新幹線で乗車 していた駅はどこからどこまで
ですかっていうと名古屋駅から 新横浜駅っていうふうになります
よねと。なので境界地っていうのは 岐阜羽島と名古屋っていうのが
境界ですし、新横浜と品川っていう のが境界地になりますと。このとき
新横浜駅まで乗車したって言った ときの新横浜駅までっていう言葉
は新横浜駅を含みますよね。これを ぜひ覚えておいてほしいんですけ
れどもその上でもう一つ例同じ 東海道新幹線の例を持ってきます。
今度は東海道新幹線の望みは名古屋 駅を出ると新横浜駅まで停車しません
って言ったときを考えます。この ときに望みが止まらない駅って
どこなんですかっていうと三河安城 から三河安城豊橋浜松垣川静岡
新富士三島熱海小田原ですよね。 境界地は名古屋と三河安城そして
小田原と新横浜になります。この とき新横浜駅まで停車しません
って言っていますがこのときの 新横浜駅までっていうのは新横浜
駅自身含みませんよね。先ほども 新横浜駅まで乗ったって言った
場合は新横浜駅を含んだ一方で 新横浜駅まで停車しませんって
言った場合は新横浜駅に含まない わけですよね。同じ新横浜駅まで
という文章ここ一部を切り取った ところで言うと文章なんですが
どこどこまでって言っているとき に含む場合もあれば含まない場合
もある。これ日本語の前後でどういう ふうに表現しているかによって
変わったりしているわけですよね。 っていうふうに自然言語っていう
テスト技法を仕様の曖昧さ指摘に活用する
のは数式で書く以上に境界が曖昧 になりやすいです。なので自然言語
の適用を自然言語にも境界地面積 っていうのを適用することでこれ
仕様の曖昧さの指摘につながる ことができます。結構テストコード
でどういう値を取るかっていう ので境界地面積とかをやりがち
なんですがそれはぜひやってほしいん ですがそれだけじゃなくて仕様の
曖昧さの指摘にもつながるので 仕様書であったりとか設計のドキュメント
とかのレビューのときにこれ境界 ってどこなんですかねっていう
のをぜひ議論することが大事かな と思います。なのでテスト設計
技法として動地分割 境界地面積 今回は境界地面積を紹介しました
今後も他のテスト設計技法も紹介 していきますがこれらって別に
コードだけではなくて仕様書とか 設計のドキュメントにおいても
使えるのでぜひそういうところ でもテスト設計技法っていうの
を活用してかつここって違うじゃない ですかっていう指摘だけじゃなくて
ここって例えば境界地で考えたら ちょっと曖昧だなと思ったんですけど
ここってどう含むんですかねみたいな 議論をしてそれをすることによって
ぜひより良いプロダクトづくり っていうのを目指していければな
と思っています ということで今回は自然言語
質問コーナー:開発者がテストを行う際の注意点
に境界地面積を適用するという お話をしてきました 今日のオープニング
では話したとおり 自分は最初は あんまり境界地面積って数値の
とき使うんでしょうぐらいにしか 思ってなかった時期もあったんですけ
れども こういうふうにぜひ自然言語 にも境界地面積っていうのを適用
して考えてみてほしいなと思います ここからはまた質問のコーナー
になります 以前いただいた質問 から紹介していきます これ実際
に自分が登壇したときにもらった 質問の内容なので 一部なかなか
分かりづらいかもしれませんが 今回の質問はお話の中で 登壇
した中でテスト活動の一部を開発 者が行うっていう話をしたんですね
そのときに この工程で気をつけている ことがあれば参考までにお伺い
したいですということで ざっくり 内容を話すと テスト活動を全部
QAとか テストエンジニアが頑張るん じゃなくて 開発者が一部行うっていう
のがあってもいいんじゃないか っていうお話をしたんですね
この工程で気をつけているっていう ところで言うと 結局 自分が病院
の内容とかで話しているような いつもテストプロセスを意識しよう
っていう話をしているんですけれども やっぱり いきなりテストの手順
とかテストのスクリプトがある わけではなくて やっぱりテスト
設計としてどういうテストのパターン がとか その前段としてのテスト
分析で何テストしたいのかっていう ところが絶対あると思っていて
そこの何をテストしたいのかっていう 話であったりとか どうしてその
テストをやるのかっていう テスト の意図っていうものが消えない
ようにするっていうのは大事かな と思っています 特にテストスクリプト
であったりとか テスト手順書に 今 開発者自身が書いたりすると
どうしてそのテストを選んだのか っていうのが見えなくなってくる
ことがある 意図が消えていっちゃう っていうことがあるので そうならない
ように工夫をして テストコード そういうところにちゃんと残す
ようにしていきたいっていうか そういうふうにすることが多い
かなと思っています ということで 質問 ありがとうございました
エンディングとリスナーへの呼びかけ
ではエンディングです btesting.fm ではリスナーさんからのお便り
を募集しています エピソードの 感想や私に聞いてみたい質問や
テストのお悩みなど どんなこと でも構いません 投稿フォームは
番組概要欄にあります また エピソード の感想は ハッシュタグ
btesting banscotestingでXのポストを お願いいたします 今日の話で言う
と やっぱりこの境界値分析 数値 のときに使えばいいんでしょって
思っていたら 実は自然言語でも 使えるっていうのは 人によって
は目から鱗かもしれません そういう そうなんだって思った方は ぜひ
感想をもらえると嬉しいです もしも これからも聞きたいという
方は お手持ちのPodcastアプリで 番組のフォローもお願いします 最新回
が上がったとき すぐに気づける と思うので ぜひフォローをお願いします
これからも 今回は境界値分析を 話しましたが これからもテスト
設計方法 他にも話していきます し それ以外のテストの雑談の話
もいろいろしていきたいと思います ので ぜひフォローをお願いします
ということで 今回はここまでです それでは また次回
バイバイ
11:31

コメント

スクロール