アジャイルを支えるテストアーキテクチャ設計/Test Architecting for Agile

Transcript

1. アジャイルを支える テストアーキテクチャ設計 ～高品質と高スピードを両立させるテストアプローチ～ 井芹 洋輝 2024/10/31 @サイボウズ
2. 自己紹介 ⚫経歴 • 開発者、テストエンジニア、コンサルタント、QAエンジニアと様々な立場で 様々なプロダクトのソフトウェアテスト業務に従事 • 現在は車メーカーのスクラムプロジェクトでQA/テスト テックリードを担当 • JSTQB技術委員、テスト設計コンテストU30クラスファウンダー ⚫著作・講演 • 「テスト自動化の成功を支えるチームと仕組み」 「シフトレフトテストを支える現代的なテスト設計」 「テスト設計をより良くするモデリングと観点分析」 「Androidアプリテスト技法」「システムテスト自動化標準ガイド」 「テストの視点を活用したTDDアプローチの検討とその検証」など
3. この講演について ⚫テストアーキテクチャ設計でアジャイル開発をサポートするアプローチ を解説します
4. ソフトウェア開発での高品質と高スピードを両立させるテストアプローチ https://speakerdeck.com/goyoki/test-approach-that-improves-quality-and-agility-together テストアーキテクチャ 設計の工夫 アーキテクチャ のテスト容易性確保 テスト品質の 作りこみ 妥当なテストを導く プロセス構築 チームの テスト能力の確保 Whole Team アプローチと チーム文化形成 開発インフラと テストシステムの 整備 品質マネジメント の整備 高品質と高スピードの両立を支えるテストアプローチ テストアプローチを支える基礎 本日要望頂いた テーマ
5. テストアーキテクチャ設計とは
6. テストアーキテクチャ設計 ⚫俯瞰的・抽象的なテスト活動・テスト設計構造の集まりをアーキテク チャと見なし、アーキテクティングとしてテスト活動の連携や構造を工 夫する • ユニットテスト、統合テストといった各テストレベルで何をするか、どう連携す るかを設計する • セキュリティテストや性能テストと言ったテストタイプを、テスト設計が着手で きるレベルまで識別・具体化する。テストタイプ同士の連携を設計する ⚫テストレベル設計/テストタイプ設計、テスト基本設計、テスト戦略策 定など様々な呼び名がある。 テストアーキテクチャという名前にこだわる必要はない
7. テストアーキテクチャの具体的な表現 ⚫テストの構成要素のプロセス定義 • 例えば開発プロセスモデル ⚫テストの構成要素の定義 • 例えばテストレベル、テストタイプ、テストスイートのそれぞれの定義 • 重要度や十分性基準も含む ⚫テストの構成要素の関係性の定義 • 例えばテスト戦略、リスク・課題管理 ⚫特別なモデルや表現は必須ではない。 既存の開発の進め方の中で、無理のない表現で方針を定義する
8. テストアーキテクチャの例（1/3） テストの構成要素のプロセス定義 ⚫開発プロセスで、テストレベル、テストタイプの関係性を開発プロセス 上で定義 ⚫より詳細な定義が必要なら、テストに特化したプロセス定義で補足
9. テストアーキテクチャの例（2/3） テストの構成要素の定義 テストレベル テスト対象の粒度 目的 サイクル・タイミング ユニットテスト ユニット ユニットのふるまいが正しいことを確認する CI（各ブランチ更新ごと） 統合テスト コンポーネントセット システム コンポーネントセットのふるまいが正しいことを確認する インテグレーションが適切なことを確認する CI（主要ブランチ更新ご と） システムテスト システム システムの振る舞いが正しいことを確認する システムがリリース可能な品質レベルであることを確認する リリース時 テストタイプ 詳細テストタイプ 目的 内容 ・・・ 機能テスト フィーチャテスト フィーチャ仕様が実現されていること を確認する フィーチャ単位にフィーチャ仕様と ソフトウェアの合致性を確認 フィーチャ調停テスト 複数のフィーチャを組み合わせたとき の調停処理が正しいか確認する フィーチャ調停仕様とソフトウェア の合致性を確認する セキュリティテスト APIペネトレーション テスト リスクの高い攻撃手法でAPIを攻撃し、 脆弱性がないことを確認する APIについての既知の攻撃手法で 攻撃を試みる ・・・ 全体のテストレベルの方針を明確化する 各テストレベルの構成要素やテスト設計の目的・方向性を明確化する（システムテストの例）
10. テストアーキテクチャの例（3/3） テストの構成要素の関係性の定義 ⚫テスト戦略や、テストにかかわるリスク・課題管理の定義の中で、テス トアーキテクチャの連携や動的な工夫を表現・管理 ⚫テストの構成要素の構造的な関係性をモデルで表現・管理 課題 課題対応方針 グローバル展開する組込み製品 の表示文言の品質確保 文言の正確性確認、翻訳品質確認：データ静的テスト 文言描画の確認： アプリケーション描画：エミュレータテストで全網羅 実機動作：自動キャプチャーテストで代表パターン確認 現地依存の本番環境確認： ローカライゼーションテスト
11. テストアーキテクチャの具体的な表現 ⚫テストの構成要素のプロセス定義 ⚫テストの構成要素の定義 ⚫テストの構成要素の関係性の定義
12. アジャイルにとっての アーキテクチャの重要性
13. アーキテクチャはアジャイルの要・基盤 ⚫適切に設計されたアーキテクチャはスケーラビリティ、性能、保守性、 セキュリティ、デプロイ容易性など様々な品質を支える ⚫適切に設計されたアーキテクチャは優れた保守性・デプロイ容易性を 実現し、アジャイルの開発作業をサポートする • 追加・変更をより安全に、より効率的にサポートする • プロダクトリリースをより安全に・より効率的にサポートする • 創発的なアプローチの中で、望ましい方向に設計・実装を誘導する。 問題ある設計・実装を予防する
14. 【関係外から持たれる誤解】アジャイルのアーキテクティングは インクリメンタルで行き当たりばったり ⚫これは危うい誤解。 アジャイルにネガティブなイメージを持つ人からしばしば持たれる誤解 ⚫アジャイルが求める優れたアーキテクチャは、行き当たりばったりで 部品を積み上げるだけでは構築できない • 望ましいアプローチはEDUP（後述） ⚫アジャイルであればこそ優れたアーキテクチャ、適切なアーキテクチャ 設計が求められる
15. テストアーキテクチャはアジャイルをサポートする ⚫アーキテクチャと同様に、テストアーキテクチャはアジャイルを支える ⚫アジャイルでテストアーキテクチャが求められる場面 • 開発の高品質と高スピードを両立させる • 例：自動テストと手動テストの効果的な組み合わせ • テスト/QAに求められる全体整合を維持する • 例：テストの責務分担 • 中長期にわたって一貫性が求められるテスト活動を支える • 例：セキュリティテスト • 様々な関係者を巻き込むテスト戦略の推進を支える • 現場に一任するテストの方向性を先導する • 例：リグレッションテスト
16. アジャイルにおける テストアーキテクチャ設計の アプローチ
17. アジャイルでのテストアーキテクチャ設計はEDUF アーキテクチャ設計と同じ ⚫アジャイルのテストアーキ設計はEDUF(Enough Design Up Front) • 最大責任時点（Most Responsible Moment：対象活動が最も責務を果た せるタイミング）でテストアーキテクチャ設計活動を実施する ≒必要なタイミングで必要な設計をきちんと行う。初期でやるべきものは初 期でやる ⚫アジャイルと相性の悪い設計アプローチ： • BDUF（Big Design Up Front）：最初に詳細に固める→変化の許容度× • NDUF（No Design Up Front）：行き当たりばったり→アーキテクチャ崩壊 ⚫テストアーキテクチャ設計は、不確実で変化の多いアジャイルの中で、 適時に適切な活動を実施し、継続的にテスト設計を導く
18. アジャイルでのテストアーキテクチャ設計はEDUF アーキテクチャ設計と同じ ⚫プロジェクト最初期（立ち上げ/初期計画立案/体制構築） • 基礎の構築。チームの体制・ロードマップ・戦略の基礎の構築を導く • 大まかなテスト活動の全体像、あるべき体制・リソース・スケジュールの根 拠をテストマネジメントにインプットする ⚫プロジェクト初期（各計画具体化/PoC/開発開始） • テストアーキテクチャを反復的に作りこみ、テスト設計の基本方針・基本構 造を設計する ⚫プロジェクト中期以降（開発本格化/保守・派生） • テストアーキテクチャの保守・改善を通して、テスト活動を先導していく
19. テストアーキテクチャ設計はあるべき姿を目指す活動 （バックキャスト） ⚫テストアーキテクチャ設計はテストの要求とテストの仕様の橋渡し ⚫要求に従って受け身でアーキテクチャを具体化するのではなく、 あるべきテストの姿を分析して、その実現のためにすり合わせる • 例）テストマネジメントと、あるべきテストの実現のためのリソース・スケジュー ル計画やプロセス策定をすり合わせる • テスト分析と、あるべきテストの実現のための分析やスコープ設定をすり合 わせる
20. プロセスでの テストアーキテクチャ設計の 位置づけ
21. テストプロセスの中のテストアーキテクチャ設計 テスト基本分析 テストアーキテク チャ設計 テスト詳細分析 テスト設計 テスト実装 テスト全体で何をするか スコープ・責務を分析する テスト全体の構成を 整理する テスト条件を分析する テストケースを設計する テスト手順を実装する イテレーションを横断して 継続的・反復的に育てる イテレーションごとのテスト に応じて実施する
22. 既知のテストプロセスとテストアーキテクチャ設計 テスト基本分析 テストアーキテク チャ設計 テスト詳細分析 テスト設計 テスト実装 本講演の定義 JSTQB テスト活動 テスト分析 テスト設計 テスト実装 [TD1]Create Test Model [TD2]Identify Test Coverage Items [TD3]Derive Test Cases [TD4]Create Test Procedures ISO/IEC/IEEE 29119
23. テストアーキテクチャ設計の 進め方
24. テストアーキテクチャの進め方 ⚫テストアーキテクチャに関わる要求・制約を分析し対応する ⚫テストアーキテクチャの厚み・抽象度を調整する ⚫テストアーキテクチャの全体の構造を整理する
25. テストアーキテクチャにかかわる要求・制約を分析し対応する ⚫テストアーキテクチャ設計では、テストの要求・制約のうち、テストアー キテクチャレベル（テストの全体構造レベル）で対応が必要なものを識 別して対応を検討する
26. テストアーキテクチャにかかわる要求・制約を分析し対応する テストへの要求 連携設計のアプローチ 特定の欠陥の検出 検出したい欠陥タイプごとにテスト活動を設計 プロダクトリスクの確認 プロダクトリスクに対し、テスト活動がどう連携するか設計 品質課題の対応 品質課題に対して、テスト活動でどう対応するか設計 課題の例 課題対応方針 グローバル展開する組込み製品 の表示文言の品質確保 文言の正確性確認、翻訳品質確認：データ静的テスト 文言描画の確認： アプリケーション描画：エミュレータテストで全網羅 実機動作：自動キャプチャーテストで代表パターン確認 現地依存の本番環境確認： ローカライゼーションテスト
27. テストアーキテクチャにかかわる要求・制約を分析し対応する ⚫特に重大なテストの要求・制約（TASR：Test-Architecturally Significant Requirements）があれば、チームの骨格となる基本設計 方針を立てる TASRの例 TASRへの対応方針 テスト基本設計方針 サービスの頻繁な 改善・変更に対応 する テスト自動化（実行および生成の自 動化）の促進により、変更対応を効 率化する テスト対象のテスト自動化容易性の向上。テスト 自動化可能な領域を拡大し、それを活用する自 動テストの責務を広げる テスト容易性向上により、テスト対象 の安定性を向上させる テスト対象の変動部分を局所化し、安定性の高 い領域を拡大する。 高い網羅性が求められるテスト範囲を分離し、統 合テストレベルで品質確保する 手動テストについて、探索的アプ ローチの拡大により、変更対応を効 率化する 変動部分に対する手動テストをテストチャータベー スの探索的テストとして実装する
28. テストアーキテクチャの厚み・抽象度を調整する ⚫識別したテスト活動は、以降のテスト分析・テスト設計活動を適切に 進められるレベルまで、具体化・関心の分離を実施する ⚫調整の観点 • テストの強みを広げる・弱みを狭める • テスト活動をやりやすくする • テスト設計の進め方が異なるものを分ける • 例）ユーザビリティ/UXテストを分離する • テストの担当組織が分かれるものを分ける • 例）セキュリティテストを分ける • テストのライフサイクルが異なるものを分ける • テストの環境やリソースが異なるものを分ける • 例）自動テストを分ける
29. テストアーキテクチャの厚み・抽象度を調整する ⚫自動化技術の発展、デプロイメントパイプラインの高度化で、様々な 長短の特徴を持つテストが採用可能になっている。 そこで次の手段を推進できる余地が広がっている • もっとも効果的なテストの責務を最大化する • それぞれのテストの強みを最大化し、弱みを最小化・補完する • テストの重複は、全体が良くなる方向で削除する • 品質を積み上げる
30. テストアーキテクチャの厚み・抽象度を調整する ⚫生産性の高いテストレベル/テストタイプの責務を最大化する • 自動化可能。CI/CDのデプロイメントパイプラインに統合可能 • テストの性能効率性・保守性を作りこみやすい • 顧客満足/プロダクト価値に近いテストができる ⚫生産性の低いテストレベル/テストタイプの責務を最小化する • 手動のシステムテストの責務を他のテストに分散する ⚫シフトレフトを推進する • シフトレフトできるテストレベル/テストタイプを確保し責務を広げる • システムテストから結合テスト・ユニットテストへテスト責務を移譲へ • テストピラミッド/テストトロフィーの戦略推進
31. テストアーキテクチャの全体の構造を整理する ⚫検討結果を、プロセス定義、テスト戦略定義、リスク・課題のコント ロール定義として整理・具体化する ⚫モデルで構造を整理する
32. テストアーキテクチャの全体の構造を整理する テストレベル テスト対象の粒度 目的 サイクル・タイミング ユニットテスト ユニット ユニットのふるまいが正しいことを確認する CI（各ブランチ更新ごと） 結合テスト コンポーネントセット システム コンポーネントセットのふるまいが正しいことを確認する インテグレーションが適切なことを確認する CI（主要ブランチ更新ご と） システムテスト システム システムの振る舞いが正しいことを確認する システムがリリース可能な品質レベルであることを確認する リリース時 テストタイプ 詳細テストタイプ 目的 内容 ・・・ 機能テスト フィーチャテスト フィーチャ仕様が実現されていること を確認する フィーチャ単位にフィーチャ仕様と ソフトウェアの合致性を確認 フィーチャ調停テスト 複数のフィーチャを組み合わせたとき の調停処理が正しいか確認する フィーチャ調停仕様とソフトウェア の合致性を確認する セキュリティテスト APIペネトレーション テスト リスクの高い攻撃手法でAPIを攻撃し、 脆弱性がないことを確認する APIについての既知の攻撃手法で 攻撃を試みる ・・・ 全体のテストレベルの方針を明確化する 各テストレベルの構成要素やテスト設計の目的・方向性を明確化する（システムテストの例）
33. テストアーキテクチャの進め方 ⚫テストアーキテクチャに関わる要求・制約を分析し対応する ⚫テストアーキテクチャの厚み・抽象度を調整する ⚫テストアーキテクチャの全体の構造を整理する
34. テストアーキテクチャ設計の薦め
35. テストアーキテクチャ設計の薦め ⚫（テストアーキテクチャ設計と呼ばなくても大丈夫です） テスト全体の構成を整理し、テスト全体の戦略立てや連携の工夫を 検討する活動は普遍的に重要です • 長短併せ持つ様々な自動テストの手段が増えた今では重要性が増してい ます ⚫アジャイルでは、柔軟な変化への対応、長い開発ライフサイクル対応、 顧客満足への対応、高頻度のリリース対応と特有の課題があります。 それに対応するテストアーキテクチャ設計が求められます ⚫チームとして、テスト全体の構造、連携を具体化する活動に力を入れ てみてください
36. テストアーキテクチャ設計のとっかかり ⚫チーム全体のテストの構成を具体化する。 その構成を反復的に成長させる ⚫テストの構成を整理し全体最適を目指す ⚫テストに影響を与える課題やリスクに対し、テストの構成を工夫する
37. ご清聴ありがとうございました