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
テストアーキテクチャ設計で実現する高品質で高スピードな開発の実践 / Test Architecture Design in Practice
ropqa
3
1.7k
チームでテストを実装していく / Implementing Tests as a Team
ropqa
0
7.7k
QA出身スリーアミーゴスでDeep Dive! スクラムで品質とスピードを意識したOne Teamを構成するために必要だったもの / Deep Dive into the the Essence of 'One Team'
ropqa
2
840
開発を加速させるためのQA活動 / Accelerating Development With Agile QA
ropqa
0
650
JaSST_nano_vol11_qa_dialogue
ropqa
0
440
Other Decks in Technology
See All in Technology
Observability infrastructure behind the trillion-messages scale Kafka platform
lycorptech_jp
PRO
0
140
低レイヤを知りたいPHPerのためのCコンパイラ作成入門 完全版 / Building a C Compiler for PHPers Who Want to Dive into Low-Level Programming - Expanded
tomzoh
4
3.1k
ハノーバーメッセ2025座談会.pdf
iotcomjpadmin
0
160
Amazon Bedrockで実現する 新たな学習体験
kzkmaeda
1
510
PostgreSQL 18 cancel request key長の変更とRailsへの関連
yahonda
0
120
25分で解説する「最小権限の原則」を実現するための AWS「ポリシー」大全 / 20250625-aws-summit-aws-policy
opelab
9
1.1k
データプラットフォーム技術におけるメダリオンアーキテクチャという考え方/DataPlatformWithMedallionArchitecture
smdmts
5
620
~宇宙最速~2025年AWS Summit レポート
satodesu
1
1.8k
Uniadex__公開版_20250617-AIxIoTビジネス共創ラボ_ツナガルチカラ_.pdf
iotcomjpadmin
0
160
登壇ネタの見つけ方 / How to find talk topics
pinkumohikan
3
350
AWS Summit Japan 2025 Community Stage - App workflow automation by AWS Step Functions
matsuihidetoshi
1
230
250627 関西Ruby会議08 前夜祭 RejectKaigi「DJ on Ruby Ver.0.1」
msykd
PRO
2
240
Featured
See All Featured
Designing for humans not robots
tammielis
253
25k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3k
Adopting Sorbet at Scale
ufuk
77
9.4k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
44
2.4k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
The World Runs on Bad Software
bkeepers
PRO
69
11k
The Power of CSS Pseudo Elements
geoffreycrofte
77
5.8k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
228
22k
Producing Creativity
orderedlist
PRO
346
40k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.4k
Statistics for Hackers
jakevdp
799
220k
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マネージャー