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
270
開発スピードの維持向上を支える、テスト設計の 漸進的進化への取り組み / 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
2.3k
QA出身スリーアミーゴスでDeep Dive! スクラムで品質とスピードを意識したOne Teamを構成するために必要だったもの / Deep Dive into the the Essence of 'One Team'
ropqa
2
350
開発を加速させるための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
20240828_EM_Fest
kzkmaeda
4
360
Dojo 20240830 COBOL to Java on Z
ichikawayasuhisa
0
240
Oracle Exadata Database Service(Dedicated Infrastructure):サービス概要のご紹介
oracle4engineer
PRO
0
9.3k
FastlyとfalcoでNode.jsレスな Webサーバー構築 : IPTV版 ABEMAアプリインフラ刷新 / Building web server using Fastly and falco without Node.js for IPTV ABEMA app
nodaguti
0
240
タイミーのBraze活用 ~PUSH通知を活用したレコメンド~
ozeshun
2
120
自社開発した大規模言語モデルをどうプロダクションに乗せて運用していくか〜インフラ編〜
pfn
PRO
4
680
AWS版GitHub?Amazon CodeCatalystの全体像をまとめてみた
oshanqq
1
3.2k
バックログを導入し やっぱやめた話
ota42y
0
170
20分で分かるIAM全機能 (拡大版) / 20240903-jawsug-yokohama-iam
opelab
3
120
Oracle Base Database Service:サービス概要のご紹介
oracle4engineer
PRO
0
13k
#Zenoh 完全に理解した 〜組込み純情篇〜
takasehideki
1
450
RAGHack: Kickoff and RAG 101
pamelafox
0
200
Featured
See All Featured
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
502
140k
Building Adaptive Systems
keathley
36
2.1k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
22
1.7k
Reflections from 52 weeks, 52 projects
jeffersonlam
346
20k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
27
1.6k
Fashionably flexible responsive web design (full day workshop)
malarkey
400
65k
[RailsConf 2023] Rails as a piece of cake
palkan
44
4.6k
Fontdeck: Realign not Redesign
paulrobertlloyd
80
5.1k
Build The Right Thing And Hit Your Dates
maggiecrowley
29
2.2k
Designing with Data
zakiwarfel
98
5k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
22
3.9k
Rebuilding a faster, lazier Slack
samanthasiow
78
8.5k
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マネージャー