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

Transcript

1. テストを導くための テストアーキテクチャの 組み立て方 JaSST'21 Tokai 井芹 洋輝

2. このセッションの目的 ◼目的 • ユニットテスト、結合テスト、システムテストなどプロジェクト全体のテスト活動の方針立て を、アーキテクティングによって進めるアプローチについて学びます ◼想定対象 • ユニットテスト、結合テスト、システムテスト含む、ソフトウェアテストに関わるエンジニア

3. ワークショップについて ◼理解を深めるための簡単な個人ワークを用意しています • あわせて解答例を紹介します。各自考え合わせに活用ください • 予稿集に、ワーク、ワークのための解説、ワーク解答例を記載しています ワーク中の見直しなどで参照ください • 予稿集を手元にダウンロードください ◼図表がかけるツールを用意ください

   • 紙、MiroやPower Pointなど絵が描けるツール ◼資料は公開します • https://speakerdeck.com/goyoki/cetam • 予稿集にもURLを記載しています

4. 自己紹介 ◼現在 • 車メーカにてアジャイル開発のテストチームのテックリードを担当 • U30テスト設計コンテスト審査委員長、JSTQB技術委員 ◼製造業を中心にソフトウェアの開発、テスト、開発インフラ整備などに従事 開発チームリーダ、コンサル、テックリードさまざまな立場でテストアーキテクティ ングを手掛ける ◼主な著作・講演

   • 「システムテスト自動化標準ガイド」「実践ソフトウェアエンジニアリング第9版」 「テスト設計をより良くするモデリングと観点分析」など

5. プロジェクト全体のテスト活動を スコープとするテストアーキテクチャ 解説のターゲット 特定のテストレベルの テストアーキテクチャ 例：システムテスト特化の テストアーキテクチャ 黒背景色部分が今回の解説対象の中心 全体テスト計画・分析 全体テスト設計

   テストプロセス テスト計画・分析 テスト設計 テスト実装・環境構築 テスト実行

6. 解説するアプローチ：CETAM （Cooperative and Evolutionary Test Architecting Method） Cooperative テストのステークホルダやテスト担当者と協調し 妥当なテストを導く

   Evolutionary 開発ライフサイクルの状況に応じて テストを継続的に洗練させる

7. アウトライン ◼テストアーキテクチャとは • アーキテクチャ/テストアーキテクチャ ◼テストアーキテクチャの概要 • 役割/立ち位置/テストアーキテクト/アプローチ ◼テストアーキテクチャの表現 ◼テストアーキテクティングの進め方 •

   全体像/基本活動/反復/テストへの展開 • 個人ワーク1/個人ワーク2

8. テストアーキテクチャとは

9. アーキテクチャとは ◼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.」 (対象の環境におけるシステムの基本的な概念や特性を、システムの要素、関係、設計 原則・発展原則として具体化したもの)

10. テストアーキテクチャとは ◼国内外各所で使われている言葉 • 共通の定義を参照しているわけではないが、おおよそ似たような概念を示す • 表現方法には多数のバリエーションがある ◼テスト設計のアーキテクチャ • 「Test architecture

    is a big picture of test design」 • 「Test architecture is just architecture of test design」 • Software Test Architecture Design focusing on Test Viewpoints https://qualab.jp/materials/SOFTEC2012-2.pdf

11. 本解説におけるテストアーキテクチャの定義 ◼テストアーキテクチャ • テストアーキテクチャとは「テストをどう実現するか」の基本的な概念や特徴を、テストの要 素、関係性、設計原則・方針で表現したもの • ユニットテスト・結合テスト・システムテストなどプロジェクトのすべてのテスト活動を対象に含む • プロジェクト全体のテスト設計とテストシステム開発の工夫を、基本的なレベルで示すものである ◼テストアーキテクティング

    • テストアーキテクチャを実現し、検証し、改善・保守する活動全般 ◼テストアーキテクト • テストアーキテクティングを担当し、その成功を責務とするロール

12. テストアーキテクチャの姿：具体例(1/4)： 全体のテスト設計活動の目的や内容を導く テストレベル テスト対象の粒度 目的 サイクル・タイミング ユニットテスト ユニット ユニットのふるまいが正しいことを確認する CI（各ブランチ更新ごと）

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

13. テストアーキテクチャの姿：具体例(2/4)： 全体のテスト活動の構造を導く インテグレー ション 結合テスト システム テスト ユニット テスト 実装

    サービス デプロイ スプリント テスト スプリント(2週間)ごとに実施 リリースごとに実施 CIとして実施 セキュリティ テスト 全体のテスト活動の関係性や依存関係を明確化する

14. テストアーキテクチャの姿：具体例(3/4)： 全体のテスト活動の横断的方針や連携を導く リスク リスク レベル テストでの対策 遠隔アップロード機能の不正利用によるソフトウェア の不正書き換え 6 認証機能評価：システムテスト

    OS設定およびコンフィグレーション評価：セキュリティテスト 全体のセキュリティアセスメント：SQA監査 シャッター制御過剰制御による駆動部分の劣化の 加速 4 システムテストで対応 加速度テスト、ロングランテストでテストする 課題やリスクに対してテスト活動をどう連携するか、どのような方針で実行するかを明確化する

15. テストアーキテクチャの姿：具体例(4/4)： 全体のテストシステムの基本設計を導く 制御 PC テスト 対象 モニタ撮影 装置 被写体 モデル

    タッチパネル エミュレータ テスト管理 サーバ CIサーバ テストドライバ CI クライアント DIO コンバータ SDカード マルチプレクサ 映像/USB-C 必要なテストシステムのアーキテクチャを明確化する テストシステム 使用するテスト システムテスト自動化環境 自動システムテスト スモークテスト レフ制御耐久テスト環境 レフ制御耐久テスト Rustユニットテスト環境 MMアプリユニットテスト ・・・ テストアーキテクチャは テスト設計活動の要素、要素の構造、 要素の連携、要素が必要とする環境 で主に表現する

16. テストアーキテクチャの姿： 開発スタイルに応じた形式で表現する ◼テストアーキテクチャ、テストアーキテクティングは、アジャイル/ウォータフォール、 小規模開発/大規模開発など問わず、どの開発スタイルでも有効 ただし開発スタイルに応じて、成果物の表現形式が変わる • 少人数の軽量な開発の場合： • チームメンバー間の方針共有を重視し、テストアーキテクチャの文書化は必要度に応じて最適化する •

    大規模開発の場合： • 重厚なコミュニケーションを支えるため、詳細にテストアーキテクチャ文章を構築・維持する

17. アウトライン ◼テストアーキテクチャとは • アーキテクチャ/テストアーキテクチャ ◼テストアーキテクチャの概要 • 役割/立ち位置/テストアーキテクト/アプローチ ◼テストアーキテクチャの表現 ◼テストアーキテクティングの進め方 •

    全体像/基本活動/反復/テストへの展開 • 個人ワーク1/個人ワーク2

18. テストアーキテクチャの概要

19. 今、テストアーキテクティングの工夫が求められる背景 ◼様々なテスト活動を高度に連携させ、開発全体で優れた価値創造やアジリティ を実現する開発スタイルが求められている • 【継続的デリバリ、DevOps】様々なテストを包含するデプロイメントパイプラインを洗練さ せ、開発とビジネスの距離を縮める • 【アジャイル】自動・手動テストを組み合わせ、継続的かつ高速なリリース&フィードバック を実現する ◼創発的・イテレーティブなテスト構築アプローチが求められている

    • 【アジャイル】イテレーションごとにテストを積み重ねつつ、全体の品質保証としての整合 性を確保し、プロダクトの品質を継続的に担保する →様々なテスト活動の総体をアーキテクチャとして扱い、アーキテクティングで その構造やメカニズムを工夫するアプローチが有効である

20. テストアーキテクティングの役割 ◼テストアーキテクチャの構築・維持を通して、次の状態を実現する： • プロジェクトの目的やステークホルダの要求にとって妥当なテストが分かり、 テストの困難な問題への解決策が明らかになっていて、 次にどのようなテスト設計・テストシステム構築を行えばよいかの方向性が見え、 かつテストの当事者がそれら方針に納得し推進しようとしている

21. テストアーキテクティングの役割：詳細 ◼ステークホルダやテスト担当者からのテストへのシーズ・要求・制約をすり合わ せし、妥当なテストの構築を導く ◼個々のテスト活動のみの努力では対応できない、困難な問題への対応方法を 編み出し、問題解決を導く ◼必要なテスト設計活動について、テスト担当者の納得を確保し、テスト設計活 動が円滑に遂行されるようにする。チーム全体アプローチを実現する ◼開発ライフサイクルの中でのテストの要求・制約の流動的な変化に対応し、テ ストを先導し続ける テストアーキテクティングは

    テストスキルとテスト技術の力を活かす問題解決ツールと 関係者の力を結集するコミュニケーションツールの 2つの役割をこなす

22. 開発ライフサイクルの中でのテストアーキテクティング 継続実施しプロジェクトを導き続ける プロジェクト最初期 立ち上げ/初期計画立案 /体制構築 プロジェクト初期 各計画具体化/ PoC/開発開始 プロジェクト中期以降 開発本格化/保守・派生

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

23. テストプロセスとテストアーキテクティング 全体にわたってテストを導く 全体テスト計画・分析 全体テスト設計 テストプロセス ・テストアーキテクチャ要求の分析 ・テストアーキテクチャの設計 ・テストアーキテクチャの評価と改善 導く テスト要求・制約の発生・変更

    ビジネス/マネジメント/ 開発/品質保証/テスト テスト活動結果のフィードバック テスト計画・分析 テスト設計 テスト実装・環境構築 テスト実行

24. テストアーキテクティングはEnough Design Up Front ◼テストアーキテクティングはEnough Design Up Front(EDUF) • 最大責任時点（Most

    Responsible Moment。対象活動が最も責務を果たせるタイミン グ）で各テストアーキテクティング作業を実施する ◼テストアーキテクティングは、不確実で変化の多いプロジェクトの中で、適時に 適切な活動を実施し、テストをどう育て・適応させていくか、継続的に導く ◼継続的に洗練させながら、その時にとってのあるべきテストの実現を目指す

25. 品質保証とテストアーキテクティング 品質エンジニアリングの一部として実施する ◼テストアーキテクティングはQAアーキテクティングの一部 ◼品質エンジニアリングの一部として、品質マネジメントや他のQA活動と連携し ながら推進する • プロセス監査、品質管理、設計の工夫、ドキュメントレビューなど、他の品質エンジニアリ ングと連携して、全体の品質エンジニアリングを支える

26. テストアーキテクティングの担い手：テストアーキテクト ◼テストアーキテクト：テストアーキテクティングを担当し、その成功を責務とする ◼テストアーキテクトは、プロジェクトのすべてのテスト活動について裁量を行使で きるのが理想 • ただし、体制的・裁量的・能力的な制約により、現実で実現するのは難しい • 実際は、プロジェクト責任者の後押しに基づいて、各テストの責任者のすり合わせをファ シリテートしながら、活動を実現することが多い •

    マネージャやQAエンジニアが担う場合も多い

27. テストアーキテクトのアンチパターン： 象牙の塔のアーキテクト ◼閉じこもってアーキテクチャを考え、トップダウンで現場にアーキテクチャを指示 するアーキテクト • 背景 • 教条やパターンへの狂信、権威主義 • テスト上流活動と現場の断絶

    • 外部リソースへのアーキテクティングの丸投げ • 属人的要因 ◼現場の制約に対応できず、納得を得られず、チームのアーキテクティング力を 伸ばせず、結果として現場の力を活かせずにテストの失敗を誘発する 適切なコミュニケーションを通して テスト関係者の納得を確保しながら、協力と連携を引き出すのは テストアーキテクティングの不可欠な活動

28. テストアーキテクティングのアプローチ： ２つのすり合わせ ◼様々なステークホルダと相互にすり合わせして妥当なテストを実現する ◼様々なテスト担当者と協力して、集合知を活用するアプローチでテストアーキテ クチャを構築する テストアーキテクティング 開発 ビジネス マネジメント 品質保証

    テスト テスト担当者 テスト担当者 テスト担当者

29. テストアーキテクティングのすり合わせの例： 組織設計のすり合わせ ◼前提：組織構造とテストアーキテクチャは強い相互依存関係をもつ （例：コンウェイの法則） • →テストアーキテクティングであるべき組織要求を示し、時には組織設計を代行する テストアーキテクティング マネジメント テスト テスト担当者

    テスト担当者 テスト担当者 テストアーキテクチャに必要な組織要求を提示する 結果としての組織構造を制約として示す 実際の組織を活用するようにテストを導く ※組織設計はマネジメントの作業

30. テストアーキテクティングのすり合わせの例： 試験性（テスタビリティ）の確保のすり合わせ ◼前提：試験性がテストアーキテクチャの選択肢に直結する （例：テスト自動化が容易なら、テスト自動化が選択肢として有効になる） • →あるべきテストアーキテクチャ実現のために必要な試験性確保を、開発に働きかける 時に試験性の設計や実装を提示する テストアーキテクティング 開発 テスト

    テスト担当者 テスト担当者 テスト担当者 試験性要求を示す 結果として実現した試験性を 制約として提示する 実現した試験性を活用するようにテストを導く

31. テストアーキテクティングでの設計技術の活用 アーキテクティングの技術でテストをより良くする ◼テストの責務についての関心事の分離/モジュール性改善の推進 • テストの責務を分割し、テスト要求・テスト観点を扱える粒度まで細分化する • テスト設計活動を円滑に推進できるように、テストの責務配置の凝集性を高める ◼全体整合性の確保/テストパイプラインの最適化 • 様々なテスト活動を重ね合わせ・分業させ、テストの有効性・網羅性を実現する

    • テスト活動のムリ・ムダ・ムラをなくす ◼中長期視点のライフサイクル設計 • 開発ライフサイクルでテストをどう育て、拡張させていくかの設計戦略を構築し、テストの適時性を確保する ◼構造的工夫によるテスト技術/テストリソース活用の拡大 • 有益なテスト技術/テストリソースの適用範囲を拡大する ◼テストの保守性の作りこみ • テストの評価容易性、変更容易性、再利用性、解析性を支える設計を組み込み、テストアーキテクチャの評価・ 維持・改善を効率化する ◼テストシステムの品質の作りこみ • テストシステムに性能効率性や信頼性、保守性など品質を支える設計を組み込み、テストの適時性や信頼性を 改善する

32. アジャイル開発でのテストアーキテクティング ◼アジャイルでは反復的な開発アプローチの中でテストの整合性を維持する必要 があるため、テストアーキテクティングが重要になる ◼アジャイルでのテストアーキテクティングの方針 • アジャイルの原則・アプローチに従う • テストの基本原則・基本構造を確立し、それに沿った形でインクリメンタルにテストを増 築していく（イテレーションごとのテストを乱雑に蓄積するのを避ける） •

    アジャイルチームのテストアーキテクティング能力を伸ばし、チームが自律的にテストアー キテクティングを行う流れを強化する • テストアーキテクチャの崩壊の監視と予防活動（テストの技術的負債の適時の回収など） • テストの基本原則・構造の推進と改善

33. アウトライン ◼テストアーキテクチャとは • アーキテクチャ/テストアーキテクチャ ◼テストアーキテクチャの概要 • 役割/立ち位置/テストアーキテクト/アプローチ ◼テストアーキテクチャの表現 ◼テストアーキテクティングの進め方 •

    全体像/基本活動/反復/テストへの展開 • 個人ワーク1/個人ワーク2

34. テストアーキテクチャの表現

35. テストアーキテクチャの表現 ◼アーキテクチャの表現 • アーキテクチャは様々な特性を備えていることから、複数のアーキテクチャ観点でみた複 数の側面で表現する • アーキテクチャ観点は、少なすぎず、多すぎない数を、重要性に基づいて選択する • 例：RUP4+1、ArchiMate ◼テストアーキテクチャを表現する観点

    主要なテストアーキテクチャ観点 このパートで紹介する主な表現手法 テストアーキテクチャの構成要素 責務構造ツリー テスト責務管理表 テストアーキテクチャの構造 パイプラインモデルとシナリオ記述 テストアーキテクチャの環境 （テストシステムの環境設計） テストアーキテクチャの連携 （要求に応じた表現手法） テストアーキテクチャの発展原則

36. テストアーキテクチャの構成要素の表現： 責務構造ツリー（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、マインドマップなど他のツリーモデリング記法でも代替可

37. テストアーキテクチャの構成要素の表現： 責務構造ツリー：例 デジタルカメラのテスト ユニットテスト・ コード解析 開発工程に対応して テストを実施する 結合テスト システム テスト

    開発組織に応じて テストを実施する 内製コンポーネントおよび システム結合以降のテスト 外製コンポーネントのテスト 開発会社ごとに受け入 れテストを実施する ユニットテスト ツリー MMシステム 受け入れテスト RTOS 受け入れテスト 結合テスト ツリー システムテスト ツリー システム アーキテクチャ

38. テストアーキテクチャの構成要素の表現： 責務構造ツリーを描く目的 ◼テストアーキテクチャの構成要素の根拠を明示する • 複雑・大規模なテストをどのように構成要素に分割したか ◼テスト責務をズームイン・ズームアウトで分析できるようにする • プロセスモデルを考えるときは抽象的なテストレベルで、テスト設計方針を考えるときは 具体的なテストタイプで ◼関心事の分離を行い、責務を扱えるサイズまで整理・分割する

39. 責務構造ツリー：基本記法 記法 説明 GSNでのGoal。テストアーキテクティングでは、テストの責務を示す。 具体的な単位として、テストレベルやテストタイプを記載する GSNでのStrategy。責務構造ツリーでは、上位の責務を下位に分解する方 針を示す GSNでのContext。責務や責務分解方針のコンテキスト（背景や根拠を示 す） GSNでのUninstantiated

    element。対象の責務がまだ具体化されていない （未完成）ことを示す GSNでのOff diagram decorator。他のツリーへの参照。グラフを分割すると きに用いる 責務 責務分解の方針 コンテキスト Off diagram その他、GSNの記法を利用可能 テストタイプ：コンポーネントやシステムのある特性に対応したテストの目的を基にテスト活動をまとめたもの(ISTQB Glossary) 性能テスト、単機能テスト、ユーザビリティテストなど

40. 責務構造ツリー：モデル構造 ユニットテスト・ コード解析 開発工程に対応して テストを実施する 結合テスト システム テスト 内製コンポーネントのテストおよび システム結合以降のテスト

    •上位のテストの責務を、下位のテストの責務に分割する •ひし形Strategyで、「どう分割したか」を明記する •テストアーキテクティングでは、テストの責務はテストレベル・ テストタイプの粒度で記載

41. テストアーキテクチャの構成要素の表現： テスト責務管理表 ◼テスト活動の責務の情報をまとめた表 • アーキテクチャレベルのテストの構成要素（テストレベル・テストタイプ）ごとに、目的、担 当組織、タイミング、その他任意の追加情報を記載する テストの責務 目的 内容 作成担当

42. テスト責務管理表：例 テストレベル テスト対象のレベル 目的 タイミング ユニットテスト ユニット ユニットのふるまいが正しいことを確認する ・・・ 結合テスト

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

43. テストアーキテクチャの構造の表現： パイプラインモデルとシナリオ記述 ◼デプロイメントパイプラインモデルでテストを含むプロセスをモデリングする • 重ね合わせ、連携、分担など、テストアーキテクティングの工夫の表現に適している インテグレー ション 結合テスト リリース テスト

    ユニット テスト 実装 サービス デプロイ スプリント テスト スプリント(2週間)ごとに実施 リリースごとに実施 スプリント レビュー CIとして実施

44. テストアーキテクチャの構造の表現： パイプラインモデルとシナリオ記述 ◼シナリオ記述：具体的なシチュエーションごとのパイプラインのふるまいを記述 する • テストアーキテクチャはプロジェクト状況に応じて変動するパラメータを持つ パイプラインでモデル化する際はシナリオ記述による場合分け記述が有効 シナリオ ユニットテスト 結合テスト

    システムテスト スプリント内テスト 全実行 全実行 追加変更分に対するテスト＋影響範囲のリグ レッションテスト リリース時テスト 全実行 全実行 全実行 hotfix時テスト 全実行 全実行 追加変更分に対するテスト＋影響範囲のリグ レッションテスト インテグ レーション 結合テスト システム テスト ユニット テスト 実装 リリース

45. テストアーキテクチャの表現： テストアーキテクチャへの要求に応じたモデリングを行う ◼アーキテクチャ観点は様々。テストアーキテクチャへの要求に基づいて、アーキ テクチャ観点を選択し、各観点ごとにテストアーキテクチャを表現する テストアーキテクチャ要求の例 テストアーキテクチャ要求に対応するモデル・表現方法 様々なテストベースの実現性保証 各テストベースとテストレベル・テストタイプのマッピング 想定される欠陥の検出 検出したい欠陥タイプとテストタイプのマッピング

    品質レベルがリリースできる水準であること の確認 品質リスク分析（テストアーキテクチャがリスクに対応できているか） 推測されるプロジェクトトラブルへの対応 プロジェクトリスク分析（テストアーキテクチャがリスクに対応できているか） 開発スケジュールに応じたテストアーキテク チャの段階的拡張 テストアーキテクティングのスケジューリング 必要なテスト環境リソースの識別 テストシステムの構造アーキテクチャ設計

46. アウトライン ◼テストアーキテクチャとは • アーキテクチャ/テストアーキテクチャ ◼テストアーキテクチャの概要 • 役割/立ち位置/テストアーキテクト/アプローチ ◼テストアーキテクチャの表現 ◼テストアーキテクティングの進め方 •

    全体像/基本活動/反復/テストへの展開 • 個人ワーク1/個人ワーク2

47. テストアーキテクティングの 進め方

48. テストアーキテクティングの進め方： アウトライン ◼テストアーキテクティングの全体像 ◼テストアーキテクティングの基本活動 • テストアーキテクチャ要求の分析 • ステークホルダ分析/要求・制約の分析 • テストアーキテクチャの設計

    • テストアーキテクチャの設計 • 関係者との調停/テスト担当者とのすり合わせ • ★個人ワーク１ • テストアーキテクチャの評価と改善 • シナリオウォークスルー • ★個人ワーク2 ◼テストアーキテクティングの反復と維持活動 ◼テストアーキテクティングのテストへの展開

49. テストアーキテクティングの進め方： アウトライン ◼テストアーキテクティングの全体像 ◼テストアーキテクティングの基本活動 • テストアーキテクチャ要求の分析 • ステークホルダ分析/要求・制約の分析 • テストアーキテクチャの設計

    • テストアーキテクチャの設計 • 関係者との調停/テスト担当者とのすり合わせ • ★個人ワーク１ • テストアーキテクチャの評価と改善 • シナリオウォークスルー • ★個人ワーク2 ◼テストアーキテクティングの反復と維持活動 ◼テストアーキテクティングのテストへの展開

50. テストアーキテクティングの全体像： 継続実施しプロジェクトを導き続ける プロジェクト最初期 立ち上げ/初期計画立案 /体制構築 プロジェクト初期 各計画具体化/ PoC/開発開始 プロジェクト中期以降 開発本格化/保守・派生

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

51. テストアーキテクティングの全体像： テストプロセスの中での立ち位置 全体テスト計画・分析 全体テスト設計 テストプロセス ・テストアーキテクチャ要求の分析 ・テストアーキテクチャの設計 ・テストアーキテクチャの評価と改善 導く テスト要求・制約の発生・変更

    ビジネス/マネジメント/ 開発/品質保証/テスト テスト活動結果のフィードバック テスト計画・分析 テスト設計 テスト実装・環境構築 テスト実行

52. テストアーキテクティングの進め方： アウトライン ◼テストアーキテクティングの全体像 ◼テストアーキテクティングの基本活動 • テストアーキテクチャ要求の分析 • ステークホルダ分析/要求・制約の分析 • テストアーキテクチャの設計

    • テストアーキテクチャの設計 • 関係者との調停/テスト担当者とのすり合わせ • ★個人ワーク１ • テストアーキテクチャの評価と改善 • シナリオウォークスルー • ★個人ワーク2 ◼テストアーキテクティングの反復と維持活動 ◼テストアーキテクティングのテストへの展開 テストアーキテクチャ要求分析 テストアーキテクチャ設計 テスト戦略・方針の策定 設計 連携設計 責務分割 構造設計 環境設計 すり合わせ 評価と改善

53. テストアーキテクチャ要求の分析 ◼テストアーキテクチャへのニーズ・シーズ・制約を分析する • テストの要求・制約のうち、テストアーキテクチャに影響するものを分析する • テストの要求・制約の詳細な分析は、各テストレベルのテスト分析で実施 • 特にASR(Architecturally significant requirements。アーキテクチャに重要な影響を与

    える要求)の識別に注力する • ASRがテストアーキテクチャの基本構造・基本方針を決定する。これをミスすると後からのリカバリが大 変になる ◼構成作業 1. ステークホルダの分析 2. テストアーキテクチャ要求の収集と分析

54. テストアーキテクチャ要求の分析 ステークホルダの分析 ◼テストアーキテクチャはビジネス、開発、マネジメント、品質保証、テストを横断 幅広くステークホルダを洗い出す カテゴリ ステークホルダ 概要 重要度 影響度 テストへの主な関心事

    製造 生産技術 製造技術の確立と改善 B B 検査技術の開発と導入 製造者 製品の組み立て A B 製造時チェックの効率化 製造検査 製品の最終品質保証 A A 製造検査の効率化 ユーザ 専属プロ 継続契約の製品評価プロ B B ブランドシリーズ特有の利用時品質の 保証 契約評価者 ユーザバリデーションの選出ユーザ B C 各カテゴリの利用時品質の保証 プロ/ハイアマチュア 製品のプロおよびハイアマチュアユーザ B B プロユースを満たす品質の保証 エントリユーザ 製品の入門ユーザ A B 初心者向けの利用時品質の保証 品質保証 法規/法務 法規制、規格、標準の適合保証 A A 法規制、規格、標準の事前適合評価 および一部評価代行 品質管理 プロジェクトの継続的な品質管理 C B テストにかかわる品質保証の提出 ソフトウェア品質保証 ソフトウェアのリリース時品質保証 A A ソフトウェアのリリース時の品質保証 ・・・ (1-1)ステークホルダ抽出 (1-2)ステークホルダ分析

55. テストアーキテクチャ要求の分析： テストアーキテクチャ要求の収集と分析 ◼ステークホルダからテストアーキテクチャへのニーズ・シーズを収集し、分析する テストアーキテクティング 開発 ビジネス マネジメント 品質保証 テスト

56. テストアーキテクチャ要求の分析： テストアーキテクチャ設計と行き来する ◼要求分析により設計を駆動し、設計の方向づけに合わせて要求を深掘りする • テストアーキテクチャ要求は巨大で流動的であり、最初から全てをやりきれない 全てをシーケンシャルプロセス的に分析しようとするとASRが埋没する テストアーキテクチャ要求分析 テストアーキテクチャ設計 要求・制約に基づいて設計を進める 設計の方向づけに合わせて要求分析を深掘りする

57. テストアーキテクチャ要求の分析 テストアーキテクチャ要求の収集と分析 ◼重要度に応じてテストアーキテクチャ要求を分析する • テストアーキテクチャを取り巻く要求は膨大。全体俯瞰の分析観点と重点部分を深掘り する分析観点を組み合わせて、テストアーキテクチャに必要な情報を獲得する 重視する目的の例 目的に対応したテストアーキテクチャ要求分析の重要点 必要なテストレベルを識別する 開発プロセス分析、テストベース分析、テスト対象のアーキテクチャ分析

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

58. テストアーキテクティングの進め方： アウトライン ◼テストアーキテクティングの全体像 ◼テストアーキテクティングの基本活動 • テストアーキテクチャ要求の分析 • ステークホルダ分析/要求・制約の分析 • テストアーキテクチャの設計

    • テストアーキテクチャの設計 • 関係者との調停/テスト担当者とのすり合わせ • ★個人ワーク１ • テストアーキテクチャの評価と改善 • シナリオウォークスルー • ★個人ワーク2 ◼テストアーキテクティングの反復と維持活動 ◼テストアーキテクティングのテストへの展開 テストアーキテクチャ要求分析 テストアーキテクチャ設計 テスト戦略・方針の策定 設計 連携設計 責務分割 構造設計 環境設計 すり合わせ 評価と改善

59. テストアーキテクチャの設計 ◼テストアーキテクチャ要求を実現するテストアーキテクチャ設計を具体化する そして以降のテスト設計活動を遂行可能にする ◼構成作業 戦略立てし、 設計して、 内外とすり合わせし洗練させる テストアーキテクチャ設計 テスト戦略・方針の策定 設計

    連携設計 責務分割 構造設計 環境設計 すり合わせ

60. テストアーキテクチャの設計 テスト戦略・方針の策定 ◼テストアーキテクチャ設計を含む、テスト全体の戦略を具体化し、テストアーキテ クチャ設計を方向づけする • 重要な要求に基づく戦略で、テストアーキテクチャの基本骨格を構築する • 後付けで対応困難な問題対応を適時のタイミングで実施する • 重大なアーキテクティングの誤りを避ける

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

61. テストアーキテクチャの設計 テスト戦略・方針の策定 ◼テストアーキテクチャ設計を含む、テスト全体の戦略を具体化し、テストアーキテ クチャ設計を方向づけする • テスト戦略を実行可能なテストアーキテクティング方針に具体化する テスト戦略 テストアーキテクティング方針 テスト自動化（実行および生成の自動化）の 促進により、変更対応を効率化する

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

62. テストアーキテクチャの設計 ◼戦略、方針に従ってテストアーキテクチャ要求の実現手段を具体化する テストアーキテクチャ設計 テスト戦略・方針の策定 設計 連携設計 責務分割 構造設計 環境設計 すり合わせ

63. テストアーキテクチャの設計 •Must要求 実現しなければならないテスト •Want要求 実現したいテスト ※テストアーキテクチャ要求分 析で明らかにする •チームができるテスト ※テストアーキテクチャ要求・制約 分析で明らかにする

    •チームができるようになる見 込みのテスト ※マネジメントとの連携およびテス ト活動の反復で実現の見通しを明 らかにする •チームができるテストの代替 手段 ※マネジメント・品質保証・開発と の連携で実現の見通しを明らかに する 関心事の分離（責務分割）、 連携検討、構造設計を通して、 テストアーキテクチャを導出

64. 【閑話】チームが遂行可能なテストタイプ（テストケイパビリティ） を日頃から蓄積する ◼日頃の技術蓄積がテストアーキテクチャの選択の幅を左右する ◼チームの技術資産として、遂行可能なテストタイプを蓄積していこう モータ制御の正確性テスト 性能計測 イーサネットのペネトレーションテスト 静的解析 機械制御のロードテスト 機械制御のロードテスト

    ウェブサービスのストレステスト OSS脆弱性評価 機能調停の組み合わせテスト ハードウェア互換性テスト UXバリデーション 障害注入テスト マニュアル合致性テスト 耐タンパ性評価 資源効率性評価 アクセシビリティ評価 ビジュアルテスト 障害回復性テスト

65. 【閑話】テストアーキテクティングでチームのテスト技術向上の 段取りを具体化する ◼マネジメントと折衝し、フィージビリティスタディフェーズの確保、必要な人材の 獲得などを働きかける ◼反復プロセスなど、成長サイクルを確保する仕組みを導入する ◼そしてチームの技術を高めて、テストアーキテクチャの選択肢を増やす

66. て テストアーキテクチャの設計 どこまで設計するか ◼テストアーキテクチャの構成要素は、テ スト設計活動をある程度独立して進め られる単位まで細分化する • 定番の単位：テストレベル、テストタイプ テスト全体 テストタイプ

    テストタイプ テストレベル テストレベル テスト分析 テスト設計 テスト実装 テスト分析 テスト設計 テスト実装 以降の活動

67. 【閑話】テストアーキテクチャの設計： テストレベルの設計アプローチ ◼テストレベルの導出 1. 開発プロセスおよびアーキテクチャの分析を通して導出する • 工程、テストベース種別、アーキテクチャ構成に対応するテストを候補に導出する 2. 課題・リスクのコントロールを観点に導出する •

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

68. 【閑話】テストアーキテクチャの設計： テストタイプの設計アプローチ ◼テストレベルに応じた導出アプローチをとる • テストレベルごとにテストタイプ設計アプローチは全く異なる • アンチパターン：全テストレベルに、ISO/IEC 25010の品質特性を一律適用して導出 • 事前準備として、テストタイプを導出しやすいように、テストレベルや上位テストタイプで

    「関心事の分離」「テスト責務の凝集性の確保」を実施するのが重要 ◼例：システムテストのテストタイプの導出 • 仕様の種別、仕様の構造（例：ラルフチャート）、仕様に関係する品質特性を切り口に分 析する その3つの切り口で、システムテスト全体の責務を、テスト設計活動がやりやすいように 凝集性を確保しながら分割し、テストタイプにする • アンチパターン： ISO/IEC 25010の品質特性をそのまま適用 • VSTePでのテストコンテナ設計など、テストの上流設計手法を活用できる

69. テストアーキテクチャの設計 「最初の一歩」の設計アプローチ ◼パターンベース • 問題・コンテキスト・フォースに合致する、成功したテストアーキテクチャパターンを用いて 設計する ◼経験ベース • 過去の成功したテストアーキテクチャ構造を参考にして設計する ◼標準・方法論ベース

    • テストアーキテクティングに関わる標準や方法論に基づいて設計する ◼集合知ベース • 様々なテスト関係者の知見を積み上げ、構造化してアーキテクチャ構造を得る

70. テストアーキテクチャの設計 3つの設計詳細化アプローチ ◼責務分割による導出 • 全体の責務を個別対応可能な粒度まで分割し、テスト アーキテクチャの構成要素と構造を導出する ◼連携設計による導出 • 方針、課題、リスクに対して、どのような連携をするか設計 する過程で、テストアーキテクチャの構成要素と構造を設

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

71. テストアーキテクチャの設計 責務分割 ◼テストの責務を実行可能な粒度まで分割する テストアーキテクチャ設計 テスト戦略・方針の策定 設計 連携設計 責務分割 構造設計 環境設計

    すり合わせ デジタルカメラのテスト ユニットテスト・ コード解析 開発工程に対応して テストを実施する 結合テスト システム テスト 開発組織に応じて テストを実施する 内製コンポーネントおよび システム結合以降のテスト 外製コンポーネントのテスト 開発組織ごとに受け入 れテストを実施する MMシステム 受け入れテスト RTOS 受け入れテスト

72. テストアーキテクチャの設計： 連携設計 テストアーキテクチャ設計 テスト戦略・方針の策定 設計 連携設計 責務分割 構造設計 環境設計 すり合わせ

73. テストアーキテクチャの設計： 連携設計 ◼テストアーキテクチャ要求に基づいて、テスト活動をどう連携させるか設計する 連携の設計を通してテストアーキテクチャの構成要素を検討する • 特に影響が重大なASRに基づいて、テストアーキテクチャの骨格を構成する テストアーキテクチャ要求の種類の例 テストアーキテクチャ要求に対応した設計作業 様々なテストベースの実現性保証 各テストベースとテストレベル・テストタイプのマッピング

    想定される欠陥の検出 検出したい欠陥タイプとテストタイプのマッピング 品質レベルがリリースできる水準であること の確認 品質リスク分析 推測されるプロジェクトトラブルへの対応 プロジェクトリスク分析 開発スケジュールに応じたテストアーキテク チャの段階的拡張 テストアーキテクティングの発展原則の具体化

74. テストアーキテクチャの設計： 連携設計 ◼テストアーキテクチャ要求に基づいて連携を設計する： 「リリース可能なリスクレベルまでリスクをコントロールする」 • リスクに対し、リスクコントロールを観点に必要なテスト活動と連携を設計する 方針 リスク レベル テストでの対策

    ユーザ評価によるモードUI変更の差し戻し 3 早期のユーザテストによるUI妥当性評価の前倒しを実施 ロボットによるUI自動テスト導入の失敗 4 反復テストによる早期のフィージビリティスタディを実施 マネジメントリスク リスク リスク レベル テストでの対策 遠隔アップロード機能の不正利用によるソフトウェアの不正 書き換え 6 認証機能評価：システムテスト 設定およびコンフィグレーション評価：セキュリティテスト 全体のセキュリティアセスメント：SQA監査 シャッター制御過剰制御による駆動部分の劣化の加速 4 システムテストで対応 加速度テスト、ロングランテストでテストする 品質リスク

75. テストアーキテクチャの設計： 構造設計 テストアーキテクチャ設計 テスト戦略・方針の策定 設計 連携設計 責務分割 構造設計 環境設計 すり合わせ

76. テストアーキテクチャの設計： 構造設計 ◼テストアーキテクチャの構造（依存関係、順序、関係性）を設計し、構成要素や 連携を導出する • 構造パターン：重ね合わせ、分業、横断的連携、繰り返し • 例：パイプラインモデル（orプロセスモデル）とシナリオ記述で構造を設計 インテグレー ション

    結合テスト システム テスト ユニット テスト 実装 サービス デプロイ スプリント テスト スプリント(2週間)ごとに実施 リリースごとに実施 CIとして実施 セキュリティ テスト シナリオ ユニットテスト 結合テスト スプリントテスト システムテスト セキュリティテスト スプリントリリース 全実行 全実行 全実行 実施しない 実施しない 通常デプロイ 全実行 全実行 全実行 全実行 全実行 Hotfix&デプロイ 全実行 全実行 全実行 追加変更分に対するテスト＋影 響範囲のリグレッションテスト リスクベースドテスト

77. テストアーキテクチャの設計： 環境設計 テストアーキテクチャ設計 テスト戦略・方針の策定 設計 連携設計 責務分割 構造設計 環境設計 すり合わせ

78. テストアーキテクチャの設計： 環境設計 ◼テストアーキテクチャ要求に基づいてテストシステムの基本設計を行う • テストアーキテクティング要求対応に注力。詳細なテスト環境設計は各テストレベルで実施 • OOD、SysML/UMLなどシステムやソフトのアーキテクチャ設計手法を活用できる 制御 PC テスト

    対象 モニタ撮影 装置 被写体 モデル タッチパネル エミュレータ テスト管理 サーバ CIサーバ テストドライバ CI クライアント DIO コンバータ SDカード マルチプレクサ 映像/USB-C •必要なテストシステムを識別する テストシステム 使用するテスト システムテスト自動化環境 自動システムテスト スモークテスト レフ制御耐久テスト環境 レフ制御耐久テスト Rustユニットテスト環境 MMアプリユニットテスト ・・・ •テストアーキテクチャ要求に対応する テストシステムを具体化する

79. テストアーキテクチャの設計：環境設計： テスト設計とテスト環境設計は不可分 ◼テストアーキテクティングにおいて、テストシステム設計とテスト設計は一緒に検討し なければならない • テスト自動化やCI/CDインフラ、IasC、仮想化をはじめとした現代のテストシステムの技術は、テ スト設計の進め方に強く影響する • 例：キーワード駆動テスト •

    また上記の技術の活用の程度が、テストの生産性に直結する。そのためテスト活動の責務設計 の重要な判断基準となる ◼例：テスト自動化の活用 • 前提 • テスト自動化ツールの指定する形式に合わせてテスト設計方針を立てなければならない • ROIに優れた自動テストの責務を増やすテストアーキテクチャ設計が有効になる • テストアーキテクチャ設計での必要なアクション • テストシステム設計を通して自動化ツールを明確化。ツールにあったテスト設計方針を具体化する • テストシステム設計を通してテストのROIを明確化。それに沿ってテストの責務設計を調整する

80. テストアーキテクチャの設計 テストアーキテクチャの詳細定義 ◼テストアーキテクチャの構成要素や連携の詳細を具体化する テストレベル テスト対象の粒度 目的 サイクル・タイミング ユニットテスト ユニット ユニットのふるまいが正しいことを確認する

    CI・各ブランチ更新ごとに実施 結合テスト コンポーネントセット システム コンポーネントセットのふるまいが正しいことを確認する インテグレーションが適切なことを確認する CI・メインブランチ更新ごとに実 施 ・・・ テストタイプ 詳細テストタイプ 目的 内容 作成担当 機能テスト フィーチャテスト フィーチャ仕様が実現されていること を確認する フィーチャ単位にフィーチャ仕様とソ フトウェアの合致性を確認 テストチーム フィーチャ調停テスト 複数のフィーチャを組み合わせたとき の調停処理が正しいか確認する フィーチャ調停仕様とソフトウェアの 合致性を確認する テストチーム セキュリティ テスト APIペネトレーションテスト リスクの高い攻撃手法でAPIを攻撃 し、脆弱性がないことを確認する APIについての既知の攻撃手法で 攻撃を試みる セキュリティテス ト ・・・ テストレベル管理表 システムテスト・テストタイプ管理表

81. 個人ワーク1

82. 【個人ワーク1】テストの責務構成の明示 ◼背景 • カメラの開発プロジェクト • テストタイプ「完成品に対するユーザビリティテスト」のテスト設計方針を検討している ◼ワーク課題 • テストタイプ「完成品に対するユーザビリティテスト」がどのような詳細なテストタイプで構 成されているかモデリングする

    • 責務構造ツリーを作成する ◼目的 • 「完成品に対するユーザビリティテスト」がどのようなテストタイプで細分化できるか、全体 像をわかりやすく共有可能にする

83. 【個人ワーク1】テストの責務構成の明示 ◼「完成品に対するユーザビリティテスト」についての要求： • 外部評価者および内部テストチームで対応する必要がある • 外部評価者によるテスト：複数のタイプの評価者ごとにテストを実施。以下が必要 • ユーザテスト：選出した想定ユーザに基本的なユーザビリティを評価してもらう • 専属プロテスト：継続契約している専属プロに評価してもらう

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

84. 個人ワーク1 解答例

85. 【個人ワーク1】テストの責務構成の明示 解答例（一例です） アクセシビリティ テスト エキスパート テスト ブランディング レビュー ユーザテスト ユーザビリティ

    ガイドライン テスト 内部ユーザビリ ティテスト テストベースごとに テストする 専属プロ テスト 内部テストチーム によるテスト 外部評価者に よるテスト 完成品に対する ユーザビリティテスト 内部テストチーム、外部評 価者それぞれでテストする 異なる種別の ユーザごとにテストする

86. テスト担当者とのすり合わせ/ステークホルダとのすり合わせ テストアーキテクチャ設計 テスト戦略・方針の策定 設計 連携設計 責務分割 構造設計 環境設計 すり合わせ

87. テスト担当者とのすり合わせ/ステークホルダとのすり合わせ ◼テストアーキテクチャ構成要素の担当者とのすり合わせで、テストアーキテク チャの調整と詳細化を行う ◼ステークホルダとのすり合わせで、テストアーキテクチャの妥当性を高める

88. テスト担当者とのすり合わせ/ステークホルダとのすり合わせ テスト担当者とのすり合わせ ◼各テストの責任者や専門家とすり合わせ、テストアーキテクチャ設計を必要な 水準まで作りこむ ユニットテスト 動的・静的それぞれで テストする 動的解析 静的解析 ユニットテスト・コード解析

    静的要求タイプごとに テストする コーディング 規約チェック ハイリスクな コード解析

89. テスト担当者とのすり合わせ/ステークホルダとのすり合わせ ステークホルダとのすり合わせ ◼テストアーキテクトとステークホルダで相互に要求・制約をすり合わせ、プロジェ クトの要求・制約を満たす妥当なテストアーキテクチャを実現する すり合わせ相手 すり合わせ内容 ビジネス ビジネス・ユーザ要求、ビジネス成否、テストのフィージビリティ マネジメント コスト、リソース、スケジュール、スコープ、体制

    開発 テスタビリティ、アーキテクチャ、インテグレーション、開発プロセス、 テストベース、開発技術 品質保証 テストの代替・補完手段、品質マネジメント テスト テストアーキテクチャ（各テストの目的、設計方針、担当など） テスト活動のフィードバック、テスト技術

90. テスト担当者とのすり合わせ/ステークホルダとのすり合わせ トレードオフの調整 ◼テストアーキテクチャ比較や、トレードオフ分析で妥当なテストアーキテクチャを 分析し、妥協点を導く • 比較やトレードオフ評価のアプローチ： • GQM法などメトリクス指標の抽出 • ATAM、意思決定マトリクス、Pros/Cons

    評価指標 フレームワークAベース フレームワークBベース 構築容易性 ＋＋ ＋ 保守性 ＋ ＋＋ ツールロックインの低さ ー ー－ パフォーマンス ＋ ＋ ・・・

91. テストアーキテクティングの進め方： アウトライン ◼テストアーキテクティングの全体像 ◼テストアーキテクティングの基本活動 • テストアーキテクチャ要求の分析 • ステークホルダ分析/要求・制約の分析 • テストアーキテクチャの設計

    • テストアーキテクチャの設計 • 関係者との調停/テスト担当者とのすり合わせ • ★個人ワーク１ • テストアーキテクチャの評価と改善 • シナリオウォークスルー • ★個人ワーク2 ◼テストアーキテクティングの反復と維持活動 ◼テストアーキテクティングのテストへの展開 テストアーキテクチャ要求分析 テストアーキテクチャ設計 テスト戦略・方針の策定 設計 連携設計 責務分割 構造設計 環境設計 すり合わせ 評価と改善

92. テストアーキテクチャの評価と改善 ◼設計したテストアーキテクチャを評価し、そのフィードバックを使って洗練させる ◼テストアーキテクチャの評価のタイミングは2つに大別される • テストアーキテクチャ設計時の評価（事前評価） • テスト活動実施後の評価（事後評価） ◼テストアーキテクチャの評価手段は目的や要求に対応して選出する • 「重大な欠陥の流出を予防したい」

    • テストアーキ設計時評価： 欠陥発生についてのシナリオウォークスルー • テスト実行後評価： 欠陥流出率の評価

93. テストアーキテクチャの評価と改善： アーキテクチャ設計時の評価手段 ◼計画立案時、設計初期時などプロジェクト初期に頼る検証手段（一部） • 下記のようなもの以外にも、ATAM、SAAMなどアーキテクチャ評価手法を適用できる 検証手法 進め方 シナリオウォークスルー 具体的なシナリオにテストアーキテクチャが対応できるか検証する 品質リスク分析

    品質リスクに対しテストアーキテクチャによるリスクコントロール結果が妥当か検証する プロジェクトリスク分析 プロジェクトリスク（テスト工数削減、不具合の多発など）に対しテストアーキテクチャによるリス クコントロール結果が妥当か検証する アーキテクチャブリーフィング ステークホルダや担当者にアーキテクチャを説明し、QCC（Question-Comment-Concern）や 改善点を募る アーキテクチャ比較 参考モデルや類似プロジェクトのテストアーキテクチャとPors/Cons分析などで比較し、相対的 に問題点・改善点を検出する 標準・方法論準拠レビュー テストアーキテクチャが、標準・規格・方法論の項目を満たしているかレビューする テストアーキ設計時評価は制約や限界が大きいものの、必要性が高い 様々な手法があるので、チームでそのスキルを蓄積し包括的に実施する

94. テストアーキテクチャの評価と改善： テスト活動実施後の評価手段 ◼プロトタイピングや反復開発時の実施時や、保守・派生開発で実施できる評価 手段（一部） • 多数の設計評価手段がある。目的やASRに基づいて評価方法・評価基準を設定する • 評価指標の抽出にはGQM法といったメトリクスやKPI導出手法が有効 検証手法 進め方

    欠陥流出率評価 各構成活動ごとに、自活動で検出すべきだったが流出させてしまった欠陥の程度で評価する フォールトインジェクション 意図的に欠陥を混入させ、それを検出できたか評価する テスト網羅性評価 各構成要素ごとに、仕様カバレッジ、コードカバレッジなど、テストの網羅性の程度で評価する テスト生産性評価 各構成要素ごとに、実際にかかったコストやリソースが妥当か評価する ビジネス妥当性評価 ビジネスのKPI達成度、SLA順守度（MTTF、実際のパフォーマンス計測結果など）、ユーザアンケート など、市場やユーザからのフィードバックを用いてテストの有効性が妥当か評価する

95. テストアーキテクチャの評価と改善： 評価体制：QAマネジメントの活動が求められる ◼テストアーキテクチャの評価では、テスト活動全体が妥当かの総合評価が求め られる その対応のために、品質マネジメントの活動、QAエンジニアのロールが求めら れる • テスト活動を含む各品質エンジニアリング活動全体として、品質確保・保証ができており、 必要な品質が実現されているかを確認する

96. テストアーキテクチャの評価手段の一例： シナリオウォークスルー ◼レビューによるアーキテクチャの評価手段の一つ ◼手順 1. シナリオ形式で実例をピックアップ 2. シナリオを実行した際に、テストアーキテクチャが目標を達成できるか、テストアーキテク チャに問題がないか、机上にて、ウォークスルーレビューで評価する ◼シナリオのピックアップ方法

    • 重要度に応じて体系的に導き出す • 導出方法の例： • リスクベース：リスクレベルの高いものについてリスクシナリオをピックアップする • 不具合タイプ：不具合を種類で分類し、各種類ごとに代表的な不具合をピックアップする • 目的ベース：テスト目的を細分化し、それぞれの目的を具体化したシナリオをピックアップする

97. テストアーキテクチャの評価手段の一例： シナリオウォークスルー（欠陥分類を用いるアプローチ） 欠陥分類 代表的な欠陥の実例 欠陥発生のシナリオ 文言の正確性 フランス語の誤翻訳 仕様作成時のフランス語翻訳を誤り、誤翻訳文言が埋め込まれる 文言描画 A形式レイアウトモニタでの文字切れ

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

98. 個人ワーク2

99. 【個人ワーク2】シナリオウォークスルーによるテストアーキテク チャの評価と改善 ◼背景 • ウェブサービスをスクラムで開発するプロジェクト • サービスは継続的デリバリで高頻度にリリースしている ◼ワーク課題 • このプロジェクトのテストアーキテクチャを、プロジェクトリスクに基づいたシナリオウォーク

    スルーで評価して問題を見つける • 見つけた問題に対し改善案を作成する

100. 【個人ワーク2】シナリオウォークスルーによるテストアーキテク チャの評価と改善 ◼評価するテストアーキテクチャ インテグレー ション 結合テスト リリース テスト ユニット テスト

     実装 サービス デプロイ スプリント テスト スプリント(2週間)ごとに実施 リリースごとに実施 スプリント レビュー テスト テスト内容 ユニットテスト ユニットが仕様を満たしているか確認。開発者が記述しCIツールで実行。自動テスト。主要ブランチ更新ごとに実行 結合テスト コンポーネントセットが仕様を満たしているか、サービスの結合ができているか確認。開発者が記述しCIツールで実行。自 動テスト。メインブランチの更新ごとに実行 スプリントテスト スプリント成果物がPO（プロダクトオーナー。要求定義者）が提示した仕様を満たしているか確認。テストエンジニアが実 施。探索的テスト スプリントレビュー スプリント成果物が妥当か確認。POが実施。レビューおよび探索的テスト リリーステスト サービスがリリースできる品質であることを確認。テストエンジニアが実施。過去のスプリントテストを再実施するリグレッ ションテストで構成する CIとして実施

101. 【個人ワーク2】シナリオウォークスルーによるテストアーキテク チャの評価と改善 ◼シナリオウォークスルーで用いるリスクシナリオ プロジェクトリスク リスクシナリオ 要求分析の誤りによる 不要な機能の実装 ＰＯがユーザからの要求を誤解し、ユーザが必要としない冗長な機能を追加してしまった 不適切な設計による 性能の不足

     性能要求について、POは必要な要求と認識していたが、ユーザストーリー（仕様）として 明文化ができていなかったため、開発者が性能要求に気づけなかった。結果としてその 性能要求が未達成のサービスを開発してしまった

102. 【個人ワーク2】シナリオウォークスルーによるテストアーキテク チャの評価と改善 ◼課題 リスクシナリオ シナリオにテストアーキテクチャが対応 できるかの評価結果 テストアーキテクチャの改善点 ＰＯがユーザからの要求を誤解し、ユーザ が必要としない冗長な機能を追加してし まった

     性能要求について、POは必要な要求と 認識していたが、ユーザストーリー（仕様） として明文化ができていなかったため、開 発者が性能要求に気づけなかった。結果 としてその性能要求が未達成のサービス を開発してしまった 課題1：リスクシナリオが示すリスクを、 テストアーキテクチャが対応できるか評価し、 結果を記述してください 課題2：課題1で問題が見つかった場合、 その改善点を記述してください

103. 個人ワーク2 解答例

104. 【個人ワーク2】シナリオウォークスルーによるテストアーキテク チャの評価とテストアーキテクチャの改善案検討 解答例 ◼解答例（一例です） リスクシナリオ シナリオにテストアーキテクチャが対応で きるかの評価 テストアーキテクチャの改善点 POがユーザからの要求を誤解し、ユーザ が必要としない冗長な機能を追加してし

     まった ×不具合を見逃す可能性が高い。 結合テストより後はPO作成仕様に依存し ている。POが誤解していると、不具合と 認識できないテストアーキテクチャとなっ ている ・スプリントレビューの実施者にユーザ に精通したステークホルダを加える ・ユーザテスト工程を設ける 性能要求について、POは必要な要求と 認識していたが、不注意でユーザストー リー（仕様）として明文化ができていな かったため、開発者が性能要求に気づけ なかった。結果としてその性能要求が未 達成のサービスを開発してしまった ◦対応できる可能性が高い POがサービスを確認するスプリントレ ビューが設けられている。POが正しく要 求を認識しているならば、そこで問題は 検出される 問題なし

105. テストアーキテクティングの進め方： アウトライン ◼テストアーキテクティングの全体像 ◼テストアーキテクティングの基本活動 • テストアーキテクチャ要求の分析 • ステークホルダ分析/要求・制約の分析 • テストアーキテクチャの設計

     • テストアーキテクチャの設計 • 関係者との調停/テスト担当者とのすり合わせ • ★個人ワーク１ • テストアーキテクチャの評価と改善 • シナリオウォークスルー • ★個人ワーク2 ◼テストアーキテクティングの反復と維持活動 ◼テストアーキテクティングのテストへの展開

106. テストアーキテクティングの反復による作りこみ ◼テストアーキテクティングの活動の中で、テストの要求・制約の追加変更、テスト 活動結果のフィードバックを継続的に監視し、それらに基づいてテストアーキテ クチャを維持・変更する トリガ 事例 対応方針 テストの要求の追加変更 開発途中の仕様変更 変更リスクへの対応方針の検討

     テストアーキテクチャの変更検討 テストの制約の変更 開発遅延によるテスト工数 削減 工数削減を加味したテストの責務調整 テスト削減に対するリスクコントロール手段を検討し組み込み テスト技術開発のフィード バック 自動化技術の獲得 テスト活動間の責務の比重の見直し(自動化比率を上げるなど) テスト活動失敗のフィード バック 許容できない欠陥の見逃し 判明 どのテスト活動で欠陥を検出すべきかを明確化し、それに応じた 責務調整 テストの網羅度目標の改善

107. テストアーキテクチャの維持 ◼テストアーキテクトは、テストアーキテクチャ崩壊の予防活動を取りまとめる • 設計したテストアーキテクチャと実際のテストアーキテクチャのギャップを監視 ギャップを見つけたら是正活動を行う • GQM法などでギャップを見つけるための評価指標を識別し運用する ◼維持を容易にするために、チームのテストアーキテクティング能力を育成し、 チームが自律的にテストアーキテクティングを行う体制を志向して、アーキテク ティングの責務を分散するアプローチが有効

     • テストアーキテクチャの崩壊や、テストの技術的負債の蓄積に気づいて、自発的にそれを 解消するようなチームを目指す

108. テストアーキテクチャの改善 ◼テストアーキテクチャの改善を継続的に行う • 要求制約の変更対応、問題対応、テスト技術獲得・改善 ◼時に必要に応じてリアーキテクティングやビッグリライトを実施する • タイミング： • レガシーなテストアーキテクチャの引継ぎ時 •

     抜本的なテスト技術の新導入 • テスト対象のリアーキテクティングやビッグリライトへの対応 • レガシーなテストアーキテクチャのリアーキテクティングでは、テストアーキテクチャのリバー スモデリングや設計根拠の具体化を、今回紹介したテストアーキテクチャの表現方法を 活用して実施する

109. テストアーキテクティングのテストへの展開 以後のテスト活動への展開 ◼抽出したテスト活動ごとにテスト設計を推進 ◼テストアーキテクチャの再利用に備えて設計 判断や設計成果物を整理・記録する て テスト全体 テストタイプ テストタイプ テストレベル

     テストレベル テスト分析 テスト設計 テスト実装 テスト分析 テスト設計 テスト実装 テストアーキテクチャ設計 以降の活動

110. テストスケジュール テストアーキテクティングのテストへの展開 以後のテスト活動への展開 ◼マネジメントと連携し、テストアーキテクチャの発展原則や各テスト活動の実施 タイミングをスケジュールに反映する 結合テスト・スプリントテスト リリーステスト リリーステスト リリーステスト •施策HW環境の構築

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

111. ご参加ありがとうございました Cooperative テストのステークホルダやテスト担当者と協調し 妥当なテストを導く Evolutionary 開発ライフサイクルの状況に応じて テストを継続的に洗練させる

112. 質疑応答