エムスリーのテスト自動化の 歴史とこれから てすらぼみーとあっぷ #2 窪田 (@kubota_junshi)

自己紹介 窪田 純士 (@kubota_junshi) QA エンジニア @ エムスリー株式会社 ● 医師向けの情報サイト・アプリの品質保証全般 ● 自動テストの検討・導入 以前は銀行システムの品質保証をしていました

本日の流れ 1. 自動テスト導入の歴史 2. テスト自動化に対する反省と方針策定 3. ツール検討 4. 今後の方針

自動テスト導入の歴史 発表の対象範囲： ● UI の自動テスト ○ 検証環境で各サービスと結合 自動テスト導入の歴史を次スライドから

自動テスト導入の歴史

自動テスト導入の歴史 (最初期 2014年の頃) ● 成果が出た！ ○ 全メンバへ展開 ○ 勉強会の実施 ○ マニュアルの作成 目的 週1リリース毎2時間の回帰テストを実施 → 回帰テスト実施コスト削減のため導入 実装方法 旧Selenium IDE で記録 → WebDriver (RSpec) へエクスポート ＋ページオブジェクトパターンを用いてメンテナンス性の改善 実行環境 Jenkinsのスレーブとして ● Windows マシン 3台 ● Mac マシン 1台 考慮点 QAチームは開発未経験者が多い。凝ったクラス・メソッド作成は一部の有識者が実施

自動テスト導入の歴史 (成長期 2015-2016年の頃) QA での施策成功 事例共有 QA チーム内展開 開発メンバへ波及 Selenium コードを書 く人の増加 継続的にテストを追加

自動テスト導入の歴史 (成長期 2015-2016年の頃) この頃の施策 ● Jenkins を利用した自動テストタスクの管理 ○ いつでも誰でも自動化したテストの実施が可能（現在でも同様） ● マニュアル作成と教育の実施 ● 毎日スケジュールでの実行（現在でも同様） ● スクリプトの標準化（現在でも同様） ○ 手動でのテスト実行が面倒なものの自動化 ○ 繰り返し利用するもののテンプレート化

自動テスト導入の歴史 (停滞期 2017-) ● 改善活動の一環であり専任がいなかったため手が空かない とテストのメンテができない ● テストが不安定でありメンテ工数の増加 ○ 重要でないテストも多く含まれていた ● 重要なテスト・メンテ可能なテスト以外は徐々に削減 ○ 必要なテストのみ残ったため、結果的には良かった ● 自動テストが殆どなくなったチームもあり ○ もちろん、継続して実施しているチームも

自動テスト導入の歴史 (停滞期 2017-) 自動テストの課題： 特に以下で苦しむこと多数 ● テストの不安定さ ○ 手動テスト操作による影響 ○ 環境起因 ( 接続先の作業など ) ● メンテナンスコスト ○ 自動化要員不足

反省と今後の方針 今までの自動テストでわかっていること ● クロスブラウザテストで検出できるものは少ない ○ 全体の 3% 程度（累計） ● 重要機能に関する回帰テストが対象 ● 変更が多く加わる部分については手動で実施 ● メンテナンス出来る人がいないと中々続かない ○ 非同期処理などで失敗しやすいコードとなりやすい Selenium 以外でも良い？ 簡単にテストを作 成したい 方針： ● Selenium に限らない方法の検討 ● 自動テスト実装できない人（慣れていない人）でもテスト作成できるように ● 細かいメンテナンスは有識者が実施

とりあえず、 wait 等を明示的に書かなくてもいいツールを検討 ツールの検討 ツール 特徴 ・比較的感覚的に書ける ・テストコード更新の度に自動でテストを実行し直してくれる ・操作ごとにDOMのスナップショットをとっているため、操作ごとの動作を再 現しながら確認できる ・クロスブラウザ対応している (IEはしていない) ・デバイスの指定ができる ・機能が豊富で色んな事ができる (Puppeteerとほとんど同様) ただし導入などが楽になったとはいえ、結局は js のコードを書かないといけない

ツールの検討（その2） コードを書けなくても自動化を推進できるようなツールを検討 ツール 特徴 QA Wolf ● ブラウザ操作から、 Jest と Playwright を用いたコードを生 成 ○ テストコードを書けない人でも、ブラウザ操作をコードに落とせる ○ 複雑な操作のテストも簡単にコード化できる ● 導入も簡単 ○ node.js さえ入っていればコマンド一つで導入可能 お、なんか良さそう …… 。

QA Wolf 導入方法 ● テスト作成では、対象の URL とテスト名を指定しま す。 ○ この例だと google.test.js というファイルが出力 ● テスト名を指定すると対象テ ストのみ、指定しない場合は 全テストの実施となる

QA Wolf 生成ファイル ● テンプレートは設定ファイルに記載 ○ デバイスやプロキシ情報の指定 ○ 前処理・後処理の指定 ● 記録中の操作はすべて記録される ○ 打ち間違いやバックスペースなども ○ スクロールは座標指定 ● アサーションは無い ○ 確認したい部分は個別に指定が必要

テンプレートはこんな感じ

テスト実行 ● テスト実行時には色々なオプションを付与することが可能 ○ 中身が Playwright であるため、クロスブラウザ確認の実施も可（ --all-browser で全ブラウザ） ● GitHub Actions であれば、 CI 設定ファイルを初期設定時に自動作成できる

QA Wolfの感想 ● さっとテストを作るのには良さそう ○ コマンド 1 つで環境構築できる ○ 誰でもテスト作成ができる ● 大量にテストを作ってメンテナンスするにはまだ、工夫が必要 ○ テストを作る・更新する運用を決めないといけない ○ そんなにたくさん作らない気もするので実は大丈夫？ ● ロゴがかわいい・面白いコマンドがある

今後の方針 ● QA Wolf を試しに運用してみる ○ 既に運用が始まっているチームもある ● 使い方の勉強会の実施 ○ QA Wolf の使い方とテストの運用方法 ○ Selenium のレクチャーも継続実施 ● ドキュメント拡充 ○ ネット上であまり多くない印象 ● テストのメンテナンス性の検証 ○ 画面要素の変更が発生した場合にどれくらいの時間がかかるか等 ● reg-suit 等の VRT との組み合わせの検討 ○ VRT テストを気軽に作るのには割と向いていそうな気が 興味がある方は、エムスリー OR @kubota_junshi へコンタクトください！