Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
チームでテストを実装していく / Implementing Tests as a Team
Search
ropQa
June 01, 2024
Technology
0
2.3k
チームでテストを実装していく / Implementing Tests as a Team
ropQa
June 01, 2024
Tweet
Share
More Decks by ropQa
See All by ropQa
QA出身スリーアミーゴスでDeep Dive! スクラムで品質とスピードを意識したOne Teamを構成するために必要だったもの / Deep Dive into the the Essence of 'One Team'
ropqa
2
350
開発スピードの維持向上を支える、テスト設計の 漸進的進化への取り組み / Continuous Test Design Development for Speed of Product Development
ropqa
0
270
開発を加速させるためのQA活動 / Accelerating Development With Agile QA
ropqa
0
530
JaSST_nano_vol11_qa_dialogue
ropqa
0
390
Other Decks in Technology
See All in Technology
デジタル化・DX推進あるある
y150saya
0
220
20分で分かるIAM全機能 (拡大版) / 20240903-jawsug-yokohama-iam
opelab
3
120
トレタO/X アーキテクチャ移行記 Next.js App Router化への道のり / TORETA TECH UPDATE 1
okunokentaro
2
560
タイミーのBraze活用 ~PUSH通知を活用したレコメンド~
ozeshun
2
120
中規模・ミドルTier開発組織におけるDevRelの戦略と実行と成果 - DevRel Guild Conference Mini -
leveragestech
2
260
疎通2024
sadnessojisan
4
490
FastlyとfalcoでNode.jsレスな Webサーバー構築 : IPTV版 ABEMAアプリインフラ刷新 / Building web server using Fastly and falco without Node.js for IPTV ABEMA app
nodaguti
0
240
New Relicで実践する外形監視
aeonpeople
1
120
実践的なバグバウンティ入門
scgajge12
4
2.1k
Namespace, Now and Then
tagomoris
0
170
株式会社M2X エンジニアチーム紹介資料
m2xsoftware
0
320
エンジニアリングマネージャーが紐解く、事業視点から組織文化まで、包括的アプローチの探求 / READYFOR
9ma3r
13
2.2k
Featured
See All Featured
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
34
1.9k
Designing for humans not robots
tammielis
248
25k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
226
52k
Designing on Purpose - Digital PM Summit 2013
jponch
113
6.8k
Thoughts on Productivity
jonyablonski
65
4.2k
The Cult of Friendly URLs
andyhume
76
5.9k
Bootstrapping a Software Product
garrettdimon
PRO
304
110k
We Have a Design System, Now What?
morganepeng
48
7.1k
Web development in the modern age
philhawksworth
204
10k
KATA
mclloyd
27
13k
Gamification - CAS2011
davidbonilla
79
4.9k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
25
1.3k
Transcript
チームでテストを実装していく ren, qawatake 2024年6⽉1⽇
2022年11月に中途入社 外部連携サービスのQAエンジニ アを担当後、現在は決済プロダク トのQAエンジニアを担当 2 ren 決済プロダクト QAエンジニア 2022年4月freeeに新卒入社 freeeカードUnlimitedを経て、
新規決済プロダクトの開発を担当 qawatake 決済プロダクト ソフトウェアエンジニア
01. チームによるテストの実装 02. テストの取り組み a. Integration Testの実装 b. テストサイズを⽤いたリグレッションテストの⾃動化 c.
受⼊基準によるテスト実装の⽀援 d. バックエンドテスト指針‧Integration Testを書いてみる会 e. チームでテストアーキテクチャを育てるために学ぶ 03. チームでテストを実装するために⼤切だったこと ⽬次
チームによるテストの実装
私たち決済プロダクトのチームでは、ユーザーストーリーをベースにしたア ジャイル開発を採⽤している その中で、QAエンジニアがストーリーの受⼊基準やテストチャーターを作 成し、それらを基にチーム全員でテストを実装している また、「どんなテスト」を「どのように実装」すれば良いかの⾔語化を進 めており、共通理解をもってテストの実装を⾏っている チームによるテストの実装 チーム全員でテストのことを考え、テストを開発する取り組み
➡ 結果、単体テストや結合テストからシステムテストまで、バランス良く 構成されたテストを実現しており、効率が良く効果の⾼いテスト活動を実現 している チームによるテストの実装 チーム全員でテストのことを考え、テストを開発する取り組み E2E Test for Critical
Pass Integration Test for Endpoint Unit Test for Business Logic ‥‥ ‥‥ ‥‥
A. プロダクトのデリバリーを⽀えるテスト活動の改善はチームの課題で あり、チーム全員で解決するべきであるため ただ、初めから開発エンジニアとQAエンジニアで協調して進められてい たわけではなく、各々が抱えていた問題意識に向き合っていく過程で、 「チームによるテストの実装」というアプローチに辿り着いた チームによるテストの実装 なぜ「チームによるテストの実装」なのか
テストの取り組み
⽬の前の課題に集中して取り組み、その課題解決から得られたインサイト を元に次の課題に取り組む、という道を辿った a. Integration Testの実装 b. テストサイズを⽤いたリグレッションテストの⾃動化 c. 受⼊基準によるテスト実装の⽀援 d.
バックエンドテスト指針‧Integration Testを書いてみる会 e. チームでテストアーキテクチャを育てるために学ぶ テストの取り組み
Integration Testの実装
Integration Testの実装 Unit Testがイケてないなぁ Integration Testで解決できないか?? • コントローラ層のテストがmockだらけで、リファクタリング耐性が低い • DBとのすべてのやりとりを検証するなど、実装の詳細が不必要にテストに露出 している
重要な機能のデグレを防ぐためにテストを書きたい。ただ、どう書く の?? • E2Eはすでに仕組みとしてある。ただ、外部サービスへのリクエスト内容はE2E ではテストしにくい… • Unit Testより範囲を広く、Integration Testでカバーしたい。だけど、実現⽅法 が分からない 当初の⼆⼈の課題感
Integration Testの実装 開発合宿 • 2⽇間 • 普段とは違うやりたい開発ができる! DIやライブラリの設定など 共通部分を整えていく 仕組みを使って
実際のテストケースを ごりごり書いていく ⼆⼈でIntegration Testの最初の1個を書いてみる at 開発合宿 2023年も開発合宿を開催しました freee Developers Hub
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
ミドルサイズのテストをどう書くか(How)のイメージが⾒えてくることで、 次のステップを考えられるように Integration Testの実装 効果的でないUnit TestをIntegration Testで置き換えていきたい! チームで書いていけるといいなぁ ⼿動での実⾏時間の⻑さに悩んでいたリグレッションテストに、 Integration
Testを活かせそう! とりあえずIntegration Testを1個書けたぞ!!
⽬の前の課題に集中して取り組み、その課題解決から得られたインサイト を元に次の課題に取り組む、という道を辿った a. ✅ Integration Testの実装 b. ⏭ テストサイズを⽤いたリグレッションテストの⾃動化 c.
受⼊基準によるテスト実装の⽀援 d. バックエンドテスト指針‧Integration Testを書いてみる会 e. チームでテストアーキテクチャを育てるために学ぶ テストの取り組み
テストサイズを用いたリグレッションテストの自動化
リグレッションテストを⼿動で⾏なっているけど、リリースの度に時間が かかり過ぎている ⾃動テストで賄いたいけど、「とりあえずE2Eテストで何とかする」は避け たい →Unit TestやIntegration Testも合わせた、E2Eテストだけじゃない リグレッションテストの⾃動化を実現したい テストサイズを⽤いたリグレッションテストの⾃動化 リグレッションテストの課題
テスト観点(テストしたいこと)をテストサイズで分類し、リグレッションテスト の各ケースがどのように⾃動テストに対応するかを整理する取り組みに着⼿した テストサイズを⽤いたリグレッションテストの⾃動化 サバンナ便り〜⾃動テストに関する連載で得られた知⾒のまとめ(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) テストサイズによる分類を試した
「そのテストケースでテストしたい機能要素はどこが責務を担っているのか?」 という考え⽅で、整理を⾏なった テストサイズを⽤いたリグレッションテストの⾃動化 機能要素の責務の担い⼿から、書くべきテストを特定する 画⾯⼊⼒の バリデーション処理 フロントエンド バックエンド 外部アプリケーション テストサイズ
: smallな バックエンドの単体テスト として実装できる
また「そのテストケースで発⾒することを⾒込んでいる事象の重篤度情報(※)」を 整理し、どのテストから対応すると良いか判断できるようにした ※重篤度とは、freee社内で定義している「事象のヤバさ」を表現する指標 4段階の指標であり、重篤度が⾼い順にcritical, major, normal, minorとしている Eng, QA, PdM,
PD全員で、プロダクトの重篤度を定義している テストサイズを⽤いたリグレッションテストの⾃動化 重篤度を⽤いて、テストケースのインパクトを表現する このテストが落ちる(この機能が正常に 動かない)ということは、 誤送⾦が起こるリスクがあるということ 重篤度critical
「テストサイズ」や「機能要素の責務」という明確な基準を⽤いたことで、 単体テストや結合テストからシステムテストまで、バランス良く構成されたテスト として整理することができた テストサイズを⽤いたリグレッションテストの⾃動化 テストサイズにより、テストの構成⽐を表現できた E2E Test Integration Test Unit
Test
実装計画に沿ってチーム全員でテスト実装したことにより、1quarterで3割の ⾃動化を達成した • 重篤度情報をもとに優先度を決めたため、インパクトの⼤きいテストから着⼿できた • 継続的に取り組むことで、ほぼ完全に⾃動化できることも分かった テストサイズを⽤いたリグレッションテストの⾃動化 効果的なテスト⾃動化を達成した
テストサイズを⽤いたリグレッションテストの⾃動化 テストの責務とテストサイズから、適切な⾃動テストを導けるようになってきた リグレッションテストという題材において、テスト観点に対する適切なテストサイズ を考えられるようになってきた これを新機能開発時にも考えていけるようになりたい!
⽬の前の課題に集中して取り組み、その課題解決から得られたインサイト を元に次の課題に取り組む、という道を辿った a. ✅ Integration Testの実装 b. ✅ テストサイズを⽤いたリグレッションテストの⾃動化 c.
⏭ 受⼊基準によるテスト実装の⽀援 d. バックエンドテスト指針‧Integration Testを書いてみる会 e. チームでテストアーキテクチャを育てるために学ぶ テストの取り組み
受入基準によるテスト実装の支援
受⼊基準によるテスト実装の⽀援 機能開発時のテストに対する課題感 機能開発時に、どのような単体テストが実装されているのか分からない 単体テストと被った内容をQAエンジニアがテストしていそう…
チーム全員で受⼊基準の内容を確かめるミーティングを開き、ストーリーごとに何 を単体テストや結合テスト、E2Eテストで実装するかを話し合う取り組みを始めた 受⼊基準によるテスト実装の⽀援 受⼊基準を満たすためのテストを考えるようにした
受⼊基準を作るタイミング(=実装前のタイミング)でテストのことを考えること で、テスタビリティを確保した設計/実装を⽀援できるようになった 受⼊基準によるテスト実装の⽀援 テスタビリティ向上を⽀援できるようになった E2E Test Integration Test Unit Test
Unit Testを書くために、この処 理は関数として切り出そう
何が単体テストや結合テストで実装されているのかが明確になり、その内容を 踏まえて⼿動で実⾏するテストを最⼩限に抑えた、効率的なテストを実現でき るようになった 手動の テスト 受⼊基準によるテスト実装の⽀援 効率的なテストを実現できるようになってきた for Critical Pass
for Endpoint for Business Logic 手動のテスト E2E Test Integration Test Unit Test
新機能開発時にも、適切な⾃動テストを考えられるようになってきた 受⼊基準によるテスト実装の⽀援 「テスト活動はチームの課題」が当たり前になってきた テスト活動の知⾒をチームで育てられるようにしたい! テストの使い分けを話題にできるようになってきた 並⾏して皆でテストを実装できるようになっていきたい!
⽬の前の課題に集中して取り組み、その課題解決から得られたインサイト を元に次の課題に取り組む、という道を辿った a. ✅ Integration Testの実装 b. ✅ テストサイズを⽤いたリグレッションテストの⾃動化 c.
✅ 受⼊基準によるテスト実装の⽀援 d. ⏭ バックエンドテスト指針‧Integration Testを書いてみる会 e. チームでテストアーキテクチャを育てるために学ぶ テストの取り組み
バックエンドテスト指針 Integration Testを書いてみる会
バックエンドテスト指針‧Integration Testを書いてみる会 次の課題感 効果的でないUnit TestをIntegration Testで置き換えていきたい! チームで書いていけるといいなぁ
バックエンドテスト指針‧Integration Testを書いてみる会 次の課題感 効果的でないUnit TestをIntegration Testで置き換えていきたい! チームで書いていけるといいなぁ まずは書き⽅を知ってもらうところから... 「Integration Testを書いてみる会」を開催
バックエンドテスト指針‧Integration Testを書いてみる会 Integration Testを書いてみる会 メンバーみんなで集まって、ひとりひとりが1ケースを担当し、実装仕切る 実際に書いてみると、詳細についての疑問が出てきたり、動かないところがで てきたり。。 • モックライブラリの使い⽅系。メール送信やgRPCのモックはどうする?? •
Integration Testで何を検証するか?? • あるメンバーのテストケースだけ、ライブラリがエラーを返す 😢 ⾮同期でやっていると時間がかかりすぎる。。 最初は同期的にやる⽅針で正解だったかも!
バックエンドテスト指針‧Integration Testを書いてみる会 チームで書いていけるか?? これからみんなでどんなテストを書いていきたいか、認識を合わせたい ドキュメント「バックエンドのテスト実装⽅針」の作成へ [再掲] 効果的でないUnit TestをIntegration Testで置き換えていきたい! チームで書いていけるといいなぁ。
バックエンドテスト指針‧Integration Testを書いてみる会 バックエンドテスト指針 例えば、こんな疑問‧懸念に答えられるような内容に • 🤔 Unit TestとIntegration Testをどう使い分けるんだっけ?? •
🤔 書き⽅は分かったけど、何に対してどれくらい書くの?? • 🤔 やることが増えるってこと??
バックエンドテスト指針‧Integration Testを書いてみる会 バックエンドテスト指針 単体テストの考え⽅/使い⽅ 「単体テストの考え⽅/使い⽅」を参考にしながら、 ⾃分たちのプロジェクトの構成に落とし込んでみる 🤔 Unit TestとIntegration Testをどう使い分けるんだっ
け??
バックエンドテスト指針‧Integration Testを書いてみる会 バックエンドテスト指針 例) • 例えば、このValidateメソッド のようなビジネスロジックは Unit Testで書きたい •
複数のプロセス外依存を呼び 出す、usecaseのテストは Integration Testでカバーした い ドメイン‧モデル/ アルゴリズム コントローラ 過度に複雑な コード コードの複雑さ/ ドメインにおけ る重要性 協⼒者オブジェクトの数 取るに⾜らない コード 単体テストの考え方/使い方 図7.1
例) 事実上のentrypointに対して、正常系の Integration Testを少なくとも1つ「必ず書く」 バックエンドテスト指針‧Integration Testを書いてみる会 バックエンドテスト指針 gateway infra usecase
/ grpc batch worker 🤔 書き⽅は分かったけど、 何に対してどれくらい書くの?? 必ず書きたいテストを明⽂化してルールに
バックエンドテスト指針‧Integration Testを書いてみる会 バックエンドテスト指針 🤔 やることが増えるってこと?? メンバーが納得感をもってIntegration Testを書けるようにしたい! • 既存のテストに対するIntegration Testのメリットを記載
• 必ずしも⼿間が増えるとは限らないことを伝えてみる
バックエンドテスト指針‧Integration Testを書いてみる会 例) • Integration Testでテストすることで、リファクタリング耐性が⾼くなります • 代わりに今ある〜のテストは書かなくてよくなります usecase repository
mock HTTP client mock DB 依存 サービス usecase repository HTTP client DB 依存 サービス バックエンドテスト指針 usecaseのテスト Integration Test
バックエンドテスト指針‧Integration Testを書いてみる会 チームで書けるようになった? • Integration Testを書いてみる会 ◦ 新規のテストケースも⼀から作成できるように! • バックエンドテスト指針
◦ いったん、⽅針にそってテスト実装を進めていけそう! 次の課題は持続可能性 困りごとや不満点に応じて、軌道修正もしていきたい!
⽬の前の課題に集中して取り組み、その課題解決から得られたインサイト を元に次の課題に取り組む、という道を辿った a. ✅ Integration Testの実装 b. ✅ テストサイズを⽤いたリグレッションテストの⾃動化 c.
✅ 受⼊基準によるテスト実装の⽀援 d. ✅ バックエンドテスト指針‧Integration Testを書いてみる会 e. ⏭ チームでテストアーキテクチャを育てるために学ぶ テストの取り組み
チームでテストアーキテクチャを育てるために学ぶ
チームでテストアーキテクチャを育てるために学ぶ • テスト活動全般を改善していくためには、チーム全員が認識できるよ うな⾔語化やモデリングを⾏う必要がある • そのようなアウトプットを、テストアーキテクチャと呼ぶ • 難しい概念なので、テストアーキテクチャのための勉強会から始める ことにした テスト活動の知⾒をチームで育てられるようにしたい!
チームでテストアーキテクチャを育てるために学ぶ freeeでは標準テストプロセスが整備されているため、まずはテストプロセス の勉強会を⾏なった 10分でわかるfreeeのQA (https://speakerdeck.com/freee/10fen-dewakarufreeenoqa?slide=36) テストプロセスの勉強会
チームでテストアーキテクチャを育てるために学ぶ 次に、基本的な⽤語を押さえるために、JSTQBのFLシラバスを⽤いて勉強会を ⾏なった JSTQB-SyllabusFoundation_V4.0.J01 (https://jstqb.jp/dl/JSTQB-SyllabusFoundation_VersionV40.J01.pdf) テスト⽤語の勉強会
モダンなテストレベル設計(ユニットテスト〜システ ムテスト等をどう設計するか)の原則 - 千⾥霧中 (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) テストアーキテクチャの勉強会
テストアーキテクチャへの取り組みは、今まさに⾏なっている チームでテストアーキテクチャを育てるために学ぶ 展望 : テストアーキテクチャを育てていく 機能テストについてより解像度を上げて効率的で効果的なテストを⽬指す ⾮機能テストも含めて全体像を整理することで、テスト活動のインパクトを より⼤きくしていきたい
チームでテストを実装するために大切だったこと
⼀歩⼀歩進めていくことが、より⼤きな価値を⽣み出すアイデアや取り組み に繋がっていった ⼀つ改善したことで⾒えるようになった課題も多くあった a. Integration Testの実装 b. テストサイズを⽤いたリグレッションテストの⾃動化 c. 受⼊基準によるテスト実装の⽀援
d. バックエンドテスト指針‧Integration Testを書いてみる会 e. チームでテストアーキテクチャを育てるために学ぶ チームでテストを実装するために⼤切だったこと
None