【勉強会メモ】E2E Test Automation Day 2019 with Selenium (Osaka)
- 日時：2019/07/20(土) 13:00 〜 19:00
- 場所：楽天株式会社大阪支社
Selenium Conf Tokyo をきっかけに関西にも広げようということで、楽天さんバックアップでの関西初開催でした。E2Eテスト関連は昨今需要が増えてきているものの関西の勉強会ではあまり取り上げられない分野なので非常にありがたいイベントでした。内容もとても充実していて、今後の現場で活かしたいと思える内容でした。
余談ですが、懇親会で伊藤さんとお話した時に何年か前に私が投稿したSeleniumの記事を覚えて頂いていて感激とともに恐縮してしまいました。それ以降Selenium関連であまりアウトプットできていないので今日もらった知見をまた今後につなげていきたいです。
E2E Test Automation Day 2019 with Selenium
Woohyeok Kim さん
www.slideshare.net
Selenium Conf Tokyo のKeynote概要
Multi-Browser Testing Strategy Map
Sekine Yasufumi(mercari Inc) さん
マルチブラウザの自動テストの必要性は高まっているが簡単ではない
ブラウザシェア
DevOpsでのテスト
- どの場面でも行う必要がある
- 自動テストは必須
マルチブラウザの自動テストが重要
W3C WebDreiver
- 標準技術として取り入れられた
- Webブラウザの標準機能としてブラウザベンダーがサポートしていく
- Safari,Edge、など主要ブラウザサポート
- iOS13 iOS Safariでもサポートアナウンス
- IEはW3C未サポート
- Selniumコミュニティがサポート
マルチブラウザのテストの難しさ
問題点1：W3Cに準拠していないケースまだある
- SafariではGet Element Textの仕様を満たしていない
W3Cの判断が分かれるケース
準拠していないケース
- 仕様の判断が分かれるケース
- ブラウザ独自の対応が必要
- 対応ブラウザを増やすほど難易度があがる
問題点2：OSとブラウザの組み合わせ
- デスクトップ
- モバイル
問題点まとめ
- デスクトップモバイル全てに対応すると組み合わせが非常に多い
- 開発環境、CI環境の構築・メンテナンスが難しい
Multi-Browser Testing Strategy Map
- Fidelty
- ブラウザとOSの組み合わせをどれだけ増やすか
- Feedback
- 実行の時間を減らす
初期段階
- 片手間で導入の段階を抜けるにはSpecialistが必要
- ここは早く抜けたほうが良い
次のステップ
- Feedbackレベルを上げる⇒Functional…1ブラウザだけでも構築
最後のステップ
- Fideltyを上げていく
- 最大限にすることが良いとは限らない
- SaasのBrowser Test
- 同時実行数で決まるため高速化xブラウザxOSはけっこうな利用料がかかる
- 20並列だと月40万
別の戦略
- Fidelityだけを上げるパターン⇒NonDevOps
- 時間をかけてでも品質を上げたいケース⇒SIerなど？
- あまり推奨しない
メルカリでは？
- プルリクエスト
- QA環境デプロイ
- 本番リリース時
自動化テストを始める前に
Yadori Yohei(Rakuten Inc) さん
www.slideshare.net
テストに関する最近のトピックス
- フロントアプリのRegressionテストが86%自動化
- モブテスト設計
フロントエンドチームは過去に2度テストの自動化に失敗している
- 最初から完璧な素晴らしいテスト自動化を目指しすぎた
- 案件の差し込みやプロジェクトの予定変更が多く、健全な計画が組めない
- 20にんで支えていたシステムを急に5人で支える事になった
- 信頼貯金はマイナス
- また自動化すると言いにくい
どうやったらテスト自動化できるか？
盗塁しよう
- ピッチャーが気づかないうちに進塁
- いつの間にかできている状態になればベスト
- 成果が出ればアピールできる
盗塁の準備
- タイムボックス⇒10%ルール
- 自分の好きな改善をしていいルール
- Minimum Vialble Productを意識
- ある程度形になるまでのコストを気にしなくても良い
担当者⇒モブ
- １人でやるにならない
- 考え方の共有
- フラットな組織と文化の醸成
振り返り⇒Retro/Pro-spective
- ビジョンが見えるようになる
- 目指す目標を定期的に確認
- 前向きになれる
成果
- 全ページエラーチェック
- スクショでの新旧比較
- 全体の86%テスト自動化
将来
- レグレッションテスト100%
- Dockerに入れて自動化
まとめ
- 小さな成果から
- モブは一体感を出すのに最適
- 過去と未来の話はバランス良く
Appiumを製品のコアに活用する
Ito Nozomi(TRIDENT Inc) さん
www.slideshare.net
Appium
Magic Pod
- Saas
- コードレス
- バックエンドはAppium
直面した課題
- ユーザーはAppiumに慣れていない
- 品質への要求がシビア
- Magic Podのコマンドは基本的にAppiumコマンドのラッパー
- 一部のコマンドの実装は複雑
遅延ロード要素のScroll/Swipe
- 課題
- Appiumには特定の要素が表示されるようにスクロールする機能
- XCUITest Driver：遅延ロードされる要素が見つかるまでスクロールできない
- UiAutomator：一部の要素で動かない
- 対策
- swipeToコマンドを作っている
- 要素が見つかるまでスワイプしている
なんでもWait
- 課題
- 待ち処理の記述は難しい
- 何を待つのかわからない
- 対策
- waitWholeRendered
- 画面キャプチャの結果が変わらなくなるまで待機
- 人間の感覚と同じ
- 残っている課題
- スクリーンショットを撮るのはすぐ終わるがイメージの比較に時間がかかる
- ロードアニメーションがないと困る
iOS picker wheel
- iOSの課題
- pickerに特定の値をセットするのが面倒
- Pickerの移動方向が現在の値によって変わる
- 対策
- inputToPicker
- 少しずつスワイプすることで値をセット
- スワイプ方法を自動計算可能
- inputToPicker
- 今後の改善
- 数値以外の判定
- 曜日、都道府県、国名
- 課題
- 巨大のツリーの取得に時間がかかる
- タイムアウトで空になることも
- テキスト中の改行が含まれない
- 対策
AIロケーターの活用
- Deep learning画像認識で要素を特定
- Magic PodはAIロケーターを活用
- NN+OCR
- UI map
- AIロケーターによる要素検索
- AIの認識結果が常に安定しているわけではない
キーボードを隠す for 日本語
- 最後のキーを探して押す
Appiumをもっと安定して信頼できるものにする
- デグレの防止
- Appium自体のテストを用意
- Magic Podに重要な機能のテスト
- 実機やエミュレーターでテスト
- コミッターとのコラボレーション
- 日本人コミッターにコンサルティングや修正を依頼
- バグ報告機能を搭載
- 多くの問い合わせは実際にはバグではない
- 問題を切り分けてAppium開発コミュニティへ報告
将来の計画
- Espresso DriverとUiAutomator2 Driverの併用
- WebdriverIOに以降
- AIモデルをappium-classfier-pluginに移行
ポスト「テスト自動化」を見据えて ~水平思考と探索的テストの世界~
Masanori Kawarada さん
なぜ探索的テストの話をするのか？
理由1
- 探索的テストが未来のテスターのしごとになる
- テスト自動化の進歩が著しい
- UIテスト自動化＋APIテスト自動化⇒手を動かすテストがどんどんなくなる
- プログラムだから開発者がテストを理解しテスト自動化を推進するようになる
- 品質専門家の需要は無くならない
- 最適な品質保証の形は各業界。各社・書くプロジェクトで異なる
- それぞれに応じたQAプロセルを作り出せる
- スタートアップは早くから品質の重要性
- QAは水先案内人
理由2
- 日本語で手に入る探索的テスト情報が少ない
- Google検索結果
- 探索的テスト：372万
- Exploratory Testing：3,710万
- 日本語の書籍も無い
- Google検索結果
探索的テストのアプローチとしての水平思考
テクニック・技法・実践
- テストチャーター
- タイムボックス
- ペアテスト
⇒ググれば出てくる
アプローチ・原論・理屈
例）選手32人のトーナメントは何試合あるか？
- 垂直思考
- 32人の半分が1回戦⇒その半分が2回戦…
- 水平思考
- 32人のうち1人が優勝で残り31人は1回負けるので31試合
ポストテスト自動化を見据えて
- 形式的テスト⇒チェックを埋める
- 探索的テスト⇒コンパス的に探す
World Quality Report 2018-19
QA・テスト戦略の目的第1位は「顧客満足」
テストとは
- 知っていることと知らないことのギャップを埋める
- 形式的テストと探索的テスト
- 形式的テストは自動化しやすいが探索的テストは自動化しにくい
頭をつかう必要がある
- 頭を使わなくていいことは機械にやらせる
- 頭をつかわなければならないことは人間がやる
頭をつかわなければならないこと？
- 専門のテストエンジニアが探索的テストをやる
世界で最も優れているテストツールは人間の頭脳
LTは簡単なメモのみです。
Introduction to Cypress
Shiiba Mitsuyuki(Rakuten, Inc.) さん
Test Assistant Pro のSelenium対応
Ishikawa Tatsuya さん
Groovy Test Fixture
Kitamura Kandai さん
- Testcontainers
- テストコード内でDocerコンテナを起動
- Wiremock
- モックのAPIサーバを立てる
Effective Android UI Testing
Lindsay, Diarmaid さん
世界のカンファレンスから~次に世界に飛ぶ人へ~
mkwrd さん
