組み合わせテストの歴史(1)

富士ゼロックスの秋山さんのHAYST法、マイクロソフトのPICTや岩通ソフトシステムの鶴巻さんのPictMasterといったツールのお蔭で、日本で直交表テストやペアワイズテストがかなり広まっていると思います。
　最近、このようなテスト技法を総称して「組み合わせテスト(Combinatorial testing)」と呼ぶことが一般的になってきています。ISTQB/JSTQBのソフトウェアテスト標準用語集ではまだこの用語は掲載されておらず、直交表テスト(Orthogonal array testing)とペアワイズテスト(Pairwise testing)が掲載されているだけなので、「組み合わせテスト(Combinatorial testing)」という呼び方は比較的新しいものだと言えます。組み合わせテスト技法はGrindalらの論文ではつぎのように定義されています。

Combination strategies are test-case selection methods where test cases are identified by combining values of the different test object input parameters based on some combinatorial strategy.
『何らかの組み合わせ手法に基づいて入力パラメタの値を組み合わせることによりテストケースを選択する技法』

M. Grindal, J. Offutt, S. Andler, "Combination Testing Strategies: A Survey", Software Testing, Verification and Reliability, Vol. 15, No. 3, pp. 167-199, 2005

今月17日～21日にカナダ・モントリオールで開催されたICST 2012 (International Conference on Software Testing, Verification and Validation)に参加したのですが、4月17日には組み合わせテストのワークショップ(Workshop on Combinatorial Testing)にも参加しました。
　ワークショップの最後の方で少しディスカッションの時間があったので飛び入りで次の資料を元に組み合わせテストの歴史を紹介し、このテスト技法が日本発のものであることを話しました。

History of combinatorial testing

なお、この歴史の資料は実は2008年7月に開催された「PictMaster勉強会」で発表した次の資料を元に最新化、英語化したものです。

組み合わせテストの歴史(PictMaster勉強会)20080717

ワークショップではMicrosoftでPICTを開発したJacek Czerwonkaさん、NISTでACTSを開発しワークショップの議長団でもあるRich Kuhnさん、Raghu Kackerさん、Yu(Jeff) Leiさん(Texas大Arlington校の准教授、IPOという組み合わせ技法を開発)らと親交を結ぶことができました。
　組み合わせテストの歴史の詳細はこのBlogで追い追い紹介していきます。

データフローテストの歴史

データフローテストは、プログラムの制御フローのパスを選択する際に、制御フローテストが分岐に着目するのに対して、変数の定義、使用の関係に着目してテストケースを設計する技法です。パス選択の基準として、すべての定義－使用のペアを実行する全duパス法(ADUP法)や，各データについて定義－使用のペアを最低一つ含むようにする全使用法(AU法)などがあります。
　コンパイラの分野では1960年後半からIBM社のAllenらによりプログラム最適化技術としてデータフロー解析の研究が進められていました。ちなみに、Allen女史はIBM社初の女性のフェローで、また2006年に女性として初めてチューリング賞を受賞されています。

F. E. Allen and J. Cocke, "A program data flow analysis procedure," Communications of the ACM, 19(3):137-146, March 1976
F. E. Allen, "The History of Language Processor Technology in IBM," IBM Journal of Research and Development, Vol. 25, No. 5, pp. 535-548, Sep. 1981

テスト技術としてデータフローテストを提案した最初の論文は1974年の米国Colorado大学のOsterweilとFosdickのものと思われますが、彼らのデータフロー解析法はコンパイラの最適化技術と似ているが観点や目的は異なると書いています。なお、OsterweilらはDAVE(Documentation, Assertion generating, Validation, Error detection)という解析ツールも開発しています。

L. D. Fosdick and L. J. Osterweil, "Data flow analysis in software reliability," Comput. Surveys, vol. 8, pp. 305, Sept. 1976
L. J. Osterweil and L. D. Fosdick, "Data Flow Analysis as an Aid in Documentation, Assertion Generation, Validation and Error Detection," University of Colorado Department of Computer Science Technical Report No. CU-CS-055-74, 1974
L. J. Osterweil and L. D. Fosdick, "DAVE - A Validation, Error Detection and Documentation System for Fortran Programs," University of Colorado Department of Computer Science Technical Report No. CU-CS-071-75, 1975

なお、オーストラリアのHermanが1976年に以下の論文を発表しています。私は論文が入手できておらず内容未確認ですが、オーストラリアでも早期にデータフローテストの研究が進められていたようです。

P. M. Herman, " A Data Flow Analysis Approach to Program Testing," Australian Computer Journal, Nov. 1976, pp. 92-96

その後、データフローテスト基準の提案や制御フローテストも含めた構造テストの網羅基準間の包含関係(subsume relation)の研究が進められています。たとえば、RappsとWeyukerは条件部で変数が使用される場合(p-use)を基準として追加する提案を行っています。

S. Rapps and E.J. Weyuker, "Data Flow Analysis Techniques for Test Data Selection," Proceedings of the 6th international conference on Software engineering, Tokyo, Japan, Pages: 272 - 278, 1982
S. Rapps and E. J. Weyuker. Selecting software test data using data flow information. IEEE Trans. Softw. Eng., SE-11(4):367-375, Apr. 1985

ソフトウェアテストの歴史年表の更新

先週開催されたJaSST'12に合わせて出版されたJaSST10周年記念誌の付録にソフトウェアテストの歴史年表を提供させていただきました。これに合わせて右サイドバーのWeb Pagesの「ソフトウェアテストの歴史年表」もJaSST10周年版にしました。

付録年表は記念誌編集長(?)の秋山浩一さんのご配慮で、なんとA2の大きさの光沢紙にしていただきましたので、とても立派なものになっています。自宅にちょうどころ合いの額があったので入れてみるとさらに格好よくなりました。ただ、難点は字が小さいので壁に掛けると少し離れた場所からは個々の記述が読めないことです。4つ折りにして机の近くにおいておくほうが使い勝手はよいかもしれません。
　なお、このブログ掲載版は、大西建児さんから誤り指摘を受けて、記念誌に提供した年表から一箇所修正してあります。どこだか分かりますか?

正解はそのうち発表させていただきます・・・
　年表の誤りや漏れに気づかれた方はコメント欄でご指摘ください。

「発表資料集」のページの作成

右サイドバーのWeb Pagesに「発表資料集」のページを作成し、私がこれまで書いたり、発表してきた資料をまとめました。私が就職してソフトウェア検査部門に配属されたのが1976年なので、私のこれまでの活動も歴史として見ていただけるかもしれません(途中にかなりのブランクがありますが)。

掲載した資料の中に1987年のCOMPSACとICQCで発表した論文があります。このうちICQCで発表した論文"Test Case Design Support System"が、AT&T社での直交表テストやPairwiseテストの開発の参考にされたものです。このあたりの経緯は日科技連SQiPのWebコラム「ソフトウェア品質のホンネ 第43回 ソフトウェア品質技術の歴史　その3 (コミュニティ)」(3. 日科技連コミュニティと直交表テスト)で書きました。なお、この二つの論文は英語なのですが、今回、当時の日本語原稿を再生したものもアップロードしておきましたのでご覧ください。

テストカバレッジ基準の歴史(1)

動的解析システムの開発の目的のひとつに、テストの妥当性(あるいは十分性)の評価がありました。この評価の手法として、テスト対象のプログラムを基本要素に分割し、テストで実行された基本要素の割合で妥当性を表現するという方法、いわゆるテストカバレッジが考案されました。基本要素としては、命令コードや判定条件など構造的なものが元になっています。なお、妥当性を評価するテストとしては制御フローテストに限らず、例えばブラックボックステスト技法によるテストの妥当性を構造的観点から評価する場合もあります。
　以下に1970年代に提案されたカバレッジ基準を紹介します。

◆TER(Test Effectiveness Ratio) [J. R. Brown]

私が調査した範囲では、テストの妥当性を示す指標として提案された最初のカバレッジ基準はTRW社のBrownのTER(Test Effectiveness Ratio:テスト有効度)です。TRW社の動的解析システムPACEの中のFLOWと呼ばれるツールで計測し、以下の2つのTERを出力しています。いわゆる命令網羅と分岐網羅(または判定条件網羅)の基準です。

J. R. Brown, "Practical applications of automated software tools," WESCON 1972, TRW Software Series SS-72-05, September 1972
J. R. Brown and R. H. Hoffman, "Evaluating the Effectiveness of Software Verification - Practical Experience with an Automated Tool," AFIPS Fall Joint Computer Conference, December 1972

◆DD-paths, level-i paths  [M. R. Paige, E. F. Miller]

General Research社の動的解析システムRXVPでは、DD-paths(または decision-to-decision paths)及びlevel-i pathsという基準で評価する仕組みが提供されていたようです。
　DD-pathsとは、ある判定文の出口から次の判定文の入り口までのパスのことを意味しています。また、level-i pathsはプログラム中の反復(iterationまたはlooping)のレベルで構造要素を分割するもので、例えばlevel-0 pathは入り口ノードから出口ノードへの単純パス、level-n pathは下位level上で開始終了点をもつループのパスを意味します。

E. F. Miller, M. R. Paige et al., "Structural techniques of program validation," in Dig. 1974 COMPCON, (Feb. 1974), pp. 161-164

◆C0,C1,C2,・・・ [E. F. Miller]

現在、カバレッジの説明の際によく使われるC0やC1と呼ばれる基準は1975年頃にEdward Millerが提案したものです。ただ、Millerはこれらの基準の定義を何回か変更しているので、論文の発表時期により少しずつ定義が異なっています。
　1975年の"The Art and the Theory of Program Testing"(MillerのCxカバレッジに関する論文のうち私が入手した最も早期のもの)では以下のように書かれており、命令網羅はC1、分岐網羅はC2というように現在の定義(命令網羅はC0、分岐網羅はC1)と異なっています。

C0: Programmer's intuition.
C1: Every statement in a program exercised at least once.
C2: Every program predicate outcome exercised at least once.
C3: At least one element of each equivalence class of program flow exercised at least once.
C4: All usefully distinct program flow classes tested with "reliable test data," plus de facto testing of what cannot be tested reliably.
・
・
Cn: A sufficient set of tests so that the tests amount to a formal program proof of correctness.

1977年に開催されたCOMPSACのチュートリアルのテキスト"Tutorial: Program Testing Techniques"に記載されている解説"4. notes on planning and measurement in testing"では

The most common measure is the C1 measure, which requires that every segment in a program be exercised at least once.

と書かれており、C1を分岐網羅(＝every segment)としています。1978年に英国で行ったInfotechのチュートリアルで、Millerは以下の定義を示して「この一年ほど、この考え方を広めている」と言っているので恐らく1977年にC0,C1などの定義を変更したと思われます。

C₀: Every statement executed at least once
C₁: Every segment executed at least once
C₁^p: Every predicate term executed for each outcome
C₂: C₁ coverage plus interior and boundary tests for each iteration
C_i^k: All program paths that involve up to k iterations executed
C_d: C₁ coverage plus single-test execution of all pairs of dependent segments
C_p: All possible successive pairs of segments co-executes
C_t: Function processing of major sub-trees in hierarchical decomposition of segment interconnection

E. Miller, "The Art and the Theory of Program Testing," Proceedings of the Fourth Texas Conference on Computing Systems, Austin, Texas, 1975
Edward Miller, "Tutorial: Program Testing Techniques," COMPSAC'77, IEEE, 1977
A. E. Westley(Editor), Infotech State of the Art Report: Software Testing, Volume 1: Analysis and Bibliography, Infotech International, 1979

◆LCSAJ(Linear Code Sequence And Jump) [M. A. Hennell, et. al]

1976年に英国Liverpool大学のHennel,WoodwardらがLCSAJ(Linear Code Sequence And Jump)triplesを提案しました。現在はLCSAJと呼ばれていますが、当初の論文はLCSAJ triplesという名称でした。triplesと付いているのは、ひとつのLCSAJがソースコード中の開始行、終了行、および飛び先行の3つの数字の組みで表されることによります。
HennellらはTRW社のBrownが示した前述の二つのTER(Hennelらは順にTER1,TER2と番号をつけています)に加えて、LCSAJを使ったより厳しい条件の基準TER3を提案しています。

M. A. Hennell, M. R. Woodward, and D. Hedley, "On program analysis," Information Proc. Lett., vol. 5, pp. 136-140, Nov. 1976

制御フローテストの歴史(3)－動的解析システム

1970年代に入ってプログラム実行時の内部の動きを調べるための動的解析システムの開発が本格化しました。解析の目的としては、プログラムの性能改善に加えて、テスト時に通過したルートを調べることによるテストの十分性の評価があります。McDonnell Douglas社のStuckiによるとこのような解析システムの最初のものは1967年にUCLAのEstrinが開発したものだそうです。当時の代表的なシステムとして、TRW社のPACE(Product Assurance Confidence Evaluator)、McDonnell Douglas社のPET(Program Evaluater and Tester)、General Research社のRXVPがあります。

実行時の動作解析は、対象プログラムのソースを解析して実行プロセスを把握するための命令を事前に挿入しておき(これをinstrumentation(計装)と呼びます)、プログラム実行時にこれらの命令により記録された情報を集計することにより行われました。先の3つのシステムはいずれもFORTRANで書かれたプログラムを対象としています。

このようなinstrumentationによるプログラムの動作解析の有用性を最初に明らかにしたのは、KnuthによるFortranプログラムの実行プロファイル分析だそうです(program "profile"と呼んだのもKnuthが最初)。Knuthは数百本のFortranプログラムの静的な統計データを解析(命令や文の出現頻度)するとともに、17本のプログラムの動的な統計データの解析(命令の実行頻度)を行い性能改善ができることを示しています。そして、このような動的な解析はデバッグ段階でプログラム中のテストされていないセクションを見つけるのに有効であることも指摘しています。

J. R. Brown, et al. "Automated Software Quality Assurance: A Case Study of Three Systems," ACM SIGPLAN Symposium, June 21-23, 1972
L. G. Stucki, "Automatic Generation of Self-Metric Software," WD2144, McDonnell Douglas Astronautics Company, 1972
E. F. Miller, et al., "Structurally based automatic program testing," EASCON-74, October 1974
D. E. Knuth, "An Empirical Study of FORTRAN Programs," Software-Practice and Experience, Vol.1, pp. 105-133, 1971

制御フローテストの歴史(2)－黎明期(カバレッジ計測)

制御フローテストでは、テスト実行時にプログラム上の意図した箇所が通過したか、どこに分岐したかを計測してテストの十分性を評価するという方法が用いられますが、この計測のためのツールの開発は1960年代前半には開始されています。

IBM社ハイファ研究所(イスラエル)のUrの論文によると1960年代にIBM社のPoughkeepsie事業所でコードカバレッジ・ツールが開発されていたようです。

S. Ur and A. Ziv, "Cross-Fertilization between Hardware Verification and Software Testing," IBM Research Laboratory in Haifa, November 2002

この論文では1964年のWarnerと1967年のHirshの論文が参考文献としてあげられており、前者はハードウェア、後者はソフトウェアのコードカバレッジ・ツールのようです。

※いずれの論文も一般に出版されたものではなくIBM Technical Report(関係者だけに配布?)なので私は内容が確認できていません。当時の状況が分かる貴重な資料なのでIBMさんが100周年記念事業か何かで閲覧可能にしてくれるといいのにと思っています(ちなみにElmendorfの原因結果グラフの論文もIBM Technical Report)。

Beizerの「ソフトウェアテスト技法」では巻末に膨大な数の参考文献が記載されているのですが、この参考文献リストにもこれらの論文があげられており簡単なコメントが書かれています。

C. D. Warner Jr., "Evaluation of program testing," TR 00.1171, IBM Data Systems Devision Development Laboratories, IBM Poughkeepsie, N.Y., 1964
<Beizerのコメント>
  『COBOLとFORTRANソースプログラムを対象にしたハードウェアの命令語モニタについてのいちばん最初の解説書』

I. N. Hirsh, MEMMAP/360, TR-p-1168, IBM System Development Division Product Test Laboratories, IBM Poughkeepsie, N.Y., 1967
<Beizerのコメント>
  『ソフトウェアのステートメントカバレージとブランチカバレージアナライザについての初期の論文』

1960年代の状況はSiemens Corporate Research社のHutchinsの論文でも言及されています。

M. Hutchins, et al., "Experiments on the effectiveness of dataflow- and controlflow-based test adequacy criteria," ICSE, pp. 191-200, 1994

Hutchinsは1969年のIBM社のSchillerの論文を参考文献として、少なくとも1960年代にはソフトウェアのテストの十分性を監視するために制御フローに基づくコードカバレッジ基準が利用されていたと書いています。

H. Schiller, "Using MEMMAP to measure the extent of. program testing," Report TR 1836, IBM Systems Development Division, Poughkeepsie, NY, Feb. 1969
<Beizerのコメント>
  『ステートメント網羅、ブランチ網羅解析についての初期の論文』

Hirsh、Schillerの論文から、1960年代後半にIBM社でMEMMAPというカバレッジ計測ツールが使われていたということが分かります。
その後、1970年代に入って各社で本格的なカバレッジ計測システムの開発と適用が始まります。

制御フローテストの歴史(1)－黎明期(グラフの利用)

制御フローテストは、プログラムの論理の流れを制御フローグラフで表現し、あらかじめ決めた網羅基準（カバレッジ基準）を満たすようにプログラムの中のパスを選択してテストケースを設計する技法です。
ここで「グラフ」とは、ノード(節点・頂点、node)とエッジ(枝・辺、edge)の集合で構成されるもので、数学の一分野であるグラフ理論はこのグラフの性質について研究する学問です。

ソフトウェアの分野でグラフ理論を適用した最初のものは、1960年にIBM社のKarpが書いた以下の論文です。

R. M. Karp, "A note on the application of graph theory to digital computer programming," Information and Control, Vol. 3, pp. 179-190, September, 1960

この論文でKarpはプログラムのフローチャートの判定条件部分をノード、論理の流れや接続の状況をエッジで表した有向線形グラフ(directed linear graph)を書き、更に形式的に扱いやすいようにノード間の接続状況を表す接続行列(connection matrix)を作成してプログラムを解析する方法を示しています。この解析に基づいて、プログラム中の到達しない終端ノードを検出する方法や、接続行列を用いて複数のプログラムを合成(composite)する方法を示しています。
ちなみにKarpは1985年にチューリング賞を受賞しています(計算理論に関する長年の貢献と、特にNP完全理論への貢献に対して)。

ソフトウェアテストの分野では、1963年に米国陸軍化学科のMillerとMaloneyが書いた以下の論文でグラフを利用してテストデータを設計する方法が紹介されたのが最初です。

J. C. Miller and C. J. Maloney, "Systematic mistake analysis of digital computer programs," Communications of the ACM, vol. 6, pp. 58-63, February 1963

この論文では、前述のKarpが示したフローチャートのグラフ化の方法を少し修正したLogical treeを用いて、つぎのようにテストを設計する方法とテスト結果からバグのある箇所を診断する方法を紹介しています。

• logical tree に基づいてルート解析(入り口から出口へのルート＝複数のパスの組合せ)することにより必要なテストに絞り込む
• プログラム内の各ルートを通過するテスト結果の分析に基づいてバグ(mistake)のある箇所を絞り込む(あるルートのテスト結果がNGの場合、OKとなっている他のルートのテスト結果からどのパスにmistakeがあるのかを判定する)

ただし、ここで紹介された方法はグラフ理論で示されているグラフの性質を利用して解析している訳ではなく、あくまでフローチャートをグラフ表現したものにもとづいて解析するというものです。
本格的にグラフ理論を適用しグラフの性質を利用したテスト技法としては、1976年にMcCabeが発表したプログラムの複雑度を表すサイクロマチック複雑度(cyclomatic complexity)、および基礎パステスト法(Basis Path Testing)ということになると思います。

T. J. McCabe, "A Complexity Measure," IEEE Transactions on Software Engineering, Vol. SE-2, No. 4, pp. 308-320, Dec. 1976

デシジョンテーブルテストの歴史

デシジョンテーブルテストは、プログラムの仕様を条件部とアクション部からなるデシジョンテーブルという表に整理し，これに基づいてテストケースを作成する技法です。デシジョンテーブルそのものはテストのために考案されたものではなく、システム分析や設計情報を整理して記述するために開発された手法です。

◆デシジョンテーブルの歴史
デシジョンテーブルは1958年頃にGE(General Electric)社やSutherland社で考案されました。当時GE社でデシジョンテーブル(最初は"Decision Structure Table"と呼ばれていたようです)を考案したBurton Gradは"Tabular Form in Decision Logic"(DATAMATION, July 1961)で、当時の状況を次のように書いています(抜粋)。

Decision logicを記録するための表は、1957年秋から1959年のGE社のIntegrated Systems Projectで使ったのが最初である(※このProjectのリーダがGrad)。このProjectではextended entry tables(拡張指定表)形式のデシジョンテーブルをman-to-machine communicationのために使用した。
1958年後半にコンサルティング会社のSutherland社で"management decision rules"を表現するための表を使い始めた。彼らはlimited entry tables(制限指定表)形式のデシジョンテーブルを使っていたと思われる。
1959年、Hunt Foods and Industries社はコンピュータシステムの計画におけるman-to-man communicationのために、システム分析でlimited entry tablesを用いた。
1960年初めからIBM社はシステム分析やプログラミングにデシジョンテーブルを積極的に活用し始めた。(※Burton Gladはこの時期にGE社からIBM社に転社したようです)

デシジョンテーブルは考案されて間もなくコンピュータ処理する検討も開始され、1960年にGE社のKavanaghはデシジョンテーブルからGEのコンパイラ言語のソースコードを生成するTABSOL(TABular Systems Oriented Language)を開発しています。その後、1960年代には COBOLやFortranなどのコンパイラ言語のソースを生成するプリプロセッサが数多く開発されています。

1960年代のデシジョンテーブルは現在のUMLのような設計記法として期待の星だったと思われ、1962年9月には"Decision Tables Symposium"が開催されています。また、1971年にはACM SIGPLAN Notices - Special issue on decision tables(Volume 6 Issue 8, September 1971) という特集も組まれました。その後、プロセッサなどのツールはあまり発展しなかったようで、手法としての華々しさもなくなりましたが、ソフトウェア技術者としての常識的な手法としては定着したと思われます。日本では1986年にJIS X0125-1986 決定表 (Decision Tables)としてJIS規格化されています(前述の制限指定表や拡張指定表はJIS X0125の用語(訳語)です)。

◆テスト設計へのデシジョンテーブルの利用の歴史
私が調べた範囲では、テストにデシジョンテーブルを用いた最初の論文は1965年のRCA社Scheffの"An Application of Decision Tables as the Source Language for Automatic Testing"です。Scheffは自動テストツール(Automatic test equipment)へのテストシーケンスの入力方法として、デシジョンテーブルの条件部をテストカテゴリとパラメタに、アクション部を結果とテストアクションに置き換え、縦の列(ルール)をテストケースとしたものを用いています。
その後、テスト設計でデシジョンテーブルを用いている例としては、

• 1970年頃にIBM社のElmendorfが考案した原因結果グラフ技法(Cause effect graphing)では、原因結果グラフからデシジョンテーブルに変換してテストケースを設計
• 1975年のGoodenoughとGerhartの"Toward a Theory of Test Data Selection"(初めてテストデータ選択を理論化した論文)では、プログラム構造に基づくテスト設計にデシジョンテーブルを用いる方法(Condition table method)を提案

があります。
テストに関する書籍の中でデシジョンテーブルによるテスト設計が書かれているものとしては、私の知る限りではBoris Beizerの"Software Testing Techniques"の第一版(1983年)が最初です。
現在では、Copelandの「はじめて学ぶソフトウェアのテスト技法」など多くのテスト技法のテキストでデシジョンテーブルテストは基本的なテスト技法として紹介されています。

テスト技術が書かれた最初の書籍(4)

しばらくBlogを書くのをさぼってましたが再開します。

しつこいですが「テスト技術が書かれた最初の書籍」シリーズの続きです。
テスト技術に関して最初に書かれた書籍は1957年にGE社のMcCrackenが書いた"Digital Computer Programming"であることを以前紹介しました(13章の"Program Checkout")。そして、ずばり"Program Testing"という用語でテスト技術が書かれた最初の書籍は1961年に出版されたIBM社のLeedsとWeinbergの"Computer Programming Fundamentals"であることも紹介しました。

実はその後、1959年にMcCrackenがもう1冊、"Programming Business Computers(D. D. McCracken, H. Weiss, and Tsai-Hwa Lee)"という書籍を出版していたことを知りました。この書籍は日本でも1960年,1961年に
  事務用計算機のプログラミング(上)(下), 高橋茂／石井治／淵一博(訳), 光琳書院
として翻訳出版されています。日本ではこの書籍がテスト技術が書かれた最初のものかもしれません。
私は最初この和訳本の12章「プログラムの検査」のコピーを入手したのですが、この章の名称が英文でProgram Testingになっていると先に紹介した1961年のLeeds & Weinbergの書籍が最初ではなくなるので慌てて原書を探しました。結局、この12章の原タイトルは"Verifying Program Accuracy"だったことが分かり事なき(?)を得ました。参考までにこの12章の構成を書いておきます。

12. プログラムの検査 Verifying Program Accuracy
12.0 はじめに Introduction
12.1 事前のプログラム検査 Detecting Programming Errors Before Running the Program
         別の人によるプログラム検査
         パンチ・カードの利用
         プログラムから逆に<流れ図>を作ること
         テスト・ケースについての卓上計算機での検査
12.2 計算機によるプログラム検査 Using the Computer to Detect Programming Errors
         予備的なプログラムの検討
         操作卓による手動操作
         プログラムの追跡
         記憶内容の取出し
         記憶内容の<変更検査>
         動的解析法
12.3 手順の検査 Procedural Checks
12.4 検査しやすいコーディング Coding for Ease of Checkout
12.5 まとめ Summary

ところで、テスト技術が書かれた最初の書籍"Digital Computer Programming"の著者のDaniel McCracken氏が先々月の7月30日に亡くなったというNew York Timesの記事が出ていました。
氏は数多くのプログラミング関係の書籍を出版しているこの分野の重鎮でした(Daniel D. McCracken - Wikipedia)。また、1982年にMichael A. Jackson(Jackson法で有名)との共同執筆でライフサイクル有害説を主張したことでも知られています。

D. McCracken and M.Jackson, "Life Cycle Concept Considered Harmful," ACM SIGSOFT Software Engineering Notes, Vol.7, No.2, 1982
   (*)この論文の紹介が情報処理学会の「情報処理」誌(1983-09-15)に掲載されています。

New York Timesの死亡記事を見ると、McCracken氏は1930年生まれなので"Digital Computer Programming(1957)"は氏が27歳の時に出版されたものということになります。当時はコンピュータやプログラミングは新しい分野だったということもありますが、若い内から活躍していたすごい方だったのですね。合掌。