ソフトウェアの品質を学びまくる

ソフトウェアの品質、ソフトウェアテストなどについて学んだことを記録するブログです。

テスト設計技法を分類する「Ostrandの4つのビュー」の原典に一生たどり着けない

テスト設計・技法

　暑かった夏ももう終わり。そろそろ秋ですね。
　この記事では初秋らしく、テスト技法を分類する切り口の1つとしての「Ｏstrandの4つのビュー」を紹介します。

　手始めに、『ASTERセミナー標準テキスト』を引用してみましょう。

ASTERセミナー標準テキストV3.1.1より

「4つのビュー」におけるテスト技法の分類

　ここでの主張は、以下の2点です。

  • テストの技法は、4つのカテゴリーに分けることができる
    • User-oriented (ユーザ指向): ユーザの要求に合うか、利用時に満足しているか
      • 例: ユースケーステスト
    • Spec-oriented (要件指向): 仕様通り実装しているか
      • 例: 境界値分析
    • Design-oriented (コード指向): ロジックは正しいか、実行されないコードはないか
      • 例: 制御パステスト
    • Fault-oriented (フォールト指向): 発生しやすい、あるいは、推測される欠陥が検出されるか
      • 例: エラー推測テスト
  • この4つのいずれかに偏るのではなく、バランスをとることが大切である

　「テスト」といった時に、みなさんは上のうちのどれを最初に連想するでしょうか？

　テストを勉強し始めた頃のわたしであれば、Spec-orientedを選んだと思います。仕様は概ね正しいものと見なして、その仕様に準じて動作することを検証するために必要なテストの空間を、いかに効率的に塗りつぶしていくかみたいな楽しさがあります。テスト自体の知識が求められる部分ですね。

　今なら、User-orientedがテストとして面白いと感じます*1。
　仕様に準じて一通り動いたとして、「本当にこれでユーザが価値を感じてくれるか、課題を解決できているのか」に焦点を当てて考える*2ものです。ドメイン知識の比率が高くなる部分です。

　この2つとは違う面白さがあるのが、Fault-oriented。ここは、バグに関する過去の知識がモノを言う部分です。
　「この辺でよくミスるんだよな」「過去にこういうやらかしがあった」みたいな知識は、要件にも仕様にも、事細かに現れるものではないため、テストエンジニアの腕の見せ所の一つでしょう。

　Design-orientedは「コード指向」と訳されていますが、アーキテクチャとか、昔の(?)言葉でいうところの「内部設計」からコードまでを含めてを対象としたもので、いわゆる「開発者テスト」に近く、設計・実装の知識が求められる部分です。

　同じ「テスト」なのに、考えるべきことも、求められる知識・スキルも異なるというのが、この分類の面白い点ですね。
　複合的な知識の総動員でテストを設計・実行し、自分たちのプロダクトがあるべき姿にどこまで近づいているかを調べる。これがテストの面白さの一つではないかなと思います。

　西康晴さんの10年前のツイートを引用してみます。

SQuBOKにおけるテスト技法の分類

　SQuBOKでは、テスト技法を使うにあたってインプットする情報をいう切り口で、テスト技法を分類しています。

ソフトウェア品質知識体系ガイド(第3版): SQuBOK Guide V3

ソフトウェア品質知識体系ガイド(第3版): SQuBOK Guide V3

  • オーム社
Amazon

  1. テスト対象のソフトウェアそのものの情報: 仕様に基づいた技法、コードに基づいた技法
  2. テスターやソフトウェアの利用者が持つ情報: 経験および直感に基づいた技法、フォールトに基づいた技法、リスクに基づいた技法、利用に基づいた技法
  3. その他: 組み合わせの技法

　1.や2.とは別に「組み合わせの技法」が位置付けられていることへの違和感は置いておくとして、根拠とする情報の種類を「ソフトウェアそのものの情報」と「人間がもつ情報」に分類するのがユニークだなと思います。テスト観点の源泉は、開発の成果物に限定されないことを示唆しています。

　Ostrandのビューでいうと、「利用に基づいた技法」がUser-oriented、「フォールトに基づいた技法」がFault-orientedになるでしょう。
　「経験および直感に基づいた技法」に属する探索的テストは、「技法というよりスタイル」とも言われますし、「リスクに基づいた技法」もどちらかといえばテストの「戦略」に属するものなので、対応するビューはなさそうです。

原典はどこにあるのか・・・

　話を戻して、「Ostrandの4つのビュー」、この話の原典はどこにあるのかが気になります。
　わたしの現時点での結論は以下の通りです。

  1. 西康晴氏が、遅くとも2005年の時点*3で、このコンセプトを国内に紹介している
  2. 日本語で「ビュー」に言及しているページは少なくないが、ほとんどは西康晴氏の資料の孫引き*4と思われる
  3. Ostrand氏の論文はいくつか見つかるが、ズバリこの「4つ」を明示しているものにはたどり着けなかった

　つまり、「Ostrandの例の論文」は、インターネット到達不能極にあると判断しています。

　一番近いと感じた論文は、THE CATEGORY-PARTITION METHOD FOR SPECIFYING AND GENERATING FUNCTIONAL TESTSです。
　引用してみましょう。翻訳はChatGPTです*5。

Functional tests can be derived from the software’s specifications, from design information, or from the code itself. All three test sources provide useful information, and none of them should be ignored. Code-based tests relate to the modular structure, logic, control flow, and data flow of the software. They have the particular advantage that a program is a formal object, and it is therefore easy to make precise statements about the adequacy or thoroughness of code-based tests. Design-based tests relate to the programming abstractions, data structures, and algorithms used to construct the software. Specification-based tests relate directly to what the software is supposed to do, and therefore are probably the most intuitively appealing type of functional tests.

機能テストはソフトウェアの仕様、設計情報、またはコード自体から派生することができます。これら3つのテスト源はすべて有用な情報を提供し、いずれも無視すべきではありません。コードベースのテストはソフトウェアのモジュラー構造、ロジック、制御フロー、およびデータフローに関連しています。プログラムは正式なオブジェクトであるため、コードベースのテストの適切さや徹底さに関する正確な声明を簡単に行うことができるという特定の利点があります。設計ベースのテストは、ソフトウェアを構築するために使用されるプログラミング抽象化、データ構造、およびアルゴリズムに関連しています。仕様ベースのテストは、ソフトウェアが行うべきことに直接関連しており、したがって、おそらく直感的に魅力的なタイプの機能テストと言えます。

　論文でCode-based、Design-basedといっているものが、「4つのビュー」でいうところのDesign-oritentedに。Specification-basedといっているものが、User-oritentedとSpec-oritentedに対応するように思えます。
　つまり、Fault-orientedに対応するものが、論文には見当たらないですね。

　原典はいったい、インターネットのどの経路を辿ればたどり着けるのか・・・。
　Ostrandの4つのビュー、原典を見つけた方は、ぜひお知らせください。

補足1

　この記事の投稿後、秋山浩一さんに教えていただきました。
　テスト技術者交流会MLにおける2007年のやりとりによると、この分類はOstrand氏の話を元にしたとのことで、論文自体にこの分類が定義されているわけではないようです。

補足2

　さらに、辰巳敬三さんにも教えていただきました。

　にしさんのJaSST’06での論文*6で以下のように言及されているとのこと。

: Ostrand はこうした観点の最上位を「ビュー(view)」と呼んでいる[2]
: [2] J. J. Marciniak, Encyclopedia of Software Engineering, John Wiley & Sons, New-York, 1994.

　論文ではなく、『Encyclopedia of Software Engineering』という書籍で説明されているのですね。Google Booksでは一部しか参照できないのですが、辰巳さんによると以下の通り、確かに4つが述べられています。

Ostrandは SOURCE OF DERIVING TESTS を problem specification, problem implementation, fault information and history, and program usage information の4つに区別し、以下のテストを説明しています。
Specification-Based Tests
Implemented-Based Tests
Fault-Based Tests
Usage-Based Tests

　「インターネット到達不能極」などと言って申し訳ありませんでした、単に有償の文献などを調べていないだけですね。。。

*1:と書いていますが、手を動かしてのテストはもうしばらくやっていません。一生現役みたいな書き方してごめんなさい・・・。

*2:これをテストの時点で考えるのでは遅い、というのはその通り。

*3:以下のような資料がある。
・2005年5月 \@IT ソフトウェアテスト・ミーティング
・2008年6月 ソフトウェアテストシンポジウム四国2008
・2013年4月 WARAI（関西テスト勉強会）スペシャル
追記: 辰巳敬三さんによると、『月刊ジャバワールド』2002年10月号の「ソフトウェア・テストの基本を学ぶ」まで遡ることができるとのこと！

*4:「孫引き」って単に「引用の引用」程度の意味だと思っていたけれど、もっとネガティブな意味を含むと知りました。「他の本から引用してあるものを、原典にさかのぼって調べることなく、そのまま更に引用すること。」

*5:わたしならこのコンテキストではderiveは「導出」、formalは「形式化された」、thoroughnessは「完全さ」と訳すかなー。statementは迷うな。

*6:JaSSTのページには論文はなく、発表スライドのみが公開されています。