テスト自動化プロジェクトでExcelを使わない１０の理由

モチベーション

　この記事はソフトウェアAdvent Calendar 2017の11日目のブログエントリとして書いています。

　昨日参加したシステムテスト自動化カンファレンス2017で、「もう２年以上、テスト自動化プロジェクトの中でExcelを使ってないなぁ」ということを思い出した。

　２年半前にガチのExcelファイルで書かれたテスト設計ドキュメントを初めて見て、このやり方ではテストが成長できなくなるということを痛切に感じた。その時の考えを２次元の表によるテスト管理の限界 - Test Automationというブログエントリにまとめてから、うちのチームではExcelをテスト自動化の中で使っていない。

　前回のエントリより２年半経って、Excelを使ってない理由についての考えがより鮮明になってきた、ここでは、それらExcelをテスト自動化で使わない理由をつらつらと書き連ねていく。

テスト自動化プロジェクトでExcelを使わない理由

理由①：Excelはユーザー環境の互換性や移植性が低い

　Excelの問題の１つ目は、開発者や運用エンジニアなどを含めたテスト自動化プロジェクトの大半のステークホルダーの環境で期待通りに動作しないことだ。Windows上で綺麗に整形されていたり、職人技の関数芸やVBA芸でまとめられたExcelファイルは、残念ながらMacやLinuxでは期待通りに表示されない。僕が今年見た一番ひどいExcelファイルでは、１回データを入力するごとに僕のMac上ではエラーが表示される。

　開発エンジニアや運用エンジニアに人気のOSであるMacやLinuxでまともに動かないツールをテスト自動化プロジェクトで使うことは、エンドユーザー向けにWindows Phoneでは動くが、AndroidやiOSではバグだらけのアプリをリリースするようなものだ。

理由②：テストケースに対するスケーラビリティが低い

　Excelはデータサイズのスケーラビリティが低い。まず、仕様が最大約100万行、最大約2万列と、一般的なテスト自動化プロジェクトで取り扱うテストケース数を考えると少なすぎる。また、実際には数万行を超えたくらいから動作がもっさりしてくる。Excelで表現できるテストケース数はせいぜい数百から数千だろう。

理由③：テストエンジニア/クライアントに対するスケーラビリティが低い

　Excelはユーザ数に対するスケーラビリティが低い。ファイル共有について、メール、共有ファイル、オンライン版など、どれを使うかにもよるが、そもそも数百人が同時にアクセス＆編集するユースケースを想定しているものではない。多分、同じタイミングで一つのファイルを編集する人間は一人か、せいぜい声を掛け合える範囲の数人を想定しているように思う。

　この問題はExcelファイルにアクセスするのが人間でなくテストクライアントの場合、顕著に起こる。テスト実行時間が長くなってきた場合など、テストクライアントを複数並べ平行に実行するようにすることでテスト実行時間を短縮する。数十から数万のテストクライアントが同時に１つのExcelファイルにアクセスした場合、ここがボトルネックになってしまうことは明白だ。

理由④：テスト実行頻度に対するスケーラビリティが低い

　Excelはテスト実行頻度に対するスケーラビリティが低い。同じテストをプロジェクト中に一回、または年に数回程度実行するだけならばExcelでも十分だ。しかし、ほとんどのテスト自動化プロジェクトの目的は柔軟なテストの実行だ。一年を通して毎日継続的に実行したり、場合によっては1日に何百回も実行することもあるだろう。

　テスト実行頻度が増えるにつれ、例えば、テスト結果ドキュメントの数も増大する。Excelでテスト設計を管理すると、数万に及ぶテスト結果との対応関係をとっていくことが難しくなってしまう。

理由⑤：テストケースの最新性の低下

　ExcelファイルがローカルPCと共有ファイルサーバーで２重管理される場合、テストケースの最新性が低下する可能性がある。共有ファイルサーバーにあるファイルが最新なのか？最新のファイルが誰のローカルPCにあるのか？などのデータの最新性の問題が簡単に起こる。加えて、複数のメンバーがローカルのファイルをどんどんと更新し続けたため、あとで変更を１つのファイルにマージするのが大変になるなんてのも、よく聞く話だ。

　これらの問題は、継続的インテグレーション(CI)のような、継続的にファイルをマージしていくフローを作ることで防ぐことが可能だが、ExcelユーザにはCIのような文化がそもそもない

理由⑥：テストケースの差分管理が煩雑

　Excelは２次元でデータを表現するため、行指向でデータを管理するSVNやGitで差分管理しようとすると煩雑になる。極端な例で言えば、１列追加しただけでもすべての行に変更が入るため、データ更新履歴としてはすべての行が対象となってしまう。そのためPullRequestのレビューで、ソースコードとテストケースの変更箇所の比較を行ったりすることが煩雑になってしまう。

理由⑦：テストコード設計の表現力が低い

　テスト設計の成果物であるテスト設計ドキュメントは、その次のアクティビティのテスト実装の入力になる。テスト自動化プロジェクトの場合は、テスト設計ドキュメントを入力として自動実行可能なテストコードを実装する。ここで問題になることは、２次元の表形式のテスト設計は、オブジェクト指向設計などのプログラム設計の手法を用いたテストコードの設計を表現できないことだ。

　例えば、テスト設計では個々のテストケースがテストに必要な情報を網羅する完全性が重視されるが、テストコード設計では、重複する部品を再利用可能なクラスとして定義することが重視される（今年のアドベントカレンダーのこれとかこれとか）。

理由⑧：テストケースの表現の煩雑さが増す

　１つのテストケースは、事前条件、テスト対象、テスト手順、テスト条件、期待値、環境など様々な情報によって表現される。これは、テストケースを表現する軸は多次元であることを意味するが、Excelの表では２次元で表現することになる。

　人間は多次元のデータ操作が苦手なので、多次元のテストケースを非正規化しExcelで表現することにも手動テストの場合には一定の価値がある。しかし、コンピュータもデータ操作するテスト自動化プロジェクトの場合、多次元のデータを２次元で表現するとデータモデルが煩雑になり自動化が難しくなってしまう。

理由⑨：テストケースの保守性<テスト項目の追加>

　Excelの凄いところは、データサイズがそれほど大きくない場合、データの追加や変更のみならず、スキーマやデータモデルの変更も簡単に行える点だ。データベースなどではスキーマ変更などを伴う変更も、列を追加したり変更したりするだけで出来る。

　しかしこの簡便性は、データスキーマの一貫性とトレードオフの関係にある。データベースの煩雑なテーブル定義の制約は、一方でスキーマの一貫性を保証する役割を担っている。しかしExcel自体はスキーマ変更を保証しないため、例えばExcelファイルのテストケースに新しい項目を追加する場合、人間がすべてチェックす必要がある。数十万、数百万のテストケースすべてに対しスキーマの一貫性をチェックするのは困難だ。

理由10：テストケースの保守性の低下<リファクタリングが困難>

　テストケースが増えてきたとき、テスト設計をリファクタリングしたくなることがある。テストカバレッジが下がらないことを保証しながら、テストスイートのグルーピングを変更したり、テストの実行順序を変更したり、テストケースを削除したりする作業だ。定期的にリファクタリングすることで、テストケースを継続的に保守可能な形に保つ。

　テスト設計をリファクタリングするためには、多次元のテスト設計を様々な２軸に射影することが不可欠になるが、もともと２次元の表で表現されている場合、この写像が困難だ。そのため、大胆なリファクタリングを行って大量のテストケースを削減することなどができなくなる。

まとめ

　テスト自動化プロジェクトでExcelを使わない理由をつらつらと書いてきた。もちろんExcelは素晴らしいツールだし、場合によってはテスト自動化プロジェクトでも使っていい場合もあるかもしれない。例えば、チームにあったテスト設計のアプローチを議論する際には、数百くらいのテストケースをExcel上で操作しながら話し合うのはいいかもしれない。また、テストレポートに掲載するグラフのドラフトバージョンを作成したりするのにもExcelは簡便なツールだ。

　一方で、テスト自動化プロジェクトに組み込むためには、Excelには制限が多すぎる。特に、テストケース数やテストエンジニア/クライアント数に対するスケーラビリティの問題は、テスト自動化にとっては致命的と言える。また、繰り返し実行することが前提のテスト自動化プロジェクトでは、２次元の表でテストケースを表現することはテストの保守性に深刻な影響を与える。