Enhancing SaaS Product Reliability and Release Velocity through Optimized Testing Approach

Agile Talks vol.3
= Replay of InSTA 2025
@LayerX Corporate Office

event page: https://agiletalks.connpass.com/event/357387/

Transcript

1. Enhancing SaaS Product Reliability and Release Velocity through Optimized Testing Approach Agile Talks vol.3 = Replay of InSTA 2025 Ren Karita freee K.K. Tsuyoshi Yumoto freee K.K.
2. 　 2 経歴 • 97年⽣まれ • オプティムに新卒⼊社 ◦ Android開発を経験した後、２年⽬にQA チームを⽴ち上げ • freeeに中途⼊社 ◦ 同期マイクロサービスのQAを担当し、同 期ジョブのintegration testを導⼊ ◦ 決済プロダクトのQA Leadを担当し、テ ストアーキテクチャの実践事例を作る ◦ 現在は組織横断のQA Tech Leadを担当 好きな⾷べ物 • カレー 苅⽥蓮(ren) QAエンジニア Ren Karita プロフィール画像の トリミング⽅法
3. 　 3 SaaSプロダクトでは、変化する市場の需要や顧客要求に対応するために、迅速 なリリースサイクルが不可⽋。 また、決済システムなどのミッションクリティカルなサービスでは特に、不具合 が⾦銭的損失や顧客の信頼損失に繋がる可能性があるため、⾼い信頼性も同様 に重要である。 成⻑し続けるSaaSが直⾯する課題
4. 　 4 信頼性を維持するためには、全ての変更に対してリグレッションテストを実施 する必要がある。 成⻑し続けるSaaSが直⾯する課題 ただ、プロダクトが成⻑し複雑になるにつれ、テストすべき機能は増え、その 実⾏コストは⼤幅に増加してしまう。 このような中、実⾏テストを下げるためにE2Eテストを⾃動化することも多い が、却って運⽤保守に多くのコストがかかるようになってしまう。 その結果、リリーススピードが犠牲になり、スピードと信頼性の間で⽭盾が⽣ じてしまう。 → ”リグレッションテストスイートの最適化” と ”適切な⾃動テスト戦略” に より、この課題を解決する
5. Our Approach: リグレッションテストスイートの再編成
6. 　 6 重篤度分類とテストサイズ分類に基づいて、リグレッションテストスイート を再編成するアプローチ。 1. 重篤度分類により、効果的なテストスイートを導出する • “事象のひどさ” を意味する重篤度に基づいてテストケースを分類することで、 ユーザーの⼿元で起こしてはいけない重⼤な事象の検知に集中したテストスイート を導出する 2. テストサイズ分類により、効率的な⾃動テストスイートを導出する • テストサイズを⽤いてテストケースと⾃動テストの対応関係を整理することで、実 ⾏コストを最適化した⾃動テストスイートを導出する Our Approach: リグレッションテストスイートの再編成
7. 　 7 テストアーキテクチャ設計の全体像
8. 　 8 テストアーキテクチャ設計の全体像
9. テストアーキテクチャ設計 1. 論理的機能構造を⽤いた機能リストの作成 2. 重篤度に基づいたテストケースの選定 3. テストサイズ分類による最適な⾃動テストスイートの作成
10. 　 10 論理的機能構造を⽤いた機能リストの作成
11. 　 11 PRDやDesign Docs, 実装されたコードをもとに、テストケースを識別する。 1. テスト対象システムをドメインごとに分割 2. ユーザー視点で観測可能な振る舞いごとに、フィーチャーを特定 3. フィーチャーを論理的機能構造で分析し、論理的機能構造アイテム(※)を特定 a. ※論理的機能構造アイテムとは、”⼊⼒調整”や”変換”などの具体的要素を指し、これが テストケースの単位になる 論理的機能構造を⽤いた機能リストの作成 階層的な機能リストの作成
12. 　 12 論理的機能構造とは、テスト対象となるシステムを⼊⼒調整、出⼒調整、変換、 貯蔵、サポート、相互作⽤、外部マネジメントといった要素で分解したもの。 論理的機能構造を⽤いた機能リストの作成 [参考] 論理的機能構造
13. テストアーキテクチャ設計 1. 論理的機能構造を⽤いた機能リストの作成 2. 重篤度に基づいたテストケースの選定 3. テストサイズ分類による最適な⾃動テストスイートの作成
14. 　 14 重篤度に基づいたテストケースの選定
15. 　 15 重篤度とは事象のひどさであり、ユーザのもとで発⽣してはいけない度合いを表す。 重篤度に基づいたテストケースの選定 重篤度は4段階で分類 重篤度 説明 Critical サービスが全面的に使えない。 Major 主要な機能が動かない、 動作不正のため役に立たない。 Normal 機能が動かない、動作不正があるが、 サービスを継続利用できる。 Minor サービスの機能が仕様通りではないが、 サービスを利用した結果には影響が無い。
16. 　 16 <テストケース選定の⽬的> リグレッションテストはソフトウェアの変更されていない 領域で⽋陥が混⼊している、もしくは露呈していることを 検出するため[ISTQB Glossaryより引⽤]のテスト。 ⼀般的な定義に加え、「ユーザーの⼿元で起こしてはいけな い重⼤な事象を検知する」ことも⽬的とし、重篤度によるテ ストケース選定を⾏う。 <テストケース選定時の基準> リスク分析と重篤度分類の具体的な判断基準は、テスト対象 サービスに関わるソフトウェアエンジニア, QAエンジニア, プロダクトマネージャー, デザイナーで話し合って決める。 重篤度に基づいたテストケースの選定 テストケース選定の⼿順 フィーチャーに対して リスク分析 ⾼リスク? 論理的機能構造アイテム を重篤度で分類 重篤度: ⾼? テストケースをリグレッ ションテストスイートに 含める Yes Yes 論理的機能構造アイテム ≒ テストケース
17. テストアーキテクチャ設計 1. 論理的機能構造を⽤いた機能リストの作成 2. 重篤度に基づいたテストケースの選定 3. テストサイズ分類による最適な⾃動テストスイートの作成
18. 　 18 テストサイズの分類は、テストがどのように実⾏され、何を許可され、どれだけのリソー スを消費するかによって決定される。 テストサイズ分類による最適な⾃動テストスイートの作成 テストサイズは3段階で分類 書籍「Googleのソフトウェアエンジニアリング」から引⽤
19. 　 19 テストサイズ分類による最適な⾃動テストスイートの作成 トランザクション制御を含むテスト → テストサイズ: Medium 型変換やインターフェイス定義の検証 → テストサイズ: Small 外部依存性のない純粋なビジネスロジックのテスト → テストサイズ: Small
20. 　 20 サービス間通信に関するテストサイズ分類は、以下の決定プロセスに従う。 テストサイズ分類による最適な⾃動テストスイートの作成 Figure 5: Test Size Classification Decision Flow
21. 　 21 論理的機能構造とソフトウェア アーキテクチャには対応関係が ある。 →論理的機能構造を介してテス トサイズを特定できる。 テストサイズ分類による最適な⾃動テストスイートの作成 テストサイズ特定の⼿順
22. 　 22 テストサイズ分類による最適な⾃動テストスイートの作成 テストサイズ特定の⼿順 Input Adjustment（⼊⼒調整） •外部からの⼊⼒データを内部⽤の形式に変換 •例：リクエストパラメータの正規化 Output Adjustment（出⼒調整） •内部データを外部⽤の形式に変換 •例：レスポンス形式の整形 Conversion（変換） •ビジネスルールに基づく計算‧変換 •例：振込⾦額の計算、税額計算 Storage（貯蔵） •データの永続化‧取得 •例：データベースへの保存‧読み込み Interaction（相互作⽤） •外部システムとの連携‧統合 •例：他サービスとのAPI通信 Support（サポート） •エラーハンドリング‧ログ出⼒等 •例：バリデーション、例外処理 Entity Layer（エンティティ層） •純粋なビジネスロジック •外部依存なし •ドメインルールの実装 UseCase Layer（ユースケース層） •トランザクション制御 •Entity Layerとの相互作⽤ •ビジネスフローの管理 Adapter Layer（アダプター層） •外部システムとのデータ変換 •データベースアクセス •外部API連携 対応関係を⾒つける <論理的機能構造> <レイヤードアーキテクチャ>
23. 　 23 テストサイズ分類による最適な⾃動テストスイートの作成 テストサイズ特定の⼿順 Entity Layer（エンティティ層） •Conversion（変換） •Support（サポート）※ドメインルール違反のハンドリング UseCase Layer（ユースケース層） •Interaction（相互作⽤）※オーケストレーション •Support（サポート）※ビジネスフロー例外のハンドリング Adapter Layer（アダプター層） •Input Adjustment（⼊⼒調整） •Output Adjustment（出⼒調整） •Storage（貯蔵） •Interaction（相互作⽤）※インターフェースの詳細実装 •Support（サポート）※型エラーなどのハンドリング レイヤードアーキテクチャの各層が担う責務と論理的機能構造の各要素が表す責 務を対応付ける。 「テスト設計の内容がどの層 の実装と対応するのか」、 「どのようなテストサイズが 適切か」を体系的に判断でき るようになる
24. 　 24 重篤度分類とテストサイズ分類の適⽤例 論理的機能構造アイテム 重篤度 テストサイズ 振込金額計算 / [変換] Critical Small 振込依頼提出 / [相互作用] Critical Medium ステータス更新のバリデーション / [サポート] Major Small 関連プロダクトへのステータス更新 / [相互作用] Major Large 振込成功に伴うメール通知 / [相互作用] Normal Medium ”振込⾦額計算” や ”振込依頼提出” の処理に誤りがあるとユーザーに直接的な⾦銭的損失を与えてしまうため、これら は重篤度 : Criticalに分類する。 ⼀⽅、 “振込成功に伴うメール通知” が動作不正の場合、ユーザーの不便は⽣じるが振込⾏為それ⾃体には影響が少な いと考えられるため、重篤度 : Normalに分類する。
25. テストアーキテクチャ導⼊の効果
26. 　 26 • リグレッションテストの84%をCIパイプラインに統合した • テスト実⾏時間を90%削減した（20時間 → 2時間） （残る⼿動テストはUX検証や外部サービスとの結合テストが避けられないもの） テストアーキテクチャ導⼊の効果 リグレッションテスト実⾏時間の⼤幅な削減
27. 　 27 リグレッションテストの実⾏時間短縮とCIパイプラインでのリグレッション テストカバレッジの拡⼤により、以下を達成 • コード変更の影響把握が容易になり、開発速度が向上 • リリース頻度が2週間から2-3⽇に改善（5倍の改善） ◦ → ⾼スピードな開発の実現 • 導⼊後6ヶ⽉経っても、既存機能のデグレに起因する障害が0件 ◦ → ⾼品質な開発の実現 テストアーキテクチャ導⼊の効果 リリース頻度の改善と、品質の維持
28. 結論
29. 　 29 本研究は、SaaS開発において普遍的に⾒られる課題に取り組む実践的な⽅法論 を⽰した。 • 課題: ◦ ⾼い信頼性を確保しながら、いかに迅速なリリース速度を維持するか • 実践的な⽅法論: ◦ 重篤度分類とテストサイズ分類に基づいてリグレッションテストスイート を体系的に再編成することで、開発チームは妥協することなく、迅速なリ リーススピードと⾼い信頼性の両⽅を達成することができる。 結論
30. 今後の展望
31. 　 31 • 設計レビュー段階から活⽤できるフレームワークに ◦ テストを考慮したソフトウェア設計(レビュー)⼿法の探索 • 異なるドメイン、アーキテクチャにも適⽤できるフレームワークに ◦ 決済サービス以外への適⽤検証 ◦ 異なるアーキテクチャ‧規模のソフトウェアへの適⽤検証 • 定量的評価を⾏えるフレームワークに ◦ テスト有効性の定量的指標の探索 ◦ ⾃動データ収集と可視化⼿法を探索 今後の展望
32. Thank you for your attention.