【ソフトウェアテスト】WEBアプリケーションにおける結合テストの考え方

「結合テストの考え方」なんて大げさなタイトルにしてしまった...

一般的なテスト論とかじゃなくて、あくまで現在自分が関わっているプロジェクトで、結合テストのテスト項目を作成している自分の感覚として思ったことを書きたいと思う。

前提として、私は今までWEBアプリケーションの開発現場にほとんど関わったことがなく、何をテストの観点とすればいいのかわからない状態で現在のプロジェクトにアサインしています。過去にWEBアプリケーションではなくWindowsアプリケーションの開発は若干関わったことがありましたが、「結合テスト」にはまったく携わっておらず「何をテストすればいいのだ？」という有様でした。

■結合テストはまず何をテストするか「観点」をまとめることから始める

やみくもにテストをすればいい、というわけではなくやはり何をテストするかをきちんと観点としてまとめる必要がある（当たり前か？！）、単体テストでも観点はまとめていたはずだけど、実際にテストケースを作成する機会というのがあまりなかったので今回非常に勉強になった。

■具体的にどんな観点が必要か

対象となるシステムの規模にもよるし、単体テストの状況とかいろいろな要因が絡むのでシンプルに「これだけあればよい」というのは難しい。今回、観点を作成した人に「何か参考にしたのか？」と聞いたのだけど、結局「これまでの経験」と言っていた。全く参考にならない回答だが、事実だろうなと思った。

「結合テスト　観点」でググればおそらくそれらしい検索結果は出るだろうが、実際のシステムに合致するかと言えばそんなこともないだろう。やはりある程度自分の過去の経験とかで「これが必要、これは不要」と取捨選択するものなのかもしれない。

正解不正解はさておき、今回のシステムで観点として挙げたものは以下のようになった。全部ではないが、このような観点に従ってテストケースを作成した。

画面間の遷移確認（元画面から次画面への遷移確認、元画面からの回帰確認、自画面のリダイレクト確認、3画面以上の複数画面間の遷移確認、A～Zまでの全通し画面遷移確認）

画面間のパラメータの受け渡し確認（セッション・Cookie・DBへの格納時の確認等）

帳票出力確認（出力・入力・マスタメンテナンスに伴う出力確認）

他システムとの連携確認

業務エラーにおける挙動確認

システムページにおける、権限制御確認

等々...

観点として挙がっているものの、実際にテストケースを作成できるとは限らない

観点作成者は「おそらくこういった観点が必要であろう」という感覚で観点を上げているので、実際にテストケースを作成するにあたって、システムのすべての画面が同じ観点でテストケースが作れるとは限らない。

例えば、終端の画面なら「次画面への遷移確認」という観点に基づくテストケースは作れない。挙げるときりがないので挙げないが、このような画面ごとにケースの作成が可能不可能というのはあるので、画面単位で「この画面はこの観点に対応しているか？」という調査が必要。

出来ればこの調査自体、複数人で同じ画面を調査することが望ましいと思う。なぜなら、一人で調査するとまったくズレた見方をしている場合があるからだ。というか実際にそうした。システムの仕様を把握していたつもりでもまったく勘違いしてたりすることもあるので、こういう二重チェックは非常に有効だと思った。

ちなみに今回のWEBアプリケーションにはモバイルに関するテストは存在しない。そもそもモバイルに対応していないからだ。また、外部攻撃に対するテストケースもない。イントラネットだから？ちょっとその辺はあいまいなので確認が必要だなと今思った。

■ある程度は単体テストと被るようなテストケースになっても仕方ない！

単一画面の入力・出力結果の確認（項目ごとのバリデーションチェック等）はさすがに不要であると思うが、「これって単体テストの範疇じゃないの？」というようなケースもある程度は「単体テストの実施で漏れていたら拾える」くらいの感覚でケースとして計上して問題ないと思う。帳票の出力確認なんてのもその範疇だと思うが、ある程度重要な機能であれば致し方ないと思うのだが、どうか？

・・・今はまだテストケース作成段階なので、また気づいたことがあったら追記するつもり