テストウェア管理のための4つの課題
テストウェアアーキテクチャを構築していくときには、図2に示す4つの課題に注意しなければなりません。
規模
自動化されたシステムテストでは、前述の図1で示したように様々なテストウェアを扱います。
自動化されたシステムテストには、何らかのスクリプトもしくはテストプログラムが必ず存在します。テスト対象のデータも必要です。そして当然ですが、メンテナンスのための何らかのドキュメント（簡単なテキストファイルかもしれませんが）も必要となります。
テストを実行すると、実行結果のデータファイルが生成されます。これと期待値とを比較することで、差分データおよび結果レポートが作成されます。
さて、もしテストケースが何百、何千もある場合にはどうなるでしょう？いくつかのファイルは共有化できるかもしれませんが、膨大な数のファイルが必要になることは容易に推測できるかと思います。特に、自動化の試みが順調に進んでいれば進んでいるほど、対象とするテストケースは増え続け、管理しなければならないファイルの数が増えていきます。この大量のファイルをいかに管理するかが1つの課題です。
再利用性
テストの自動化を実現するためには、闇雲にスクリプトを作成して、テスト用のデータを作ればよいというものではありません。
スクリプトやテスト用データの中は、同じものやよく似たものがきっと存在するでしょう。テストの自動化を成功に導くためには、これらのスクリプトやデータの再利用性についても考慮する必要があります。
コードの再利用性は、テストに限らず、一般のプログラム開発でも重要視されますが、うまくいっている現場は多くないと思います。開発者が再利用性を考慮してプログラムをコーディングしても、そのドキュメントなどが整備されていないために、別のエンジニアがすぐには再利用できなかったり、用意されている機能が何か調べるのが困難だったりするケースも散見されます。
全く同じことが、テストの自動化においても起こります。それでは、再利用性の高いスクリプトを作成し、それを他のテストオートメーター[1]と共有し、有効に使えるようにするためにはどのような努力が必要でしょうか？
また、避けなければならないこととして、既存のスクリプトのコピーを作成してカスタマイズすることがあります。これを行うと、オリジナルのスクリプトに修正が発生したときに困ります。コピーしたスクリプトも同じように修正しようにも、どれが該当するファイルなのかが分からないためです。結局、テストをしらみつぶしに実行し、大量に出るエラーからコピーされたスクリプトを見つけ出して修正するという、たいへん非生産的な作業をする羽目になります。
テストウェアの再利用性は、このような非生産的な作業を防ぐための課題です。
[1] テストの自動化を担当するエンジニア。
異なるバージョンの管理
アプリケーションに機能を追加して新バージョンをリリースする場合、それに対応するテストケースを新たに作成し、そのテストを自動化する必要があります。一方で、旧バージョンのバグ修正版を提供する状況もよくあります。その場合、機能追加に対応した新しいテストケースでは、旧バージョンのアプリケーションを正しくテストすることができません。
この問題に対処するには、アプリケーションのすべてのバージョンに対し、それと同期してテストウェアを正しく管理する必要があります。また、テスト対象のバージョンに適合するテストコードを簡単かつ間違いなく取得し、テストを実行できる仕組みも必要です。
特に、最近普及が進んでいるアジャイル型の開発の現場では、1～2週間といった短いスパンで新しい機能を実装しリリースしていくため、自動化されたテストも同じスパンで新しいバージョンを作成し、また管理しなければなりません。しかし、これは機能追加やバグフィックスなどを多く行っているアプリケーションでは大変な作業になります。これが、異なるバージョンの管理というテスト自動化の課題です。
プラットフォームや環境からの独立
テストウェアアーキテクチャの4つ目の課題は、異なる環境やハードウェアプラットフォーム上で、同じソフトウェアをテストしなければならない場合に顔を出します。
複数のプラットフォーム上で行うテストも、すべて1つのスクリプトで実施できることが何より理想的です。しかし、それが現実的ではないのは皆さんご承知のとおりです。特に、「期待結果の一部が環境に依存して変化する」ことはよくあるのではないでしょうか。例えば、プラットフォームごとに画面に出力される項目の並びや順番、文字の色、フォントが異なることはよくあると思います。このような違いの一部は、人間のテスターにとっては無視できる場合もありますが、自動化テストではこれらの違いによってテストがエラーとなることもあり得ます[2]。
また、使用するデータベース管理システムが変われば、テストのセットアップ手順や方法も都度変えることになります。テストデータをデータベースを格納するのに使うコマンドは、データベース管理システムごとに違う場合が少なくないからです。
異なるプラットフォームにまたがって自動テストを行う場合には、プラットフォームに依存する部分と依存しない部分を分けて管理できるテストウェアアーキテクチャが必要となります。これが、プラットフォームと環境からの独立というテスト自動化の課題です。
[2] この問題を解決するには、ギア本の第4章で説明されている「フィルター機能」を利用します。
