「システムテスト自動化カンファレンス2014」に参加しました

2014/12/14(日) 「システムテスト自動化カンファレンス2014」に参加してきました。

connpass
http://connpass.com/event/9618/

Togetter
http://togetter.com/li/757649

場所は六本木のヤフー株式会社さんです。
参加者は２００人くらいでしょうか。キャンセル待ちも７０人くらい出たようです。
あいかわらず参加申し込み開始後にすぐに枠が埋まるほどの人気イベントですね～
たしか11/15のJJUG CCCの基調講演中に申し込みが開始されて、私は講演聞きながらすぐ申し込んだ記憶があります。
おかげで私の申し込み順位は一桁台～。

ちなみに私、去年も参加してそんときブログ書きました。

「システムテスト自動化カンファレンス2013」に参加しました
http://makopi23.blog.fc2.com/blog-entry-126.html

去年は講演を聴講するだけでなくSeleniumのハンズオンにも参加して、とっても勉強になりました。
そして今年も参加したわけなんですが、去年同様、本当に学びが多かったのが実感です。
社内でもテスト自動化に関するWGに参加してるので、このイベントネタはとてもストライクなのですよ。

というわけでいつもどおり、自分の復習用にブログにメモを書くことにする。
といっても当日とったメモを書き起こすだけ。
後ろに行くほど手抜きｗ

---

■ 開会＋注意事項　/松木 晋祐氏

申し込み時に取ったテスト自動化に関するアンケート結果を提示していたのがすごく興味深かったです。
参加者＋補欠者で、３００人くらいの母数があったようで、とても有用なデータだと思います。
メモからいくつか抜粋してみる。

• テスト自動化の経験が無い人が約５０％。
  • 「繰りかえし開発でない」人が４７％くらいなので、それが原因の一因ではないか。
• 繰り返し開発をやっているのはコンシューマ分野の人が多い。
• テスト自動化が上手くいってるか、という問に、「多くの深刻な問題がある」と回答した人が６０％。
• 問題の内訳は以下。
  • 工数、教育、人材のリソース不足が３０％くらい。
  • 知識、スキル不足が４７％。
  • 組織やマネージャのサポート不足が１０％。
• 自動化に取り組もうとしているけど時間がない、という人が多いのかもしれない。
• 特にモバイルは環境構築する敷居が高い。
• 重要度の高いテストの自動がができていない、簡単なテストだけしか自動化できていない、という意見が多い。
  • 重要なテストをきちんと定義できているか？を考えないといけない。

アンケート結果は後日公開されるらしいので、もう一度じっくり見てみたいですね。

★ 12/21追記
アンケート結果が公開されたようです。
https://sites.google.com/site/testautomationresearch/info/stac2014_survey

---

■ オープニング：1時間で分かるSTA　/鈴木 一裕氏

1時間で分かるSTA (Software Test Automation) #stac2014 from Kazuhiro Suzuki

近々発売される「テスト自動化標準ガイド」について監訳や全体まとめを担当したとのことで、この本についていろいろ紹介がありました。

システムテスト自動化 標準ガイド (CodeZine BOOKS) (2014/12/16) Mark Fewster、Dorothy Graham 他 商品詳細を見る

こんな本が近々出るなんで、知らなかった・・・
ちなみにこの日は翔泳社さんブースもあったんですが、この講演後に完売したそうですｗ
あと２章のタイトル「キャプチャーリプレイはテスト自動化ではない」ですが、言い切りましたね～
他には、「ロバストな比較」と「センシティブな比較」はあるあるなんですが、名前付けして定義してる点が興味深かったです。
講演にユーモアも交え、上手く書籍の構成とポイントを紹介しているなぁ、と感じました。
ぜひ読んでみたいと思いました。（この講演の冒頭でも出てきましたが、「積ん読」にならないようにしないと・・・）

---

■ テスト自動化のパターンと実践　/.reviewrc
関西の３名の方による発表です。関西特有のテンションで、聞いててとても楽しいです。

■ 前川さん

テスト自動化のパターンと実践 from Hiroshi Maekawa

テスト自動化をパターン・ランゲージを使って表現する取り組みの紹介で、以下で公開中だそうな。

テスト自動化パターン言語プロジェクト
https://github.com/KenColle/AutomationPatternLanguage

この発想はユニークで、実用性もありそうですね。「ピンを生やす」って命名とか、センスあるなと思います。
これは共通認識を醸成するのに使えそうだな～と思いました。


■石川さん
「皮を剥く」というテクいやつ（テクニカルなパターン）についての紹介です。

Stac2014 石川 from Tatsuya Ishikawa

「皮を剥く」というパターンを実現するために、FriendlyというWindows用の皮むき器を開発したとのこと。斬新なアプリです。
内部仕様とテストの間にアプリケーションドライバという層を設け、技術的な部分を隠蔽するという考えも参考になります。

■ 三浦さん
エモい三浦さん（笑）による発表です。

「自動家(オートメータ)をつくる」-システムテスト自動化カンファレンス2014 「.reviewrc」枠発表- from Miura Kazuhito

三浦さんは去年のXP祭り関西でもLTをされてたように記憶してますが、あの時同様、今回もエモかったｗ
いつもすごく楽しそうにしてるなーと思うのと同時に、この情熱は素晴らしいと思うのです。
すごく積極的な姿勢が滲み出ていますよね。

「自動化」をもじって、「自動家」というロールをパターン名とした発想もユニークです。
あと、 災いを『未然に防いだ勇者』は数百あれど、英雄となれたのは『発生後に対処した者』ただ一人である という言葉は重いですね・・・

---

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

GUI自動テストの保守性を高めるには from Nozomi Ito

Seleniumが発表のメインになってました。テーマは保守性。
去年のテスト自動化カンファレンスでSeleniumのハンズオンに参加したんですが、すげー参考になったなぁ。
以下メモ。
---

• Seleniumuで記録したスクリプトをそのまま使うのはやめたほうがいい。
  • Seleniumでプログラム書く方が個人的には推奨。
• できるだけテストを失敗させない。
• Seleniumで制御するとき、何番目のdiv、とかで指定するのはやめたほうが良い。
• 最初に環境テストをやって、こけたらやめる。テストをそのまま続けると、後続のテストが赤ばっかりで埋もれる。
  • 赤が当たり前になると、どうせまたバグじゃないんだろ、とテスト失敗原因調査が後回しになる。
• ページオブジェクトデザインパターン
  • １つのページに対し１つのページオブジェクトクラスとする。
  • divの何番目とかの言葉がスクリプトに出てこなくなる。
  • 画面のUI構成に依存しないようになる。
• 画面がロードされるのを待つとき、指定時間待つよりは、ある要素が表示されるまで待つようにする。

---

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

#STAC2014 状態遷移を活用した自動テストのテスト戦略とデプロイメントパイプライン from Kyon Mm

テスト方面でいろいろ発信されているきょん氏。
発表の中で「拝承」が何度か出てきましたが、私、その拝承に勤めてるんです。。。
以下メモ。
---

• 効果のあるテストを自動化しないと意味がない。
• ValueStreamMap
  • 無駄な時間を見える化する
  • テスト自動化はバリューストリームを短くする手段の１つしかない
• 受け入れステージで、この機能使ったら次にこの機能使って～、みたいな最低限のパスを通るスモークテストを、巡回セールスマン問題で解いて生成する。
• 画面を１個ずつすべて定義して、その画面をすべて通る機能の使い方を自動生成で出させた。

---

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

ビルドプロセスとCI #STAC2014 from Koji Hasegawa

• 「ハンマーを持つ人には、すべてが釘に見える」
  • ツールを使ってると、ツールに振り回される。
• Jenkinsの学習は「カエル本＋ググる力」。

---

■ 社内スマホアプリのビルド配信ツールによる自動化事例 /赤根 稔朗氏(Yahoo! JAPAN)

Yahooで独自のビルド配信ツールを開発して自動化した事例。
スライド、公開されるかな・・・・？

---

■ Test Automation Patterns 2014 冬コレ！/松木 晋祐氏


テスト自動化パターンの紹介です。こんな概念あるんですね。参考になります。


■テストセレクタ

• 個々最近、ファイルにタグをつける概念が出てきた。
• 昔はフォルダでしか分けれなかった。
• １つのテストに複数のタグを付けておく。
• あるテストをやりたいときは、そのタグ付きのテストやろう、みたいにできる。
• フォルダ管理よりタグ管理のほうが柔軟なテストができる。

■効くところをテストする

• もっとも基本的なユースケースを自動化してずっとテストを実行し続けて、ラムドムが線形に伸びていないことを確認する

■ページオブジェクト

• ページオブジェクトをnewしてからアクセスする
• テストしたいコードと、対象を認識するコードを分離する。

■テスト自動化に関わる人たち

• ロールを定義して、テストに対する過度な期待をコントロールする。
• テストエンジニアとテスト自動化エンジニアは別。

■クロスカバレッジコーディネータ

• 組織を俯瞰（カバレッジ）して、全体最適でツールの配置を考える人
• テストコードを書く人だけじゃなくて、いろんなロールがあること認識してもらうの重要。
• テスト自動化にかかる６０％が、テスト自動化の設計。スクリプティングは１０％で少ない。

■ファジング　ファザー

• 不正系、異常系のテストは値を無限に作れる。
• テストデータを生成して食わして結果を見て、を繰り返す。
• クラッシュした時に、どのテストデータでクラッシュしたのかわかるようにすることが大事。

■前の版と比較する

• なにかと合ってるか合ってないか、だけ判断できる。
• 一度正しいと確定した結果は、次それと比較して同じなら正しいと判定する。
• テストが増えると、分析時間も伸びる。これはよろしくない。スケールしない。
• 結果を分析するシステムも一緒に考えないとうまくいかない。

■可変遅延

• 待ちが必要な場合，待ち時間は可変にする。
• 非同期UIのテストは、どんどん重要になっている
• twitterは非同期でツイートをとってTLに表示する。ネットワークによって状況が変わる。
• ２秒以内にこのUIがアップしてくること、みたいなテストをやる。
• 非同期テストにはパフォーマンステストが入ってくる。

■DJR

• テストフレームワークを作る人に参考にしてもらう

■Red Magician（赤魔導師）

• テスト設計も自動化もできる人

---

★感想：
去年も素晴らしかったが、今年も大変有意義なセッションが揃っていて、すげー勉強になった。
あと、スタッフさんのサポートが手厚くて素晴らしい。
2Fの受付とかエレベータ当番とか、発表が聞けないにもかかわらず、手厚くサポートしていただいて本当に感謝。

448ページ、一人で読むの辛いので読書会とかないかなぁ～(チラッ システムテスト自動化 標準ガイド (CodeZine BOOKS) http://t.co/9mGnSg5RFo #stac2014

— makopi23 (@makopi23) 2014, 12月 14

求む英雄。

関係者の皆様、ありがとうございました。