チームでテストを実装していく / Implementing Tests as a Team

by ropQa

Slide 1

Slide 1 text

チームでテストを実装していく ren, qawatake 2024年6⽉1⽇

Slide 2

Slide 2 text

2022年11月に中途入社  外部連携サービスのQAエンジニアを担当後、現在は決済プロダクトのQAエンジニアを担当  2 ren  決済プロダクト QAエンジニア 2022年4月freeeに新卒入社 freeeカードUnlimitedを経て、新規決済プロダクトの開発を担当  qawatake  決済プロダクトソフトウェアエンジニア

Slide 3

Slide 3 text

01. チームによるテストの実装 02. テストの取り組み a. Integration Testの実装 b. テストサイズを⽤いたリグレッションテストの⾃動化 c. 受⼊基準によるテスト実装の⽀援 d. バックエンドテスト指針‧Integration Testを書いてみる会 e. チームでテストアーキテクチャを育てるために学ぶ 03. チームでテストを実装するために⼤切だったこと⽬次

Slide 4

Slide 4 text

チームによるテストの実装

Slide 5

Slide 5 text

私たち決済プロダクトのチームでは、ユーザーストーリーをベースにしたアジャイル開発を採⽤しているその中で、QAエンジニアがストーリーの受⼊基準やテストチャーターを作成し、それらを基にチーム全員でテストを実装しているまた、「どんなテスト」を「どのように実装」すれば良いかの⾔語化を進めており、共通理解をもってテストの実装を⾏っているチームによるテストの実装チーム全員でテストのことを考え、テストを開発する取り組み

Slide 6

Slide 6 text

➡ 結果、単体テストや結合テストからシステムテストまで、バランス良く構成されたテストを実現しており、効率が良く効果の⾼いテスト活動を実現しているチームによるテストの実装チーム全員でテストのことを考え、テストを開発する取り組み E2E Test for Critical Pass Integration Test for Endpoint Unit Test for Business Logic ‥‥ ‥‥ ‥‥

Slide 7

Slide 7 text

A. プロダクトのデリバリーを⽀えるテスト活動の改善はチームの課題であり、チーム全員で解決するべきであるためただ、初めから開発エンジニアとQAエンジニアで協調して進められていたわけではなく、各々が抱えていた問題意識に向き合っていく過程で、「チームによるテストの実装」というアプローチに辿り着いたチームによるテストの実装なぜ「チームによるテストの実装」なのか

Slide 8

Slide 8 text

テストの取り組み

Slide 9

Slide 9 text

⽬の前の課題に集中して取り組み、その課題解決から得られたインサイトを元に次の課題に取り組む、という道を辿った a. Integration Testの実装 b. テストサイズを⽤いたリグレッションテストの⾃動化 c. 受⼊基準によるテスト実装の⽀援 d. バックエンドテスト指針‧Integration Testを書いてみる会 e. チームでテストアーキテクチャを育てるために学ぶテストの取り組み

Slide 10

Slide 10 text

Integration Testの実装

Slide 11

Slide 11 text

Integration Testの実装 Unit Testがイケてないなぁ Integration Testで解決できないか？？ ● コントローラ層のテストがmockだらけで、リファクタリング耐性が低い ● DBとのすべてのやりとりを検証するなど、実装の詳細が不必要にテストに露出している重要な機能のデグレを防ぐためにテストを書きたい。ただ、どう書くの？？ ● E2Eはすでに仕組みとしてある。ただ、外部サービスへのリクエスト内容はE2E ではテストしにくい… ● Unit Testより範囲を広く、Integration Testでカバーしたい。だけど、実現⽅法が分からない当初の⼆⼈の課題感

Slide 12

Slide 12 text

Integration Testの実装開発合宿 ● ２⽇間 ● 普段とは違うやりたい開発ができる！ DIやライブラリの設定など共通部分を整えていく仕組みを使って実際のテストケースをごりごり書いていく⼆⼈でIntegration Testの最初の1個を書いてみる at 開発合宿 2023年も開発合宿を開催しました freee Developers Hub

Slide 13

Slide 13 text

NewApp NewUseCase NewDB NewHogeClient Integration Testの実装プロダクションコード Integration Test そのまま NewConﬁg NewTestConﬁg 置き換えこんなIntegration Testを書いてみました前提 ● Back EndはGo ● google/wireを利⽤ちょっと紹介 ● テストもwireでDI ● 差分は最⼩限に e.g., 依存サービスのURL差し替え NewApp NewUseCase NewDB NewHogeClient

Slide 14

Slide 14 text

ミドルサイズのテストをどう書くか（How）のイメージが⾒えてくることで、次のステップを考えられるように Integration Testの実装効果的でないUnit TestをIntegration Testで置き換えていきたい！チームで書いていけるといいなぁ⼿動での実⾏時間の⻑さに悩んでいたリグレッションテストに、 Integration Testを活かせそう！とりあえずIntegration Testを１個書けたぞ！！

Slide 15

Slide 15 text

⽬の前の課題に集中して取り組み、その課題解決から得られたインサイトを元に次の課題に取り組む、という道を辿った a. ✅ Integration Testの実装 b. ⏭ テストサイズを⽤いたリグレッションテストの⾃動化 c. 受⼊基準によるテスト実装の⽀援 d. バックエンドテスト指針‧Integration Testを書いてみる会 e. チームでテストアーキテクチャを育てるために学ぶテストの取り組み

Slide 16

Slide 16 text

テストサイズを用いたリグレッションテストの自動化

Slide 17

Slide 17 text

リグレッションテストを⼿動で⾏なっているけど、リリースの度に時間がかかり過ぎている⾃動テストで賄いたいけど、「とりあえずE2Eテストで何とかする」は避けたい →Unit TestやIntegration Testも合わせた、E2Eテストだけじゃないリグレッションテストの⾃動化を実現したいテストサイズを⽤いたリグレッションテストの⾃動化リグレッションテストの課題

Slide 18

Slide 18 text

テスト観点（テストしたいこと）をテストサイズで分類し、リグレッションテストの各ケースがどのように⾃動テストに対応するかを整理する取り組みに着⼿したテストサイズを⽤いたリグレッションテストの⾃動化サバンナ便り〜⾃動テストに関する連載で得られた知⾒のまとめ（2023年5⽉版）〜 / Automated Test Knowledge from Savanna 202305 edition - Speaker Deck (https://speakerdeck.com/twada/automated-test-knowledge-from-savanna-202305-edition?slide=3 1) テストサイズによる分類を試した

Slide 19

Slide 19 text

「そのテストケースでテストしたい機能要素はどこが責務を担っているのか？」という考え⽅で、整理を⾏なったテストサイズを⽤いたリグレッションテストの⾃動化機能要素の責務の担い⼿から、書くべきテストを特定する画⾯⼊⼒のバリデーション処理フロントエンドバックエンド外部アプリケーションテストサイズ : smallなバックエンドの単体テストとして実装できる

Slide 20

Slide 20 text

また「そのテストケースで発⾒することを⾒込んでいる事象の重篤度情報(※)」を整理し、どのテストから対応すると良いか判断できるようにした ※重篤度とは、freee社内で定義している「事象のヤバさ」を表現する指標 4段階の指標であり、重篤度が⾼い順にcritical, major, normal, minorとしている Eng, QA, PdM, PD全員で、プロダクトの重篤度を定義しているテストサイズを⽤いたリグレッションテストの⾃動化重篤度を⽤いて、テストケースのインパクトを表現するこのテストが落ちる（この機能が正常に動かない）ということは、誤送⾦が起こるリスクがあるということ重篤度critical

Slide 21

Slide 21 text

「テストサイズ」や「機能要素の責務」という明確な基準を⽤いたことで、単体テストや結合テストからシステムテストまで、バランス良く構成されたテストとして整理することができたテストサイズを⽤いたリグレッションテストの⾃動化テストサイズにより、テストの構成⽐を表現できた E2E Test Integration Test Unit Test

Slide 22

Slide 22 text

実装計画に沿ってチーム全員でテスト実装したことにより、1quarterで3割の⾃動化を達成した ● 重篤度情報をもとに優先度を決めたため、インパクトの⼤きいテストから着⼿できた ● 継続的に取り組むことで、ほぼ完全に⾃動化できることも分かったテストサイズを⽤いたリグレッションテストの⾃動化効果的なテスト⾃動化を達成した

Slide 23

Slide 23 text

テストサイズを⽤いたリグレッションテストの⾃動化テストの責務とテストサイズから、適切な⾃動テストを導けるようになってきたリグレッションテストという題材において、テスト観点に対する適切なテストサイズを考えられるようになってきたこれを新機能開発時にも考えていけるようになりたい！

Slide 24

Slide 24 text

⽬の前の課題に集中して取り組み、その課題解決から得られたインサイトを元に次の課題に取り組む、という道を辿った a. ✅ Integration Testの実装 b. ✅ テストサイズを⽤いたリグレッションテストの⾃動化 c. ⏭ 受⼊基準によるテスト実装の⽀援 d. バックエンドテスト指針‧Integration Testを書いてみる会 e. チームでテストアーキテクチャを育てるために学ぶテストの取り組み

Slide 25

Slide 25 text

受入基準によるテスト実装の支援

Slide 26

Slide 26 text

受⼊基準によるテスト実装の⽀援機能開発時のテストに対する課題感機能開発時に、どのような単体テストが実装されているのか分からない単体テストと被った内容をQAエンジニアがテストしていそう…

Slide 27

Slide 27 text

チーム全員で受⼊基準の内容を確かめるミーティングを開き、ストーリーごとに何を単体テストや結合テスト、E2Eテストで実装するかを話し合う取り組みを始めた受⼊基準によるテスト実装の⽀援受⼊基準を満たすためのテストを考えるようにした

Slide 28

Slide 28 text

受⼊基準を作るタイミング（＝実装前のタイミング）でテストのことを考えることで、テスタビリティを確保した設計/実装を⽀援できるようになった受⼊基準によるテスト実装の⽀援テスタビリティ向上を⽀援できるようになった E2E Test Integration Test Unit Test Unit Testを書くために、この処理は関数として切り出そう

Slide 29

Slide 29 text

何が単体テストや結合テストで実装されているのかが明確になり、その内容を踏まえて⼿動で実⾏するテストを最⼩限に抑えた、効率的なテストを実現できるようになった手動のテスト受⼊基準によるテスト実装の⽀援効率的なテストを実現できるようになってきた for Critical Pass for Endpoint for Business Logic 手動のテスト E2E Test Integration Test Unit Test

Slide 30

Slide 30 text

新機能開発時にも、適切な⾃動テストを考えられるようになってきた受⼊基準によるテスト実装の⽀援「テスト活動はチームの課題」が当たり前になってきたテスト活動の知⾒をチームで育てられるようにしたい！テストの使い分けを話題にできるようになってきた並⾏して皆でテストを実装できるようになっていきたい！

Slide 31

Slide 31 text

⽬の前の課題に集中して取り組み、その課題解決から得られたインサイトを元に次の課題に取り組む、という道を辿った a. ✅ Integration Testの実装 b. ✅ テストサイズを⽤いたリグレッションテストの⾃動化 c. ✅ 受⼊基準によるテスト実装の⽀援 d. ⏭ バックエンドテスト指針‧Integration Testを書いてみる会 e. チームでテストアーキテクチャを育てるために学ぶテストの取り組み

Slide 32

Slide 32 text

バックエンドテスト指針 Integration Testを書いてみる会

Slide 33

Slide 33 text

バックエンドテスト指針‧Integration Testを書いてみる会次の課題感効果的でないUnit TestをIntegration Testで置き換えていきたい！チームで書いていけるといいなぁ

Slide 34

Slide 34 text

バックエンドテスト指針‧Integration Testを書いてみる会次の課題感効果的でないUnit TestをIntegration Testで置き換えていきたい！チームで書いていけるといいなぁまずは書き⽅を知ってもらうところから... 「Integration Testを書いてみる会」を開催

Slide 35

Slide 35 text

バックエンドテスト指針‧Integration Testを書いてみる会 Integration Testを書いてみる会メンバーみんなで集まって、ひとりひとりが１ケースを担当し、実装仕切る実際に書いてみると、詳細についての疑問が出てきたり、動かないところがでてきたり。。 ● モックライブラリの使い⽅系。メール送信やgRPCのモックはどうする？？ ● Integration Testで何を検証するか？？ ● あるメンバーのテストケースだけ、ライブラリがエラーを返す 😢 ⾮同期でやっていると時間がかかりすぎる。。最初は同期的にやる⽅針で正解だったかも！

Slide 36

Slide 36 text

バックエンドテスト指針‧Integration Testを書いてみる会チームで書いていけるか？？これからみんなでどんなテストを書いていきたいか、認識を合わせたいドキュメント「バックエンドのテスト実装⽅針」の作成へ [再掲] 効果的でないUnit TestをIntegration Testで置き換えていきたい！チームで書いていけるといいなぁ。

Slide 37

Slide 37 text

バックエンドテスト指針‧Integration Testを書いてみる会バックエンドテスト指針例えば、こんな疑問‧懸念に答えられるような内容に ● 🤔 Unit TestとIntegration Testをどう使い分けるんだっけ？？ ● 🤔 書き⽅は分かったけど、何に対してどれくらい書くの？？ ● 🤔 やることが増えるってこと？？

Slide 38

Slide 38 text

バックエンドテスト指針‧Integration Testを書いてみる会バックエンドテスト指針単体テストの考え⽅/使い⽅「単体テストの考え⽅/使い⽅」を参考にしながら、⾃分たちのプロジェクトの構成に落とし込んでみる 🤔 Unit TestとIntegration Testをどう使い分けるんだっけ？？

Slide 39

Slide 39 text

バックエンドテスト指針‧Integration Testを書いてみる会バックエンドテスト指針例） ● 例えば、このValidateメソッドのようなビジネスロジックは Unit Testで書きたい ● 複数のプロセス外依存を呼び出す、usecaseのテストは Integration Testでカバーしたいドメイン‧モデル/ アルゴリズムコントローラ過度に複雑なコードコードの複雑さ/ ドメインにおける重要性協⼒者オブジェクトの数取るに⾜らないコード単体テストの考え方/使い方図7.1

Slide 40

Slide 40 text

例）事実上のentrypointに対して、正常系の Integration Testを少なくとも１つ「必ず書く」バックエンドテスト指針‧Integration Testを書いてみる会バックエンドテスト指針 gateway infra usecase / grpc batch worker 🤔 書き⽅は分かったけど、何に対してどれくらい書くの？？必ず書きたいテストを明⽂化してルールに

Slide 41

Slide 41 text

バックエンドテスト指針‧Integration Testを書いてみる会バックエンドテスト指針 🤔 やることが増えるってこと？？メンバーが納得感をもってIntegration Testを書けるようにしたい！ ● 既存のテストに対するIntegration Testのメリットを記載 ● 必ずしも⼿間が増えるとは限らないことを伝えてみる

Slide 42

Slide 42 text

バックエンドテスト指針‧Integration Testを書いてみる会例） ● Integration Testでテストすることで、リファクタリング耐性が⾼くなります ● 代わりに今ある〜のテストは書かなくてよくなります usecase repository mock HTTP client mock DB 依存サービス usecase repository HTTP client DB 依存サービスバックエンドテスト指針 usecaseのテスト Integration Test

Slide 43

Slide 43 text

バックエンドテスト指針‧Integration Testを書いてみる会チームで書けるようになった？ ● Integration Testを書いてみる会 ○ 新規のテストケースも⼀から作成できるように！ ● バックエンドテスト指針 ○ いったん、⽅針にそってテスト実装を進めていけそう！次の課題は持続可能性困りごとや不満点に応じて、軌道修正もしていきたい！

Slide 44

Slide 44 text

⽬の前の課題に集中して取り組み、その課題解決から得られたインサイトを元に次の課題に取り組む、という道を辿った a. ✅ Integration Testの実装 b. ✅ テストサイズを⽤いたリグレッションテストの⾃動化 c. ✅ 受⼊基準によるテスト実装の⽀援 d. ✅ バックエンドテスト指針‧Integration Testを書いてみる会 e. ⏭ チームでテストアーキテクチャを育てるために学ぶテストの取り組み

Slide 45

Slide 45 text

チームでテストアーキテクチャを育てるために学ぶ

Slide 46

Slide 46 text

チームでテストアーキテクチャを育てるために学ぶ ● テスト活動全般を改善していくためには、チーム全員が認識できるような⾔語化やモデリングを⾏う必要がある ● そのようなアウトプットを、テストアーキテクチャと呼ぶ ● 難しい概念なので、テストアーキテクチャのための勉強会から始めることにしたテスト活動の知⾒をチームで育てられるようにしたい！

Slide 47

Slide 47 text

チームでテストアーキテクチャを育てるために学ぶ freeeでは標準テストプロセスが整備されているため、まずはテストプロセスの勉強会を⾏なった 10分でわかるfreeeのQA (https://speakerdeck.com/freee/10fen-dewakarufreeenoqa?slide=36) テストプロセスの勉強会

Slide 48

Slide 48 text

チームでテストアーキテクチャを育てるために学ぶ次に、基本的な⽤語を押さえるために、JSTQBのFLシラバスを⽤いて勉強会を⾏なった JSTQB-SyllabusFoundation_V4.0.J01 (https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J01.pdf) テスト⽤語の勉強会

Slide 49

Slide 49 text

モダンなテストレベル設計（ユニットテスト〜システムテスト等をどう設計するか）の原則 - 千⾥霧中 (https://goyoki.hatenablog.com/entry/2023/04/22/2 10640) ⽤語の理解をした上で、QAアーキテクチャやテストアーキテクチャの勉強会を⾏なったチームでテストアーキテクチャを育てるために学ぶイマドキのソフトウェアのテストやQAの考え⽅ (https://www.slideshare.net/YasuharuNishi/line-dev eloper-meetup-in-tokyo-39-presentation-modiﬁed) テストアーキテクチャの勉強会

Slide 50

Slide 50 text

テストアーキテクチャへの取り組みは、今まさに⾏なっているチームでテストアーキテクチャを育てるために学ぶ展望 : テストアーキテクチャを育てていく機能テストについてより解像度を上げて効率的で効果的なテストを⽬指す⾮機能テストも含めて全体像を整理することで、テスト活動のインパクトをより⼤きくしていきたい

Slide 51

Slide 51 text

チームでテストを実装するために大切だったこと

Slide 52

Slide 52 text

⼀歩⼀歩進めていくことが、より⼤きな価値を⽣み出すアイデアや取り組みに繋がっていった⼀つ改善したことで⾒えるようになった課題も多くあった a. Integration Testの実装 b. テストサイズを⽤いたリグレッションテストの⾃動化 c. 受⼊基準によるテスト実装の⽀援 d. バックエンドテスト指針‧Integration Testを書いてみる会 e. チームでテストアーキテクチャを育てるために学ぶチームでテストを実装するために⼤切だったこと

Slide 53

Slide 53 text

No content