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

Transcript

1. チームでテストを実装していく ren, qawatake 2024年6⽉1⽇
2. 2022年11月に中途入社
 外部連携サービスのQAエンジニ アを担当後、現在は決済プロダク トのQAエンジニアを担当
 2 ren
 決済プロダクト QAエンジニア 2022年4月freeeに新卒入社 freeeカードUnlimitedを経て、 新規決済プロダクトの開発を担当
 qawatake
 決済プロダクト ソフトウェアエンジニア
3. 01. チームによるテストの実装 02. テストの取り組み a. Integration Testの実装 b. テストサイズを⽤いたリグレッションテストの⾃動化 c. 受⼊基準によるテスト実装の⽀援 d. バックエンドテスト指針‧Integration Testを書いてみる会 e. チームでテストアーキテクチャを育てるために学ぶ 03. チームでテストを実装するために⼤切だったこと ⽬次
4. チームによるテストの実装
5. 私たち決済プロダクトのチームでは、ユーザーストーリーをベースにしたア ジャイル開発を採⽤している その中で、QAエンジニアがストーリーの受⼊基準やテストチャーターを作 成し、それらを基にチーム全員でテストを実装している また、「どんなテスト」を「どのように実装」すれば良いかの⾔語化を進 めており、共通理解をもってテストの実装を⾏っている チームによるテストの実装 チーム全員でテストのことを考え、テストを開発する取り組み
6. ➡ 結果、単体テストや結合テストからシステムテストまで、バランス良く 構成されたテストを実現しており、効率が良く効果の⾼いテスト活動を実現 している チームによるテストの実装 チーム全員でテストのことを考え、テストを開発する取り組み E2E Test for Critical Pass Integration Test for Endpoint Unit Test for Business Logic ‥‥ ‥‥ ‥‥
7. A. プロダクトのデリバリーを⽀えるテスト活動の改善はチームの課題で あり、チーム全員で解決するべきであるため ただ、初めから開発エンジニアとQAエンジニアで協調して進められてい たわけではなく、各々が抱えていた問題意識に向き合っていく過程で、 「チームによるテストの実装」というアプローチに辿り着いた チームによるテストの実装 なぜ「チームによるテストの実装」なのか
8. テストの取り組み
9. ⽬の前の課題に集中して取り組み、その課題解決から得られたインサイト を元に次の課題に取り組む、という道を辿った a. Integration Testの実装 b. テストサイズを⽤いたリグレッションテストの⾃動化 c. 受⼊基準によるテスト実装の⽀援 d. バックエンドテスト指針‧Integration Testを書いてみる会 e. チームでテストアーキテクチャを育てるために学ぶ テストの取り組み
10. Integration Testの実装
11. Integration Testの実装 Unit Testがイケてないなぁ Integration Testで解決できないか？？ • コントローラ層のテストがmockだらけで、リファクタリング耐性が低い • DBとのすべてのやりとりを検証するなど、実装の詳細が不必要にテストに露出 している 重要な機能のデグレを防ぐためにテストを書きたい。ただ、どう書く の？？ • E2Eはすでに仕組みとしてある。ただ、外部サービスへのリクエスト内容はE2E ではテストしにくい… • Unit Testより範囲を広く、Integration Testでカバーしたい。だけど、実現⽅法 が分からない 当初の⼆⼈の課題感
12. Integration Testの実装 開発合宿 • ２⽇間 • 普段とは違うやりたい開発ができる！ DIやライブラリの設定など 共通部分を整えていく 仕組みを使って 実際のテストケースを ごりごり書いていく ⼆⼈でIntegration Testの最初の1個を書いてみる at 開発合宿 2023年も開発合宿を開催しました freee Developers Hub
13. NewApp NewUseCase NewDB NewHogeClient Integration Testの実装 プロダクションコード Integration Test そのまま NewConfig NewTestConfig 置き換え こんなIntegration Testを書いてみました 前提 • Back EndはGo • google/wireを利⽤ ちょっと紹介 • テストもwireでDI • 差分は最⼩限に e.g., 依存サービス のURL差し替え NewApp NewUseCase NewDB NewHogeClient
14. ミドルサイズのテストをどう書くか（How）のイメージが⾒えてくることで、 次のステップを考えられるように Integration Testの実装 効果的でないUnit TestをIntegration Testで置き換えていきたい！ チームで書いていけるといいなぁ ⼿動での実⾏時間の⻑さに悩んでいたリグレッションテストに、 Integration Testを活かせそう！ とりあえずIntegration Testを１個書けたぞ！！
15. ⽬の前の課題に集中して取り組み、その課題解決から得られたインサイト を元に次の課題に取り組む、という道を辿った a. ✅ Integration Testの実装 b. ⏭ テストサイズを⽤いたリグレッションテストの⾃動化 c. 受⼊基準によるテスト実装の⽀援 d. バックエンドテスト指針‧Integration Testを書いてみる会 e. チームでテストアーキテクチャを育てるために学ぶ テストの取り組み
16. テストサイズを用いたリグレッションテストの自動化
17. リグレッションテストを⼿動で⾏なっているけど、リリースの度に時間が かかり過ぎている ⾃動テストで賄いたいけど、「とりあえずE2Eテストで何とかする」は避け たい →Unit TestやIntegration Testも合わせた、E2Eテストだけじゃない リグレッションテストの⾃動化を実現したい テストサイズを⽤いたリグレッションテストの⾃動化 リグレッションテストの課題
18. テスト観点（テストしたいこと）をテストサイズで分類し、リグレッションテスト の各ケースがどのように⾃動テストに対応するかを整理する取り組みに着⼿した テストサイズを⽤いたリグレッションテストの⾃動化 サバンナ便り〜⾃動テストに関する連載で得られた知⾒のまとめ（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) テストサイズによる分類を試した
19. 「そのテストケースでテストしたい機能要素はどこが責務を担っているのか？」 という考え⽅で、整理を⾏なった テストサイズを⽤いたリグレッションテストの⾃動化 機能要素の責務の担い⼿から、書くべきテストを特定する 画⾯⼊⼒の バリデーション処理 フロントエンド バックエンド 外部アプリケーション テストサイズ : smallな バックエンドの単体テスト として実装できる
20. また「そのテストケースで発⾒することを⾒込んでいる事象の重篤度情報(※)」を 整理し、どのテストから対応すると良いか判断できるようにした ※重篤度とは、freee社内で定義している「事象のヤバさ」を表現する指標  4段階の指標であり、重篤度が⾼い順にcritical, major, normal, minorとしている  Eng, QA, PdM, PD全員で、プロダクトの重篤度を定義している テストサイズを⽤いたリグレッションテストの⾃動化 重篤度を⽤いて、テストケースのインパクトを表現する このテストが落ちる（この機能が正常に 動かない）ということは、 誤送⾦が起こるリスクがあるということ 重篤度critical
21. 「テストサイズ」や「機能要素の責務」という明確な基準を⽤いたことで、 単体テストや結合テストからシステムテストまで、バランス良く構成されたテスト として整理することができた テストサイズを⽤いたリグレッションテストの⾃動化 テストサイズにより、テストの構成⽐を表現できた E2E Test Integration Test Unit Test
22. 実装計画に沿ってチーム全員でテスト実装したことにより、1quarterで3割の ⾃動化を達成した • 重篤度情報をもとに優先度を決めたため、インパクトの⼤きいテストから着⼿できた • 継続的に取り組むことで、ほぼ完全に⾃動化できることも分かった テストサイズを⽤いたリグレッションテストの⾃動化 効果的なテスト⾃動化を達成した
23. テストサイズを⽤いたリグレッションテストの⾃動化 テストの責務とテストサイズから、適切な⾃動テストを導けるようになってきた リグレッションテストという題材において、テスト観点に対する適切なテストサイズ を考えられるようになってきた これを新機能開発時にも考えていけるようになりたい！
24. ⽬の前の課題に集中して取り組み、その課題解決から得られたインサイト を元に次の課題に取り組む、という道を辿った a. ✅ Integration Testの実装 b. ✅ テストサイズを⽤いたリグレッションテストの⾃動化 c. ⏭ 受⼊基準によるテスト実装の⽀援 d. バックエンドテスト指針‧Integration Testを書いてみる会 e. チームでテストアーキテクチャを育てるために学ぶ テストの取り組み
25. 受入基準によるテスト実装の支援
26. 受⼊基準によるテスト実装の⽀援 機能開発時のテストに対する課題感 機能開発時に、どのような単体テストが実装されているのか分からない 単体テストと被った内容をQAエンジニアがテストしていそう…
27. チーム全員で受⼊基準の内容を確かめるミーティングを開き、ストーリーごとに何 を単体テストや結合テスト、E2Eテストで実装するかを話し合う取り組みを始めた 受⼊基準によるテスト実装の⽀援 受⼊基準を満たすためのテストを考えるようにした
28. 受⼊基準を作るタイミング（＝実装前のタイミング）でテストのことを考えること で、テスタビリティを確保した設計/実装を⽀援できるようになった 受⼊基準によるテスト実装の⽀援 テスタビリティ向上を⽀援できるようになった E2E Test Integration Test Unit Test Unit Testを書くために、この処 理は関数として切り出そう
29. 何が単体テストや結合テストで実装されているのかが明確になり、その内容を 踏まえて⼿動で実⾏するテストを最⼩限に抑えた、効率的なテストを実現でき るようになった 手動の テスト 受⼊基準によるテスト実装の⽀援 効率的なテストを実現できるようになってきた for Critical Pass for Endpoint for Business Logic 手動のテスト E2E Test Integration Test Unit Test
30. 新機能開発時にも、適切な⾃動テストを考えられるようになってきた 受⼊基準によるテスト実装の⽀援 「テスト活動はチームの課題」が当たり前になってきた テスト活動の知⾒をチームで育てられるようにしたい！ テストの使い分けを話題にできるようになってきた 並⾏して皆でテストを実装できるようになっていきたい！
31. ⽬の前の課題に集中して取り組み、その課題解決から得られたインサイト を元に次の課題に取り組む、という道を辿った a. ✅ Integration Testの実装 b. ✅ テストサイズを⽤いたリグレッションテストの⾃動化 c. ✅ 受⼊基準によるテスト実装の⽀援 d. ⏭ バックエンドテスト指針‧Integration Testを書いてみる会 e. チームでテストアーキテクチャを育てるために学ぶ テストの取り組み
32. バックエンドテスト指針 Integration Testを書いてみる会
33. バックエンドテスト指針‧Integration Testを書いてみる会 次の課題感 効果的でないUnit TestをIntegration Testで置き換えていきたい！ チームで書いていけるといいなぁ
34. バックエンドテスト指針‧Integration Testを書いてみる会 次の課題感 効果的でないUnit TestをIntegration Testで置き換えていきたい！ チームで書いていけるといいなぁ まずは書き⽅を知ってもらうところから... 「Integration Testを書いてみる会」を開催
35. バックエンドテスト指針‧Integration Testを書いてみる会 Integration Testを書いてみる会 メンバーみんなで集まって、ひとりひとりが１ケースを担当し、実装仕切る 実際に書いてみると、詳細についての疑問が出てきたり、動かないところがで てきたり。。 • モックライブラリの使い⽅系。メール送信やgRPCのモックはどうする？？ • Integration Testで何を検証するか？？ • あるメンバーのテストケースだけ、ライブラリがエラーを返す 😢 ⾮同期でやっていると時間がかかりすぎる。。 最初は同期的にやる⽅針で正解だったかも！
36. バックエンドテスト指針‧Integration Testを書いてみる会 チームで書いていけるか？？ これからみんなでどんなテストを書いていきたいか、認識を合わせたい ドキュメント「バックエンドのテスト実装⽅針」の作成へ [再掲] 効果的でないUnit TestをIntegration Testで置き換えていきたい！ チームで書いていけるといいなぁ。
37. バックエンドテスト指針‧Integration Testを書いてみる会 バックエンドテスト指針 例えば、こんな疑問‧懸念に答えられるような内容に • 🤔 Unit TestとIntegration Testをどう使い分けるんだっけ？？ • 🤔 書き⽅は分かったけど、何に対してどれくらい書くの？？ • 🤔 やることが増えるってこと？？
38. バックエンドテスト指針‧Integration Testを書いてみる会 バックエンドテスト指針 単体テストの考え⽅/使い⽅ 「単体テストの考え⽅/使い⽅」を参考にしながら、 ⾃分たちのプロジェクトの構成に落とし込んでみる 🤔 Unit TestとIntegration Testをどう使い分けるんだっ け？？
39. バックエンドテスト指針‧Integration Testを書いてみる会 バックエンドテスト指針 例） • 例えば、このValidateメソッド のようなビジネスロジックは Unit Testで書きたい • 複数のプロセス外依存を呼び 出す、usecaseのテストは Integration Testでカバーした い ドメイン‧モデル/ アルゴリズム コントローラ 過度に複雑な コード コードの複雑さ/ ドメインにおけ る重要性 協⼒者オブジェクトの数 取るに⾜らない コード 単体テストの考え方/使い方 図7.1
40. 例） 事実上のentrypointに対して、正常系の Integration Testを少なくとも１つ「必ず書く」 バックエンドテスト指針‧Integration Testを書いてみる会 バックエンドテスト指針 gateway infra usecase / grpc batch worker 🤔 書き⽅は分かったけど、 何に対してどれくらい書くの？？ 必ず書きたいテストを明⽂化してルールに
41. バックエンドテスト指針‧Integration Testを書いてみる会 バックエンドテスト指針 🤔 やることが増えるってこと？？ メンバーが納得感をもってIntegration Testを書けるようにしたい！ • 既存のテストに対するIntegration Testのメリットを記載 • 必ずしも⼿間が増えるとは限らないことを伝えてみる
42. バックエンドテスト指針‧Integration Testを書いてみる会 例） • Integration Testでテストすることで、リファクタリング耐性が⾼くなります • 代わりに今ある〜のテストは書かなくてよくなります usecase repository mock HTTP client mock DB 依存 サービス usecase repository HTTP client DB 依存 サービス バックエンドテスト指針 usecaseのテスト Integration Test
43. バックエンドテスト指針‧Integration Testを書いてみる会 チームで書けるようになった？ • Integration Testを書いてみる会 ◦ 新規のテストケースも⼀から作成できるように！ • バックエンドテスト指針 ◦ いったん、⽅針にそってテスト実装を進めていけそう！ 次の課題は持続可能性 困りごとや不満点に応じて、軌道修正もしていきたい！
44. ⽬の前の課題に集中して取り組み、その課題解決から得られたインサイト を元に次の課題に取り組む、という道を辿った a. ✅ Integration Testの実装 b. ✅ テストサイズを⽤いたリグレッションテストの⾃動化 c. ✅ 受⼊基準によるテスト実装の⽀援 d. ✅ バックエンドテスト指針‧Integration Testを書いてみる会 e. ⏭ チームでテストアーキテクチャを育てるために学ぶ テストの取り組み
45. チームでテストアーキテクチャを育てるために学ぶ
46. チームでテストアーキテクチャを育てるために学ぶ • テスト活動全般を改善していくためには、チーム全員が認識できるよ うな⾔語化やモデリングを⾏う必要がある • そのようなアウトプットを、テストアーキテクチャと呼ぶ • 難しい概念なので、テストアーキテクチャのための勉強会から始める ことにした テスト活動の知⾒をチームで育てられるようにしたい！
47. チームでテストアーキテクチャを育てるために学ぶ freeeでは標準テストプロセスが整備されているため、まずはテストプロセス の勉強会を⾏なった 10分でわかるfreeeのQA (https://speakerdeck.com/freee/10fen-dewakarufreeenoqa?slide=36) テストプロセスの勉強会
48. チームでテストアーキテクチャを育てるために学ぶ 次に、基本的な⽤語を押さえるために、JSTQBのFLシラバスを⽤いて勉強会を ⾏なった JSTQB-SyllabusFoundation_V4.0.J01 (https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J01.pdf) テスト⽤語の勉強会
49. モダンなテストレベル設計（ユニットテスト〜システ ムテスト等をどう設計するか）の原則 - 千⾥霧中 (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-modified) テストアーキテクチャの勉強会
50. テストアーキテクチャへの取り組みは、今まさに⾏なっている チームでテストアーキテクチャを育てるために学ぶ 展望 : テストアーキテクチャを育てていく 機能テストについてより解像度を上げて効率的で効果的なテストを⽬指す ⾮機能テストも含めて全体像を整理することで、テスト活動のインパクトを より⼤きくしていきたい
51. チームでテストを実装するために大切だったこと
52. ⼀歩⼀歩進めていくことが、より⼤きな価値を⽣み出すアイデアや取り組み に繋がっていった ⼀つ改善したことで⾒えるようになった課題も多くあった a. Integration Testの実装 b. テストサイズを⽤いたリグレッションテストの⾃動化 c. 受⼊基準によるテスト実装の⽀援 d. バックエンドテスト指針‧Integration Testを書いてみる会 e. チームでテストアーキテクチャを育てるために学ぶ チームでテストを実装するために⼤切だったこと