pirosikick's diary

君のハートにunshift

Webアプリの正しいUIテストの方法が決定されなかった

勉強会

今夜、Webアプリの正しいUIテストの方法が決定されますに行ってきた。 正しいUIテストの方法は決定されなかった（ディスカッション終わって帰ったからその後に決定したのかもしれないけど）

感想

Androidが端末毎に違うバグがあったり、IE時代よりテストが大変な時代にみんなどうやって効率的にUIテスト（自分のイメージでは、実機を触ったりSeleniumでエンドユーザの動きを出来る限り再現するテスト）やっているのかなーってのが気になって参加してみたけど、あんまりそういう話はなかったｗまだ「これだ！」っていう解答は見つかってないのかもしれない。

講演パート

前半の講演のところは事例的なのが2つで、あと3つはテスト製品の紹介だった。

サイボウズ宮田さんのkintone開発で受け入れテストをSeleniumを使って自動化している話はいいところ・悪いところ両方聞けてすごく参考になったが、自動化するコストはやっぱり高そうで、テスト数が多いとテスト実行時間もやっぱりすごくかかるみたい。

DeNA沖田さんの話は、Domain Agent Patternっていう言葉が出てきたけど、それをSeleniumでどういう風に実装しているのかもっと具体的に聞きたかった。

ディスカッションパート

後半のディスカッションは、すごく美味しそうな食事（銀のさらとビール！）が出てきたのに自分の席からは取りづらく、空腹ですごくイライラしてしまいほとんど聞いてなかったｗ（テーブルの周りの人ばかり食ってずるい！！スタッフの人、もっとテーブルの配置ちゃんと考えてほしい！！！）

その中でも印象に残った話は、Oracle榑松さんが「イノベーションはUIテスト（というか製品）の敵。次々と新しい技術が出ると製品開発が追いつかない。」っていうことを言っていて、その流れで「GoogleグラスのUIテストってどうしますかね？」っていう話に発展してDeNA沖田さんが「そういうテストまで考えられた製品が売れる時代になるのでは」って言ってのが面白かった（間違ってたらすいません）。

Androidの話も開発者が開発しやすい端末でいいサービスがリリースされて、バグが多いような悪い端末にコンテンツが不足して売れなくなれば理想なのかなと思った。が、ビジネス的にはより多くの人にリーチできた方がいいので、なかなか難しいだろうなーとも思う。

以下、メモ

講演「UIテストの自動化は何が良いのか、どのように実現するのか？」

Oracle 榑松氏「OracleのTestingToolsのご紹介」

  • 自己紹介
    • 元エンピレックス株式会社、Oracleに買収される
    • 林業好きらしいｗ
  • Oracle Application Testing Suite
  • Application Replay
    • 本番環境のユーザ動作をキャプチャして、それをTest環境で実行とかできる
  • 本番データをテスト環境にクローンして、マスキングして個人情報を殺す
  • まぁ、全部ライセンス料必要やけどねｗ

サイボウズ 宮田氏「kintoneチームを支える Seleniumテスト」

  • 自己紹介
    • B2Bサービス「kintone」開発チーム所属
    • FEからBEまで
  • 実際のSeleniumの運用事例
  • Seleniumって大変じゃない？
    • 安定しない、UI変更で死、実行時間が長い、ブラウザ対応大変etc
    • kintoneでもメンテ不能になったことも
  • なぜ自動化するの？なにを自動化するの？とチームで議論
  • 受け入れテストが自動化の効果が高そうという結論
  • 自動化しないと。。
    • 大きな変更での動作確認ができない
    • 不具合の原因調査できない
  • 目標「高品質かつ高速な開発を行う」
  • kintoneチームのSeleniumテスト
    • プログラマーが自動化
    • WebDraiver + Grid
    • 本番コピー環境で試験
    • 700のテストケース！
    • 全部で24並列で20分もかかる
  • CI → Jenkins + Pipeline Plugin
    • 全部通るのに40、50分
    • 落ちた時はメンション飛ぶで
  • 安定運用に関してはブログ見ろや
  • メリット
    • 安心感
    • 怪しい変更がすぐわかる
    • 自動化中に実装漏れに気づくことも
    • チーム全体の品質への意識が変わるで
    • 早期発見することで修正のコストを最小限にする
  • 課題
    • Selenium Gridのノード管理つらい
    • ブラウザ・WebDriverのバージョンアップでテストが不安定になることも
    • 効果の見える化
  • 自動化する前に戻りたいとは思わない！自動化最高！
  • まとめ
    • Seleniumは結構大変（もしかしたらSeleniumじゃなくても大変
    • でも、受け入れテストが手動なのはリスク高いでござる

Xenophy 佐川氏「UIテストどうやるか」

DeNA 沖田氏「Selenium in Mobage Platform」

  • 自己紹介
    • @okitan
    • WebDB+Pressに記事寄稿しとるで
    • 会社：SWETグループ（Software Engineer in Test）
  • 正しいUIテスト？→わからんぜよ。何をUIテストと呼ぶべきなのか
  • Selenium RC + WebDriver
  • WebDriver APIはw3c標準になろうとしてる
  • 8月にSelenium3が出るかも。→モバイルより
  • Mobage Platform
    • End User, OpenID Connect, SAP, SocialAPI etc
  • システムテスト
    • 本番同様にデプロイしてやる
    • テストデータも出来る限り本来のやり方で作成
  • ユーザ間のインタラクションが主
  • ユーザを意識をしないでテストを書く
    • ID/Passwordでログインしてとか辛い
  • デバイスも意識させない
    • 隠蔽してる
    • PCでもスマフォでも共通化できるように
  • Domain Agent Patternや！
    • UAがセッションデータを持ってて、単体で機能実行が可能
    • 複数ユーザ、異なるデバイスのテストが書きやすい
  • まとめ
    • UIはスコープ外にして、Seleniumテスト
    • Domain Agent Patternの活用や！

日本IBM 金元氏「」

  • 打鍵テスト自動化のソリューション（RTW）、品質の可視化し継続的に品質改善（MQA）