クリスマスの足音が近づく12月13日、3回目となるシステムテスト自動化カンファレンス（STAC2015）が東京赤坂のヤフー株式会社の会議室で開催されました。
今年のテーマは「システムテスト自動化エンジニアの今とこれから」です。“これから”の自動化の分野を牽引していくエンジニアが登壇する魅力あるイベントとなりました。今年も例年に漏れず、用意した220席はあっという間に埋まり、一時は50人以上のキャンセル待ちがでていました。昨年に引き続きレポートを担当させていただくことになりましたので、冬の寒さに負けない現場の熱気を最大限お伝えしていこうと思います。
STAC2015はテスト自動化研究会（STAR）によって運営されています。STARは「テスト自動化技術における高度なスキルを検討・定義し、それを広く世に広く啓蒙する」ことを目的として2012年に発足し、本カンファレンスを主催しているコミュニティでもあります。昨年は自動化研究会の有志が『システムテスト自動化標準ガイド』を翻訳しています。
開会の挨拶／松木 晋祐
STARのメンバーの松木さんによるオープニングセッションです。はじめにSTARの趣旨、スコープ、これまでの実績などが紹介されました。続いて、今回の参加者の業務分野や自動化経験などのアンケート結果が紹介されました。今年のシステムテスト自動化経験者は60％程度、また自動化で問題があると感じているエンジニアは95％以上、繰り返し型ではない開発のスタイルは50％以上となっていました。このことから、今回はウォーターフォール開発の現場でシステムテストの自動化を担当し、何らかの問題意識を持っている参加者が多いようです。
松木さんによる挨拶
松木さんから「主催者側、参加者側関係なく、会場の皆さん同士で交流してください。今日一日楽しんでいきましょう！」という言葉でSTAC2015が開幕しました。
テスト自動化のスキルを考えよう！～テスト自動化エンジニアに求められるスキル、期待される役割～
1．ISTQB編／早川 隆治（テスト自動化研究会）
STARのメンバーの早川さんによる、ISTQBで定義されているテスト自動化分野のエキスパートについてのセッションです。このシラバスは英語版のみ（2015年12月現在、英語版のダウンロードは一時中止）ですが、テスト自動化研究会の有志が翻訳をしています。
早川さん
ISTQBのテスト自動化分野のエキスパートのシラバスは以下の2つのパートから成り立っています。
テスト自動化を作り上げる過程はソフトウェアの開発のライフサイクルと似ていて、きちんと設計をする必要があり、作ったものは改善していく必要があります。さらに自動化の対象のシステムと同期をとりながら作り上げる必要があるため、実際には開発と同じようなスキルが必要です、と早川さんは言います。
テスト自動化分野のエキスパートシラバスのダウンロードの再開が待ち望まれると共に、日本語化されるのが待ち遠しくなりました。
- STAC2015 講演1 テスト自動化のスキルを考えよう！～テスト自動化エンジニアに求められるスキル、期待される役割～
2．SSF編／コヤマン（テスト自動化研究会）
STARのメンバーであるコヤマンさんのAutomationTest.SSF（※）についてのセッションです。SSFはスキル標準フレームワーク： Skill Standards Frameworkの略であり、テスト自動化スキル標準であるAutomationTest.SSFをSTARの有志で検討中です。スキルレベルをレーダーチャートなどを用いて可視化することで、「現場の人が学習するための指標を作れるようにする」ということを目的としています。
コヤマンさん
α版では、テストレベルに依存しないテスト自動化のスキルは以下の4つのカテゴリに分けています。
- テスト自動化関連の管理：うまくテスト自動化を進め維持する
- テスト自動化戦略の作成：テスト自動化システムの開発ライフサイクルとテスト自動化戦略をまとめる
- テスト自動化システムの開発：テスト自動化システムを作る
- 自動テストケースの開発・実行：自動テストケースを作り実行する
本セッションではそれぞれのカテゴリを詳細に説明しました。特に事前アンケートでも気になっている人が多かった自動化戦略については、テスト自動化戦略とテスト自動化システムの範囲の違いを表している図も示され、わかりやすい説明となっています。
最後にコヤマンさんから、このスキル標準はみなさんと一緒に考えて作っていきたいと思いますので、パブリックコメントをお願いしますというメッセージがありました。
自分に不足しているスキルを、レーダーチャートなどを使って一目で分かるというのは実務者にとってありがたいことですし、組織でシステムテストの自動化を進めていくときもマネージャーがどのようなエンジニアをアサインしたら良いのか判断するときの手助けになると感じました。
自動家は見た～自動化の現場の真実～／おいしが（旧.reviewrc）
昨年の.reviewrc改め、おいしがの自動化のパターンのセッションです。
まずはMicrosoft MVPである前川さんの前説から始まり、会場の参加者が自動家芸人？のみうみうさんを大声で呼び出しました。昨年のエモーショナルな熱いトークに魅せられ、ファンになった人も多いはずです。みうみうさんは自動化にこだわりを持つエンジニアがいなくなるとどうなるかということを、フィクションを織り交ぜながら説明しました。
前川さん
みうみうさん
おいしがはこのような状況も以下のような自動化のパターンとして整理しています。
※［ ］内はGitHubで管理されている関西発のテスト自動化のパターン
さらに開発者サイドからの意見のみならず、マネージャーに扮した水野さんからマネージャーサイドの意見が出ました。マネージャーの思考の流れを説明したあと、開発者は自動化の効果を数値で説明することで、マネージャーと価値を共有する必要があり、さらには『組織が儲かる』という視点からロジックを整理することが重要であると説きました。
開発者とマネージャーの意見がバランスよく織り交ぜられ、良く練られたセッションだと感じました。良いものを作りたいがゆえにコスト意識が薄くなることがある開発者にとってハッとすることが多かったのではないでしょうか？昨年のレポートでも書きましたが、みうみうさんのプレゼンはあまりに熱すぎて文字では半分も伝えることはできません。みうみうさんのプレゼンをライブでご覧になることをオススメします。
広告システム刷新よもやま話 - テストが当たり前となるまでにやったこと／森下 大介（ヤフー株式会社MSC開発本部マーケッターPF開発部）
Yahoo Japanの森下さんによる広告システムをイチから作り直したときの経験や知見を伝えるセッションです。
森下さん
以前のYahoo Japanでは、コンパイルと型宣言がない言語で広告システムが構築されていました。中途で入った森下さんはきちんとデータを扱いたいと考えていましたが、ビジネス的なインパクトも大きいため、大きく変えることには踏み出せないでいました。その間にもシステムには機能が追加され、着実に技術負債が積み重なっていきます。そのような状況の中、ある大きなバグをきっかけに、部門長から「イチから全部変えなさい！」という指示が出ました。
森下さんたちは考え抜いた末に、これまでとは別の言語であるJavaを採用することを決めました。さらには自分たちのシステムにあった以下のようなテスティングフレームワークやDIという設計パターンの適用、さらにはインターフェースの定義言語を作ることなどさまざまな取り組みを行い、YahooJapanの広告システムを刷新していきました。
- 言語：Java
- →コンパイルと型宣言があり、ある程度馴染みがある
- テスティングフレームワーク：Spock（Groovyアプリケーションで動作する）
- →Groovyは表形式でテストケースを記述することができる
- IDE：IntelliJ
- →Spockとの相性が良い
- 設計パターン： DI（Dependency Injection）
- →依存性を少なくして、テストを実施しやすくする
いくら良い方向に行くと頭でわかっていても、別の言語、新しい技術に取り組んで成果を出すというは並々ならぬプレッシャーがあったはずです。森下さんは淡々と語っていましたが、その決断力と行動力は驚嘆に値します。
また森下さんはマネージャーの協力が大事と語っており、「ボトムアップだけではできないことはある。仲間がいれば個の範疇を超えた成果が必ず出る。」という言葉が印象的でした。テスタビリティやシステムテストの自動化を見据え、ソフトウェア設計をするというのは、これから新規開発するプログラマにとっても重要な技術の一つとなっていくと、ひしひしと感じたセッションになりました。
楽天の品質改善を加速する継続的システムテストパターン／荻野 恒太朗、菊川 真理子（楽天）
楽天の荻野さんと菊川さんによる継続的システムテストパターンのセッションです。
楽天の20サービスのシステムテスト自動化に関わることで見えてきた継続的システムテストに関する知見を整理すると、以下の図のようになります。荻野さんは菊川さんとの寸劇を交えながら実装をひとつずつ説明していきました。
菊川さんの打ち合わせかアドリブかわからない寸劇が素晴らしいと、絶賛の声が上がりましたが、一方では寸劇に気を取られてしまい内容がイマイチ頭に入らなかったという声もちらほら聞こえてきました（笑
荻野さんと菊川さん
全てを紹介することはできないので、筆者の心に留まったエピソードをいくつか紹介します。
メトリクスの意義
結果が数値として目に見えることで、開発者のモチベーションが上がります。メトリクスの1つである『デプロイの頻度』はビジネス価値につながるものの1つであり、役員などの経営層に訴求できる指標となります。
生産性と自動テスト
N日でコインを100枚貯める場合は以下のどちらが良いでしょうか？
- 中身が見えない豚の貯金箱
- いくら溜まったか見えるATM貯金箱（アプリ）
継続的な自動テストは2のイメージであり、品質に問題がある場合はすぐに修正するなどの行動につながります。毎日品質についてフィードバックするツールの1つです。
DevOps
自動テストがない場合は運用側でバグが発生し、最終的にはエンドユーザーの価値の低下につながります。しかし、継続的システムテストがある場合は、開発側（Dev）でバグを抽出できるので、信頼性の高いソフトウェアを運用側（Ops）に届けることができます。
荻野さんは「毎日コミットされ、毎日テストされバグが見つかる。そういう世界を作っていきたい」、「テストだけ詳しいエンジニアではなく、自動化にもリリースにも詳しいエンジニアを育てたい。」と熱い思いをセッションの端々で語ってくれました。
キーワード駆動によるシステムテストの自動化について／小井土 亨（SQiP運営委員会メンバー、株式会社OSK）
小井土さんによるキーワード駆動の実例を紹介するセッションです。
ソフトウェアの機能追加や変更時には、回帰テストや構成テストなどコストが増大していきます。もちろんそれを自動化していくのですが、自動テストそれ自体にも作成工数、保守工数は存在します。それを解決するひとつのアプローチがキーワード駆動（※）による自動テストです。
スクリプトからデータを分離したのがデータ駆動スクリプトであり、さらに対象や操作を抽象化したものがキーワード駆動スクリプトです。全てのテストをキーワード駆動にするのではなく、システムの特性に応じてデータ駆動とキーワード駆動をハイブリッドで用いるほうが現実的な解決策となります。
小井土さん
一通りの説明を終えた後、小井土さんはキーワード駆動の実例を簡単なサンプルアプリとそのコードを見せながらデモを実施しました。この仕組みはC#とPowerShellで書かれていて、コードはCodePlexで公開されているので、興味ある方は参照してください。このデモではあるフォルダ内の1つのファイルが1つのテストケースとして実行されます。本体のアプリに手が入ったときもコードを変更することなく、テストケースを追加するだけで、テストが実行されてキーワード駆動のメリットも感じることができました。
キーワード駆動の仕組みはアーキテクチャやフレームワークといっても過言ではありません。アーキテクチャは強制しないといけない、なんでもできるアーキテクチャは大抵ダメと、システムテストの自動化セッションにもかかわらず、しっかりと設計の真髄も教えてくれました。
Testing Tools for Mobile App／松尾和昭（クックパッド）
クックパッドの松尾さんによるモバイルアプリ開発のツールや事例のセッションです。松尾さんは猫好きらしく、壁紙に猫の画像を出すことで参加者の疲れを癒しつつ、ハートをガッチリとキャッチしていました（笑）。
松尾さん
クックパッドは元々Webで伸びましたが、最近ではモバイルからのアクセスが多く、Apple製品やAndroid製品に力を入れています。移り変わりが早いiOSとAndroidのプラットフォームの比較やクックパッドで実際に使っているツール群を紹介しました。環境の変化が激しく、高頻度なリリースを行うためには必然的に標準で提供されるツール中心になります。変化は強制され、無視することはできません。
事例の紹介では、CPU/メモリの過剰消費の障害から、その対策とそこから得た学びを共有しました。見えていないものは改善することができないので、必要なものは開発フローに組み込むようにして、プロセスを改善しているとのことです。
本セッションはモバイル関連でシステムテストの自動化を進めているエンジニアにとっては、とても有意義だったと思います。また松尾さんがクックパッドに入社し、テストやテスト自動化に真摯に取り組んだことで、クックパッドのエンジニアにとって、それまでの『テストする人』のイメージがガラリと変わったようです。一人のエンジニアが企業文化を変えたというエピソードに驚きを隠せませんでした。
パネルディスカッションLIVE！ テスト自動化”エンジニア” の今とこれから
- 登壇者
- 森下 大介（ヤフー株式会社）／荻野 恒太朗（楽天）／小井土 亨（SQiP運営委員会メンバー、株式会社OSK）／松尾 和昭（クックパッド）／みうみう（おいしが）
- モデレータ
- 浅黄 友隆（ヒューマンクレスト）／松木 晋祐（ベリサーブ）
パネラーの皆さん
モデレータのお2人
事前に用意された質問とTwitterに投稿された質問をパネリストに聞いていくパネルセッションです。ここでは注目の質問と回答をいくつか紹介します。
今後テスト自動化で広げたいこと挑戦したいことは何ですか？
荻野さん：テスト実行以外の自動化に挑戦したいです。自分はもともとデータ屋で機械学習などを担当していました。メトリクスを集めて、テスト設計の一部を自動化できると思っています。
森下さん：機能テスト、システムテストはやりきれていないので、そこに注力していきたいです。他にも環境の構築、データの投入などの自動化の仕組みも気になっています。
今後IoTの問題は避けて通れないと思うけどどう思いますか？
みうみうさん：廉価な機器と簡易に使えるAPIが増えてきたことで、IoTへのハードルが下がっていくと思います。
小井土さん：IoTは分散型のシステムなので、問題発生時に自動で収集し、絞込みを行うところまで自動化しないと辛いのではないでしょうか？
自動テストと手動テストの切り分けはどうやっているのか？
松尾さん：テスト設計自体は差がありません。0か1かはっきりしているものに関しては自動化へ切り出すようにしています。
小井土さん：市場にインパクトがあるところで、Checkingにあたるものを優先的に自動化していきます。
自動化を進める上で一番重要な要素は何でしょうか？
小井土さん：メンドクサイからどうにかしたいなと思うことです。自分がやっていることに対して疑問を持つことが重要です。
森下さん：取り組む側や推進する側の視点があります。取り組む側はまず手を動かしてなんぼだと思っています。
荻野さん：パッション、スキル、スモールチーム！
松尾さん：問題解決することを楽しむことが一番です。
みうみうさん：人が幸せになれること。幸せ指数が一番高いものを取ります。
閉会の挨拶
最後に、前実行委員長の太田さんからの閉会の挨拶がありました。STARに閉じない外部への広がりが出てきて、テスト自動化が進んできましたのを嬉しく思いますとのことでした。さらにスポンサー提供の自動化関連本プレゼントのじゃんけん大会が大いに盛り上がりを見せ、最後まで熱気に包まれたカンファレンスとなりました。
太田さんによる閉会の挨拶
感想
昨年のSTAC2014では、システムテスト標準ガイドに沿いながら自動化の現場でのパターンなどが多く語られていましたが、今年のSTAC2015ではさらに実務者寄りのカンファンスになりました。これからシステムテストに取り組む開発者にとっては一筋の光明が見え、自動化エンジニアになりたいと考えているテスターにはプログラミングの壁が立ちはだかったように見えたのではないでしょうか？
開発者は、自動化の仕組みの構築と同時に、同値分割、境界値分析などのテスト技法を学び、テストの質を上げていくのが良いと思います。一方、プログラムに壁を感じたテスターは簡単なプログラムの作成や、可能であれば単体テストコードを書いていくことで、プログラミングがより身近になり、自動化への道が開けていくと思います。
本カンファレンスでは同じような悩みを持つ仲間と知り合う機会となったと共に、各セッションの講演者がみなさんの自動化エンジニアのロールモデルになるのではないでしょうか？最後に3年目となる本カンファレンスを継続して開催してくださったスタッフ、講演者の皆様に心から感謝し、本レポートを終えたいと思います。本当にどうもありがとうございました。
