Agile Testing Days 2015でRichard Bradshaw氏は，“テストオートメーション(test automation)”という用語の使用が，開発チームにとって，オートメーションのメリットを活用する上での制約となっている状況について説明した。
InfoQはBradshaw氏にインタビューして，テストとチェックの違い，それらが共に重要である理由，オートメーションはテストをどのようにサポートするのか，オートメーションフレームワークの活用，テストの問題に常に注目すべき理由，などについて話を聞いた。
InfoQ: テストとチェックの違いについて，詳しく説明してください。
Bradshaw: 私は現在でも，James Bach氏とMichael Bolton氏が“testing and checking refined”という記事で行った定義を支持しています。自分自身の見解を持つために，皆さんにも一読をお勧めしたい記事です。私の考えるおもな違いは，学習に関するものです。学習，すなわち知識の獲得です。私たちがテストをする目的は，ソフトウェアに関する知識，ビジネスニーズの知識を得て，その情報に基づいた意思決定を行うためです。テストをする時の私たちは，自由にシステムを探り，経験則に従い，発見に基づいて探索し，新たな情報を求めます。そして学びます。しかしながら，チェックはチェックであって，それ以外ではありません。私たちは，何らかのモデルに従ってシステムをチェックし，そのモデルに対する違いを見つけ出します。それは一連のアルゴリズムの実行であって，学習ではありません。そして私たちは，チェックした結果を評価し，問題の所在を判断します。これは人にしかできないことです。
InfoQ: そのどちらも重要であると考えるのはなぜですか？
Bradshaw: お互いに補完し合うからです。どちらか一方のみを行うのは，非常に難しいことだと思います。システムの重要機能，特にビジネスのコストや評判を損なう可能性のあるものには，チェックが必要です。それがバグかどうかは，当然ながら議論の余地があります。ですからここで指摘するのは重要なこと，例えばAmazonで購入できなかった，Slackのメッセージが遅れなかった，といったことです。それと同時に，システムの新機能もテストして，その動作を理解しておかなくてはなりません。新機能がシステムの他の部分に与える影響のテストも必要です。チェックはこのようなテストの指標になります。ある領域で変更が確認できれば，その領域を探索してテストすべきだ，ということになります。
InfoQ: 講演では，オートメーションはテストをサポートするものであるべきで，置き換えるものであってはならない，という話がありましたが，それについて説明して頂けますか？
Bradshaw: 私のこれまでの役割の中で，オートメーションはテスト，特に回帰テストを置き換えるためのものだ，という話を何度か聞きました。テスト担当者を実際にオートメーションに置き換えることができる，という議論の場に居合わせたことも何度かあります。もちろんこれは，まったくのでっち上げです。講演の要旨にこれを加えた理由は，テストやチェックに関する私のコメントと同じです。私の意見では，一般に自動テストと呼ばれているものの大部分は，実際にはシステムのモデルを体系化して，それに対してチェックを行うという，自動チェックなのです。しかしながら，先程述べたような理由で，テストは行わなくてはなりません。従って理解すべきなのは，自動チェックはテストの労力を軽減するものであって，置き換えるものではないという点です。もしテストの必要性を認めるならば，テストをより早く，より深く実施する，あるいはテストの範囲を拡げる方法を探しましょう。例えばデータ管理や状態操作，ログ解析など，テストをサポートするためにどのようなツールを開発できるのでしょうか。
InfoQ: あなたが使用しているオートメーションフレームワークの例をあげて頂けますか？それらを使って，どのようにテストを自動化しているのでしょう？
Bradshaw: よく利用しているのはjigsawの類，いわゆるjigsawアーキテクチャです。抽象化やデカップリングではよく挙がる名前だと思います。アーキテクチャの設計では，すべてをスタンドアロンの部品として設計する方法をよく用います。例えば，GUIの自動チェックの一般的アプローチとしては，次のようなものを用意します。データを管理するコードと，それをスプレッドシートから読み取るか，データベースを作成するコード。私たちのためにブラウザインスタンスを生成するコード。そのページのインタラクションを管理するコード，一般にはPageObjects。そして最後に，私たちのためにレポート結果を処理するコード。これらの部品がすべて集まって，GUIチェックの自動化に使用できるツールを形成するのです。その一方で，アーキテクチャを小さな部品で設計したことによって，これをテスト作業全体で利用することができるようになります。データ生成コードのためにGUIや，場合によってはコマンドラインインターフェースを作る場合がありますが，担当するチームメンバがこのデータ生成コードを利用すれば，DB自体の操作に関わる必要はなくなります。私が現在手掛けているもうひとつの例は，アプリの1～N種類のデバイスへのデプロイ，ローンチ，ログイン，停止という操作に，モバイルオートメーションアーキテクチャの一部を使用するものです。ワンヒットで複数のデバイスのアップデートが可能になることで，バージョン毎に15～30分の節約が可能になり，15～30分多くテストすることができます。
InfoQ: テストとオートメーションに関して，テスト担当者と研究成果を共有したいと思うのはどちらですか？
Bradshaw: オートメーションに関する話し方や考え方を変える必要があります。私たちが解決しようとしているのは“自動化の必要性”という問題ではなく，テストの問題であることを忘れてはなりません。テスト問題についてじっくり考え，最も相応しいツールを使用して，その限界を認識してください。
私がここで言いたいのは，どうしても欲しいおもちゃのように，オートメーションをただがむしゃらに追い求めている企業があることです。オートメーションを究極の目標のように捉えているチームもあります。つまり，セットアップとアクションとアサーションで構成されたスクリプトです。私たちは，このような型を破らなければなりません。テストに改良が必要なのはどこなのか，批判的に考えてください。その結果，オートメーションが有効と判断したのであれば，それを組み込めばいいのです。アプローチのボトルネックを分析してください。ただし，より深く，例えば回帰テストに時間が掛かり過ぎている，といったように分析するのです。時間が掛かり過ぎているのは，どの部分なのでしょう？ボトルネックの自動化すべき部分を見つけましょう。すべてがそうだとは限らないはずです。
そして最後に，オートメーションは間抜けなので，常に教育しなければならないことを覚えておいてください。手間がかかりますが，その時間はありますか？人であるあなたは，常に学ぶことができます。カスタムツールで武装した自分を思い描いてください。その場合，テストをどの程度改善できそうですか？