テスト自動化のアプローチ__範囲別の採用ツールと手法.pdf

2024/11/22のテスト自動化勉強会の資料です。

Transcript

1. テスト自動化のアプローチ 
 　～範囲別の採用ツールと手法 
 2024/11/22
 テスト自動化エンジニア勉強会　 
 ～各社の取り組みや課題から学ぶ会～ 
 エムスリー株式会社　城本　由希 
 1
2. 自己紹介 • 城本　由希　@yuki_shiro_823 • エムスリー株式会社で組織横断のチームであるQAチームに所属 • 担当はリサーチの部門であるBIRでアンケートの作成や配信などのシステムの QA • QAエンジニアのスキル向上を目指してQAチーム内の勉強会を開いたり、ツー ルの導入・運用を行っている • 広島出身のカープファン 2 2
3. 今日話すこと、メインターゲット 3 ＜話すこと ＞ 1. E2Eテストツール導入時の 課題とアプローチ 2. API自動化時の課題と アプローチ 3. まとめ ＜メインターゲット＞ • テスト自動化に興味のある人 ◦ 特に課題毎にアプローチを 検討している人 3
4. エムスリーのQAチームの立ち位置 4 開発 エンジニア QA エンジニア 自分 組織横断のQAチームに所属 担当サービスがBIR 4
5. E2Eテスト自動化ツール 導入時の 課題とアプローチ 図はgihyo.jpの和田卓人氏の「サバンナ便り ～ソフトウェア開発の荒野を生き抜く～」 第5回「テストピラミッド 」よりお借りしました。強調箇所はこちらで付けています。 5
6. やりたいこと テストをガンガン回したい 開発を高速に安心して進めたい 6 6
7. 背景：エムスリーでのテスト自動化の状況（2020） • テスト実施、リグレッションに時間がかかっている ◦ 一部E2Eテスト自動化に着手できておらず、手動テストで対応 • 自動テストの作成、メンテナンスが一部の知識のあるメンバーに集中してし まうため全体展開が進みづらい ◦ SeleniumやPlaywrightはある程度コードが書ける必要がある ◦ 自動実行用の環境にアップデートやメンテに手が回りづらい 7
8. E2Eテストでカバーしたい範囲 8 マイクロサービス① マイクロサービス② マイクロサービス③ テストしたい範囲（ユースケースで通る範囲）
9. 検討内容と狙い 検討：2020当時広まりつつあったローコードツールで解決できないか？ 狙い： • 課題の解消 ◦ ローコードツールのため、QAチームのメンバー全員が扱える ▪ Webブラウザの操作のレコードでテストケース作成が可能 ▪ 自前で実行用の環境を準備する必要がない • mablの標準機能でカバーできる範囲が広がる ◦ 簡単なスモークテストやVRTを実施する機能がついており、リンク切れな どの検知は自動で行える 9 9
10. アプローチ：スモールトライアル まずは担当チーム（BIR）でトライアル開始 • ペアプロ的な対応 ◦ 1~2ケース一緒に作れば初めて使うメンバーもすぐ使い始められる • できる感覚をつかんでもらう ◦ 体感では7~8割程度がレコーディングしたとおりに動かせる ◦ GUIからwaitやassertionの追加ができる。IF文やFOR文も可能 テスト対象システムが自動化と相性の良いものであれば レコーディングとGUIで自動テストケースが作成可能！ 10 10
11. 参考：mablの実際の画面 11 ブラウザの操作を一連の ステップとして記録 waitやassertionの追加も GUIからできる 11
12. アプローチ：全体への拡大 1チーム（BIR）で成功体験を積んでから他チームへ拡大 • 複数チームで運用を行うためのルール作り ◦ 命名規則やクラウド実行タイミングのルール整備 • 質問しやすい場の整備 ◦ 週一の勉強会や自動テスト関連のSlackチャンネル 現在は利用チームが7チームに拡大 mablであれば自動テストに対応できるメンバーが増えた 12 12 ※こちらの記事でも詳しく紹介しておりますのでご覧ください 「mabl Experience'23で「複数チームでmablを活用する際の課題と対応」について話しました 」
13. mabl導入の結果 13 テストをガンガン回したい 開発を高速に安心して進めたい 当初の狙いは概ね達成 アプローチ中のチームや 運用課題対応中のチームもある。 が、そこは次の課題が 出てきたと考えている 13
14. APIテスト自動化時の 課題とアプローチ 図はgihyo.jpの和田卓人氏の「サバンナ便り ～ソフトウェア開発の荒野を生き抜く～」 第5回「テストピラミッド 」よりお借りしました。強調箇所はこちらで付けています。 14
15. やりたいこと テストをガンガン回したい 開発を高速に安心して進めたい 15
16. 背景：テスト自動化の状況（2022） 背景(1)プロジェクト状況 リニューアルプロジェクトが始まる 大きいサービスからパーツを分けてマイクロサービス化 （パーツのINPUT、OUTPUTに変更はない） →大きいサービスの毎週の定期リリースから外れた →都度リリースができるようになりPDCA回しやすくなった リグレッション機会が増える 16 16
17. 背景：テスト自動化の状況（2022） 背景(2)自動テストのカバー状況 • モバイルアプリは自動テストがない • PC/SPのWebアプリはmabl他でカバーされている 背景(3)リソース状況 • 通常のリリース向けのテストの実施も必要 • 担当のQAはコーディングにも積極的に取り組む姿勢アリ 17 17
18. APIテストでカバーしたい範囲 ※理解あってるか確認してから図は直します 18 18
19. APIテストでカバーしたい範囲 19 19 m3.com 基盤系 API群 各サービス群 テストしたい範囲 簡略化したイメージ API API API …… サービス サービス サービス ……
20. 検討内容と狙い 検討：APIテストでカバーできないか 狙い： 背景(1)プロジェクト状況 →自動テストを整備し、増えたリグレッションテストの回数に対応したい 背景(2)自動テストのカバー状況 →自動テストでカバーできる範囲を増やしたい 背景(3)リソース状況 →外部仕様に変更ないものはEngが自動テストを回すことで 　QAリソースの逼迫を防ぐ 　メンテナンスをEng、QA双方ができるようにする 20 20
21. 補足 「外部仕様に変更ないものは Engが自動テストを回すことで 　QAリソースの逼迫を防ぐ」について 21 事前にテスト実施について以下のルールを定めていた • QAチームによるテストが必要なもの ◦ 仕様自体の変更 ◦ ロジックに変更が入ったもの　など • 開発Engによるテストでよいもの ◦ 外部仕様に変更がないもの ▪ 非機能ライブラリ等のマイナーアップデートなど ◦ 軽い変更 ▪ 文言のみ、閾値のみの変更など 21
22. アプローチ 仮説：APIテストで背景に挙げたことに対応できるのではないか 状況のおさらい： 外部仕様に変更はなく、APIを一個ずつ置き換えていく ＝変更前後でAPIのINとOUTが変わらなければOK 対応：まずはscenarigoを使用して1案件実施 　　　→APIテストを自動化する方向で解決しそうという実感を得る　 　　　→その後runnに置き換えて対象範囲拡大 　　　（チュートリアルが整っていて導入しやすい） 22 22 scenarigoについてはこちらで詳しく 紹介しておりますのでどうぞ 「API テスト事始め ーテストツールscenarigoを添えてー」
23. アプローチの結果どう変わったか Before：自動テスト整備前は手動テスト 　　　　（所要0.5人日程度） After：（事前の相談） 　　　自動テストのpass 　　　Slackワークフローで完結 　　　(テスト実施の実働が短縮) 23 23
24. APIテスト導入の結果 24 テストをガンガン回したい 開発を高速に安心して進めたい 当初の狙いは概ね達 成 （まだ運用中チームは少ない ので拡大予定） 24
25. まとめ • やりたいこと「システムテストをガンガン回したい」「開発を高速に安心して 進めたい」に対して、範囲別に2つのアプローチをとった ◦ E2Eテストはローコード自動化サービスの mabl ◦ インテグレーションテストは APIテストツールのrunn • 当初の狙いとしては概ね達成。新しく出てきた課題に対応しようとしている 25 25
26. ぜひフォローよろしくお願いします！ 26 エムスリーの公式 Xはこちら！！ ご清聴ありがとうございました！ 26