Tweet
Tweet

Slide 1

Slide 1 text

QA自動化チームの立ち上げと テスト自動化の現状 Masatomo Takano 株式会社メルペイ QA Engineer

Slide 2

Slide 2 text

Masatomo Takano / @nir_takemi 株式会社メルペイ QA Engineer ● 金融系システムのQA経験約5年 ● スマホ向けゲームのクライアント開発経験約 4年 ● スマホ向けゲームのバックエンド開発経験約 1年 ● メルペイにてQA Engineerとして参画 ● 興味ある領域はテストの自動化 ● 趣味はアプリ開発（今は英語学習アプリ作成中）

Slide 3

Slide 3 text

目次 01 課題 02 自動化チームの発足について 03 アクション ● テスト自動化の現状整理 ● 自動化基盤の作成 ● 自動テストの作成（サポート） など 04 おわりに

Slide 4

Slide 4 text

目次 01 課題 02 自動化チームの発足について 03 アクション ● テスト自動化の現状整理 ● 自動化基盤の作成 ● 自動テストの作成（サポート） など 04 おわりに

Slide 5

Slide 5 text

● 全社的な状況 ○ リリースしたい機能/サービスが多い ○ リリーススピードを早くしたい ● QA組織の課題 ○ QAエンジニアがもっと必要！ ■ 1人が複数プロジェクトを兼任している状況 ■ 協力会社の方々に多分にご協力いただいている状況 課題 → テストを自動化することで、少しでも緩和したいが、 　自動化している時間が確保できない！

Slide 6

Slide 6 text

目次 01 課題 02 自動化チームの発足について 03 アクション ● テスト自動化の現状整理 ● 自動化基盤の作成 ● 自動テストの作成（サポート） など 04 おわりに

Slide 7

Slide 7 text

● 自分の担当サービスでテスト自動化が進んでいた ○ QA Engineer1年生の1年間で取り組んだことの紹介 ■ https://engineering.mercari.com/blog/entry/20201225-78a1840466/ ○ リグレッションテストの自動化を段階的に実装した話【 Merpay Tech Fest 2021】 ■ https://engineering.mercari.com/blog/entry/20210928-mtf2021-day5-2/ ○ QA Engineer2年生がQA的技術的負債と立ち向かった話 ■ https://engineering.mercari.com/blog/entry/20220118-dfa7943248/ ● リリース速度も安定していた ● 自動化周りに興味があった 自動化チームの発足について

Slide 8

Slide 8 text

● 自分の担当サービスでテスト自動化が進んでいた ○ QA Engineer1年生の1年間で取り組んだことの紹介 ■ https://engineering.mercari.com/blog/entry/20201225-78a1840466/ ○ リグレッションテストの自動化を段階的に実装した話【 Merpay Tech Fest 2021】 ■ https://engineering.mercari.com/blog/entry/20210928-mtf2021-day5-2/ ○ QA Engineer2年生がQA的技術的負債と立ち向かった話 ■ https://engineering.mercari.com/blog/entry/20220118-dfa7943248/ ● リリース速度も安定していた ● 自動化周りに興味があった 自動化チームの発足について チーム横断で動ける チーム（一人）として 動いてみたい！

Slide 9

Slide 9 text

自動化チームの発足について

Slide 10

Slide 10 text

自動化チームの発足について どうしよう？

Slide 11

Slide 11 text

● 理想の状態を考えてみた ○ 既存案件 ■ リグレッションテストは自動テストを実行するだけ ○ 新規案件 ■ テスト計画の段階で、テストの自動化戦略が決定している ■ リリースまでに自動テストが回せる状態になっている 自動化チームの発足について

Slide 12

Slide 12 text

● 自動化チームのミッション ○ まずは自動化の基盤を整えよう！ ○ 各QAチームが自動テストを書ける（メンテできる）状態にしよう 自動化チームの発足について

Slide 13

Slide 13 text

ちょっとまって

Slide 14

Slide 14 text

● 動こうにも知らないことだらけだった ○ どのチームがどれだけ自動化できているのか？ ○ そもそも対象のサービスはどれだけあるのか？ 自動化チームの発足について → 把握しているメンバーが誰もいない状態だった

Slide 15

Slide 15 text

まずは状況を整理しよう！

Slide 16

Slide 16 text

● ロードマップ(仮) a. テスト自動化の現状整理 b. サポート対象のチームを選定 c. 自動テストの作成（サポート） 自動化チームの発足について

Slide 17

Slide 17 text

目次 01 課題 02 自動化チームの発足について 03 アクション ● テスト自動化の現状整理 ● 自動化基盤の作成 ● 自動テストの作成（サポート） など 04 おわりに

Slide 18

Slide 18 text

● ヒアリングポイント ○ 対象のマイクロサービス ○ テスト対象（バックエンド or フロントエンド or アプリ） ○ 現状の自動化状況 ○ 現状の利用ツール ○ 今後自動化していきたいのか？ ● ※2021/11 時点のものでちょっと情報が古いです 現状整理

Slide 19

Slide 19 text

● テスト対象に関する補足情報 ○ マイクロサービス単位での品質保証 ■ フロント、アプリとの結合前に見つかるべき不具合の発見 ■ マイクロサービス間の結合で見つかるべき不具合の発見 ■ マイクロサービス単位でのリリース 現状整理 テスト ピラミッド
 「テストの基礎」の「テストを作成」より引用
 https://developer.android.com/training/testing/fundamentals#write-tests


Slide 20

Slide 20 text

● 対象のサービス数 ○ バックエンド：50+ ○ フロントエンド：10+ ○ アプリ：5+ 現状整理 =マイクロサービス数 アプリから利用するマイクロサービス数 加盟店等に関するWebベースのサービス数

Slide 21

Slide 21 text

● 自動化状況 現状整理

Slide 22

Slide 22 text

● 自動化状況 現状整理 → 自動化できている割合 　フロントエンド > バックエンド > アプリ

Slide 23

Slide 23 text

● 自動化不要の理由 ○ 規模が小さく、自動化するメリットが少ない ○ QAがそもそも関与していない（社内サービス等） ○ 現在稼働していない ○ NFCなど実機依存のケースなど 現状整理

Slide 24

Slide 24 text

● 利用ツール 現状整理

Slide 25

Slide 25 text

● 自動化状況（バックエンドのAPI/ジョブ別） 現状整理 → APIのテストよりもジョブのテストの方が自動化難易度が高そう

Slide 26

Slide 26 text

● 利用ツール（バックエンドのAPI/ジョブ別） 現状整理

Slide 27

Slide 27 text

● 利用ツール（バックエンドのAPI/ジョブ別） 現状整理 → バックエンドの内製ツールは、ジョブを単発で実行したりするものが多い

Slide 28

Slide 28 text

● バックエンドの内製ツールでの自動化 ○ ジョブを単発で実行したりするものが多い ○ ジョブを実行、値のチェックもできるのは珍しい ■ バッチ処理のリグレッションテスト自動化のトライ ● https://engineering.mercari.com/blog/entry/20220412-try-batch-regressio n-test-automation/ ■ リグレッションテストの自動化を段階的に実装した話【 Merpay Tech Fest 2021】 ● https://engineering.mercari.com/blog/entry/20210928-mtf2021-day5-2/ 現状整理　〜バックエンドの利用ツール補足〜

Slide 29

Slide 29 text

● 利用ツール（バックエンドのマニュアルテストのみ） 現状整理

Slide 30

Slide 30 text

● 利用ツール（バックエンドのマニュアルテストのみ） 現状整理 ● Postmanが使いやすい ● スピード感を持って対応する際に Postmanが採用されやすい ● scenarigoの利用が自動化前提で 使われている（推測）

Slide 31

Slide 31 text

● バックエンド ○ APIテストはPostman or scenarigo を利用 ○ APIテストのマニュアル実行で用いられる割合はPostmanが多い ○ ジョブのテストは内製ツール or scenarigo を利用 ○ 開発チーム側ではgoのe2eテストツールでIntegration testまで実 行。APIテストからはQAチーム側で、異なるツールを用いて実行する ことが主 ■ マイクロサービスの開発とテストファースト /テスト駆動開発 ● https://engineering.mercari.com/blog/entry/gears-microservices/ 自動化の傾向まとめ

Slide 32

Slide 32 text

● フロントエンド ○ 基本的に Cypress ○ Cypressで対応不可の部分はマニュアル実行 ○ 開発エンジニアもIntegration testでCypressを利用 ■ メルペイフロントエンドのテスト自動化方針 ● https://engineering.mercari.com/blog/entry/20211208-test-automation -policy-in-merpay-frontend/ 自動化の傾向まとめ

Slide 33

Slide 33 text

● アプリ ○ iOSは、XCUI ○ Androidは、Espresso ○ 開発エンジニアでのみ、テストコードを書いている状況 ○ 機能追加時等、QAでのテストは100%マニュアルテスト ○ 以前はappiumベースだった時もあった ■ メルカリQA-SETチームが進めているテスト自動化についての質問まとめ ● https://engineering.mercari.com/blog/entry/2017-10-03-093955/ 自動化の傾向まとめ

Slide 34

Slide 34 text

● 全体 ○ 開発/QAエンジニア共に近い環境で書けると自動化が進む傾向あり ■ フロントエンド ● 開発エンジニア：Cypress ● QAエンジニア：Cypress ■ バックエンド ● 開発エンジニア：Go ● QAエンジニア：Postman or scenarigo ■ アプリ ● 開発エンジニア：XCUI or Espresso ● QAエンジニア：ほぼ関われていない 自動化の傾向まとめ

Slide 35

Slide 35 text

● 全体 ○ 基本的にツールは一つに絞る ○ ツールの選定の要素として、 開発エンジニアが利用しやすい（馴染みある）ものに寄せる ○ テストコードはシンプルに書くようにする（保守性/可読性重視） ■ 開発エンジニアもQAもみんなが理解しやすいのを目指すべき ■ 振る舞いこそ正義！ 自動化ポリシー 「なぜE2Eテストでidを使うべきではないのか」 より引用（https://blog.autify.com/ja/why-id-should-not-be-used ）
 


Slide 36

Slide 36 text

● シンプルなテストコードの例　〜バックエンド〜 a. ユーザを作成 b. スマート払いで商品を購入 c. 月次ジョブを実行（清算可能状態にする） d. 清算をする e. 清算が正常に完了したか確認する 自動化ポリシー

Slide 37

Slide 37 text

● シンプルなテストコードの例　〜フロントエンド〜 a. アドレスを入力 b. パスワードを入力 c. ログインボタンを押下 d. サービスのトップ画面に遷移することを確認する 自動化ポリシー

Slide 38

Slide 38 text

● バックエンド ○ APIテストの自動化はscenarigoを用いる ○ バッチのテストも基本scenarigoを用いる ■ DebugAPI経由でバッチと同じ処理を実行 ■ pluginでバッチを実行 ○ ただし内製ツールでデータ準備をする場合、 内製ツールを拡張して自動テストできるようにする 自動化ポリシー

Slide 39

Slide 39 text

● フロントエンド ○ Cypressを用いる ● アプリ ○ iOSは、XCUIを用いる ○ Androidは、Espressoを用いる 自動化ポリシー

Slide 40

Slide 40 text

● 対応ポリシー ○ バックエンドに対象を絞る ○ サポート対象は以下の観点で優先付 ■ 自動化の基盤が整っていないサービス ■ リリース/リグレッションテストが定期的に発生し、 自動化ができていないサービス ○ スムーズに運用するために ツールの理解を深める働きかけをする どうしていこうか？

Slide 41

Slide 41 text

● ロードマップ 修正版 a. テスト自動化の現状整理 b. サポート対象のチームを選定 c. 自動化基盤の作成 d. 自動テストの作成（サポート） e. （並行して）自動化ツールの勉強会 こうしていこう！

Slide 42

Slide 42 text

目次 01 課題 02 自動化チームの発足について 03 アクション ● テスト自動化の現状整理 ● 自動化基盤の作成 ● 自動テストの作成（サポート） など 04 おわりに

Slide 43

Slide 43 text

● APIテストのみを対象とするサービス a. scenarigoのsetup対応を請負 ● テストのオペレーションの中で内製ツール等の実行が含まれる場合 a. 使い方をヒアリング b. 処理をscenarigoのpluginで実装 c. scenarigoで自動化できるよう調整 自動化基盤の作成

Slide 44

Slide 44 text

目次 01 課題 02 自動化チームの発足について 03 アクション ● テスト自動化の現状整理 ● 自動化基盤の作成 ● 自動テストの作成（サポート） など 04 おわりに

Slide 45

Slide 45 text

● 実際に自動テストを作成 ● 作成した内容を勉強会で、他チームにもシェア ● 相談ベースで自動化テスト作成のサポート 自動テストの作成 / サポート

Slide 46

Slide 46 text

● 実際に自動テストを作成 ● 作成した内容を勉強会で、他チームにもシェア ● 相談ベースで自動化テスト作成のサポート 自動テストの作成 / サポート → 一人チームだと対応量に限界が……

Slide 47

Slide 47 text

● 優先度の高いプロジェクトによりフォーカスしてサポート ● 開発エンジニア側にお任せできるところはお任せ （ケースはQAが考えて、テストコードの実装は開発エンジニアさん 等） 自動テストの作成 / サポート

Slide 48

Slide 48 text

● 成果 a. テスト自動化の状況を可視化した b. 自動化の基盤を整えた（＝自動化できる状況を提供できた） c. 複数チームで、自動化の一歩目を踏み出せた d. 自動化をどうしてけばいいかの方向性を出すことができた ● 課題 a. ケースの追加とメンテナンスがまだまだ難しい状況 ■ 対応可能な人が少 ■ ツールの使い方が難 b. アプリの自動化が未だにノータッチ 自動化チームの成果と今後の課題

Slide 49

Slide 49 text

● その他 a. 今回定めた自動化のポリシーが、他の新規プロジェクトでも活きた ■ mercari NFT ● バックエンド（管理ツール） ● フロントエンド（未ログイン時） 自動化チームの成果と今後の課題 方向性は 間違って なさそう？

Slide 50

Slide 50 text

目次 01 課題 02 自動化チームの発足について 03 アクション ● テスト自動化の現状整理 ● 自動化基盤の作成 ● 自動テストの作成（サポート） など 04 おわりに

Slide 51

Slide 51 text

● テストの自動化を推進するチームを作ってみた a. テスト自動化の現状を整理した b. 自動テストの基盤構築をサポートした c. 自動テストの作成をサポートした d. 自動テストで使用するツールの勉強会を実施した おわりに

Slide 52

Slide 52 text

● 現状整理した結果 a. バックエンドの自動化が進むと嬉しい状況だった b. 利用ツール ■ バックエンド：scenarigo｜Postman｜内製ツール ■ フロントエンド：Cypress ■ アプリ：XCUI｜Espresso おわりに

Slide 53

Slide 53 text

● 自動化ポリシーを定めた a. ツールは多用せず、基本1つに集約！ ■ バックエンド：scenarigo （条件によっては内製ツールも利用） ■ フロントエンド：Cypress ■ アプリ：XCUI｜Espresso b. テストコードは誰でも分かるくらいシンプルに！ おわりに

Slide 54

Slide 54 text

● 改めてチームで全員品質を意識して行動する大事さを感じました ● 一人でできることの限界を感じました ● テスト自動化周りに興味ある方は是非お声がけください！ さいごに

Slide 55

Slide 55 text

No content