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

テストを導くためのテストアーキテクチャの組み立て方/cetam

Hiroki Iseri
November 20, 2021

 テストを導くためのテストアーキテクチャの組み立て方/cetam

Hiroki Iseri

November 20, 2021
Tweet

More Decks by Hiroki Iseri

Other Decks in Technology

Transcript

  1. アーキテクチャとは ◼ISO/IEC/IEEE 42010 (システムアーキテクチャ関連の規格) • 「Architecture: fundamental concepts or properties

    of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution.」 (対象の環境におけるシステムの基本的な概念や特性を、システムの要素、関係、設計 原則・発展原則として具体化したもの)
  2. テストアーキテクチャの姿:具体例(1/4): 全体のテスト設計活動の目的や内容を導く テストレベル テスト対象の粒度 目的 サイクル・タイミング ユニットテスト ユニット ユニットのふるまいが正しいことを確認する CI(各ブランチ更新ごと)

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

    サービス デプロイ スプリント テスト スプリント(2週間)ごとに実施 リリースごとに実施 CIとして実施 セキュリティ テスト 全体のテスト活動の関係性や依存関係を明確化する
  4. テストアーキテクチャの姿:具体例(3/4): 全体のテスト活動の横断的方針や連携を導く リスク リスク レベル テストでの対策 遠隔アップロード機能の不正利用によるソフトウェア の不正書き換え 6 認証機能評価:システムテスト

    OS設定およびコンフィグレーション評価:セキュリティテスト 全体のセキュリティアセスメント:SQA監査 シャッター制御過剰制御による駆動部分の劣化の 加速 4 システムテストで対応 加速度テスト、ロングランテストでテストする 課題やリスクに対してテスト活動をどう連携するか、どのような方針で実行するかを明確化する
  5. テストアーキテクチャの姿:具体例(4/4): 全体のテストシステムの基本設計を導く 制御 PC テスト 対象 モニタ撮影 装置 被写体 モデル

    タッチパネル エミュレータ テスト管理 サーバ CIサーバ テストドライバ CI クライアント DIO コンバータ SDカード マルチプレクサ 映像/USB-C 必要なテストシステムのアーキテクチャを明確化する テストシステム 使用するテスト システムテスト自動化環境 自動システムテスト スモークテスト レフ制御耐久テスト環境 レフ制御耐久テスト Rustユニットテスト環境 MMアプリユニットテスト ・・・ テストアーキテクチャは テスト設計活動の要素、要素の構造、 要素の連携、要素が必要とする環境 で主に表現する
  6. 開発ライフサイクルの中でのテストアーキテクティング 継続実施しプロジェクトを導き続ける プロジェクト最初期 立ち上げ/初期計画立案 /体制構築 プロジェクト初期 各計画具体化/ PoC/開発開始 プロジェクト中期以降 開発本格化/保守・派生

    プロジェクトフェーズ テストアーキテクティングの活動 (継続的に反復する) ・テストアーキテクチャ要求の分析 ・テストアーキテクチャの設計 ・テストアーキテクチャの評価と改善 テストアーキテクティングで フォーカスする活動 ・テストの体制・計画・戦略の基礎の 構築を導く 見積もりの根拠/あるべき体制/必要なリソー ス/テストアーキテクチャの基礎 ・テスト計画・戦略の具体化を導く ・テスト設計の基本方針・基本構造 の確立を導く ・テスト活動を導く ・変化への対応を導く ・テストの再利用を導く ・テストアーキテクチャを維持する 反復の継続
  7. テストアーキテクティングはEnough Design Up Front ◼テストアーキテクティングはEnough Design Up Front(EDUF) • 最大責任時点(Most

    Responsible Moment。対象活動が最も責務を果たせるタイミン グ)で各テストアーキテクティング作業を実施する ◼テストアーキテクティングは、不確実で変化の多いプロジェクトの中で、適時に 適切な活動を実施し、テストをどう育て・適応させていくか、継続的に導く ◼継続的に洗練させながら、その時にとってのあるべきテストの実現を目指す
  8. テストアーキテクトのアンチパターン: 象牙の塔のアーキテクト ◼閉じこもってアーキテクチャを考え、トップダウンで現場にアーキテクチャを指示 するアーキテクト • 背景 • 教条やパターンへの狂信、権威主義 • テスト上流活動と現場の断絶

    • 外部リソースへのアーキテクティングの丸投げ • 属人的要因 ◼現場の制約に対応できず、納得を得られず、チームのアーキテクティング力を 伸ばせず、結果として現場の力を活かせずにテストの失敗を誘発する 適切なコミュニケーションを通して テスト関係者の納得を確保しながら、協力と連携を引き出すのは テストアーキテクティングの不可欠な活動
  9. テストアーキテクティングでの設計技術の活用 アーキテクティングの技術でテストをより良くする ◼テストの責務についての関心事の分離/モジュール性改善の推進 • テストの責務を分割し、テスト要求・テスト観点を扱える粒度まで細分化する • テスト設計活動を円滑に推進できるように、テストの責務配置の凝集性を高める ◼全体整合性の確保/テストパイプラインの最適化 • 様々なテスト活動を重ね合わせ・分業させ、テストの有効性・網羅性を実現する

    • テスト活動のムリ・ムダ・ムラをなくす ◼中長期視点のライフサイクル設計 • 開発ライフサイクルでテストをどう育て、拡張させていくかの設計戦略を構築し、テストの適時性を確保する ◼構造的工夫によるテスト技術/テストリソース活用の拡大 • 有益なテスト技術/テストリソースの適用範囲を拡大する ◼テストの保守性の作りこみ • テストの評価容易性、変更容易性、再利用性、解析性を支える設計を組み込み、テストアーキテクチャの評価・ 維持・改善を効率化する ◼テストシステムの品質の作りこみ • テストシステムに性能効率性や信頼性、保守性など品質を支える設計を組み込み、テストの適時性や信頼性を 改善する
  10. テストアーキテクチャの表現 ◼アーキテクチャの表現 • アーキテクチャは様々な特性を備えていることから、複数のアーキテクチャ観点でみた複 数の側面で表現する • アーキテクチャ観点は、少なすぎず、多すぎない数を、重要性に基づいて選択する • 例:RUP4+1、ArchiMate ◼テストアーキテクチャを表現する観点

    主要なテストアーキテクチャ観点 このパートで紹介する主な表現手法 テストアーキテクチャの構成要素 責務構造ツリー テスト責務管理表 テストアーキテクチャの構造 パイプラインモデルとシナリオ記述 テストアーキテクチャの環境 (テストシステムの環境設計) テストアーキテクチャの連携 (要求に応じた表現手法) テストアーキテクチャの発展原則
  11. テストアーキテクチャの構成要素の表現: 責務構造ツリー(GSN) ◼モデリング手法 • 責務分割構造をツリーでモデリングする • GSN(Goal Structuring Notation)の記法を活用する •

    https://scsc.uk/gsn • HAYST法のD-Case(GSN活用)によるテスト戦略立てから着想を得て具体化した • http://jasst.jp/symposium/jasst18tohoku/pdf/S1.pdf ◼GSNの慣習との差異 • Goalはテスト活動の責務に特化する • Solutionは省略可 ◼D-Case、マインドマップなど他のツリーモデリング記法でも代替可
  12. テストアーキテクチャの構成要素の表現: 責務構造ツリー:例 デジタルカメラのテスト ユニットテスト・ コード解析 開発工程に対応して テストを実施する 結合テスト システム テスト

    開発組織に応じて テストを実施する 内製コンポーネントおよび システム結合以降のテスト 外製コンポーネントのテスト 開発会社ごとに受け入 れテストを実施する ユニットテスト ツリー MMシステム 受け入れテスト RTOS 受け入れテスト 結合テスト ツリー システムテスト ツリー システム アーキテクチャ
  13. 責務構造ツリー:基本記法 記法 説明 GSNでのGoal。テストアーキテクティングでは、テストの責務を示す。 具体的な単位として、テストレベルやテストタイプを記載する GSNでのStrategy。責務構造ツリーでは、上位の責務を下位に分解する方 針を示す GSNでのContext。責務や責務分解方針のコンテキスト(背景や根拠を示 す) GSNでのUninstantiated

    element。対象の責務がまだ具体化されていない (未完成)ことを示す GSNでのOff diagram decorator。他のツリーへの参照。グラフを分割すると きに用いる 責務 責務分解の方針 コンテキスト Off diagram その他、GSNの記法を利用可能 テストタイプ:コンポーネントやシステムのある特性に対応したテストの目的を基にテスト活動をまとめたもの(ISTQB Glossary) 性能テスト、単機能テスト、ユーザビリティテストなど
  14. 責務構造ツリー:モデル構造 ユニットテスト・ コード解析 開発工程に対応して テストを実施する 結合テスト システム テスト 内製コンポーネントのテストおよび システム結合以降のテスト

    •上位のテストの責務を、下位のテストの責務に分割する •ひし形Strategyで、「どう分割したか」を明記する •テストアーキテクティングでは、テストの責務はテストレベル・ テストタイプの粒度で記載
  15. テスト責務管理表:例 テストレベル テスト対象のレベル 目的 タイミング ユニットテスト ユニット ユニットのふるまいが正しいことを確認する ・・・ 結合テスト

    コンポーネントセット システム コンポーネントセットのふるまいが正しいことを確認する インテグレーションが適切なことを確認する ・・・ システムテスト システム システムの振る舞いが正しいことを確認する システムがリリース可能な品質レベルであることを確認する ・・・ テストタイプ 詳細テストタイプ 目的 内容 ・・・ 機能テスト フィーチャテスト フィーチャ仕様が実現されてい ることを確認する フィーチャ単位にフィーチャ仕様とソ フトウェアの合致性を確認 ・・・ フィーチャ調停テスト 複数のフィーチャを組み合わせ たときの調停処理が正しいか 確認する フィーチャ調停仕様とソフトウェアの 合致性を確認する ・・・ セキュリティテスト APIペネトレーションテスト リスクの高い攻撃手法でAPIを 攻撃し、脆弱性がないことを確 認する APIについての既知の攻撃手法で 攻撃を試みる ・・・ ・・・ テストレベル管理表 システムテストを構成するテストタイプ管理表
  16. テストアーキテクチャの構造の表現: パイプラインモデルとシナリオ記述 ◼シナリオ記述:具体的なシチュエーションごとのパイプラインのふるまいを記述 する • テストアーキテクチャはプロジェクト状況に応じて変動するパラメータを持つ パイプラインでモデル化する際はシナリオ記述による場合分け記述が有効 シナリオ ユニットテスト 結合テスト

    システムテスト スプリント内テスト 全実行 全実行 追加変更分に対するテスト+影響範囲のリグ レッションテスト リリース時テスト 全実行 全実行 全実行 hotfix時テスト 全実行 全実行 追加変更分に対するテスト+影響範囲のリグ レッションテスト インテグ レーション 結合テスト システム テスト ユニット テスト 実装 リリース
  17. テストアーキテクチャの表現: テストアーキテクチャへの要求に応じたモデリングを行う ◼アーキテクチャ観点は様々。テストアーキテクチャへの要求に基づいて、アーキ テクチャ観点を選択し、各観点ごとにテストアーキテクチャを表現する テストアーキテクチャ要求の例 テストアーキテクチャ要求に対応するモデル・表現方法 様々なテストベースの実現性保証 各テストベースとテストレベル・テストタイプのマッピング 想定される欠陥の検出 検出したい欠陥タイプとテストタイプのマッピング

    品質レベルがリリースできる水準であること の確認 品質リスク分析(テストアーキテクチャがリスクに対応できているか) 推測されるプロジェクトトラブルへの対応 プロジェクトリスク分析(テストアーキテクチャがリスクに対応できているか) 開発スケジュールに応じたテストアーキテク チャの段階的拡張 テストアーキテクティングのスケジューリング 必要なテスト環境リソースの識別 テストシステムの構造アーキテクチャ設計
  18. テストアーキテクティングの進め方: アウトライン ◼テストアーキテクティングの全体像 ◼テストアーキテクティングの基本活動 • テストアーキテクチャ要求の分析 • ステークホルダ分析/要求・制約の分析 • テストアーキテクチャの設計

    • テストアーキテクチャの設計 • 関係者との調停/テスト担当者とのすり合わせ • ★個人ワーク1 • テストアーキテクチャの評価と改善 • シナリオウォークスルー • ★個人ワーク2 ◼テストアーキテクティングの反復と維持活動 ◼テストアーキテクティングのテストへの展開
  19. テストアーキテクティングの進め方: アウトライン ◼テストアーキテクティングの全体像 ◼テストアーキテクティングの基本活動 • テストアーキテクチャ要求の分析 • ステークホルダ分析/要求・制約の分析 • テストアーキテクチャの設計

    • テストアーキテクチャの設計 • 関係者との調停/テスト担当者とのすり合わせ • ★個人ワーク1 • テストアーキテクチャの評価と改善 • シナリオウォークスルー • ★個人ワーク2 ◼テストアーキテクティングの反復と維持活動 ◼テストアーキテクティングのテストへの展開
  20. テストアーキテクティングの全体像: 継続実施しプロジェクトを導き続ける プロジェクト最初期 立ち上げ/初期計画立案 /体制構築 プロジェクト初期 各計画具体化/ PoC/開発開始 プロジェクト中期以降 開発本格化/保守・派生

    プロジェクトフェーズ テストアーキテクティングの活動 (継続的に反復する) ・テストアーキテクチャ要求の分析 ・テストアーキテクチャの設計 ・テストアーキテクチャの評価と改善 テストアーキテクティングで フォーカスする活動 ・テストの体制・計画・戦略の基礎の 構築を導く 見積もりの根拠/あるべき体制/必要なリソー ス/基本テストアーキテクチャの提示 ・テスト計画・戦略の具体化を導く ・テスト設計の基本方針・基本構造 の確立を導く ・テスト活動を導く ・変化への対応を導く ・テストの再利用を導く ・テストアーキテクチャを維持する 反復の継続
  21. テストアーキテクティングの進め方: アウトライン ◼テストアーキテクティングの全体像 ◼テストアーキテクティングの基本活動 • テストアーキテクチャ要求の分析 • ステークホルダ分析/要求・制約の分析 • テストアーキテクチャの設計

    • テストアーキテクチャの設計 • 関係者との調停/テスト担当者とのすり合わせ • ★個人ワーク1 • テストアーキテクチャの評価と改善 • シナリオウォークスルー • ★個人ワーク2 ◼テストアーキテクティングの反復と維持活動 ◼テストアーキテクティングのテストへの展開 テストアーキテクチャ要求分析 テストアーキテクチャ設計 テスト戦略・方針の策定 設計 連携設計 責務分割 構造設計 環境設計 すり合わせ 評価と改善
  22. テストアーキテクチャ要求の分析 ◼テストアーキテクチャへのニーズ・シーズ・制約を分析する • テストの要求・制約のうち、テストアーキテクチャに影響するものを分析する • テストの要求・制約の詳細な分析は、各テストレベルのテスト分析で実施 • 特にASR(Architecturally significant requirements。アーキテクチャに重要な影響を与

    える要求)の識別に注力する • ASRがテストアーキテクチャの基本構造・基本方針を決定する。これをミスすると後からのリカバリが大 変になる ◼構成作業 1. ステークホルダの分析 2. テストアーキテクチャ要求の収集と分析
  23. テストアーキテクチャ要求の分析 ステークホルダの分析 ◼テストアーキテクチャはビジネス、開発、マネジメント、品質保証、テストを横断 幅広くステークホルダを洗い出す カテゴリ ステークホルダ 概要 重要度 影響度 テストへの主な関心事

    製造 生産技術 製造技術の確立と改善 B B 検査技術の開発と導入 製造者 製品の組み立て A B 製造時チェックの効率化 製造検査 製品の最終品質保証 A A 製造検査の効率化 ユーザ 専属プロ 継続契約の製品評価プロ B B ブランドシリーズ特有の利用時品質の 保証 契約評価者 ユーザバリデーションの選出ユーザ B C 各カテゴリの利用時品質の保証 プロ/ハイアマチュア 製品のプロおよびハイアマチュアユーザ B B プロユースを満たす品質の保証 エントリユーザ 製品の入門ユーザ A B 初心者向けの利用時品質の保証 品質保証 法規/法務 法規制、規格、標準の適合保証 A A 法規制、規格、標準の事前適合評価 および一部評価代行 品質管理 プロジェクトの継続的な品質管理 C B テストにかかわる品質保証の提出 ソフトウェア品質保証 ソフトウェアのリリース時品質保証 A A ソフトウェアのリリース時の品質保証 ・・・ (1-1)ステークホルダ抽出 (1-2)ステークホルダ分析
  24. テストアーキテクチャ要求の分析 テストアーキテクチャ要求の収集と分析 ◼重要度に応じてテストアーキテクチャ要求を分析する • テストアーキテクチャを取り巻く要求は膨大。全体俯瞰の分析観点と重点部分を深掘り する分析観点を組み合わせて、テストアーキテクチャに必要な情報を獲得する 重視する目的の例 目的に対応したテストアーキテクチャ要求分析の重要点 必要なテストレベルを識別する 開発プロセス分析、テストベース分析、テスト対象のアーキテクチャ分析

    法規制・標準の適合保証に必要なテストを明 らかにする テストに関わる法規制・標準の識別、法規制・標準の中でのテストへの要求項目の分析 テスト実施タイミングおよびそこでのテスト十分 性基準を明らかにする リリーススケジュールの調査、リリースごとの品質目標の分析、 テスト要求分析 システムテストのテストタイプを分析する テスト要求分析、システムを構成する品質特性の分析、機能構造(インターフェースや静 的データなど)の分析 テスト自動化の適用範囲を明らかにする テスタビリティの調査、リソース計画の分析、保有するテスト自動化技術の調査 テストによるリスクコントロールが妥当か調査 する 品質リスクの分析、プロジェクトリスクの分析 結合テストのテストタイプを分析する テスト対象のアーキテクチャ調査、インテグレーションプロセスの分析、 コンポーネントセットごとの品質目標とテスタビリティの評価
  25. テストアーキテクティングの進め方: アウトライン ◼テストアーキテクティングの全体像 ◼テストアーキテクティングの基本活動 • テストアーキテクチャ要求の分析 • ステークホルダ分析/要求・制約の分析 • テストアーキテクチャの設計

    • テストアーキテクチャの設計 • 関係者との調停/テスト担当者とのすり合わせ • ★個人ワーク1 • テストアーキテクチャの評価と改善 • シナリオウォークスルー • ★個人ワーク2 ◼テストアーキテクティングの反復と維持活動 ◼テストアーキテクティングのテストへの展開 テストアーキテクチャ要求分析 テストアーキテクチャ設計 テスト戦略・方針の策定 設計 連携設計 責務分割 構造設計 環境設計 すり合わせ 評価と改善
  26. テストアーキテクチャの設計 テスト戦略・方針の策定 ◼テストアーキテクチャ設計を含む、テスト全体の戦略を具体化し、テストアーキテ クチャ設計を方向づけする • 重要な要求に基づく戦略で、テストアーキテクチャの基本骨格を構築する • 後付けで対応困難な問題対応を適時のタイミングで実施する • 重大なアーキテクティングの誤りを避ける

    ASR・重要な目的 テスト戦略 サービスの頻繁な改善・ 変更に対応する テスト自動化(実行および生成の自動化)の促 進により、変更対応を効率化する テスタビリティ向上により、テスト対象の安定性 を向上させる 手動テストについて、探索的アプローチの拡大 により、変更対応を効率化する 例:アジャイル開発でのテスト戦略 テストアーキテクチャ設計 テスト戦略・方針の策定 設計 連携設計 責務分割 構造設計 環境設計 すり合わせ
  27. テストアーキテクチャの設計 テスト戦略・方針の策定 ◼テストアーキテクチャ設計を含む、テスト全体の戦略を具体化し、テストアーキテ クチャ設計を方向づけする • テスト戦略を実行可能なテストアーキテクティング方針に具体化する テスト戦略 テストアーキテクティング方針 テスト自動化(実行および生成の自動化)の 促進により、変更対応を効率化する

    テスト対象のテスト自動化容易性の向上。テスト自動化可能な領域を拡 大し、それを活用する自動テストの責務を広げる テスタビリティ向上により、テスト対象の安定 性を向上させる テスト対象の変動部分を局所化し、安定性の高い領域を拡大する。 安定性の高い領域に高網羅度のテスト責務を配置する 手動テストについて、探索的アプローチの拡 大により、変更対応を効率化する 探索的テスト人材の育成を促進するプロセスを構築する。またそれを促 進するリソースマネジメント・スケジュールをマネジメントに要求する。 システムテストは探索的テスト主体の方針を取る 例:アジャイル開発でのテスト戦略
  28. テストアーキテクチャの設計 •Must要求 実現しなければならないテスト •Want要求 実現したいテスト ※テストアーキテクチャ要求分 析で明らかにする •チームができるテスト ※テストアーキテクチャ要求・制約 分析で明らかにする

    •チームができるようになる見 込みのテスト ※マネジメントとの連携およびテス ト活動の反復で実現の見通しを明 らかにする •チームができるテストの代替 手段 ※マネジメント・品質保証・開発と の連携で実現の見通しを明らかに する 関心事の分離(責務分割)、 連携検討、構造設計を通して、 テストアーキテクチャを導出
  29. 【閑話】チームが遂行可能なテストタイプ(テストケイパビリティ) を日頃から蓄積する ◼日頃の技術蓄積がテストアーキテクチャの選択の幅を左右する ◼チームの技術資産として、遂行可能なテストタイプを蓄積していこう モータ制御の正確性テスト 性能計測 イーサネットのペネトレーションテスト 静的解析 機械制御のロードテスト 機械制御のロードテスト

    ウェブサービスのストレステスト OSS脆弱性評価 機能調停の組み合わせテスト ハードウェア互換性テスト UXバリデーション 障害注入テスト マニュアル合致性テスト 耐タンパ性評価 資源効率性評価 アクセシビリティ評価 ビジュアルテスト 障害回復性テスト
  30. 【閑話】テストアーキテクチャの設計: テストレベルの設計アプローチ ◼テストレベルの導出 1. 開発プロセスおよびアーキテクチャの分析を通して導出する • 工程、テストベース種別、アーキテクチャ構成に対応するテストを候補に導出する 2. 課題・リスクのコントロールを観点に導出する •

    課題・リスクに対応するために、多すぎず、少なすぎないテストレベルを導出する ◼導出したテストレベルの責務設計 • 開発ライフサイクル全体でのROI(費用対効果)・要求対応の観点で責務を調整する • ROIの低いテストレベルの責務を、ROIの高いテストレベルの責務に移動させる(例:テストピラミッド) • テストレベルごとの方針 • 例:コンポーネント(ユニット)テスト • 開発対象の種別、フレームワーク、開発言語に応じて設定する • ほとんどの場合で既にベストプラクティスが確立されているので素直に従う • 構造でなく原則・アプローチを指向して具体化する(TDDなど) • 例:結合テスト • アーキテクチャ/インテグレーションプロセス/環境制約に合わせてテストレベルの責務を調整する
  31. 【閑話】テストアーキテクチャの設計: テストタイプの設計アプローチ ◼テストレベルに応じた導出アプローチをとる • テストレベルごとにテストタイプ設計アプローチは全く異なる • アンチパターン:全テストレベルに、ISO/IEC 25010の品質特性を一律適用して導出 • 事前準備として、テストタイプを導出しやすいように、テストレベルや上位テストタイプで

    「関心事の分離」「テスト責務の凝集性の確保」を実施するのが重要 ◼例:システムテストのテストタイプの導出 • 仕様の種別、仕様の構造(例:ラルフチャート)、仕様に関係する品質特性を切り口に分 析する その3つの切り口で、システムテスト全体の責務を、テスト設計活動がやりやすいように 凝集性を確保しながら分割し、テストタイプにする • アンチパターン: ISO/IEC 25010の品質特性をそのまま適用 • VSTePでのテストコンテナ設計など、テストの上流設計手法を活用できる
  32. テストアーキテクチャの設計 3つの設計詳細化アプローチ ◼責務分割による導出 • 全体の責務を個別対応可能な粒度まで分割し、テスト アーキテクチャの構成要素と構造を導出する ◼連携設計による導出 • 方針、課題、リスクに対して、どのような連携をするか設計 する過程で、テストアーキテクチャの構成要素と構造を設

    計する ◼構造設計による導出 • プロセスベースでテストアーキテクチャを設計し、テストアー キテクチャの構成要素と構造を設計する テストアーキテクチャ設計 テスト戦略・方針の策定 設計 連携設計 責務分割 構造設計 環境設計 すり合わせ
  33. テストアーキテクチャの設計 責務分割 ◼テストの責務を実行可能な粒度まで分割する テストアーキテクチャ設計 テスト戦略・方針の策定 設計 連携設計 責務分割 構造設計 環境設計

    すり合わせ デジタルカメラのテスト ユニットテスト・ コード解析 開発工程に対応して テストを実施する 結合テスト システム テスト 開発組織に応じて テストを実施する 内製コンポーネントおよび システム結合以降のテスト 外製コンポーネントのテスト 開発組織ごとに受け入 れテストを実施する MMシステム 受け入れテスト RTOS 受け入れテスト
  34. テストアーキテクチャの設計: 連携設計 ◼テストアーキテクチャ要求に基づいて、テスト活動をどう連携させるか設計する 連携の設計を通してテストアーキテクチャの構成要素を検討する • 特に影響が重大なASRに基づいて、テストアーキテクチャの骨格を構成する テストアーキテクチャ要求の種類の例 テストアーキテクチャ要求に対応した設計作業 様々なテストベースの実現性保証 各テストベースとテストレベル・テストタイプのマッピング

    想定される欠陥の検出 検出したい欠陥タイプとテストタイプのマッピング 品質レベルがリリースできる水準であること の確認 品質リスク分析 推測されるプロジェクトトラブルへの対応 プロジェクトリスク分析 開発スケジュールに応じたテストアーキテク チャの段階的拡張 テストアーキテクティングの発展原則の具体化
  35. テストアーキテクチャの設計: 連携設計 ◼テストアーキテクチャ要求に基づいて連携を設計する: 「リリース可能なリスクレベルまでリスクをコントロールする」 • リスクに対し、リスクコントロールを観点に必要なテスト活動と連携を設計する 方針 リスク レベル テストでの対策

    ユーザ評価によるモードUI変更の差し戻し 3 早期のユーザテストによるUI妥当性評価の前倒しを実施 ロボットによるUI自動テスト導入の失敗 4 反復テストによる早期のフィージビリティスタディを実施 マネジメントリスク リスク リスク レベル テストでの対策 遠隔アップロード機能の不正利用によるソフトウェアの不正 書き換え 6 認証機能評価:システムテスト 設定およびコンフィグレーション評価:セキュリティテスト 全体のセキュリティアセスメント:SQA監査 シャッター制御過剰制御による駆動部分の劣化の加速 4 システムテストで対応 加速度テスト、ロングランテストでテストする 品質リスク
  36. テストアーキテクチャの設計: 構造設計 ◼テストアーキテクチャの構造(依存関係、順序、関係性)を設計し、構成要素や 連携を導出する • 構造パターン:重ね合わせ、分業、横断的連携、繰り返し • 例:パイプラインモデル(orプロセスモデル)とシナリオ記述で構造を設計 インテグレー ション

    結合テスト システム テスト ユニット テスト 実装 サービス デプロイ スプリント テスト スプリント(2週間)ごとに実施 リリースごとに実施 CIとして実施 セキュリティ テスト シナリオ ユニットテスト 結合テスト スプリントテスト システムテスト セキュリティテスト スプリントリリース 全実行 全実行 全実行 実施しない 実施しない 通常デプロイ 全実行 全実行 全実行 全実行 全実行 Hotfix&デプロイ 全実行 全実行 全実行 追加変更分に対するテスト+影 響範囲のリグレッションテスト リスクベースドテスト
  37. テストアーキテクチャの設計: 環境設計 ◼テストアーキテクチャ要求に基づいてテストシステムの基本設計を行う • テストアーキテクティング要求対応に注力。詳細なテスト環境設計は各テストレベルで実施 • OOD、SysML/UMLなどシステムやソフトのアーキテクチャ設計手法を活用できる 制御 PC テスト

    対象 モニタ撮影 装置 被写体 モデル タッチパネル エミュレータ テスト管理 サーバ CIサーバ テストドライバ CI クライアント DIO コンバータ SDカード マルチプレクサ 映像/USB-C •必要なテストシステムを識別する テストシステム 使用するテスト システムテスト自動化環境 自動システムテスト スモークテスト レフ制御耐久テスト環境 レフ制御耐久テスト Rustユニットテスト環境 MMアプリユニットテスト ・・・ •テストアーキテクチャ要求に対応する テストシステムを具体化する
  38. テストアーキテクチャの設計:環境設計: テスト設計とテスト環境設計は不可分 ◼テストアーキテクティングにおいて、テストシステム設計とテスト設計は一緒に検討し なければならない • テスト自動化やCI/CDインフラ、IasC、仮想化をはじめとした現代のテストシステムの技術は、テ スト設計の進め方に強く影響する • 例:キーワード駆動テスト •

    また上記の技術の活用の程度が、テストの生産性に直結する。そのためテスト活動の責務設計 の重要な判断基準となる ◼例:テスト自動化の活用 • 前提 • テスト自動化ツールの指定する形式に合わせてテスト設計方針を立てなければならない • ROIに優れた自動テストの責務を増やすテストアーキテクチャ設計が有効になる • テストアーキテクチャ設計での必要なアクション • テストシステム設計を通して自動化ツールを明確化。ツールにあったテスト設計方針を具体化する • テストシステム設計を通してテストのROIを明確化。それに沿ってテストの責務設計を調整する
  39. テストアーキテクチャの設計 テストアーキテクチャの詳細定義 ◼テストアーキテクチャの構成要素や連携の詳細を具体化する テストレベル テスト対象の粒度 目的 サイクル・タイミング ユニットテスト ユニット ユニットのふるまいが正しいことを確認する

    CI・各ブランチ更新ごとに実施 結合テスト コンポーネントセット システム コンポーネントセットのふるまいが正しいことを確認する インテグレーションが適切なことを確認する CI・メインブランチ更新ごとに実 施 ・・・ テストタイプ 詳細テストタイプ 目的 内容 作成担当 機能テスト フィーチャテスト フィーチャ仕様が実現されていること を確認する フィーチャ単位にフィーチャ仕様とソ フトウェアの合致性を確認 テストチーム フィーチャ調停テスト 複数のフィーチャを組み合わせたとき の調停処理が正しいか確認する フィーチャ調停仕様とソフトウェアの 合致性を確認する テストチーム セキュリティ テスト APIペネトレーションテスト リスクの高い攻撃手法でAPIを攻撃 し、脆弱性がないことを確認する APIについての既知の攻撃手法で 攻撃を試みる セキュリティテス ト ・・・ テストレベル管理表 システムテスト・テストタイプ管理表
  40. 【個人ワーク1】テストの責務構成の明示 ◼「完成品に対するユーザビリティテスト」についての要求: • 外部評価者および内部テストチームで対応する必要がある • 外部評価者によるテスト:複数のタイプの評価者ごとにテストを実施。以下が必要 • ユーザテスト:選出した想定ユーザに基本的なユーザビリティを評価してもらう • 専属プロテスト:継続契約している専属プロに評価してもらう

    • エキスパートテスト:メインターゲットのプロおよびハイエンドユーザに、プロユースに耐えられるか評価しても らう • 内部テストチームによるテスト:ユーザビリティ要件およびユーザビリティガイドラインに基づいてテ ストを実施。以下が必要 • 内部ユーザビリティテスト:ユーザビリティ要件を実現しているか評価 • アクセシビリティテスト:UIがアクセシビリティガイドラインに適合しているか評価 • ブランディングレビュー:ブランドポリシーに適合しているか評価 • ユーザビリティガイドラインテスト:社内ユーザビリティガイドラインに適合しているか評価 課題:親ノードを「完成品に対するユーザビリティテスト」として、 上記で提示されているテストタイプを責務構造ツリーでモデリングしてください
  41. 【個人ワーク1】テストの責務構成の明示 解答例(一例です) アクセシビリティ テスト エキスパート テスト ブランディング レビュー ユーザテスト ユーザビリティ

    ガイドライン テスト 内部ユーザビリ ティテスト テストベースごとに テストする 専属プロ テスト 内部テストチーム によるテスト 外部評価者に よるテスト 完成品に対する ユーザビリティテスト 内部テストチーム、外部評 価者それぞれでテストする 異なる種別の ユーザごとにテストする
  42. テストアーキテクティングの進め方: アウトライン ◼テストアーキテクティングの全体像 ◼テストアーキテクティングの基本活動 • テストアーキテクチャ要求の分析 • ステークホルダ分析/要求・制約の分析 • テストアーキテクチャの設計

    • テストアーキテクチャの設計 • 関係者との調停/テスト担当者とのすり合わせ • ★個人ワーク1 • テストアーキテクチャの評価と改善 • シナリオウォークスルー • ★個人ワーク2 ◼テストアーキテクティングの反復と維持活動 ◼テストアーキテクティングのテストへの展開 テストアーキテクチャ要求分析 テストアーキテクチャ設計 テスト戦略・方針の策定 設計 連携設計 責務分割 構造設計 環境設計 すり合わせ 評価と改善
  43. テストアーキテクチャの評価と改善: アーキテクチャ設計時の評価手段 ◼計画立案時、設計初期時などプロジェクト初期に頼る検証手段(一部) • 下記のようなもの以外にも、ATAM、SAAMなどアーキテクチャ評価手法を適用できる 検証手法 進め方 シナリオウォークスルー 具体的なシナリオにテストアーキテクチャが対応できるか検証する 品質リスク分析

    品質リスクに対しテストアーキテクチャによるリスクコントロール結果が妥当か検証する プロジェクトリスク分析 プロジェクトリスク(テスト工数削減、不具合の多発など)に対しテストアーキテクチャによるリス クコントロール結果が妥当か検証する アーキテクチャブリーフィング ステークホルダや担当者にアーキテクチャを説明し、QCC(Question-Comment-Concern)や 改善点を募る アーキテクチャ比較 参考モデルや類似プロジェクトのテストアーキテクチャとPors/Cons分析などで比較し、相対的 に問題点・改善点を検出する 標準・方法論準拠レビュー テストアーキテクチャが、標準・規格・方法論の項目を満たしているかレビューする テストアーキ設計時評価は制約や限界が大きいものの、必要性が高い 様々な手法があるので、チームでそのスキルを蓄積し包括的に実施する
  44. テストアーキテクチャの評価と改善: テスト活動実施後の評価手段 ◼プロトタイピングや反復開発時の実施時や、保守・派生開発で実施できる評価 手段(一部) • 多数の設計評価手段がある。目的やASRに基づいて評価方法・評価基準を設定する • 評価指標の抽出にはGQM法といったメトリクスやKPI導出手法が有効 検証手法 進め方

    欠陥流出率評価 各構成活動ごとに、自活動で検出すべきだったが流出させてしまった欠陥の程度で評価する フォールトインジェクション 意図的に欠陥を混入させ、それを検出できたか評価する テスト網羅性評価 各構成要素ごとに、仕様カバレッジ、コードカバレッジなど、テストの網羅性の程度で評価する テスト生産性評価 各構成要素ごとに、実際にかかったコストやリソースが妥当か評価する ビジネス妥当性評価 ビジネスのKPI達成度、SLA順守度(MTTF、実際のパフォーマンス計測結果など)、ユーザアンケート など、市場やユーザからのフィードバックを用いてテストの有効性が妥当か評価する
  45. テストアーキテクチャの評価手段の一例: シナリオウォークスルー ◼レビューによるアーキテクチャの評価手段の一つ ◼手順 1. シナリオ形式で実例をピックアップ 2. シナリオを実行した際に、テストアーキテクチャが目標を達成できるか、テストアーキテク チャに問題がないか、机上にて、ウォークスルーレビューで評価する ◼シナリオのピックアップ方法

    • 重要度に応じて体系的に導き出す • 導出方法の例: • リスクベース:リスクレベルの高いものについてリスクシナリオをピックアップする • 不具合タイプ:不具合を種類で分類し、各種類ごとに代表的な不具合をピックアップする • 目的ベース:テスト目的を細分化し、それぞれの目的を具体化したシナリオをピックアップする
  46. テストアーキテクチャの評価手段の一例: シナリオウォークスルー(欠陥分類を用いるアプローチ) 欠陥分類 代表的な欠陥の実例 欠陥発生のシナリオ 文言の正確性 フランス語の誤翻訳 仕様作成時のフランス語翻訳を誤り、誤翻訳文言が埋め込まれる 文言描画 A形式レイアウトモニタでの文字切れ

    描画領域不足で、幅広フォント文字を最大数入力したら描画領域を超過する ・・・ (1)欠陥分類ごとに欠陥の実例が発生するシナリオをピックアップ (2)「欠陥発生のシナリオ」にテストアーキテクチャが対応できるか、ウォークスルーレビューする 「外国語の誤翻訳は本来システムテストでピックアップすべきだが、フラ ンス語が分かる担当者確保が検討されておらず見逃す可能性がある」 「文字切れは結合テストでのエミュレータによる自動テストで検出される」
  47. 【個人ワーク2】シナリオウォークスルーによるテストアーキテク チャの評価と改善 ◼評価するテストアーキテクチャ インテグレー ション 結合テスト リリース テスト ユニット テスト

    実装 サービス デプロイ スプリント テスト スプリント(2週間)ごとに実施 リリースごとに実施 スプリント レビュー テスト テスト内容 ユニットテスト ユニットが仕様を満たしているか確認。開発者が記述しCIツールで実行。自動テスト。主要ブランチ更新ごとに実行 結合テスト コンポーネントセットが仕様を満たしているか、サービスの結合ができているか確認。開発者が記述しCIツールで実行。自 動テスト。メインブランチの更新ごとに実行 スプリントテスト スプリント成果物がPO(プロダクトオーナー。要求定義者)が提示した仕様を満たしているか確認。テストエンジニアが実 施。探索的テスト スプリントレビュー スプリント成果物が妥当か確認。POが実施。レビューおよび探索的テスト リリーステスト サービスがリリースできる品質であることを確認。テストエンジニアが実施。過去のスプリントテストを再実施するリグレッ ションテストで構成する CIとして実施
  48. 【個人ワーク2】シナリオウォークスルーによるテストアーキテク チャの評価と改善 ◼シナリオウォークスルーで用いるリスクシナリオ プロジェクトリスク リスクシナリオ 要求分析の誤りによる 不要な機能の実装 POがユーザからの要求を誤解し、ユーザが必要としない冗長な機能を追加してしまった 不適切な設計による 性能の不足

    性能要求について、POは必要な要求と認識していたが、ユーザストーリー(仕様)として 明文化ができていなかったため、開発者が性能要求に気づけなかった。結果としてその 性能要求が未達成のサービスを開発してしまった
  49. 【個人ワーク2】シナリオウォークスルーによるテストアーキテク チャの評価と改善 ◼課題 リスクシナリオ シナリオにテストアーキテクチャが対応 できるかの評価結果 テストアーキテクチャの改善点 POがユーザからの要求を誤解し、ユーザ が必要としない冗長な機能を追加してし まった

    性能要求について、POは必要な要求と 認識していたが、ユーザストーリー(仕様) として明文化ができていなかったため、開 発者が性能要求に気づけなかった。結果 としてその性能要求が未達成のサービス を開発してしまった 課題1:リスクシナリオが示すリスクを、 テストアーキテクチャが対応できるか評価し、 結果を記述してください 課題2:課題1で問題が見つかった場合、 その改善点を記述してください
  50. 【個人ワーク2】シナリオウォークスルーによるテストアーキテク チャの評価とテストアーキテクチャの改善案検討 解答例 ◼解答例(一例です) リスクシナリオ シナリオにテストアーキテクチャが対応で きるかの評価 テストアーキテクチャの改善点 POがユーザからの要求を誤解し、ユーザ が必要としない冗長な機能を追加してし

    まった ×不具合を見逃す可能性が高い。 結合テストより後はPO作成仕様に依存し ている。POが誤解していると、不具合と 認識できないテストアーキテクチャとなっ ている ・スプリントレビューの実施者にユーザ に精通したステークホルダを加える ・ユーザテスト工程を設ける 性能要求について、POは必要な要求と 認識していたが、不注意でユーザストー リー(仕様)として明文化ができていな かったため、開発者が性能要求に気づけ なかった。結果としてその性能要求が未 達成のサービスを開発してしまった ◦対応できる可能性が高い POがサービスを確認するスプリントレ ビューが設けられている。POが正しく要 求を認識しているならば、そこで問題は 検出される 問題なし
  51. テストアーキテクティングの進め方: アウトライン ◼テストアーキテクティングの全体像 ◼テストアーキテクティングの基本活動 • テストアーキテクチャ要求の分析 • ステークホルダ分析/要求・制約の分析 • テストアーキテクチャの設計

    • テストアーキテクチャの設計 • 関係者との調停/テスト担当者とのすり合わせ • ★個人ワーク1 • テストアーキテクチャの評価と改善 • シナリオウォークスルー • ★個人ワーク2 ◼テストアーキテクティングの反復と維持活動 ◼テストアーキテクティングのテストへの展開
  52. テストアーキテクティングの反復による作りこみ ◼テストアーキテクティングの活動の中で、テストの要求・制約の追加変更、テスト 活動結果のフィードバックを継続的に監視し、それらに基づいてテストアーキテ クチャを維持・変更する トリガ 事例 対応方針 テストの要求の追加変更 開発途中の仕様変更 変更リスクへの対応方針の検討

    テストアーキテクチャの変更検討 テストの制約の変更 開発遅延によるテスト工数 削減 工数削減を加味したテストの責務調整 テスト削減に対するリスクコントロール手段を検討し組み込み テスト技術開発のフィード バック 自動化技術の獲得 テスト活動間の責務の比重の見直し(自動化比率を上げるなど) テスト活動失敗のフィード バック 許容できない欠陥の見逃し 判明 どのテスト活動で欠陥を検出すべきかを明確化し、それに応じた 責務調整 テストの網羅度目標の改善
  53. テストアーキテクチャの改善 ◼テストアーキテクチャの改善を継続的に行う • 要求制約の変更対応、問題対応、テスト技術獲得・改善 ◼時に必要に応じてリアーキテクティングやビッグリライトを実施する • タイミング: • レガシーなテストアーキテクチャの引継ぎ時 •

    抜本的なテスト技術の新導入 • テスト対象のリアーキテクティングやビッグリライトへの対応 • レガシーなテストアーキテクチャのリアーキテクティングでは、テストアーキテクチャのリバー スモデリングや設計根拠の具体化を、今回紹介したテストアーキテクチャの表現方法を 活用して実施する
  54. テストスケジュール テストアーキテクティングのテストへの展開 以後のテスト活動への展開 ◼マネジメントと連携し、テストアーキテクチャの発展原則や各テスト活動の実施 タイミングをスケジュールに反映する 結合テスト・スプリントテスト リリーステスト リリーステスト リリーステスト •施策HW環境の構築

    •試作基板環境の構築 •本番環境の構築 自動システム試験環境開発 テストアーキテクチャ 構築 施策環境向け 自動システム試験環境開発 エミュレータ 環境開発 ツールFS コンポーネントテスト・ 結合テスト 設計方針確立 テストアーキテクチャ PoC リリーステスト構築 リリーステスト構築 スプリントテスト確立