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 Test Design Development for Speed of Product Development
Search
ropQa
May 10, 2024
Technology
0
230
開発スピードの維持向上を支える、テスト設計の 漸進的進化への取り組み / 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
チームでテストを実装していく / Implementing Tests as a Team
ropqa
0
1.7k
QA出身スリーアミーゴスでDeep Dive! スクラムで品質とスピードを意識したOne Teamを構成するために必要だったもの / Deep Dive into the the Essence of 'One Team'
ropqa
2
240
開発を加速させるためのQA活動 / Accelerating Development With Agile QA
ropqa
0
510
JaSST_nano_vol11_qa_dialogue
ropqa
0
380
Other Decks in Technology
See All in Technology
VPoEの視点から見た、ヘンリーがサーバーサイドKotlinを使う理由 / Why Server-side Kotlin 2024
cho0o0
1
420
運用改善、不都合な真実 / 20240722-ssmjp-kaizen
opelab
17
8k
コンテナ・K8s研修 - 前半 コンテナ基礎・ハンズオン【MIXI 24新卒技術研修】
mixi_engineers
PRO
0
170
CEL(Common Expression Language)で書いた条件にマッチしたIAM Policyを見つける / iam-policy-finder
fujiwara3
0
710
簡単に始めるSnowflakeの機械学習
nayuts
1
190
E2Eテスト自動化プラットフォームにおけるAIの活用
shift_evolve
0
180
JBUG岡山 #6 WordCamp男木島の チームビルディング
takeshifurusato
0
150
【基調講演】変える、今ここから ― IoTとAIで紡ぐ未来
soracom
PRO
0
320
dxd2024-生成AIに振り回された3か月間の成功と失敗/dxd2024-link-and-motivation
lmi
2
260
Azure AI ことはじめ
tsubakimoto_s
0
130
MySQLのロックの種類とその競合
yoku0825
6
1.6k
クラウド利用者の「責任」をどう果たす?AWSセキュリティ対策のススメ #AWSSummit
hiashisan
0
270
Featured
See All Featured
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
26
1.8k
Designing the Hi-DPI Web
ddemaree
276
34k
KATA
mclloyd
20
13k
Agile that works and the tools we love
rasmusluckow
325
20k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
121
18k
How To Stay Up To Date on Web Technology
chriscoyier
784
250k
The Invisible Customer
myddelton
117
13k
Statistics for Hackers
jakevdp
792
220k
Git: the NoSQL Database
bkeepers
PRO
423
64k
A Philosophy of Restraint
colly
200
16k
The Mythical Team-Month
searls
217
43k
How GitHub (no longer) Works
holman
305
140k
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マネージャー