テストに対する考え方

いままでSEという仕事を続けてきて、テストの項目抽出や、手法について、一般的な観点がなかなか見出せなかった。特に、新規開発完了後、障害や追加機能の対応を行った場合、どこまでの範囲を確認すればよいのか、ここに明確な基準がなかったため、新たなバグを埋め込んてしまうことが多々あった。
最近ようやく方向らしきものが見えてきたので、まとめておく。

• テストの定義

前提

システムを構成する永続データ（データベース、ファイル）に着目する。

単体テスト

機能に対するさまざまな「アクション」に対し、永続データに対する更新操作と「レスポンス」が正しいかを確認する。

結合テスト

複数機能間の更新操作による応答が正しいかを確認する。

上記「単体テスト」にて使用している単語の定義は以下のとおり。

アクション

機能に対する起動トリガー。ユーザ操作や、システムによる自動実行（定時処理など）が考えられる。

レスポンス

ユーザに対する結果の提示を表す。画面表示の更新や、帳票出力などが考えられる。

• 修正に対するテスト範囲の洗い出し
  • モジュール依存による単体テスト影響範囲の洗い出し
    • 修正モジュールが他のモジュールの継承元となっている場合、派生先モジュールの単体テスト項目についても影響ないか確認する。
    • 修正モジュールが他のモジュールから呼び出されている場合、呼び出し元モジュールの単体テスト項目についても影響ないか確認する。
  • 永続データの参照による結合テスト影響範囲の洗い出し
    • 永続データの更新方法が変わらない場合、修正モジュールが参照している永続データを更新する機能との関連による結合テスト項目について確認する。
    • 永続データの更新方法が変わる場合、上記の項目に加え、更新対象となる永続データを参照する機能との関連による結合テスト項目について確認する。この確認は、再帰的に全ての機能と結合テスト項目を抽出して行う。

以上の方法で、記憶にある限り修正に伴うデグレードは未然に防げたと感じている。
ただ、これを実現するために以下の情報が必要となる。

• モジュール - 永続データ参照更新関連表 (いわゆるCURD表)
• モジュール間クロスリファレンス

いままでこれらの情報について、それほど重要性を感じてなく、というよりは、新規開発のとき作成しても、その後の仕様変更や障害対応などできちんとメンテナンスされなかったため、ほとんど作成されていないのだが、テストのことを考えると、ちゃんと作成し、その後も正しくメンテナンスされる仕組みを考える必要があると思う。