エムスリーのテスト自動化の 歴史とこれから

弊社のシステムテストの自動化は2014年からはじまりました。成功や失敗の歴史を振返りつつ、現時点で抱えている問題にこれからどのように対処していこうとしているのかをお話します。
Keyword: QA Wolf

Transcript

1. エムスリーのテスト自動化の 歴史とこれから てすらぼみーとあっぷ #2 窪田 (@kubota_junshi)
2. 自己紹介 窪田 純士 (@kubota_junshi) QA エンジニア @ エムスリー株式会社 • 医師向けの情報サイト・アプリの品質保証全般 • 自動テストの検討・導入 以前は銀行システムの品質保証をしていました
3. 本日の流れ 1. 自動テスト導入の歴史 2. テスト自動化に対する反省と方針策定 3. ツール検討 4. 今後の方針
4. 自動テスト導入の歴史 発表の対象範囲： • UI の自動テスト ◦ 検証環境で各サービスと結合 自動テスト導入の歴史を次スライドから
5. 自動テスト導入の歴史
6. 自動テスト導入の歴史 (最初期 2014年の頃) • 成果が出た！ ◦ 全メンバへ展開 ◦ 勉強会の実施 ◦ マニュアルの作成 目的 週1リリース毎2時間の回帰テストを実施 → 回帰テスト実施コスト削減のため導入 実装方法 旧Selenium IDE で記録 → WebDriver (RSpec) へエクスポート ＋ページオブジェクトパターンを用いてメンテナンス性の改善 実行環境 Jenkinsのスレーブとして • Windows マシン 3台 • Mac マシン 1台 考慮点 QAチームは開発未経験者が多い。凝ったクラス・メソッド作成は一部の有識者が実施
7. 自動テスト導入の歴史 (成長期 2015-2016年の頃) QA での施策成功 事例共有 QA チーム内展開 開発メンバへ波及 Selenium コードを書 く人の増加 継続的にテストを追加
8. 自動テスト導入の歴史 (成長期 2015-2016年の頃) この頃の施策 • Jenkins を利用した自動テストタスクの管理 ◦ いつでも誰でも自動化したテストの実施が可能（現在でも同様） • マニュアル作成と教育の実施 • 毎日スケジュールでの実行（現在でも同様） • スクリプトの標準化（現在でも同様） ◦ 手動でのテスト実行が面倒なものの自動化 ◦ 繰り返し利用するもののテンプレート化
9. 自動テスト導入の歴史 (停滞期 2017-) • 改善活動の一環であり専任がいなかったため手が空かない とテストのメンテができない • テストが不安定でありメンテ工数の増加 ◦ 重要でないテストも多く含まれていた • 重要なテスト・メンテ可能なテスト以外は徐々に削減 ◦ 必要なテストのみ残ったため、結果的には良かった • 自動テストが殆どなくなったチームもあり ◦ もちろん、継続して実施しているチームも
10. 自動テスト導入の歴史 (停滞期 2017-) 自動テストの課題： 特に以下で苦しむこと多数 • テストの不安定さ ◦ 手動テスト操作による影響 ◦ 環境起因 ( 接続先の作業など ) • メンテナンスコスト ◦ 自動化要員不足
11. 反省と今後の方針 今までの自動テストでわかっていること • クロスブラウザテストで検出できるものは少ない ◦ 全体の 3% 程度（累計） • 重要機能に関する回帰テストが対象 • 変更が多く加わる部分については手動で実施 • メンテナンス出来る人がいないと中々続かない ◦ 非同期処理などで失敗しやすいコードとなりやすい Selenium 以外でも良い？ 簡単にテストを作 成したい 方針： • Selenium に限らない方法の検討 • 自動テスト実装できない人（慣れていない人）でもテスト作成できるように • 細かいメンテナンスは有識者が実施
12. とりあえず、 wait 等を明示的に書かなくてもいいツールを検討 ツールの検討 ツール 特徴 ・比較的感覚的に書ける ・テストコード更新の度に自動でテストを実行し直してくれる ・操作ごとにDOMのスナップショットをとっているため、操作ごとの動作を再 現しながら確認できる ・クロスブラウザ対応している (IEはしていない) ・デバイスの指定ができる ・機能が豊富で色んな事ができる (Puppeteerとほとんど同様) ただし導入などが楽になったとはいえ、結局は js のコードを書かないといけない
13. ツールの検討（その2） コードを書けなくても自動化を推進できるようなツールを検討 ツール 特徴 QA Wolf • ブラウザ操作から、 Jest と Playwright を用いたコードを生 成 ◦ テストコードを書けない人でも、ブラウザ操作をコードに落とせる ◦ 複雑な操作のテストも簡単にコード化できる • 導入も簡単 ◦ node.js さえ入っていればコマンド一つで導入可能 お、なんか良さそう …… 。
14. QA Wolf 導入方法 • テスト作成では、対象の URL とテスト名を指定しま す。 ◦ この例だと google.test.js というファイルが出力 • テスト名を指定すると対象テ ストのみ、指定しない場合は 全テストの実施となる
15. QA Wolf 生成ファイル • テンプレートは設定ファイルに記載 ◦ デバイスやプロキシ情報の指定 ◦ 前処理・後処理の指定 • 記録中の操作はすべて記録される ◦ 打ち間違いやバックスペースなども ◦ スクロールは座標指定 • アサーションは無い ◦ 確認したい部分は個別に指定が必要
16. テンプレートはこんな感じ
17. テスト実行 • テスト実行時には色々なオプションを付与することが可能 ◦ 中身が Playwright であるため、クロスブラウザ確認の実施も可（ --all-browser で全ブラウザ） • GitHub Actions であれば、 CI 設定ファイルを初期設定時に自動作成できる
18. QA Wolfの感想 • さっとテストを作るのには良さそう ◦ コマンド 1 つで環境構築できる ◦ 誰でもテスト作成ができる • 大量にテストを作ってメンテナンスするにはまだ、工夫が必要 ◦ テストを作る・更新する運用を決めないといけない ◦ そんなにたくさん作らない気もするので実は大丈夫？ • ロゴがかわいい・面白いコマンドがある
19. 今後の方針 • QA Wolf を試しに運用してみる ◦ 既に運用が始まっているチームもある • 使い方の勉強会の実施 ◦ QA Wolf の使い方とテストの運用方法 ◦ Selenium のレクチャーも継続実施 • ドキュメント拡充 ◦ ネット上であまり多くない印象 • テストのメンテナンス性の検証 ◦ 画面要素の変更が発生した場合にどれくらいの時間がかかるか等 • reg-suit 等の VRT との組み合わせの検討 ◦ VRT テストを気軽に作るのには割と向いていそうな気が 興味がある方は、エムスリー OR @kubota_junshi へコンタクトください！