【ソフトウェアテスト】結合テストをどうすすめるか

現在のプロジェクト、一つ前のプロジェクトで結合テスト（統合テストやITなどと呼ばれる）にテスト設計部分から関わったことである程度テストに関する知識というか経験が得られたような気がする。これまでも決して結合テストに関わっていなかったわけではなかったはずだが、何故かどんなことをしてテストを進めたのか記憶にまったくない。gdbでCのプログラムをちょこちょこ進めたアレは単体テストだったような気もするし、バッチを叩いて結果を確認したアレは結合テストだったはずだが...

ウォーターフォール開発モデルでの結合テスト

私はWF（ウォーターフォール）開発モデルでしか開発をしたことがないので、それ以外の開発モデルでのテストの経験も当然ありません。JSTQBの参考書によればイテレーティブーインクリメンタル開発モデルという開発モデル（アジャイル開発モデルやプロトタイピングなど）では、まずテストケースを作成してUTを実施してからソースの実装を行う、なんていう手段を取るようですがちょっとイメージがわかないですね。

現在のPJ、そして一つ前のPJもWEBシステムでした。実はWEBシステムのPJ自体も一つ前のPJが最初でなにをテストすればいいのか手探り状態でした（じゃあWEBシステム以外なら手探り状態じゃないのか？と言われたら答えはNOだろうけども）。

話を戻すと、WF開発モデルであれば有名なV字モデルというものがあり、結合テストであればテストベース（テストケース設計などで参照するもの）は基本設計書がベースになる。

f:id:starscream1999:20180505231221p:plain — 有名なVモデル

基本設計書といってもPJによってドキュメントは様々あると思いますが、自分が参画したPJでは、以下のようなドキュメント類がありました。

画面定義書
バッチ仕様書
テーブル仕様書
コード定義書
画面遷移図
CRUD図
システム構成図
業務フロー図

単体テストでテストベースとして参照されるのは、画面定義書だったりテーブル仕様書、コード定義書だったりするので、実際厳密な線引がハッキリしてるわけではないと思う。ただ、テスト単位で「なにをテストするのか」ははっきりさせておかないといけない。

なにをテストするか目的と手段をはっきりさせる

なにをテストするかというのは、テストケースの期待値に書いてあるけれども、もうちょっとマクロな視点で考えたときに「テスト計画書」というものを作ってPJ全体で共有できるとと良い。なにをテストするか、ということはなにをテストしないかもわかってないといけないということ。

テスト計画書ってなに？という感じだが、以下のようなものを盛り込んだドキュメントのこと。

テスト目的
テスト戦略
テストすべき機能
テストしない機能
テストアイテムの合否判定基準
中止／再開基準
テスト成果物
テストタスク
スケジュール
リスクと対策

実は今のPJに参画するまでテスト計画書なんて見たことも聞いたこともなかった（実は前のPJでもテスト計画書自体はあったらしいけれども）。他のPJでもあったのかは今となっては不明だけど、よく考えなくてもこれがないと指針がはっきりしないので、大きなプロジェクトだと必須なドキュメントなのではなかろうか...

ちなみに「テスト計画書を書いてね」と言われても全部一人で書けるわけないのでそれぞれパートを分けて役割分担するのが普通なのかもしれない。システム側だけでなく基盤側もテスト範囲に含むような場合、基盤チームの人でないとハッキリしないことも多いだろうし、協力会社として参画してればテストの中止／再開基準なんて一人で決められるものではないし。

テスト目的には、何のためにテストを行うかを明記する。結合テストと言ってもシステム内結合(IT1と言ったりする）とシステム外結合（IT2と言ったりする）で分けてテストするケースが多いと思うので、IT1での範囲とIT2での範囲を明確化して、さらにIT1ではなにをテストするかIT2ではなにをテストするか～といった感じで項目ごとに記述する。

たとえば、項目として「機能検証」があり項目詳細として「全画面・全機能・全帳票が仕様どおりに動作することを確認する」がテスト目的となる。

テスト戦略には具体的にどのようにテストを行うかを書く。今回テストのリスクと対策もガッチリ書いたけど、品質管理的にNGを食らうらしいので非常に抽象的なものに書き直されていた...

テスト計画を基にテスト設計やテストケース作成をおこなう

テスト目的がハッキリしたので、実際にテスト設計を行う。ここでは、方針を具体化する。テスト観点やテスト対象の機能を実施単位に分割したりする。

悩ましいのはテスト観点で、あまり具体的にこの観点が必要・不必要というのはないような気がするので、取捨選択が難しい。これは前のPJでも観点を作った人に「どのように観点を選定したのですか？」と聞いたけれど「これまでの経験で決めました」と言っていたし、今回も似たような選定方法で決められていた。

テストケースはテスト観点をベースに画面なら画面遷移の確認だったり、DBの更新結果の確認だったりを期待値として書いていく。データの更新などは単体テストでもやっているだろうし、どのあたりまでを確認範囲とするかやどうやって確認するか（画面上で確認できるレベルまでしか見ないのか、DBの中身まで確認するのかなど）はプロジェクトによると思う。

難しいな、と感じたのは単純な画面遷移でも「どのような前提条件で」画面遷移するかなどの機能以外の部分の記述で、業務フローからテストシナリオを起こしていれば別だが、起こしてない場合単なる機能確認になるので実際に打鍵する際の手順が不明確になる点。

画面遷移だけでなく、ボタンクリックやリストボックス選択などのイベント系処理に関しても、入力値が必要な場合に妥当な入力値はなにか？という部分は業務を知らないとテストケースに書けない。とりあえず最大桁数を入力値とする、という形でテストケースを書いたことがあったが数値計算が必要な画面項目などでは範囲を超える入力になってテストが進まなかったりした経験もあった。

このように「正解がない非常にモヤッとした状態」というのはありがちなので、誰かが「とりあえずここはこう進めることにする」と旗振りをするしかない。テストケースを書いている段階で基本設計書が仕様変更で更新されていることもあるし、色々と決まったとおりに進まないこともままある。

テストって難しいなって改めて思います。