師走も半ばの2014年12月14日、東京赤坂のヤフー株式会社の会議室をお借りして、昨年に続き2回目となる「システムテスト自動化カンファレンス2014（STAC2014⁠）⁠」が開催されました。今年のテーマは「広く普及しキャズムを超えてきたシステムテスト自動化について、そのアーキテクチャやパターンについても考えていこう」というものです。なんとイベントの受付開始から24時間を待たずに191名の定員が埋まり、最終的には200名近いキャンセル待ちが出るという超人気イベントとなりました。今回はイベントの内容と共に現場の熱気もお伝えしたいと思います。

STAC2014はテスト自動化研究会（STAR）によって運営されています。STARは「テスト自動化技術における高度なスキルを検討・定義し、それを広く世に広く啓蒙する」ことを目的として2012年に発足し、本カンファレンスを主催しているコミュニティでもあります。「⁠テスト自動化エンジニア/Test Autometor」という職業を作っていきたいという熱い思いには個人的にも強く共感しています。

また今回のイベントに合わせるように、STARメンバーが中心となって翻訳した『システムテスト自動化標準ガイド』という書籍が発売されました。この本は以下のような2部構成になっています。

• 第1部：原著である『Software Test Automation』の第1部の翻訳
• 第2部：日本のエンジニアによる書き下ろしのケーススタディ[1]

本カンファレンスはこの書籍とリンクするような形で進められましたので、各セッションをより深く理解するためには『システムテスト自動化標準ガイド』のご一読をお勧めします。

開会の挨拶：松木 晋祐

STARのメンバーである松木さんから開会の挨拶です。はじめにSTARの趣旨、スコープ、これまでの実績などが紹介されました。続いて、今回の参加者の業務分野や自動化経験などのアンケート結果が紹介されました。

今回のテーマの前提として「キャズムを超えた」と言っていましたが、参加者を見ると経験が無い方が約半数とキャズムを超えてない可能性があるので、本日皆さんとキャズムを超えたいと思います！と冗談混じりに言っていました。しかし、逆に考えると経験の無い多くの方がこのようなイベントに参加すること自体が、システムテスト自動化への関心の高まりを示していると考えてよいと思います。

1時間でわかるSTA：鈴木 一裕

『システムテスト自動化標準ガイド』3章の翻訳と監修を行った鈴木さんが⁠”1時間でわか（った気になれ）るSTA⁠”というテーマで発表しました。STAとはシステムテスト自動化標準ガイドの原著であるSoftware Test Automationの略語になります。

大きなカンファレンスなどでの発表は初めてという鈴木さんでしたが、緊張も見せずに「タイトルは⁠”1時間でわかる⁠”となっていますが、1時間でわかることはないので本を買ってください！」といきなり言い放ちました。会場からは笑いがこぼれ、少し固かった雰囲気がほんわかと和みました。

鈴木さんは翻訳したSTA第1部の11章すべてを紹介してくれましたが、今回は印象に残ったところをピックアップしてお伝えします。また各章と自動化の対応づけを以下の図を使って説明していました。一口に自動化といっても人によって定義は様々であるため、このようなマップは講演者と参加者の話のコンテキストを合わせる上でとても有用だと感じています。

第1章

この本では「自動化する以前にテストはまともですか？」ということが一貫して言われています。個人的な経験からも、自動化が難しいと言っている人の中には、元々のテストの方に問題がある人がそこそこの割合で存在しているようです。

さらに自動化の長所や留意点などを伝えてくれましたので、ここでも一部紹介したいと思います。個人的に気になったところは組織の⁠”非現実的な期待を抱きがち⁠”というところです。どうしてもマネージャー層や経営層は自動化に過度な期待をしまいますので、自動化でできること/できないこと、投資や得られるリターン、メンテナンスコストなどもはっきりさせておくことが重要だと感じました。

長所

• 量の面/テストケース追加コストが安いので多数のテストケースを実行できる
• 量の面/リグレッションテストを気軽に実行できる
• 質の面/テストの実行手順の再現性が高い

留意点

• 技術面/手動のテストよりも技術力が必要
• 技術面/テストでバグ０＝品質OKではない
• 組織面/非現実的な期待を抱きがち

第3章

テスト自動化知識体系（TABOK）によると、テストスクリプトは以下の3レベルに分けられています。

Level1: リニアスクリプト、構造化スクリプト

Level2: 共有スクリプト、データ駆動スクリプト

Level3: 構造化スクリプト、キーワード駆動スクリプト

より良いテスト自動化のためにはキャプチャ時に記述されたリニアスクリプトをそのまま使うのではなく、構造を変えることでスクリプティングのレベルを上げていく必要があるとのことです。

リニアスクリプト＋分岐＋反復＋呼び出し

→ 構造化スクリプト

構造化スクリプト＋機能分割

→ 共有スクリプト

構造化スクリプト＋データの切り離し

→ データ駆動スクリプト

構造化スクリプト＋機能分割＋データの切り離し＋機能の抽象化（キーワード化）

→ キーワード駆動スクリプト

ただし全てレベルが高ければよいというわけではなく、プロジェクト規模や期間に応じた選択、さらに高レベルのアプローチでは規律の徹底が必要ということでした。

第6章

テストの前処理・後処理は複雑で退屈な作業です。一方同じような処理を実施していることが多いため切り出しやすく自動化しやすいという特徴があります。仮にテストの実行が手動でも、前処理・後処理を自動化するだけでも意味があるとのことです。

売れ行き好調

休憩時間には鈴木さんの熱いセッションを聞いた参加者が、『⁠システムテスト自動化標準ガイド』を買うために長蛇の列を作りました。割引と一日早い先行販売という2つのプレミアムも手伝って用意していた在庫は一瞬でなくなったようです。このときの最後の一冊を買ったのがラッキーにも私でした。

テスト自動化のパターンと実践：.reviewrc

関西から乗り込んできたテスト自動化好きなおじさん3人（自称）が、関西のノリで自動化について熱く語りました。

テスト自動化パターンについて／前川 博志

前川さんからは関西で検討しているテスト自動化のパターン[2]についての紹介がありました。

テスト自動化にはみんなが共通してハマる罠が数多く存在します。テスト自動化に取り組んでいる人達のさまざまな経験をアクセスしやすい形で公開することで、解決策や関連問題への気づきを与えることを目的にしているとのことです。新しいパターンやアンチパターンがある方はぜひプルリクエストを送ってみてください。

皮を剥く／石川 達也

石川さんによる⁠”皮を剥く⁠”というパターンの具体的な紹介です。

皮とはGUIのことであり、システムテスト自動化で問題になることが多いGUIの操作を飛ばし、内部のロジックを直接叩いてテストを実行するというパターンです。石川さんの経験によると、システムテスト自動化のボトルネックはほとんどが「操作技術」になるとのことです。石川さんはWindow専用の皮むき器であるFriendlyというライブラリを作成し、無料で公開しています。

Friendlyの紹介

URL：http://www.codeer.co.jp/AutoTest

「システムテストなんでできるだけ上位から叩けた方が良いけど、テストの本質的な対象でない部分がボトルネックになって自動化を諦めるなんて本当にもったいない！」という石川さんの言葉に、Friendlyというライブラリを開発した思いを垣間見ることができました。

自動家（オートメーター）を作る／三浦 一仁

“みうみう⁠”という愛称で親しまれている三浦さんによる“⁠自動家（オートメータ）を作る⁠”というパターンの具体的な紹介です。三浦さんは自動化が大好きで、実際に考え、機構を作り出す人のことを⁠”自動家（オートメーター）⁠”と呼ぶと定義しています。

自動家にとって重要なモノとして自動化術、自動化脳、自動化主義の3つを挙げていました。そしてこれらを持つエンジニアがこれからは重要視されていく、と将来の展望を熱く語る三浦さんに、会場全体が惹き込まれていました。

また自動化そのものに価値があり、それを行う自動家にもまた価値がある。そして最後は「そういう自動家に俺はなる！」という熱いコミットで締めくくりました。

三浦さんの発表はあまりに熱すぎて全てを文字では伝えることはできません。シンポジウムやカンファレンスなど機会を見つけて、ライブでプレゼンをご覧になることをオススメします。

STA 第2部：GUI自動テストの保守性を高めるには：伊藤 望

『システムテスト自動化標準ガイド』の12章を書き下ろした伊藤さんによるSeleniumでの保守性に関するセッションです。

Seleniumで記録したスクリプトをそのまま使うことは保守性が良くないため、プログラミング言語を使用したり、Excel等からスクリプトを作成するように工夫していく必要があります。

プログラミング言語を使用した場合、失敗したテストを放置せずにメンテナンスし続けることが重要です。環境がクリーンではないためテストが失敗したり、不安定なネットワーク環境のためテストが中断することは、テストの自動化に取り組んだことがある人であれば頷ける事例ばかりだと思います。チームとしてテストの結果を共有して⁠”テスト失敗への関心⁠”を高めておくことで速やかに原因を突き止めることができるとのことでした。

テストスクリプトも共通化する必要があり、プログラミングでも言われるDRYの原則やSeleniumでよく用いられるページオブジェクトデザインパターンの紹介がありました。

最後は伊藤さん自身がオープンソースで作ったテストスクリプト＆テスト結果をレポートするSahaginを紹介してくれました。

STA 第2部：状態遷移テストにおけるテスト設計と実行の自動化：きょん

システムテスト自動化標準ガイドの15章を書き下ろしたきょんさんによるセッションです。「⁠当初45ページのボリュームがあった真の15章を見せてやんよ！」という煽りからセッションが始まりました。

きょんさん曰く「テスト自動化はあくまで手段であり、ソフトウェア開発自体をより良いサイクルにするのがそもそもの目的」とのことです。ソフトウェアのリリースまでのイベントを時間軸に並べたバリューストリームマップにマッピングすることで、ムダな工程が見えてくるということでした。

ムダな工程の一例として、大きいシステムである程度網羅的なテストをしたい場合にテストケースの選択を人が実施すると時間がかかるということがあります。このムダを取るために、状態遷移に着目し、ダイクストラ法などを用いることでテストケースの選択を自動化するという実例を紹介してくれました。

テストの実行の自動化に目が行きがちなコンテキストの中で、テストケースの選択を自動化するという事例は新鮮に写りました。

STA 第2部 : ビルドプロセスとCI：長谷川 孝二

『システムテスト自動化標準ガイド』の14章を書き下ろした長谷川さんによる、ビルドプロセスとCIのセッションです。

「ハンマーを持つ人は全てが釘に見える」と言われることがありますが、数年前CIにハマった長谷川さんは、とある有名なアプリでなめこの餌やりと収穫を自動化したようです。会場の「欲しい…」というつぶやきを尻目に、長谷川さんはこのような過ち（？）を繰り返さないために、システムテスト自動化標準ガイドから知見を得ましょうと勧めました。

システムテスト自動化の基本となる5章のテストウェアアーキテクチャ、6章の前処理と後処理の自動化についての説明を行い、CIツールとして有名なJenkins以外にもCloudBeesやTravis CIなどのツールも紹介しました。またビルドパイプラインの説明とそれを実現するWalterというツールの紹介もありました。ツール自体の詳しい紹介は省きますが、このようなツールを探していた人にはかなり有用なセッションになったと思います。

最後に長谷川さんは「ツールに振り回されず、開発がはかどるCI環境を！」というメッセージでセッションをまとめました。沢山ツールを紹介した後だけに、かなり心に響く一言になったと思います。

質疑応答ではどこからそのような情報を得ているのですか？という質問に対して、ほとんどがTwitterなどのSNSからです、という驚きの回答も飛び出し、会場を湧かせていました。

社内スマホアプリのビルド配信ツールによる自動化事例：赤根 稔朗（Yahoo! JAPAN）

ヤフー株式会社の赤根さんによる社内ツールの事例を紹介です。ヤフー株式会社では数多くのスマホアプリを開発しているのですが、以前の開発では以下の4点の問題があったようです。

• ある人の環境でしかビルドが通らない
• PCに繋がらないとインストールできない
• 検証環境別のアプリがほしい
• 学習者コストが大

これらの課題に対してJenkinsと連携する社内専用のCIツールを作り、ビルドとアプリ配信の2つを自動化したとのことです。

実際にデモを見せてもらったのですが、スマホからQRコードを読み込むことで、簡単にスマホへのインストールができる仕組みになっているようです。この取り組みによりインストール作業が楽になり、潜在的なテスターが増えたということです。実際には別の開発チームが空き時間を見つけてお互いにテストを実施しているようで、組織としても素晴らしいと感じました。

社内専用のCIツールなので、そのツール自体を使うことはできませんが、赤根さんの課題へのアプローチの仕方や非公式ながら横の繋がりを大切にして取り組む姿勢などはとても参考になりました。

Test Automation Patterns 2014 冬コレ！：松木 晋祐

Test Automation Patternsとは、テスト自動化に取り組む際の経験に基づく優れた考え方、プロセスであり、Software Test Automationの著者であるDorothyさんを中心にまとめられています。パターンは以下の4つに分類されています。

• Execution／実行
• Design／デザイン
• Process／プロセス
• Management／管理

Test Automation Patterns

URL：https://testautomationpatterns.wikispaces.com/Test+Automation+Patterns

本セッションでは松木さんセレクトで来年流行ると思われる10のTest Automation Patternsと日本から提案したいと考えている2つのパターンの紹介がありました。そのうち印象に残った3つのパターンを紹介したいと思います。

Lazy Automator

怠け者は自分が楽をするためにあらゆる努力をするため、最高のテスト自動化のエンジニアになりえるというパターン

Test Selector

膨大な量のテストケースを様々な視点で選択できるように、テストケースにタグを付けておくというパターン

Red Magician（※3）

テストエンジニアとテスト自動化エンジニアを区別せずに育てるというパターン。日本から提案予定のパターンのひとつ。

欧米ではテスト設計技術とテスト自動化技術を明確に分けていますが、日本はこれからどうしていくべきか、という問いかけも含めたRed Magician（赤魔導士）パターンの提案がありました。みなさんはどうお考えでしょうか？

最後に松木さんは「以前の保証だけのテストから最近は開発のインフラとしての一面も持つようになっています。インフラという技術は色あせない技術であり、テストやテスト自動化を勉強することは価値があります。これからの超基盤技術に皆さんワクワクしていきましょう！」という熱い言葉で締めくくりました。

閉会の挨拶

実行委員長の太田さんによる閉会の挨拶が行われました。太田さんは、テスト実行を自動化するだけではなく、計画、戦略、設計などの自動化とつながる技術を身に付ける必要があるとのこと。またシステムテストは少しずつノウハウが溜まってきているところなので、それらを共有していきたいとこれからの意気込みを語ってくれました。

また本カンファレンスは来年も実施すると宣言をしていましたので、今年参加された方はもちろん、惜しくも参加できなかった方もぜひ楽しみにお待ちください。

まとめ

本カンファレンスは2年目を迎え、実例のみならずシステムテスト自動化についてアーキテクチャやパターンなどさらに深い知識、経験を共有できる場になったと感じました。

システムテスト自動化はキャズムを超えていない可能性があるとの懸念がありましたが、本カンファレンスの継続的実施や書籍のシステムテスト自動化標準ガイドの発売により、システムテスト自動化は日本全国に普及が進み、間違いなくキャズムを超えていくと確信しています。

自分も含め本カンファレンスの参加したほとんどのエンジニアは、今まで以上にテスト自動化を深く知り、使いこなし、より良いシステム開発を目指したいと思ったはずです。そして沢山の仲間がいると気づいたこともまた大きな収穫になったのではないでしょうか。

最後にこのような大規模なカンファレンスを無料で開催してくださったスタッフ、講演者の皆様に感謝し、本レポートを終えたいと思います。本当にどうもありがとうございました。