弊社のシステムテストの自動化は2014年からはじまりました。成功や失敗の歴史を振返りつつ、現時点で抱えている問題にこれからどのように対処していこうとしているのかをお話します。 Keyword: QA Wolf
エムスリーのテスト自動化の歴史とこれからてすらぼみーとあっぷ#2窪田(@kubota_junshi)
View Slide
自己紹介窪田 純士(@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へコンタクトください！
jkubota
sbtechnight
line_developers_tw
takashiinui
toshiaizawa
akiomik
niba1122
masashi_sutou
nenonaninu
line_developers
foursue
smashingmag
philhawksworth
kastner
morganepeng
soudai
colly
rasmusluckow
eileencodes
frogandcode
tanoku
samlambert