mablの導入と開発・QA間の協力体制 2021/12/11　ソフトウェアテスト自動化カンファレンス2021
 エムスリー株式会社　城本　由希
 1

自己紹介 ● 城本　由希　@yuki_shiro_823 ● エムスリー株式会社で組織横断のチームであるQAチームに所属 ● 担当はリサーチの部門であるBIRでアンケートの作成や配信などのシステム のQA ● QAエンジニアのスキル向上を目指してQAチーム内の勉強会を開いたり、 有志でテスト設計コンテストに出場したりしている ● 広島出身のカープファン 2

今日話すこと、メインターゲット 3 ＜話すこと＞ 1. mablとは何か 2. なぜmablを導入したのか a. 導入前の状況 3. 導入してどうだったか a. スムーズに行った点 b. ちょっと工夫が必要だった点 c. チームから得られたサポート 4. 今後の取り組み 5. まとめ ＜メインターゲット＞ ● ローコード自動化サービスが 気になっている人 ● ローコード自動化サービスの 導入を始めたばかりの人

エムスリーの紹介 4 “インターネットを活用し、 健康で楽しく長生きする人を一 人でも増やし、 不必要な医療コストを一円でも 減らすこと” →　テクノロジーで支援する

エムスリーのQAチームの立ち位置 5 エムスリー 経営会議 マネジメントチーム VPoE CTO GL 採用TL エンジニア人事担当 事業チーム （8） 横断チーム （8） Unit1 MR君 Unit3 新領域 Unit4 サイトプロモ Unit5 コンシューマ Unit6 キャリア Unit7 BIR Unit9 治験 電カル SRE 基盤 マルデバ AI機械学習 セキュリティ QA 2021-4-1時点：97名 採用チーム グループ会社 支援 プロダクト 支援 5 開発 エンジニア QA エンジニア 自分 組織横断のQAチームに所 属し、担当サービスが BIR

mablとは何か Webブラウザアプリ向けのE2Eテスト自動化クラウドサービス ● 操作をレコードすることによりローコードでテストケース作成が可能 ● AIを活用したオートヒーリングと画面崩れ検知の機能がある ● APIテスト、モバイルWebテストにも対応 6

mablとは何か 7 ブラウザの操作を一連の ステップとして記録 waitやassertionの追加も GUIからできる

なぜmablを導入したのか ＜解決したい課題＞ ● テスト実施、リグレッションに時間がかかっている ○ 一部E2Eテスト自動化に着手できておらず、手動テストしているシステムがある ● 自動テストの作成、メンテナンスが一部の知識のあるメンバーに集中してし まうため全体展開が進みづらい ○ SeleniumやPlaywrightを使っているが、これらはある程度コードが書ける必要がある ○ 自動実行用の環境にアップデートやメンテが必要だが、手が回りづらい ツールである程度解決できるのでは？ 8

なぜmablを導入したのか ＜mablを選んだ理由＞ ● 課題の解消 ○ ローコードツールのため、QAチームのメンバー全員が扱える ■ Webブラウザの操作のレコードでテストケース作成が可能 (一部JavaScriptで記述する必要あり） ○ 自前で実行用の環境を準備する必要がない ● mablの標準機能でカバーできる範囲が広がる ○ 簡単なスモークテストやVRTを実施する機能がついており、リンク切れなどの検知は自動で 行える まずはBIRでmablを導入してみよう！ 9

導入してどうだったか　～スムーズに行った点 ● 体感では7~8割程度がレコーディングしたとおりに動かせる ● 1~2ケース一緒に作れば初めて使うメンバーもすぐに使い始められる ● waitやassertionの追加もGUIで提供されている機能で対応できる テスト対象システムが自動化と相性の良いものであれば レコーディングとGUIで自動テストケースが作成可能 10

導入してどうだったか　～スムーズに行った点 11 Assertionの追加の例 確認対象の要素をクリック で選択 Assertionのタイプを選択 ・等しい、以上、以下 ・含まれる ・～で始まる ・存在する　etc GUIでのクリックや選択で 完結するため、自動化経 験の少ないメンバーにも扱 いやすい

ちょっと工夫が必要だった点 ● 記録したとおりに動かないところもある ○ テーブルのセルの中をクリックしたり、文字入力するようなUI ○ idやnameがついていない要素 ○ 相性の悪いUI ● データを初期化/固定化する必要がある ○ ※テスト自動化につきものの課題であり、mablの問題ではない 12

ちょっと工夫が必要だった点 ＜mablの機能で解決したもの＞ ● テーブルのセルの中をクリックした り、文字入力するようなUI →CSS SelectorやXpathで指定 13 CSS SelectorかXpathで要 素を指定する 該当の要素に対して行う操 作を選択する

チームから得られたサポート(1) ＜工夫が必要だった点についてチームで解決したもの：UI編＞ 「記録したとおりに動かないところもある」への対処 ● idやnameがついていない要素にはすぐに振ってもらう ○ QAからのリクエスト次第即座にidやnameを追加してもらえた ○ その他mablのレコーディングで拾えない要素を拾えるパターンに直してもらった ● mablで操作しやすいよう一部の要素を変更する ○ 例：マニュアルテストでは、コピーボタンでURL取得→URLバーにペーストしていた箇所を URLをリンクにしてクリックで遷移できるようにしてもらった 14

チームから得られたサポート(2) ＜工夫が必要だった点についてチームで解決したもの：データ編＞ 「データを初期化/固定化する必要がある」への対処 ● データバックアップ＆リストアできるツールを作ってもらった ● ※一部対応が難しいものはデータ作成からケース内で行うことで回避 テスト対象のシステムをツールで テストしやすくする協力をチームから得られた 15

チームから得られたサポート ふりかえり ＜結果的に事前にやっておいてよかったこと＞ ● 解決したい課題のチームでの共有・合意 （これが解決するとチームとしても嬉しいことがある） ○ テスト実施、リグレッションに時間がかかっている ○ 自動テストの作成、メンテナンスが一部の知識のあるメンバーに集中してしまうため全体展 開が進みづらい ＜これからローコード自動化サービスを使おうと思ってる方へ＞ ● mablはすごく便利、だけどmablだけではどうにもならないこともある 開発エンジニアとの協力体制が取れて、テスト対象システムもテストしやすく する対応が並行で取れるとスピーディに自動化が進む 16

現状、所感 ＜現状＞ ● 既存の主要システムのリグレッションテストの自動化は完了 ○ ライブラリのバージョンアップなど全体的なリグレッションテストが必要な対応では特に効果 を発揮 ● 新規アプリ作成の際は、最初からmablでテストケースを作成する ○ 事前にmablでテストケース作成が可能か検討 ■ ユースケースに自動化できない部分が含まれてないか ■ 自動化できる場合はmablと相性の悪いところはないかmockレビューの際に確認 ○ テストケースの細かい仕様はmablのステップやassertionとして記述する ＜所感＞ ● リグレッションを気軽にできる安心感は大きい ● テストケースのメンテナンスも楽にできている 17

今後の取り組み ＜BIR＞ ● 新規アプリ作成の際は、最初からmablでテストケースを作成する ○ 記録したテストケースにどのくらい手をかける必要があるか計測中 ■ どの程度が記録したまま動かせるのか ■ どの程度開発エンジニアにサポートして貰う必要があるのか ■ テスト対象システム側の変更にオートヒーリングがどの程度まで追随してくれるのか ＜QAチーム＞ ● BIRで試してみた成果を他の事業チームでも広めていく ○ まずはmablとテスト対象システムの相性確認から実施中 18

今後の取り組み 自動化のその先はどうするのか？ ● 現状ではあまり手を出せてない分野を強化したい ○ ユーザビリティ ○ セキュリティ（専門チームにお任せしている状態） ○ 性能（開発エンジニアにお任せしている状態） etc 19

まとめ ● テスト自動化の推進のため、ローコードテスト自動化サービスのmablを導 入 ● テスト対象システムが自動化と相性が良ければ、テスト自動化経験のないメ ンバーにもテスト自動化を進めてもらえる ● それでも工夫が必要だった点は、mablの機能やチームからの強力なサ ポートで解決した ○ 必要であればテスト対象システムをテストしやすくする変更を入れてもらった 20

21 ご清聴ありがとうございました！ よろしければ エムスリーテックブログもご覧ください。 自動化の取り組みなども紹介しています！ https://www.m3tech.blog/