読者です 読者をやめる 読者になる 読者になる

Test Automation

テスト自動化とか品質とか勉強会とかやってるエンジニア(Automation Architect)のブログです。

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

Refactorable Testing Architecture 継続的システムテスト

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

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

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

2次元の表

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

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

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

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

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

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

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

利点の前提条件

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

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

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

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

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

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

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

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

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

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

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

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

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

  • テストスクリプトを実装するエンジニアにとっての必要最低限な情報は何か?
  • テスト設計プロセスの中で、テスト実装者が実行した方がプロセスが最適化されるものは何か?

についての議論を踏まえ、自動テストに最適化されているプロセスを定義し比較する事が必要である。

まとめ

 僕はこれらの「2次元の表によるテスト管理の限界」について、テスト設計がリファクタリング不可能である問題、とこれから呼ぶ事にする。

 継続的インテグレーションが導入されているプロジェクトでは、リファクタリングを定期的に行い技術的負債を返済しながらプロダクトの品質改善を行うのと同様に、テスト設計も定期的に改善されていかなければならない。そう、きっとテスト自動化プロジェクトとスクラムはとても相性がいいのだ。

 次回のエントリでは、アジャイルテスターの人達がどのようにテスト設計とそのリファクタリングについて考えているのか、何も考えていないのか、について書く。

参考情報

http://qualab.jp/materials/SOFTEC2012-2.pdf

JaSSTソフトウェアテストシンポジウム-JaSST'15 Tokyo レポート