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

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

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

Hiroki Iseri

October 31, 2024
Tweet

More Decks by Hiroki Iseri

Other Decks in Programming

Transcript

  1. 自己紹介 ⚫経歴 • 開発者、テストエンジニア、コンサルタント、QAエンジニアと様々な立場で 様々なプロダクトのソフトウェアテスト業務に従事 • 現在は車メーカーのスクラムプロジェクトでQA/テスト テックリードを担当 • JSTQB技術委員、テスト設計コンテストU30クラスファウンダー

    ⚫著作・講演 • 「テスト自動化の成功を支えるチームと仕組み」 「シフトレフトテストを支える現代的なテスト設計」 「テスト設計をより良くするモデリングと観点分析」 「Androidアプリテスト技法」「システムテスト自動化標準ガイド」 「テストの視点を活用したTDDアプローチの検討とその検証」など
  2. ソフトウェア開発での高品質と高スピードを両立させるテストアプローチ https://speakerdeck.com/goyoki/test-approach-that-improves-quality-and-agility-together テストアーキテクチャ 設計の工夫 アーキテクチャ のテスト容易性確保 テスト品質の 作りこみ 妥当なテストを導く プロセス構築

    チームの テスト能力の確保 Whole Team アプローチと チーム文化形成 開発インフラと テストシステムの 整備 品質マネジメント の整備 高品質と高スピードの両立を支えるテストアプローチ テストアプローチを支える基礎 本日要望頂いた テーマ
  3. テストアーキテクチャの例(2/3) テストの構成要素の定義 テストレベル テスト対象の粒度 目的 サイクル・タイミング ユニットテスト ユニット ユニットのふるまいが正しいことを確認する CI(各ブランチ更新ごと)

    統合テスト コンポーネントセット システム コンポーネントセットのふるまいが正しいことを確認する インテグレーションが適切なことを確認する CI(主要ブランチ更新ご と) システムテスト システム システムの振る舞いが正しいことを確認する システムがリリース可能な品質レベルであることを確認する リリース時 テストタイプ 詳細テストタイプ 目的 内容 ・・・ 機能テスト フィーチャテスト フィーチャ仕様が実現されていること を確認する フィーチャ単位にフィーチャ仕様と ソフトウェアの合致性を確認 フィーチャ調停テスト 複数のフィーチャを組み合わせたとき の調停処理が正しいか確認する フィーチャ調停仕様とソフトウェア の合致性を確認する セキュリティテスト APIペネトレーション テスト リスクの高い攻撃手法でAPIを攻撃し、 脆弱性がないことを確認する APIについての既知の攻撃手法で 攻撃を試みる ・・・ 全体のテストレベルの方針を明確化する 各テストレベルの構成要素やテスト設計の目的・方向性を明確化する(システムテストの例)
  4. テストアーキテクチャはアジャイルをサポートする ⚫アーキテクチャと同様に、テストアーキテクチャはアジャイルを支える ⚫アジャイルでテストアーキテクチャが求められる場面 • 開発の高品質と高スピードを両立させる • 例:自動テストと手動テストの効果的な組み合わせ • テスト/QAに求められる全体整合を維持する •

    例:テストの責務分担 • 中長期にわたって一貫性が求められるテスト活動を支える • 例:セキュリティテスト • 様々な関係者を巻き込むテスト戦略の推進を支える • 現場に一任するテストの方向性を先導する • 例:リグレッションテスト
  5. アジャイルでのテストアーキテクチャ設計はEDUF アーキテクチャ設計と同じ ⚫アジャイルのテストアーキ設計はEDUF(Enough Design Up Front) • 最大責任時点(Most Responsible Moment:対象活動が最も責務を果た

    せるタイミング)でテストアーキテクチャ設計活動を実施する ≒必要なタイミングで必要な設計をきちんと行う。初期でやるべきものは初 期でやる ⚫アジャイルと相性の悪い設計アプローチ: • BDUF(Big Design Up Front):最初に詳細に固める→変化の許容度× • NDUF(No Design Up Front):行き当たりばったり→アーキテクチャ崩壊 ⚫テストアーキテクチャ設計は、不確実で変化の多いアジャイルの中で、 適時に適切な活動を実施し、継続的にテスト設計を導く
  6. テストプロセスの中のテストアーキテクチャ設計 テスト基本分析 テストアーキテク チャ設計 テスト詳細分析 テスト設計 テスト実装 テスト全体で何をするか スコープ・責務を分析する テスト全体の構成を

    整理する テスト条件を分析する テストケースを設計する テスト手順を実装する イテレーションを横断して 継続的・反復的に育てる イテレーションごとのテスト に応じて実施する
  7. 既知のテストプロセスとテストアーキテクチャ設計 テスト基本分析 テストアーキテク チャ設計 テスト詳細分析 テスト設計 テスト実装 本講演の定義 JSTQB テスト活動

    テスト分析 テスト設計 テスト実装 [TD1]Create Test Model [TD2]Identify Test Coverage Items [TD3]Derive Test Cases [TD4]Create Test Procedures ISO/IEC/IEEE 29119
  8. テストアーキテクチャにかかわる要求・制約を分析し対応する テストへの要求 連携設計のアプローチ 特定の欠陥の検出 検出したい欠陥タイプごとにテスト活動を設計 プロダクトリスクの確認 プロダクトリスクに対し、テスト活動がどう連携するか設計 品質課題の対応 品質課題に対して、テスト活動でどう対応するか設計 課題の例

    課題対応方針 グローバル展開する組込み製品 の表示文言の品質確保 文言の正確性確認、翻訳品質確認:データ静的テスト 文言描画の確認: アプリケーション描画:エミュレータテストで全網羅 実機動作:自動キャプチャーテストで代表パターン確認 現地依存の本番環境確認: ローカライゼーションテスト
  9. テストアーキテクチャにかかわる要求・制約を分析し対応する ⚫特に重大なテストの要求・制約(TASR:Test-Architecturally Significant Requirements)があれば、チームの骨格となる基本設計 方針を立てる TASRの例 TASRへの対応方針 テスト基本設計方針 サービスの頻繁な 改善・変更に対応

    する テスト自動化(実行および生成の自 動化)の促進により、変更対応を効 率化する テスト対象のテスト自動化容易性の向上。テスト 自動化可能な領域を拡大し、それを活用する自 動テストの責務を広げる テスト容易性向上により、テスト対象 の安定性を向上させる テスト対象の変動部分を局所化し、安定性の高 い領域を拡大する。 高い網羅性が求められるテスト範囲を分離し、統 合テストレベルで品質確保する 手動テストについて、探索的アプ ローチの拡大により、変更対応を効 率化する 変動部分に対する手動テストをテストチャータベー スの探索的テストとして実装する
  10. テストアーキテクチャの厚み・抽象度を調整する ⚫識別したテスト活動は、以降のテスト分析・テスト設計活動を適切に 進められるレベルまで、具体化・関心の分離を実施する ⚫調整の観点 • テストの強みを広げる・弱みを狭める • テスト活動をやりやすくする • テスト設計の進め方が異なるものを分ける

    • 例)ユーザビリティ/UXテストを分離する • テストの担当組織が分かれるものを分ける • 例)セキュリティテストを分ける • テストのライフサイクルが異なるものを分ける • テストの環境やリソースが異なるものを分ける • 例)自動テストを分ける
  11. テストアーキテクチャの厚み・抽象度を調整する ⚫生産性の高いテストレベル/テストタイプの責務を最大化する • 自動化可能。CI/CDのデプロイメントパイプラインに統合可能 • テストの性能効率性・保守性を作りこみやすい • 顧客満足/プロダクト価値に近いテストができる ⚫生産性の低いテストレベル/テストタイプの責務を最小化する •

    手動のシステムテストの責務を他のテストに分散する ⚫シフトレフトを推進する • シフトレフトできるテストレベル/テストタイプを確保し責務を広げる • システムテストから結合テスト・ユニットテストへテスト責務を移譲へ • テストピラミッド/テストトロフィーの戦略推進
  12. テストアーキテクチャの全体の構造を整理する テストレベル テスト対象の粒度 目的 サイクル・タイミング ユニットテスト ユニット ユニットのふるまいが正しいことを確認する CI(各ブランチ更新ごと) 結合テスト

    コンポーネントセット システム コンポーネントセットのふるまいが正しいことを確認する インテグレーションが適切なことを確認する CI(主要ブランチ更新ご と) システムテスト システム システムの振る舞いが正しいことを確認する システムがリリース可能な品質レベルであることを確認する リリース時 テストタイプ 詳細テストタイプ 目的 内容 ・・・ 機能テスト フィーチャテスト フィーチャ仕様が実現されていること を確認する フィーチャ単位にフィーチャ仕様と ソフトウェアの合致性を確認 フィーチャ調停テスト 複数のフィーチャを組み合わせたとき の調停処理が正しいか確認する フィーチャ調停仕様とソフトウェア の合致性を確認する セキュリティテスト APIペネトレーション テスト リスクの高い攻撃手法でAPIを攻撃し、 脆弱性がないことを確認する APIについての既知の攻撃手法で 攻撃を試みる ・・・ 全体のテストレベルの方針を明確化する 各テストレベルの構成要素やテスト設計の目的・方向性を明確化する(システムテストの例)