「テスト条件」とは何かが分からず悩んでいたところ、にしさん (@YasuharuNishi) にTwitter上でレクチャーいただくという、貴重な機会をいただきました。このやり取りをまとめることは同じ悩みを抱えた方の手助けになると考え、本記事を公開するに至りました。
今回は編集をせず、スレッドの流れの整理にとどめ、やり取りをそのままに引用しています。
なお、私は文中で「（ぱと）」若しくは「@pato_taityo さん」となっています。
https://twitter.com/pato_taityo/status/1349519598501052420 のスレッドより。
（ぱと）
今更ながら、テスト条件とテストケースの違いが判らなくなってきた…。より正確には「テスト条件」とは何かが分からなくなった。「入力Aと入力Bを加算した結果を表示すること」は（具体的な）テスト条件で、それを操作（テスト）手順に落とし込んだものがテストケース…？
テスト条件について調べるうちに、西さん(@YasuharuNishi)の解説に行きあたって、より分からなくった面もある。
テスト条件とテスト観点 - Togetter
この説明からはテスト条件⊆テスト観点の関係にあるようにも読み取れる。が、その理解でよいのだろうか。まだ何か理解しきれていない気がするんだよなぁ。
（にしさん）
組織や人によって、テスト条件やテスト観点という概念の使い方は様々ですからね。私流でよろしければお答えしますよ。 (^_^)
（ぱと）
ぜひお願いします！まとめを何度も読み返したのですが、私に前提の理解や知識が足りていないため、理解しきれませんでした。まず、テスト条件やテスト観点をどのように定義しているのでしょうか？ここでは西さん流で構いません。
（にしさん）
遅くなってすみません。まず、私はテスト条件という用語は厳密に使いません。抽象的なものを表す時も、具体的なテスト値を表す時もあります。その時話しているテストタイプによりますが、テストケースを実行する際に入力として扱うようなものを表すことが多いです。これらは相手の理解に合わせてます。
で、テスト観点を理解するためには、少なくとも3つのことを理解しておかなくてはなりません。抽象度と、テストケースの構成要素、バグの検出への影響です。
抽象度は一番理解しやすいと思います。テストケースを設計するときには、具体的な値を示すもの（例: 東135°•北38°）と、抽象的なもの（例: 経度•緯度、位置情報）といった抽象度を区別しなくてはなりません。そこで前者をテスト値、後者をテスト観点と呼んでます。
後者のうち最も具体的なもの（テスト値より1段階だけ抽象的なもの）をボトムテスト観点やパラメータと呼んでます。最も抽象的なものをトップテスト観点やビューと呼んでます。
前者がインスタンスで、後者がクラスのようなもの、とざっくり考えるとわかりやすいかもしれません。
テスト条件という用語は、割と両方を意味してしまいます。区別したい時には高位テスト条件と呼ぶ人もいますね。
まぁ厳密には親テスト観点と子テスト観点の間の関係は「抽象度」だけではないのですが、それはまた今度。
次に構成要素ですが、一般にテストケースは、事前条件、テスト条件、トリガー、テスト対象、テスト環境、期待結果など、様々な要素から構成されます。
これらは典型的な例だと区別しやすいのですが、実務では区別しにくい場合があります。例えば構成テストタイプ（動作環境を変更するテストタイプ）で、周辺機器を変えるテストをしたい時、周辺機器はテスト条件でしょうか、テスト環境でしょうか。
この問いって、不毛なんです。なので僕は、テストケースの目的を表すものをテスト観点と呼ぶことにしました。ですからこの例の場合、周辺機器はテスト観点と呼びます。
じゃあ例えば周辺機器がSSDだとして、書き込みや読み込みといった機能や、何メガバイトのデータを読み書きするのかといった量はどう扱うのでしょう。僕は、SSDでバグを出すために考えなきゃいけないのであれば、それらもテスト観点として扱います。
厳密には、これはバグ検出型のテスト設計と保証型のテスト設計で変わりますが、それはまた今度。
つまりテスト条件という用語は一般に、抽象度を区別せず、テストケースの特定の構成要素に限定して意味することが多いです。テスト観点は僕の場合、抽象度を区別して、テストケースの特定の構成要素に限定せず、バグが出るかどうかに関係しそうかものを意味します。
と、書いてみましたが、多分この説明ではとても分かりにくいと思うので（説明が下手でごめんなさい）、色々聞いてくださいまし。 m(__)m
（ぱと）
解説をありがとうございました！心待ちにしていたので、大変うれしかったです。
何度も読み返したり、他の資料にもあたっているうちに、混乱してきてしまったので、追加で質問をさせてください。
(1)
テスト条件は入力に限定されるのでしょうか？
「条件」という響きから「AならばB」のとき、テスト条件がAのみを指しているように感じます（Aは入力でBは期待結果）。
ですが、『基本から学ぶテストプロセス管理』の用語集では「テスト条件」を「テストケース内のステップ、サブステップ、またはアクションの組み合わせをいくつか実行することによって生み出されるシステムの状態または状況。」と定義しています。これは出力（期待結果）を指しているように感じました。どのように解釈するのが正しいでしょうか？
(2)
テスト条件とテスト観点 - Togetter
以前のツイート群からは「テスト観点とは高位テスト条件である。テスト観点からテスト対象に合わせて具体的にしたものがテスト条件である。」というようにテスト観点とテスト条件は抽象度の違いであるととらえました。
ですが、今回の解説を踏まえると、単に抽象度の理解ととらえて良いのかわからなくなりました。
つまりテスト条件という用語は一般に、抽象度を区別せず、テストケースの特定の構成要素に限定して意味することが多いです。テスト観点は僕の場合、抽象度を区別して、テストケースの特定の構成要素に限定せず、バグが出るかどうかに関係しそうかものを意味します。
https://twitter.com/YasuharuNishi/status/1350838641489137665
このツイートでの「抽象度を区別する／しない」の説明とごっちゃになっているのが原因なのですが、どのように紐解いて理解すべきでしょうか。
大変お忙しいと思いますので、お時間と余裕があるときにご教示いただけますと幸いです。その間に私も思考を整理してみます。
https://twitter.com/YasuharuNishi/status/1351185878346039299 のスレッドより。
※このスレッドは少し横道へ逸れ、勉強方法に関するやりとりになっています。
（にしさん）
えーと、多分、@pato_taityo さんの勉強の仕方のために、混乱してると思われますので、その話を先にしますね。
高校までで習う数学や物理学、化学などに比べて、ソフトウェア工学はとても歴史が浅く、ソフトウェアテストはさらにもう少し歴史が浅いです。この差を理解しておかないと、勉強してて大混乱します。
歴史の深い技術や学問では、知識体系がきちんと整理されていますし、用語の定義もきちんと標準化されています。ニュートン力学は良い例だと思います。こういう技術では、どの先生から聞いてもどの参考書を読んでも同じことが書いてあります。
でもソフトウェアテストは歴史が浅いため、どの先生から聞いてもどの参考書を読んでも同じことが書いてあるわけではありません。「標準化されている」とは言えないわけです。
言い換えると、同じ用語でも、教える人や参考書が違えば、違う意味で使われます。聞いている方は大混乱ですよね。
しかも始末に負えないことに、教える人や参考書がそれぞれの概念をきちんと理解しているかどうかも保証できません。それじゃあ、聞いている方が理解できるわけがありません。
したがって一番混乱する勉強法は、Aさんに聞いたらこう言ってたけどBさんに聞いたらこう言ってて、なんか矛盾している、みたいに、色んな流儀をつまみ食いすることです。
なんとなく@pato_taityo さんからのご質問を読んでいて、そんな気がしています。
（ぱと）
ソフトウェアの他の分野でも比較的歴史が浅い＆用語の定義がバラバラ、ということがありました。その分野を専門に扱う本は英語含め数冊しか無く、それらを見比べて解釈する、ということをしていました。それでもその時に上手くいっていたのは、知見を持つ方が解釈の道筋をつけてくれたからでした。
もし今回のように独学するのであれば、この著者はこの用語をこういう定義で議論を展開している、ということを念頭に置いた上で、議論全体の構成を理解する。と考え直したのですが、いかがでしょうか？
著者の考える定義が必ずしも説明されていないこともあり、このようなケースでは混乱しますが…。
（にしさん）
はい。仰る通りです。例えば、引用して頂いた「基本から学ぶテストプロセス管理」におけるテスト条件の定義ですが、確かに用語集にはそう書いてあるものの、本文でテスト条件について例を含めてきちんと書いてあるところを見つけられませんでした。
ざっと見ただけなので見落としかもしれませんので、もしご存じなら教えてください。 m(_)m
で、「基本から学ぶテストプロセス管理」では、テストケースがいわゆるテスト手順を含んでいますね。そしてこの本が準拠しているとされているIEEE829（-1998かな？）には、テスト条件（test condition）は定義されていません。（ちなみにIEEE829-2008も同様です。）
さて、ではこの本におけるテスト条件の定義は、何のために行われたのでしょう？どうも
@pato_taityo さんが考えてるものとは少し違うかもしれません。 (^^;
ちなみにISO/IEC/IEEE29119シリーズでは、「test condition. (1) testable aspect of a component or system, such as a function, transaction, feature, quality attribute, or structural element identified as a basis for testing」と定義されています。 https://pascal.computer.org/sev_display/index.action
ところで、@pato_taityo さんは、何をしたくて/知りたくてテスト条件を理解しようとしてらっしゃるのですか？ (^_^)
（ぱと）
重ねて丁寧な返信を頂き、ありがとうございます。話題が分岐しており、それぞれに返信したいのですが、考えを整理するのに時間がかかって追い切れておらず、申し訳ございません…。分岐した話題については別途返信させてください。
知りたいことは「JSTQBのシラバスにおける『テスト条件』とは何か」です。用語自体は頻出するのですが、シラバスということもあってか、解説や具体例はありません。用語集とTA「1.4テスト分析」に少し説明があるくらいでした。これでは私が理解するには情報が足りませんでした。
そこで他の資料（「基本から学ぶテストプロセス管理」もその一つです）に手掛かりを求めましたが、袋小路に迷い込んだ、というのが現状でした。レクチャー頂いた考え方を参考に今一度シラバスに立ち返ろうかと考えていましたが、他にすべき事があればご教示頂きたいです。
なお、テスト条件とは何かと言うことについて、具体例を持って説明した資料は今のところ見つけられていません。ご指摘通り「基本から学ぶテストプロセス管理」の本文内からも見つけられませんでした。
https://twitter.com/YasuharuNishi/status/1351188320752193536 のスレッドより。
※このスレッドでは本流に戻っています。
（にしさん）
で、@pato_taityo さんのご質問に答えます。
(1)a「テスト条件は入力に限定されるのでしょうか？」 --- されません。でも人というか流儀に依存します。入力だけを指す人もいます。
ISTQBでは「An aspect of the test basis that is relevant in order to achieve specific test objectives.」と書いてあります。抽象的ですね。
JSTQBではもっと補足して「コンポーネントやシステムのアイテムやイベントで、テストケースにより検証できるもの。たとえば、機能、トランザクション、フィーチャー、品質の属性、構造要素など」と書いてあります。
すなわちISTQB/JSTQBでは、テスト条件は入力だけに限定されません。
私もISTQB/JSTQBと同じように、テスト条件は入力だけに使いません。
(1)b「「条件」という響きから「AならばB」のとき、テスト条件がAのみを指しているように感じます（Aは入力でBは期待結果）。」 --- はい。そう思うのも無理はありません。初心者ならそれでよいと思います。
でも例えば構成テストの場合、様々な動作環境に変更しても動くかどうかをテストしますが、入力値はどの環境でも同じであるテストケースかもしれません。この場合、テスト条件は入力値ではなくて、「様々な動作環境」を指す方が設計しやすいです。
だってテスト設計って、テスト条件を色々変えていきますよね。構成テストで変えたいのは入力値じゃなくて動作環境ですから。
そうすると、動作環境は入力値ではないということで、(1)bの答えになります。
(1)c「『基本から学ぶテストプロセス管理』…では…「テストケース内のステップ、サブステップ、またはアクションの組み合わせをいくつか実行することによって生み出されるシステムの状態または状況。」と定義しています。これは出力（期待結果）を指しているように感じました。」
えーと、ご自分がこの本に沿ったテスト設計を身につけたいのでなく、単に用語確認のために使っているのであれば、この定義は忘れた方がよいと思います。
(2)「今回の解説を踏まえると、単に抽象度の理解ととらえて良いのかわからなくなりました。」 --- @pato_taityo さんがテスト条件をどう捉えているかが分からなかったので、抽象度以外のことも説明しました。でも一番分かりやすいのは、抽象度の違いだと思います。
引用して頂いたTogetterも、抽象度の違いだけとは言ってませんね。でもまずは、入力系に限定して、抽象度の違いについてしっかり理解しておくのがよいと思います。
多分ですね、矛盾なく全ての定義を理解しようとすると、ドツボにはまると思います。そうじゃなくて、自分はどういうテスト設計をしたいのか、その時にテスト条件やテスト観点という用語をどう使いたいのか、そう使って困ることはないのか、と考える方が実り多い気がします。
ちなみにテスト条件という用語は、あまりにも色んな人が色んな定義で使っていてよく分からんということで、今度改訂されるISO/IEC/IEEE29119シリーズでは削除される方向で議論されています。それくらい「テスト条件」という用語は、深く考えると理解しにくい用語なのです。
でもね、xSTQBやJTC1/SC7/WG26（ISO/IEC/IEEE29119シリーズを決めている人たち）の全員がちゃんと「テスト条件」という概念を理解しているか、というと、そうでもないのですよ。
顔も見たことない、分かってるかどうかも保証できない誰かの定義に頼るくらいなら、自分なりのテスト設計の方法を生み出しながら自分なりの定義をしてしまい、自分が「この人はよく分かってる」と感じる人と1対1で（オープンに）議論する方が実り多いし、実務に役立つと思います。
なんか上手く答えられている気がしないので、モヤモヤするところがあればいくらでも聞いてください。 (^_^)
（ぱと）
こんにちは。先日の書き込み以降、考えてみたことをまとめます。
「JSTQBのシラバスにおける『テスト条件』とは何か」という疑問に対し、明確な答えは出せていません。用語集の解説が答えなのかもしれませんが、それを自分の言葉で説明できないでいます。
JSTQBのシラバスに答えを求めるなら、テストアナリスト「1.4 テスト分析」にテスト条件の具体例があります。ここでの例のうち、私なら「画面Xの機能性」はテスト観点に振り分けるものですし、「～正しい長さよりも一桁足りない～を拒否する」はテスト条件といわれてもしっくりきます。
抽象度を問わずこれらをひっくるめたものがJSTQBにおける『テスト条件』ではないか、と考えました。
このようなふわっとした理解（解釈）に対して不安はありますが、シラバスを読み直す中で気付きがあれば適宜見直せばよいかなと。
あと、シラバスはあくまで学習指針であり、その内容を一生懸命理解しようとするより、自分が学びたいことを学び、実践することがより大事なのではとも。JSTQB認定テスト対策だけを考えればだいぶ回り道かもしれませんが、ゴールは単に合格を目指すことではないので。
まとめるといいつつ、上手くまとめられませんでしたが、このように考えてみました。
もし考え違いなどあれば（そしてお時間があれば）、ご指導・アドバイスいただけますと幸いです。
（にしさん）
遅くなってすみません。有益なコメントになるかどうかは分かりませんが…。
@pato_taityo さんが何を悩んでおられるかの可能性を考えていたのですが、一つは「テスト条件という概念を何のために考えなきゃいけないのか」。もう一つは「何のために使うかは分かってて、どんなものがテスト条件になりえて、どんなものはテスト条件にならないのか」。かな、と思いました。
ツイートを読んでいると「テスト条件という概念を何のために考えなきゃいけないのか」については分かっていると思ってます。これを分かるということは、テスト開発のプロセスを分かっている、ということになりますね。
JSTQBのシラバスは、分かって読まないと、テスト設計のプロセスや方法論が読み取りにくいかもしれません。詳しい手順としては書いてないので。でも考え方は書いてありますね。
「何のために使うかは分かってて、どんなものがテスト条件になりえて、どんなものはテスト条件にならないのか」については、色々考えておられて、かなり分かってこられた感じがします。
実は、この疑問はかなり高度な技術的課題なんです。テスト設計は、もの凄く初歩的なレベルだと「書き写し」でできてしまう気がするのですが、この疑問が出てくるレベルになると「モデリング」の知見や技術が必要になります。
高位レベルとか低位レベルなんていうのは、抽象度とか段階的詳細化というモデリングの概念をテストに適用したわけですね。
ですので、@pato_taityo さんが書かれていた「抽象度を問わずこれらをひっくるめたもの」がテスト条件という理解で問題ないと思います。
テスト条件という用語は非常に曖昧で、人によって使われ方が違いますからね。国際規格の次版では削っちゃった方がいい（別の用語を使うことでもっとしっかり定義した方がいい）という議論もされています。
何か少しでもお役に立てるツイートだといいのですが、気になるところとか分かりにくいところは引き続き聞いてくださいね。 (^_^)
（ぱと）
私の言葉足らずなツイートに対し、言わんとしていることを汲み取って適切なアドバイス頂き、大変恐縮です。ありがとうございます。
ここまでに頂いた解説を読み返し、自分の言葉でまとめてみました。
開発プロセスでは単体テスト・結合テストのようにテストレベルでステップを設定することがある。また、各テストレベル内でも開発プロセス同様のステップ（分析、設計、実装、実行）を踏んで進行することがある。
開発プロセスは要件という抽象度の高い物から、コード（実装）という具体的な物へ変換するプロセスである。適切なステップを踏むことで適切な変換を実現出来る。
テストも同様で、このテストの目的は何か。目的を実現するためにどうすれば良いのか。と、抽象度を徐々に下げる（具体化する）ことで、テストの目的に合ったテストケースを生成する事が出来る。
「テスト条件」はこの具体化の過程で使われる用語である。「テスト条件」の定義は定まっていない。一例として「どんな要素（例：機能、品質等）をテストしたいのか？を指す」の意味で使われることもある。
ALシラバス テストアナリスト「1.4 テスト分析」にテスト条件の具体例があり、「画面Xの機能性」は抽象度の高い例、「画面Xでは、正しい長さよりも一桁足りないアカウント番号を拒否する」は抽象度の低い（具体的な）例と言える。
今回のように用語の定義は必ずしも定まっていない。ただ、著者の中では何かしらの定義を持って記述しているはずなので、それが何であるかを意識しつつ、著者はその用語を使って何を主張したいのか読み解くと良い。
…と理解してみたところ、JSTQBでの用語の定義もストンと理解できました。最初からそう書いてあったのだけど、それの意味するところをようやく解釈できるようになりました。
JSTQBではもっと補足して「コンポーネントやシステムのアイテムやイベントで、テストケースにより検証できるもの。たとえば、機能、トランザクション、フィーチャー、品質の属性、構造要素など」と書いてあります。
https://twitter.com/YasuharuNishi/status/1351189133222432771
西さんの貴重なお時間を割いてレクチャー頂いた今回のツイート群はブログ等の形でまとめようかと考えています。同じように悩んでしまった方の一助になればと。
もし差し支えるようであれば個人メモに留めますので、その旨ご連絡頂けますと幸いです。
本当にありがとうございました！
