テストの自動化、その最新事情：テストの自動化に向けたアジャイルなアプローチ

[（翻訳/株式会社サイクス 宗雅彦），StickyMinds.com　]

　テストの自動化を“もっとアジャイル”にすることについて、特別なものは何も必要ない。テストの自動化に対する視点を広げ、自分に役立つツールをインターネットで検索し始めるだけでよい。後は、ほっておけば何とかなる。しかし、たいていの場合はチーム独自にツール開発担当者を用意する方がうまくいく。優れたツール開発担当者は、ソリューションを短時間で準備できるよう、Java、Perl、あるいはPythonといった高級言語のプログラム手法に関する知識があるはずだ。優れたツール開発担当者はツールに対する強い愛着があり、無償あるいは低価格の役に立つツールについて勉強している。優れたテストツール開発担当者なら、テストの何たるかも分かってくるだろう。

　“アジャイルな自動化”においてわれわれが利用する方法は分かりやすい。ツール開発担当者がテスターの作業を監視し、テスターが進める作業にツールがどのように役立つかを判断する。ツール開発担当者は、個人的な計画を強いるのではなく、テスターの身になって支援するという姿勢で望む。

　もしツール開発担当者がいない場合は、1人1人のテスターが自動化のチャンスに目を光らせる必要がある。テスターがツールやプログラミングを知れば知るほど、有益なツールを見つけるのに効果的であることを肝に銘じたい。

テストの自動化に向けたアジャイルアプローチの例

　あるテスターが2つのCSVファイルの抜き取り検査を行ったが、両者の違いを発見できなかった。そこで、テスターはDannyに助けを求めて2つのCSVファイルを比較したところ、データが1列すべて間違っていることをツールが教えてくれた。さらに1時間調査したところ、データの非整合性を見つけるもっと良いツールがあることも新たに分かった。

　Jamesの方は、オークションの状況を常に詳細にレポートできるオークションシステムをチェックするテストチームを助けた。このツールを使ったところ、テストケースの実行に一切ミスがなく終わっただけでなく、目的のシナリオと条件のテスト完了を自動的に確認できた。このチームは、およそ2年間もこのようなレポート機能を使わずテストを行っていたが、ツールの開発には着手から完成までわずか3時間しかかからなかった。

　Dannyは、数万レコードを一晩でWebベースのデータベースフロントエンドに読み込んでくれる応急プログラムを、Perl WWW::Mechanizeモジュールを使って書いた。すると次の日には、大規模データベースとの連係に関連するアプリケーションのパフォーマンスの問題がすぐに判明した。

　インストール手順がファイルシステムやレジストリに与えた影響をテスターが正確に知るのにインストールテストツールが役立つことは、2人とも実感できた。

　どの例でも、わずか数時間の作業だけで大きな価値を生み出すことができた。われわれは、テスターたちがツールを使ってテスト作業を改善するのを助けたのだ。われわれにとっては、ツールがテストをサポートする、というのがテストの自動化の定義だ。このことから、テストの自動化は、寝ている間に文句もいわずにテストをしてくれるロボットの概念をはるかに超えるものであることが分かる。自動化されたテストの設計はこれまでもしてきた。何らかの問題に対してテスターに注意を呼び掛ける自動テストも利用してきた。これらはどれもテストの自動化だが、もっと新しい自動化を考えてみよう。

実用的なものを40時間以内で投入すること

　これができなければ、作業が間違っていたということになる。

　ソリューションを段階的に配布していくことは“アジャイルな自動化”のカギだ。実働1週間以下で配布されたソリューションと、それ以上時間をかけたものの間に大きな違いがあることは分かる。プロジェクトが長引けば、リスクが増し、ほかの短時間作業に利用できるであろうリソースも消費される。時間を要する作業は数日単位で配布できる単発の短い作業に切り分け、次の作業に着手する前に配布とテストが完了するようにしたい。

　自動化プロジェクトがうまく進んでいない場合は、1カ月後といわず、プロジェクト着手からおよそ1週間後にはそれを把握したい。ソリューションをいじり過ぎていたらどうなるだろうか？ アジャイルアプローチでは、差分をいくつか配布した時点で、自動化の品質が十分かどうかはテスターが判断し、ツール開発担当者は自動化のほかの優先事項に取り組む。

　作業期間が短ければ、ツール開発担当者やテスター（特に兼任の場合）がプロジェクトを自己承認する方が適切となり、管理上の見落としを多数排除できるようになる。自動化作業の期間が1週間を超えると、上司の承認が必要になる可能性が高く、自動化プロセスは一段と複雑かつ遅いものになってしまう。

　一部の作業に40時間以上かかるようなことが予想される場合、あるいはあまり時間がかからないと思った作業に40時間近くかかっている場合は、作業をいったん保留にすべきだ。本当に細分化できているか、そのアプローチが本当にうまくいくのか考えたい。

自動化の世界に伽藍（がらん：Cathedral）はない

　これまで見てきた多くの「昔ながらの」自動化努力は、専門家が伽藍という殻に閉じこもっているように思える。Jamesはあるケースで、クライアントとあまりに懸け離れ過ぎていて、彼が話を聞いたテスターにはその存在すら分かっていなかった、という大規模な自動化戦略を目にしたことがある。開発作業がすでに9カ月も進められていたにもかかわらずである。Dannyの方も、チームのニーズを考慮しない中央集権化された自動化作業グループにテストチームが反発するのを見たことがある。

　では、殻に閉じこもる伽藍形式の逆は何だろうか？ それは、バザールの屋台のように可能な限り多くの種類のツールを使って日々のテストプロセス主導で進む自動化であり、将来的なものではなく、具体的な当面のニーズに対応するテストの自動化だ。難しいテストを自動化するインフラの構築に長期的な自動化プロジェクトが必要なことは間違いない。だが、大規模な戦略は、すぐに大きな効果を発揮する多くの小さいソリューションを見えなくしてしまう、というのがわれわれの経験からいえることだ。

　アジャイルテストの自動化に絶対不可欠なのは、実施中のあらゆるテスト作業でツールが役立つ場所などに関し、幅広い視点で考えることだ。初めて作業を自動化する、もしくは既存の自動化を改善するには、ツールの部品をダウンロード、作成、もしくは購入し、各部品を1週間以内に完成させたい。組織内にツール開発担当者を置き、「自動化の伽藍」に進展を邪魔させないようにしたい。ツールはかなり大きな力となり得る。すぐにも活用していただきたい。

メモ：Neill McCarthyの助言に謝辞を述べる。

<参考資料>
・Agile Test Automation白書、James Bach著
・「The Cathedral and the Bazaar」（伽藍とバザール）、Eric Raymond著
・「Manifesto for Agile Software Development」

［著者について］Danny R. Faughtはテストコンサルタント、作家、そしてトレーナーとして活動中。StickyMinds.comで記事を連載中で、各所のSoftware Quality Engineeringカンファレンスで講演している。Open Testware Reviewsを発行し、テキサス州フォートワースのTejas Software Consultingも経営する。詳細はtejasconsulting.comをご覧いただきたい。コメントは faught@tejasconsulting.com まで。James Bachはテストトレーニング／コンサルティング会社Satisfice, Inc.の創業者（Cem KanerおよびBret Pettichordとの共同設立）で、「Lessons Learned in Software Testing」という著書がある。StickyMinds.comのコラムも多数執筆し、Software Quality Engineeringカンファレンスでも講演している。コメントは james@satisfice.com まで。

翻訳/株式会社サイクス 宗雅彦