Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Enhancing SaaS Product Reliability and Release ...

Avatar for ropQa ropQa
July 09, 2025

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/

Avatar for ropQa

ropQa

July 09, 2025
Tweet

More Decks by ropQa

Other Decks in Technology

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開発を経験した後、2年⽬にQA チームを⽴ち上げ

    • freeeに中途⼊社 ◦ 同期マイクロサービスのQAを担当し、同 期ジョブのintegration testを導⼊ ◦ 決済プロダクトのQA Leadを担当し、テ ストアーキテクチャの実践事例を作る ◦ 現在は組織横断のQA Tech Leadを担当 好きな⾷べ物 • カレー 苅⽥蓮(ren) QAエンジニア Ren Karita プロフィール画像の トリミング⽅法
  3.   6 重篤度分類とテストサイズ分類に基づいて、リグレッションテストスイート を再編成するアプローチ。 1. 重篤度分類により、効果的なテストスイートを導出する • “事象のひどさ” を意味する重篤度に基づいてテストケースを分類することで、 ユーザーの⼿元で起こしてはいけない重⼤な事象の検知に集中したテストスイート

    を導出する 2. テストサイズ分類により、効率的な⾃動テストスイートを導出する • テストサイズを⽤いてテストケースと⾃動テストの対応関係を整理することで、実 ⾏コストを最適化した⾃動テストスイートを導出する Our Approach: リグレッションテストスイートの再編成
  4.   11 PRDやDesign Docs, 実装されたコードをもとに、テストケースを識別する。 1. テスト対象システムをドメインごとに分割 2. ユーザー視点で観測可能な振る舞いごとに、フィーチャーを特定 3.

    フィーチャーを論理的機能構造で分析し、論理的機能構造アイテム(※)を特定 a. ※論理的機能構造アイテムとは、”⼊⼒調整”や”変換”などの具体的要素を指し、これが テストケースの単位になる 論理的機能構造を⽤いた機能リストの作成 階層的な機能リストの作成
  5.   15 重篤度とは事象のひどさであり、ユーザのもとで発⽣してはいけない度合いを表す。 重篤度に基づいたテストケースの選定 重篤度は4段階で分類 重篤度 説明 Critical サービスが全面的に使えない。 Major

    主要な機能が動かない、 動作不正のため役に立たない。 Normal 機能が動かない、動作不正があるが、 サービスを継続利用できる。 Minor サービスの機能が仕様通りではないが、 サービスを利用した結果には影響が無い。
  6.   16 <テストケース選定の⽬的> リグレッションテストはソフトウェアの変更されていない 領域で⽋陥が混⼊している、もしくは露呈していることを 検出するため[ISTQB Glossaryより引⽤]のテスト。 ⼀般的な定義に加え、「ユーザーの⼿元で起こしてはいけな い重⼤な事象を検知する」ことも⽬的とし、重篤度によるテ ストケース選定を⾏う。

    <テストケース選定時の基準> リスク分析と重篤度分類の具体的な判断基準は、テスト対象 サービスに関わるソフトウェアエンジニア, QAエンジニア, プロダクトマネージャー, デザイナーで話し合って決める。 重篤度に基づいたテストケースの選定 テストケース選定の⼿順 フィーチャーに対して リスク分析 ⾼リスク? 論理的機能構造アイテム を重篤度で分類 重篤度: ⾼? テストケースをリグレッ ションテストスイートに 含める Yes Yes 論理的機能構造アイテム ≒ テストケース
  7.   22 テストサイズ分類による最適な⾃動テストスイートの作成 テストサイズ特定の⼿順 Input Adjustment(⼊⼒調整) •外部からの⼊⼒データを内部⽤の形式に変換 •例:リクエストパラメータの正規化 Output Adjustment(出⼒調整)

    •内部データを外部⽤の形式に変換 •例:レスポンス形式の整形 Conversion(変換) •ビジネスルールに基づく計算‧変換 •例:振込⾦額の計算、税額計算 Storage(貯蔵) •データの永続化‧取得 •例:データベースへの保存‧読み込み Interaction(相互作⽤) •外部システムとの連携‧統合 •例:他サービスとのAPI通信 Support(サポート) •エラーハンドリング‧ログ出⼒等 •例:バリデーション、例外処理 Entity Layer(エンティティ層) •純粋なビジネスロジック •外部依存なし •ドメインルールの実装 UseCase Layer(ユースケース層) •トランザクション制御 •Entity Layerとの相互作⽤ •ビジネスフローの管理 Adapter Layer(アダプター層) •外部システムとのデータ変換 •データベースアクセス •外部API連携 対応関係を⾒つける <論理的機能構造> <レイヤードアーキテクチャ>
  8.   23 テストサイズ分類による最適な⾃動テストスイートの作成 テストサイズ特定の⼿順 Entity Layer(エンティティ層) •Conversion(変換) •Support(サポート)※ドメインルール違反のハンドリング UseCase Layer(ユースケース層)

    •Interaction(相互作⽤)※オーケストレーション •Support(サポート)※ビジネスフロー例外のハンドリング Adapter Layer(アダプター層) •Input Adjustment(⼊⼒調整) •Output Adjustment(出⼒調整) •Storage(貯蔵) •Interaction(相互作⽤)※インターフェースの詳細実装 •Support(サポート)※型エラーなどのハンドリング レイヤードアーキテクチャの各層が担う責務と論理的機能構造の各要素が表す責 務を対応付ける。 「テスト設計の内容がどの層 の実装と対応するのか」、 「どのようなテストサイズが 適切か」を体系的に判断でき るようになる
  9.   24 重篤度分類とテストサイズ分類の適⽤例 論理的機能構造アイテム 重篤度 テストサイズ 振込金額計算 / [変換] Critical

    Small 振込依頼提出 / [相互作用] Critical Medium ステータス更新のバリデーション / [サポート] Major Small 関連プロダクトへのステータス更新 / [相互作用] Major Large 振込成功に伴うメール通知 / [相互作用] Normal Medium ”振込⾦額計算” や ”振込依頼提出” の処理に誤りがあるとユーザーに直接的な⾦銭的損失を与えてしまうため、これら は重篤度 : Criticalに分類する。 ⼀⽅、 “振込成功に伴うメール通知” が動作不正の場合、ユーザーの不便は⽣じるが振込⾏為それ⾃体には影響が少な いと考えられるため、重篤度 : Normalに分類する。
  10.   27 リグレッションテストの実⾏時間短縮とCIパイプラインでのリグレッション テストカバレッジの拡⼤により、以下を達成 • コード変更の影響把握が容易になり、開発速度が向上 • リリース頻度が2週間から2-3⽇に改善(5倍の改善) ◦ →

    ⾼スピードな開発の実現 • 導⼊後6ヶ⽉経っても、既存機能のデグレに起因する障害が0件 ◦ → ⾼品質な開発の実現 テストアーキテクチャ導⼊の効果 リリース頻度の改善と、品質の維持
  11.   29 本研究は、SaaS開発において普遍的に⾒られる課題に取り組む実践的な⽅法論 を⽰した。 • 課題: ◦ ⾼い信頼性を確保しながら、いかに迅速なリリース速度を維持するか • 実践的な⽅法論:

    ◦ 重篤度分類とテストサイズ分類に基づいてリグレッションテストスイート を体系的に再編成することで、開発チームは妥協することなく、迅速なリ リーススピードと⾼い信頼性の両⽅を達成することができる。 結論
  12.   31 • 設計レビュー段階から活⽤できるフレームワークに ◦ テストを考慮したソフトウェア設計(レビュー)⼿法の探索 • 異なるドメイン、アーキテクチャにも適⽤できるフレームワークに ◦ 決済サービス以外への適⽤検証

    ◦ 異なるアーキテクチャ‧規模のソフトウェアへの適⽤検証 • 定量的評価を⾏えるフレームワークに ◦ テスト有効性の定量的指標の探索 ◦ ⾃動データ収集と可視化⼿法を探索 今後の展望