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
400
開発スピードの維持向上を支える、テスト設計の 漸進的進化への取り組み / 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
350
テストアーキテクチャ設計で実現する高品質で高スピードな開発の実践 / Test Architecture Design in Practice
ropqa
3
1.9k
チームでテストを実装していく / Implementing Tests as a Team
ropqa
0
8.7k
QA出身スリーアミーゴスでDeep Dive! スクラムで品質とスピードを意識したOne Teamを構成するために必要だったもの / Deep Dive into the the Essence of 'One Team'
ropqa
2
910
開発を加速させるためのQA活動 / Accelerating Development With Agile QA
ropqa
0
670
JaSST_nano_vol11_qa_dialogue
ropqa
0
460
Other Decks in Technology
See All in Technology
現場で効くClaude Code ─ 最新動向と企業導入
takaakikakei
1
240
20250903_1つのAWSアカウントに複数システムがある環境におけるアクセス制御をABACで実現.pdf
yhana
3
550
「全員プロダクトマネージャー」を実現する、Cursorによる仕様検討の自動運転
applism118
21
10k
実践!カスタムインストラクション&スラッシュコマンド
puku0x
0
370
職種の壁を溶かして開発サイクルを高速に回す~情報透明性と職種越境から考えるAIフレンドリーな職種間連携~
daitasu
0
150
Codeful Serverless / 一人運用でもやり抜く力
_kensh
7
400
RSCの時代にReactとフレームワークの境界を探る
uhyo
10
3.4k
Snowflakeの生成AI機能を活用したデータ分析アプリの作成 〜Cortex AnalystとCortex Searchの活用とStreamlitアプリでの利用〜
nayuts
1
480
初めてAWSを使うときのセキュリティ覚書〜初心者支部編〜
cmusudakeisuke
1
240
会社紹介資料 / Sansan Company Profile
sansan33
PRO
6
380k
Platform開発が先行する Platform Engineeringの違和感
kintotechdev
4
550
MCPで変わる Amebaデザインシステム「Spindle」の開発
spindle
PRO
3
3.2k
Featured
See All Featured
Fantastic passwords and where to find them - at NoRuKo
philnash
52
3.4k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
GraphQLの誤解/rethinking-graphql
sonatard
72
11k
Unsuck your backbone
ammeep
671
58k
The Cult of Friendly URLs
andyhume
79
6.6k
Code Review Best Practice
trishagee
70
19k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.1k
Facilitating Awesome Meetings
lara
55
6.5k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
18
1.1k
GitHub's CSS Performance
jonrohan
1032
460k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
53
2.9k
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マネージャー