テストアーキテクチャ設計で実現する高品質で高スピードな開発の実践 / Test Architecture Design in Practice

Transcript

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