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
開発スピードの維持向上を支える、テスト設計の 漸進的進化への取り組み / Continuous...
Search
ropQa
May 10, 2024
Technology
0
390
開発スピードの維持向上を支える、テスト設計の 漸進的進化への取り組み / Continuous Test Design Development for Speed of Product Development
2024.05.10 / freee QA LT会
ropQa
May 10, 2024
Tweet
Share
More Decks by ropQa
See All by ropQa
Enhancing SaaS Product Reliability and Release Velocity through Optimized Testing Approach
ropqa
1
270
テストアーキテクチャ設計で実現する高品質で高スピードな開発の実践 / Test Architecture Design in Practice
ropqa
3
1.8k
チームでテストを実装していく / Implementing Tests as a Team
ropqa
0
8k
QA出身スリーアミーゴスでDeep Dive! スクラムで品質とスピードを意識したOne Teamを構成するために必要だったもの / Deep Dive into the the Essence of 'One Team'
ropqa
2
850
開発を加速させるためのQA活動 / Accelerating Development With Agile QA
ropqa
0
660
JaSST_nano_vol11_qa_dialogue
ropqa
0
440
Other Decks in Technology
See All in Technology
BEYOND THE RAG🚀 ~とりあえずRAG?を超えていけ! 本当に使えるAIエージェント&生成AIプロダクトを目指して~ / BEYOND-THE-RAG-Toward Practical-GenerativeAI-Products-AOAI-DevDay-2025
jnymyk
4
180
[SRE NEXT 2025] すみずみまで暖かく照らすあなたの太陽でありたい
carnappopper
2
720
How Do I Contact Jetblue Airlines® Reservation Number: Fast Support Guide
thejetblueairhelpsupport
0
210
Microsoft Defender XDRで疲弊しないためのインシデント対応
sophiakunii
3
370
「現場で活躍するAIエージェント」を実現するチームと開発プロセス
tkikuchi1002
5
850
PHPでResult型やってみよう
higaki_program
0
160
データエンジニアリング 4年前と変わったこと、 4年前と変わらないこと
tanakarian
1
260
An introduction to Claude Code SDK
choplin
3
3k
安定した基盤システムのためのライブラリ選定
kakehashi
PRO
3
150
CDKコード品質UP!ナイスな自作コンストラクタを作るための便利インターフェース
harukasakihara
2
250
スプリントレビューを効果的にするために
miholovesq
4
1.1k
AWS Well-Architected から考えるオブザーバビリティの勘所 / Considering the Essentials of Observability from AWS Well-Architected
sms_tech
1
750
Featured
See All Featured
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.6k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
The Cult of Friendly URLs
andyhume
79
6.5k
Building Flexible Design Systems
yeseniaperezcruz
328
39k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.7k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
Learning to Love Humans: Emotional Interface Design
aarron
273
40k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.8k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
108
19k
Java REST API Framework Comparison - PWX 2021
mraible
31
8.7k
Side Projects
sachag
455
43k
Transcript
開発スピードの維持向上を⽀える、テスト設計の 漸進的進化への取り組み 2024.05.10
2 01. テスト設計の成果物を繰り返し使う 02. テスト設計の保守性 03. テスト設計の漸進的進化 04. さいごに ⽬次
3 経歴 • オプティムに新卒⼊社 ◦ Android開発を経験した後、2年⽬から QAに転⾝ • freeeに中途⼊社
◦ 同期マイクロサービスのQAを担当し、同 期ジョブのintegration testを導⼊ ◦ 現在は決済プロダクトのQAを担当し、 Agile QAに挑戦中 好きな⾷べ物 • カレー 苅⽥蓮(ren) QAエンジニア Ren Karita プロフィール画像の トリミング⽅法
テスト設計の成果物を繰り返し使う
5 freee QAは、多くのプロジェクトでテスト設計の成果物としてテストチャーターを作成している テストチャーターとは探索的テストで使われるテストの書き⽅ テストケースより粒度が⼤きく、なんのためのテストなのか、その⽬的がわかるように書くのが特徴 テスト設計の成果物を繰り返し使う テスト設計の成果物 = テストチャーター
テストチャーターの例
6 過去に作ったテストチャーターを、その後の機能開発でも繰り返し使う リグレッションテスト → テストチャーターをそのまま使う 機能改修時のテスト → テストチャーターを修正して使う テスト設計の成果物を繰り返し使う
テストチャーター テストラン (リグレッションテスト) テストラン (機能改修時のテスト) テスト設計の成果物の保存場所とは別に、 テスト実⾏結果の保存場所を⽤意する (そのような使い⽅を⽀援してくれるテスト管理 ツールを採⽤している) テストの資産として蓄積し、使い続ける
7 過去に作ったテストチャーターを、その後の機能開発でも繰り返し使う リグレッションテスト → テストチャーターをそのまま使う 機能改修時のテスト → テストチャーターを修正して使う テスト設計の成果物を繰り返し使う
テストチャーター テストラン (リグレッションテスト) テストラン (機能改修時のテスト) テストの資産として蓄積し、使い続ける リグレッションテストのテスト戦略に従って対象の テストチャーターを洗い出し、テストランにまとめる
8 過去に作ったテストチャーターを、その後の機能開発でも繰り返し使う リグレッションテスト → テストチャーターをそのまま使う 機能改修時のテスト → テストチャーターを修正して使う テスト設計の成果物を繰り返し使う
テストチャーター テストラン (リグレッションテスト) テストラン (機能改修時のテスト) テストに関する因⼦‧⽔準の変更や、期待値の変更 などを反映する テストの資産として蓄積し、使い続ける
テストの保守性 テストを変更/修正するときの容易さ テストを再利⽤できる度合い テストを解析するときの容易さ
10 新機能開発時はフィーチャーやスコープが定まりきっていない状態でテスト設計をするため、チャーター と属するセクション(※)、セクション間の関連が微妙になることがある (※セクションとは、チャーターの属するフォルダ/ディレクトリを表す概念) たとえば、最初は画⾯をセクションとして画⾯単位のチャーターを作っていたけど、画⾯を横断する機能 が出てきたことで、その機能に対するチャーターをどのセクションに⼊れていいか分からなくなったり、 「複数画⾯」のような曖昧なセクションが発⽣したりする場合が該当する このように、テストチャーターを管理する構造に曖昧さや⽭盾が⽣じると、テストチャーター群の⾒通し が悪くなったり、更に新しいチャーターを追加する際に悩む時間が多くなったりする
つまり、テストチャーターの理解容易性と保守性が低下する これは、テストチャーターを管理する構造が、現在のプロダクトの構造と乖離してしまうためである テストの保守性 プロダクト開発が進むにつれて⽣じる問題 = テストの保守性の低下
テスト設計の漸進的進化
12 中⻑期的にチャーターを使いやすい状態に保つためにも、テストチャーターの構造は継続的に⾒直す必要 がある • 画⾯ごとの構成だったものをフィーチャーごとの構成に変えたり、 • セクション間の親⼦関係を修正したり • プロダクトのアーキテクチャが明確に定まっている場合は、そのアーキテクチャに沿った構造にする
のも良い ◦ 私が担当している決済プロダクトはモジュラモノリスを採⽤しているので、現在のテストチャー ターの構造も、そのモジュールをベースにした構造に収まっている →保守性が⾼まり、機能改修時にテストチャーターの修正を⾏いやすくなる →理解容易性が⾼まり、機能に対してテストしたいことをすぐに確認できるようになる テスト設計の漸進的進化 テストの保守性を改善する
13 理解容易性が⾼まり、機能に対してテストしたいことをすぐに確認できるようになる テスト設計の漸進的進化 テストの保守性を改善する 要求理解 仕様検討 設計 この機能って以前 どんなことに気を
つけていたっけ? 関連する機能への 影響を把握したい
14 理解容易性が⾼まり、機能に対してテストしたいことをすぐに確認できるようになる →機能開発のスピードをブーストさせることができる テスト設計の漸進的進化 テストの保守性を改善する 要求理解 仕様検討 設計 この機能って以前
どんなことに気を つけていたっけ? 関連する機能への 影響を把握したい テストチャーター こんなテスト観点があったよ 過去にこういうチャーター の組み合わせでテストラン を組んでたよ
15 リグレッションテストはリリースごとに実施する必要があるため、そのテストランを作成するコストもリ リースの度に発⽣する 都度かかるコスト(=再利⽤性の低さ)を改善するために、リグレッションテスト対象のテストチャー ターをフィルタリングできるような情報を付与する テスト設計の漸進的進化 繰り返し⾏うテストにかかるコストを下げる テストチャーター テストラン
(リグレッションテスト) 抽出!
16 プロダクトの機能が増えてテストチャーターの数が増えると、追加開発時に「全ての関連機能が⼤事で、 できる限りたくさんのテストをしたい」気持ちになってくる ただ、使える時間は限られているので、リスクに従って何をテストするかを決める必要がある そのリスクの表現として、テストチャーターに「⾒込んでいる重篤度(※)」を記載している (※重篤度とは、freee社内で定義している「事象のヤバさ」を表現する指標 4段階の指標であり、重篤度が⾼い順にcritical, major, normal,
minorとしている) →重篤度の⾼い事象を防ぐために選択するべきテストチャーターが明確になり、プロダクトのコア機能が どこかを理解しやすくなる テスト設計の漸進的進化 テスト設計の成果物から得られる価値を育てていく
17 テストの保守性や理解容易性が⾼まり、テストから得られる価値が増えていくとどうなるか →より複雑に巨⼤になっていくプロダクトの開発スピードの維持向上を⽀える、プロダクト組織の知⾒を育て続けられる テスト設計の漸進的進化 テスト設計の成果物から得られる価値を育てていく 蓄積したテスト設計の知⾒を、 ソフトウェアの設計や次のテスト活動に活かす テスト活動から得られた知⾒ を蓄積する
さいごに
19 freeeでは「スモールビジネスを、世界の主役に。」をミッションに掲げ、「アイデアやパッション やスキルがあればだれでも、ビジネスを強くスマートに育てられるプラットフォーム」の実現を⽬ 指してサービスの開発および提供をしています。 QAチームでは、社会の進化を担う責任感をもって品質にコミットし、⾃律的に⾏動できる仲間を募 集しています。 さいごに QAエンジニア QAマネージャー