２次元の表によるテスト管理の限界

ソフトウェアテスト業界の古き大発明

　どの業界にも大発明が起きる瞬間がある。オーディオ業界のステレオスピーカー、映像業界のDVD、携帯電話業界のソフトウェアインターフェースなどなど。これらの破壊的な発明はそれまでの常識を覆し、全く新しい利便性や効率性をもたらす。過去使われていた方法は淘汰され、長期間に渡って多くの人に親しまれる。こういった大発明は劇的に世界を変える一方、多くの人に長期間親しまれてきたため、次に起きそうな革新を阻害するという事がしばしば起きる。誰だって長期間親しんで来たものが変化する時には少なからずの抵抗を覚える。

　「２次元の表によるテスト設計とテストケースの管理」はまさにこれにあたる。これだけ多くのテスター、テストアナリスト、テストマネージャーに親しまれ、長く使われて来たのはおそらく「革新的な発明」であり「とても便利なツール」だったからだ。しかし、次世代のテストを考える場合、この大発明を棄てる事も選択肢として考えなければならない。

２次元の表

２次元の表によるテスト管理の特徴

　様々な情報をすべて２次元の表に詰め込む。これが２次元の表でテストを管理する事の特徴だ。以下のような異なる属性が一つの２次元の表で管理されているテスト設計をみなさんも見た事があるのではないだろうか？

テスト環境
テスト観点
テスト条件
テスト技法
テスト事前条件
期待値
テスト手順

すべての情報が一つのテーブルによって表されている事が大きな特徴だ。

２次元の表によるテスト管理の利点

　すべての情報が一つのテーブルによって管理されているので全体の見通しが良いというのが大きな利点の一つだ。特にマネージャーはこのテーブルを見るだけで、何をどのようにテストしているのか一目瞭然に分かる。テスト観点やテスト条件を見れば何をテストしているのか分かるだろうし、テスト手順や技法を見ればどのようにテストしているのか分かる。

　また、この２次元の表によるテスト管理の利点としてもう１点、テスト設計者とテスト実行者を分ける事が可能になる事がある。なるほど。どこかで聞いたような話だが、テスト設計とテスト実行の役割を明確に分ける事により、テスト実行の部分をスケール出来るようにする。「人月の神話」を信じているような、レガシーな大規模開発ではありえそうな話だ。

利点の前提条件

　しかし、この利点を効果的に得る為には一つの条件が前提となる。それはテスト設計に変更が入らないという事。少し条件を弱めれば、テスト設計の時点でテスト設計への変更要求がある程度予測可能である事である。

　ウォーターフォール開発が一般的であった時代には少なくともプロジェクトマネージャー、アーキテクト、QAマネージャー間では合意可能な前提であったのだと思う。しかし、アジャイル開発のようなテスト設計への変更要求が大前提の開発スタイルではいくつかの大きな問題を引き起こす。

２次元の表によるテスト管理の問題点

①テスト条件の追加•変更更要求に対し、変更箇所が多い

　テーブルを非正規化してしまっている事の弊害として、テスト設計変更要求に対して変更箇所が多いというメンテナンス容易性の問題がある。例えば、新しい仕様の追加によりテスト条件を１カ所追加したい場合、正規化しているテーブルに対してならば１カ所だけ変更するだけで済むものも、非正規化しているテーブルに対しては、select文で条件に合致するレコードを抽出し、条件に合致するレコード全てに対してテスト条件を追加する必要がある事と同じ問題が起きる。

②テスト設計の継続的改善が難しい

また、テスト設計の継続的改善が難しい事も問題である。テスト設計は一度実施したら終わりというものではなく、継続的に改善する必要がある。これには2つの理由がある。

１つ目の理由は、テストの実行結果によってテスト設計も改善する必要がある事である。テスト実行前にバグを発見可能と予測して作ったテストケースと、実際にバグを見つけたテストケースとの間にはきっと差分がある。その差分によりテストケースを追加する事は当然であるが、加えてテスト設計も見直す必要がある。

　2つ目の理由は、プロダクト側のアーキテクチャ変更に伴うものである。アーキテクチャが変われば当然求められる品質も変わる。テスト設計自体を変更する必要性が生じる。

③テスト自動化への移行の問題

　テスト自動化が成功していない事例をいくつか見たり聞いたりしてきたがその原因の一つに、手動テストが前提の"テスト設計者"と"テスト実行者"のロールモデルをそのままに、テスト自動化プロジェクトを実施したというものがある。

　よく聞く「手動のテスト実行よりも、テストスクリプトの実装の方がコストが高い」という話。今まで通りのテスト設計をして、テスト実行をテスト実装で置き換えるという前提であれば、その比較は正しい。しかし、僕はこの比較についてかなり懐疑的に考えている。「手動テストに最適化されたプロセスのコスト」と、「自動テストに最適化されていないプロセスのコスト」の比較にどんな意味があるのだろうか？

　テスト自動化へ移行する場合、少なくとも