テスト分析に使う参照モデルである論理的機能構造についての私の意見

6月の中旬頃ですが、テスト分析をする際に使う参照モデルの件でTwitterで話がありました。Twitterだと話が断片的になり、私が込み入ったことを理解するのにも、それを理解してもらえるように説明するのは難しいので、止めちゃいました。（ごめんなさい、あきやまさん）

で、止めちゃったことを反省していますし、自分自身でもはっきりさせたいので、ここで整理します。

論理的機能構造は、もともと大村朔平さんの書籍「一般システムの現象学」に書かれていたものを、私がテスト分析のモデルとして引用し始めて、今ではオリジナルとは違う絵になってしまったものです。

モデリングの話から始まった

モデルというものはあるものを見えやすくするために必要なものを強調し、不要なものを取り消すのであるが、そのモデル化について、秋山さんは説明したのだと思います。

モデルの特徴として強調したいところをより強調させるとシンプルになるが、捨てないでいろいろ残すと、現実に近づくあまり、複雑で理解困難さが残るという話で、単純から複雑な方へIPOから順序付けてくれた話になります。ただし、モデルをシンプルにするためにデフォルメさせるには観点が必要なので、その話が次になります。

テスト分析のモデルとしてどうあるべきか

テストで網羅したいものをあえて網羅しやすくするために、モデルの要素から入出力のチェックを「あえて」外してシンプルにする話をしています。ただし、ここの「サービス」が私はまだどの話なのかが理解できていません。

ここは、テスト設計をするためのの基本セオリーどおりの話であり、全く異論の余地はありません。

論理的機能構造について

「私、本当に大人げなくてすいません」という感じなのですが、「同時にいろいろ考えられる頭のよい人」というのが、私には、頭の良い限られた人しか使えない限定的なモデルだと言っているように感じてしまったんです。（秋山さんがそう思っているかはわかりません。）

なので、私がちょっと絡み始めました。それに対して、まずは論理的機能構造が良い理由を話してもらえました。（まぁ、私もこのモデルを自分で考えたわけでもなく、その頃読んだ本で、これなら汎用的に行ける！って思って現場での適用を進めていき、自分の解釈を足すってことを始めただけなのですが。）

ここは、論理的機能構造に対して、私の理解しているとおりに秋山さんも話をされているので、あえて口を挟むことは何もありません。

湯本の意見

ここが私がわからなくなったところです。論理的機能構造では、目的とノイズが表現できていないので、足りないのはわかるのです。ただ、IPOと貯蔵と状態（サポートと相互作用）は、表現されているのですが、逆にいうとモデルの観点としてHAYST法より不足しているがあまり、もっとシンプルだと思っていたのです。それが「頭の良い人しかできない」って言われると、私には「複雑で分かりづらい」と言われているように感じてしまいました。

更にいうと、私はテストベース（設計書や仕様書）から読み取る場合、状態というより、サポートと相互作用の方が仕様の表現に近いので読み取りやすいって思っています。

ここで、これを言ってしまうのは、私には、「頭の良い開発者以外には論理的機能構造をテストのための分析モデルに使うのはよくない」と聞こえてしまいました。更にいうとテスト設計には使えないって書いているように聞こえてしまいました。私の想像力が働きすぎなのかもしれません。

ただし、私の意見として、テストベースが仕様書や設計書で、それを元にテストケースを作るのであれば、仕様書や設計書で書かれた機能についての話を整理するために使いやすいモデルを分析に使った方がテストベースを読み取りやすいと思っているんです。更に入出力のようなUTで済みそうなところまでモデルで整理できた方が、テスト対象に対する理解が早くできると思っています。別のテストレベルと重複するのであればテストしないということも明示的にできます。つまり、ラルフチャートで観点になっていることが足されていないけど逆にわかりやすいのでは？という意見です。（分かりやすいのでは？は個人的意見になってしまいますが。）

テスト対象に対してある程度理解があれば、秋山さんがいうようなことは捨象してしまった方が効率が良いというのも理解できないことはないのですが。。。何度もいうので申し訳ないのですが、逆にテスト対象をあまり知らない人ほど、論理的機能構造で分析した方が機能に対する理解が進みテスト対象全体を把握するには向いていると思っています。

しかしこれに対して、「論理的機能構造は頭が良い人しか使えない」ってなってしまうのがどうも理解に苦しみます。

多分、「頭の良い人」というのが、世の中のどのくらいの人たちを想定しているかによります。「テスト設計は頭の良い人しかできない」というレベルを指しているのか？、「テスト設計をする人のレベルでは使いこなせない」という意味で使っているのか？によるかと思います。

なぜこうなるか最後に考察

こういう意見になったことを冷静に考えると、バックボーンがあきやまさんと私で違うのが原因かもとも思いました。私は、テスト専門会社出身なので、いろいろな「今まで見たことのないテスト対象」をテストするって経験を積んで来てからコンサルになったのですが、あきやまさんは、基本的にはプリンタという意味では同等のものを対象としたテストをずっとしてきてからコンサルになっているので、入出力やデータ保存と言った単体テストでできる当たり前なものをあえて捨象するのかと思った次第です。（私が間違っているかもしれないのでご意見あれば是非お願いします）

システムテストレベル以降では、単体で見つかる不具合のテストをちゃんとやるのは馬鹿げているかもしれないっていうのもありますし、そうなると捨象も大事だとは思うのですがその前にテスト対象への理解が足りない時にそれをすると分析を誤ると思います。そのためには論理的機能構造のような仕様や設計の理解がしやすいモデルがよいというのが私の意見です。

（うまくまとまる話にできなくてすいません。後日に頭が整理できたら再度トライします。）