結合テストの歴史と進化 第1回：IBMメインフレーム時代

はじめに

現代のソフトウェアテストは、GitHubアクションでのCI/CDやマイクロサービスの結合テストなど、高度に自動化された環境で行われています。このような便利な環境に至るまでの結合テストの歴史を紐解きながら、現代のテスト手法への理解を深めていきたいと思います。

IBM System/360の登場

1964年、IBMは革新的なメインフレームコンピュータ「System/360」を発表しました。
それまでのコンピュータは科学計算や事務処理等、特定の用途専用に設計されており、別の用途に使いまわすことは困難でした。
そんな時代に登場したSystem/360はOS（オペレーティングシステム）の概念を確立し、ハードウェアとソフトウェアの分離を進めることで、様々な用途に汎用的にコンピュータを使用できることが画期的でした。
「360」というのは360度を表し、あらゆる用途に対応できる「全方位」であることを示しています。
これは、ソフトウェア開発の歴史における重要な転換点となりました。

パンチカードの時代の結合テスト

当時のプログラミングは、パンチカードを使用して行われていました。一枚のカードに一行のプログラムが記載され、数千行のプログラムは文字通り、段ボール箱いっぱいのパンチカードの山となりました。

* 1960年代のアセンブリコード例
* 二つの浮動小数点数（DATA1とDATA2）を加算し、その結果をRESULTに格納する
START    BALR  R12,0         * ベースレジスタの設定
        USING *,R12
        L     R3,DATA1       * データのロード
        A     R3,DATA2       * 加算
        ST    R3,RESULT     * 結果の保存
DATA1    DC    F'100'        * 定数定義
DATA2    DC    F'200'
RESULT   DS    F             * 結果格納領域
        END

このような環境での結合テストには、以下のような特徴的な課題がありました：

1. 物理的な制約

   • プログラムの修正には、パンチカードの差し替えや再パンチが必要
   • カードの順序が狂うと、プログラム全体が機能しなくなる
   • テスト実行のたびにカードを読み込む必要があった

2. 時間的な制約

   • コンパイルに数時間かかることも
   • エラーが発生した場合、次の実行まで丸一日待つことも

初期の結合テスト手法

IBMのプログラマー、Fred Brooks（のちに「人月の神話」の著者）は、当時のテスト手法について以下のように記しています

"プログラムの結合は、まるで巨大な手術のようだった。すべての部品が揃っているか確認し、一つずつ慎重に組み合わせていく。エラーが発生すれば、それは大きな手戻りを意味した。"

当時の結合テスト手法の特徴

1. ステップバイステップの結合

   • 最小単位のモジュールから開始
   • 動作確認済みのモジュールに、新しいモジュールを一つずつ追加
   • 各ステップでの詳細なログ取得と解析

2. バッチ処理としてのテスト実行

   • テストケースもパンチカードで準備
   • 結果は紙の出力で確認
   • エラーの場合、メモリダンプ¹を解析

メモリダンプによるデバッグ

Memory Dump Example (1960s):
0000: 4C00 0000 0000 0000  L....... 
0008: 5820 1004 0000 0000  ........ 
0010: 5010 2000 0000 0000  ........ 

このようなメモリダンプを読み解き、問題箇所を特定する技術は、当時のプログラマーにとって必須のスキルでした。

結合テストの標準化への第一歩

この時代の経験から、以下のような教訓が得られました

1. モジュール間のインターフェース定義の重要性
   • メインフレーム時代、複数のプログラマーがそれぞれパンチカードでプログラムを作成
   • プログラム間のデータ受け渡しは、主にメモリ上の共有領域を介して行われていた
   • インターフェースの定義があいまいだと、深刻な問題が発生
2. 段階的なテストの必要性
   • コンピュータの実行時間は非常に高価（1時間あたり数千ドル）
   • デバッグ用のメモリダンプ出力も大量の紙を消費
   • 一度にすべてのモジュールを結合すると、エラーの原因特定が困難
3. テスト結果の記録と追跡の重要性
   • テスト実行には長時間を要する（数時間〜一日）
   • コンピュータリソースの予約が必要
   • 同じバグの再発が大きなコスト損失に

これらの教訓は、のちのモジュール化時代における設計手法や、現代のテスト戦略にも大きな影響を与えています。

振り返りと現代への示唆

IBMメインフレーム時代の結合テストから得た現代の結合テスト戦略。

1. 体系的なアプローチの重要性

   • 当時確立された「ステップバイステップの結合」の考え方は、現代でも有効
   • テスト計画の重要性は時代を超えて不変

2. ドキュメンテーションの価値

   • インターフェース仕様の明確な定義
   • テスト結果の詳細な記録

3. 制約がもたらすイノベーション

   • 限られたリソースでの効率的なテスト手法の開発
   • エラー検出・診断技術の進化

1. メモリダンプとは
   コンピューターが動いている最中のメモリの中身は、プログラムの命令やデータでいっぱいです。このメモリの中身を、ある特定のタイミングでファイルに保存することで、その時点でのコンピューターの状態を記録することができます。 ↩