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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

ワークショップについて ◼理解を深めるための簡単な個人ワークを用意しています • あわせて解答例を紹介します。各自考え合わせに活用ください • 予稿集に、ワーク、ワークのための解説、ワーク解答例を記載していますワーク中の見直しなどで参照ください • 予稿集を手元にダウンロードください ◼図表がかけるツールを用意ください • 紙、MiroやPower Pointなど絵が描けるツール ◼資料は公開します • https://speakerdeck.com/goyoki/cetam • 予稿集にもURLを記載しています

Slide 4

Slide 4 text

自己紹介 ◼現在 • 車メーカにてアジャイル開発のテストチームのテックリードを担当 • U30テスト設計コンテスト審査委員長、JSTQB技術委員 ◼製造業を中心にソフトウェアの開発、テスト、開発インフラ整備などに従事開発チームリーダ、コンサル、テックリードさまざまな立場でテストアーキテクティングを手掛ける ◼主な著作・講演 • 「システムテスト自動化標準ガイド」「実践ソフトウェアエンジニアリング第9版」「テスト設計をより良くするモデリングと観点分析」など

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

解説するアプローチ：CETAM （Cooperative and Evolutionary Test Architecting Method） Cooperative テストのステークホルダやテスト担当者と協調し妥当なテストを導く Evolutionary 開発ライフサイクルの状況に応じてテストを継続的に洗練させる

Slide 7

Slide 7 text

アウトライン ◼テストアーキテクチャとは • アーキテクチャ/テストアーキテクチャ ◼テストアーキテクチャの概要 • 役割/立ち位置/テストアーキテクト/アプローチ ◼テストアーキテクチャの表現 ◼テストアーキテクティングの進め方 • 全体像/基本活動/反復/テストへの展開 • 個人ワーク1/個人ワーク2

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

テストアーキテクチャの姿：具体例(2/4)：全体のテスト活動の構造を導くインテグレーション結合テストシステムテストユニットテスト実装サービスデプロイスプリントテストスプリント(2週間)ごとに実施リリースごとに実施 CIとして実施セキュリティテスト全体のテスト活動の関係性や依存関係を明確化する

Slide 14

Slide 14 text

テストアーキテクチャの姿：具体例(3/4)：全体のテスト活動の横断的方針や連携を導くリスクリスクレベルテストでの対策遠隔アップロード機能の不正利用によるソフトウェアの不正書き換え 6 認証機能評価：システムテスト OS設定およびコンフィグレーション評価：セキュリティテスト全体のセキュリティアセスメント：SQA監査シャッター制御過剰制御による駆動部分の劣化の加速 4 システムテストで対応加速度テスト、ロングランテストでテストする課題やリスクに対してテスト活動をどう連携するか、どのような方針で実行するかを明確化する

Slide 15

Slide 15 text

テストアーキテクチャの姿：具体例(4/4)：全体のテストシステムの基本設計を導く制御 PC テスト対象モニタ撮影装置被写体モデルタッチパネルエミュレータテスト管理サーバ CIサーバテストドライバ CI クライアント DIO コンバータ SDカードマルチプレクサ映像/USB-C 必要なテストシステムのアーキテクチャを明確化するテストシステム使用するテストシステムテスト自動化環境自動システムテストスモークテストレフ制御耐久テスト環境レフ制御耐久テスト Rustユニットテスト環境 MMアプリユニットテスト・・・テストアーキテクチャはテスト設計活動の要素、要素の構造、要素の連携、要素が必要とする環境で主に表現する

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

今、テストアーキテクティングの工夫が求められる背景 ◼様々なテスト活動を高度に連携させ、開発全体で優れた価値創造やアジリティを実現する開発スタイルが求められている • 【継続的デリバリ、DevOps】様々なテストを包含するデプロイメントパイプラインを洗練させ、開発とビジネスの距離を縮める • 【アジャイル】自動・手動テストを組み合わせ、継続的かつ高速なリリース&フィードバックを実現する ◼創発的・イテレーティブなテスト構築アプローチが求められている • 【アジャイル】イテレーションごとにテストを積み重ねつつ、全体の品質保証としての整合性を確保し、プロダクトの品質を継続的に担保する →様々なテスト活動の総体をアーキテクチャとして扱い、アーキテクティングでその構造やメカニズムを工夫するアプローチが有効である

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

開発ライフサイクルの中でのテストアーキテクティング継続実施しプロジェクトを導き続けるプロジェクト最初期立ち上げ/初期計画立案 /体制構築プロジェクト初期各計画具体化/ PoC/開発開始プロジェクト中期以降開発本格化/保守・派生プロジェクトフェーズテストアーキテクティングの活動 (継続的に反復する) ・テストアーキテクチャ要求の分析・テストアーキテクチャの設計・テストアーキテクチャの評価と改善テストアーキテクティングでフォーカスする活動・テストの体制・計画・戦略の基礎の構築を導く見積もりの根拠/あるべき体制/必要なリソース/テストアーキテクチャの基礎・テスト計画・戦略の具体化を導く・テスト設計の基本方針・基本構造の確立を導く・テスト活動を導く・変化への対応を導く・テストの再利用を導く・テストアーキテクチャを維持する反復の継続

Slide 23

Slide 23 text

テストプロセスとテストアーキテクティング全体にわたってテストを導く全体テスト計画・分析全体テスト設計テストプロセス・テストアーキテクチャ要求の分析・テストアーキテクチャの設計・テストアーキテクチャの評価と改善導くテスト要求・制約の発生・変更ビジネス/マネジメント/ 開発/品質保証/テストテスト活動結果のフィードバックテスト計画・分析テスト設計テスト実装・環境構築テスト実行

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

テストアーキテクトのアンチパターン：象牙の塔のアーキテクト ◼閉じこもってアーキテクチャを考え、トップダウンで現場にアーキテクチャを指示するアーキテクト • 背景 • 教条やパターンへの狂信、権威主義 • テスト上流活動と現場の断絶 • 外部リソースへのアーキテクティングの丸投げ • 属人的要因 ◼現場の制約に対応できず、納得を得られず、チームのアーキテクティング力を伸ばせず、結果として現場の力を活かせずにテストの失敗を誘発する適切なコミュニケーションを通してテスト関係者の納得を確保しながら、協力と連携を引き出すのはテストアーキテクティングの不可欠な活動

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

テストアーキテクティングのすり合わせの例：組織設計のすり合わせ ◼前提：組織構造とテストアーキテクチャは強い相互依存関係をもつ（例：コンウェイの法則） • →テストアーキテクティングであるべき組織要求を示し、時には組織設計を代行するテストアーキテクティングマネジメントテストテスト担当者テスト担当者テスト担当者テストアーキテクチャに必要な組織要求を提示する結果としての組織構造を制約として示す実際の組織を活用するようにテストを導く ※組織設計はマネジメントの作業

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

テストアーキテクティングでの設計技術の活用アーキテクティングの技術でテストをより良くする ◼テストの責務についての関心事の分離/モジュール性改善の推進 • テストの責務を分割し、テスト要求・テスト観点を扱える粒度まで細分化する • テスト設計活動を円滑に推進できるように、テストの責務配置の凝集性を高める ◼全体整合性の確保/テストパイプラインの最適化 • 様々なテスト活動を重ね合わせ・分業させ、テストの有効性・網羅性を実現する • テスト活動のムリ・ムダ・ムラをなくす ◼中長期視点のライフサイクル設計 • 開発ライフサイクルでテストをどう育て、拡張させていくかの設計戦略を構築し、テストの適時性を確保する ◼構造的工夫によるテスト技術/テストリソース活用の拡大 • 有益なテスト技術/テストリソースの適用範囲を拡大する ◼テストの保守性の作りこみ • テストの評価容易性、変更容易性、再利用性、解析性を支える設計を組み込み、テストアーキテクチャの評価・維持・改善を効率化する ◼テストシステムの品質の作りこみ • テストシステムに性能効率性や信頼性、保守性など品質を支える設計を組み込み、テストの適時性や信頼性を改善する

Slide 32

Slide 32 text

アジャイル開発でのテストアーキテクティング ◼アジャイルでは反復的な開発アプローチの中でテストの整合性を維持する必要があるため、テストアーキテクティングが重要になる ◼アジャイルでのテストアーキテクティングの方針 • アジャイルの原則・アプローチに従う • テストの基本原則・基本構造を確立し、それに沿った形でインクリメンタルにテストを増築していく（イテレーションごとのテストを乱雑に蓄積するのを避ける） • アジャイルチームのテストアーキテクティング能力を伸ばし、チームが自律的にテストアーキテクティングを行う流れを強化する • テストアーキテクチャの崩壊の監視と予防活動（テストの技術的負債の適時の回収など） • テストの基本原則・構造の推進と改善

Slide 33

Slide 33 text

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

テストアーキテクチャの表現 ◼アーキテクチャの表現 • アーキテクチャは様々な特性を備えていることから、複数のアーキテクチャ観点でみた複数の側面で表現する • アーキテクチャ観点は、少なすぎず、多すぎない数を、重要性に基づいて選択する • 例：RUP4+1、ArchiMate ◼テストアーキテクチャを表現する観点主要なテストアーキテクチャ観点このパートで紹介する主な表現手法テストアーキテクチャの構成要素責務構造ツリーテスト責務管理表テストアーキテクチャの構造パイプラインモデルとシナリオ記述テストアーキテクチャの環境（テストシステムの環境設計）テストアーキテクチャの連携（要求に応じた表現手法）テストアーキテクチャの発展原則

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

テストアーキテクチャの構成要素の表現：責務構造ツリー：例デジタルカメラのテストユニットテスト・コード解析開発工程に対応してテストを実施する結合テストシステムテスト開発組織に応じてテストを実施する内製コンポーネントおよびシステム結合以降のテスト外製コンポーネントのテスト開発会社ごとに受け入れテストを実施するユニットテストツリー MMシステム受け入れテスト RTOS 受け入れテスト結合テストツリーシステムテストツリーシステムアーキテクチャ

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

責務構造ツリー：モデル構造ユニットテスト・コード解析開発工程に対応してテストを実施する結合テストシステムテスト内製コンポーネントのテストおよびシステム結合以降のテスト ●上位のテストの責務を、下位のテストの責務に分割する ●ひし形Strategyで、「どう分割したか」を明記する ●テストアーキテクティングでは、テストの責務はテストレベル・テストタイプの粒度で記載

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

テストアーキテクチャの構造の表現：パイプラインモデルとシナリオ記述 ◼デプロイメントパイプラインモデルでテストを含むプロセスをモデリングする • 重ね合わせ、連携、分担など、テストアーキテクティングの工夫の表現に適しているインテグレーション結合テストリリーステストユニットテスト実装サービスデプロイスプリントテストスプリント(2週間)ごとに実施リリースごとに実施スプリントレビュー CIとして実施

Slide 44

Slide 44 text

テストアーキテクチャの構造の表現：パイプラインモデルとシナリオ記述 ◼シナリオ記述：具体的なシチュエーションごとのパイプラインのふるまいを記述する • テストアーキテクチャはプロジェクト状況に応じて変動するパラメータを持つパイプラインでモデル化する際はシナリオ記述による場合分け記述が有効シナリオユニットテスト結合テストシステムテストスプリント内テスト全実行全実行追加変更分に対するテスト＋影響範囲のリグレッションテストリリース時テスト全実行全実行全実行 hotfix時テスト全実行全実行追加変更分に対するテスト＋影響範囲のリグレッションテストインテグレーション結合テストシステムテストユニットテスト実装リリース

Slide 45

Slide 45 text

テストアーキテクチャの表現：テストアーキテクチャへの要求に応じたモデリングを行う ◼アーキテクチャ観点は様々。テストアーキテクチャへの要求に基づいて、アーキテクチャ観点を選択し、各観点ごとにテストアーキテクチャを表現するテストアーキテクチャ要求の例テストアーキテクチャ要求に対応するモデル・表現方法様々なテストベースの実現性保証各テストベースとテストレベル・テストタイプのマッピング想定される欠陥の検出検出したい欠陥タイプとテストタイプのマッピング品質レベルがリリースできる水準であることの確認品質リスク分析（テストアーキテクチャがリスクに対応できているか）推測されるプロジェクトトラブルへの対応プロジェクトリスク分析（テストアーキテクチャがリスクに対応できているか）開発スケジュールに応じたテストアーキテクチャの段階的拡張テストアーキテクティングのスケジューリング必要なテスト環境リソースの識別テストシステムの構造アーキテクチャ設計

Slide 46

Slide 46 text

Slide 47

Slide 47 text

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

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

Slide 50

Slide 50 text

テストアーキテクティングの全体像：継続実施しプロジェクトを導き続けるプロジェクト最初期立ち上げ/初期計画立案 /体制構築プロジェクト初期各計画具体化/ PoC/開発開始プロジェクト中期以降開発本格化/保守・派生プロジェクトフェーズテストアーキテクティングの活動 (継続的に反復する) ・テストアーキテクチャ要求の分析・テストアーキテクチャの設計・テストアーキテクチャの評価と改善テストアーキテクティングでフォーカスする活動・テストの体制・計画・戦略の基礎の構築を導く見積もりの根拠/あるべき体制/必要なリソース/基本テストアーキテクチャの提示・テスト計画・戦略の具体化を導く・テスト設計の基本方針・基本構造の確立を導く・テスト活動を導く・変化への対応を導く・テストの再利用を導く・テストアーキテクチャを維持する反復の継続

Slide 51

Slide 51 text

テストアーキテクティングの全体像：テストプロセスの中での立ち位置全体テスト計画・分析全体テスト設計テストプロセス・テストアーキテクチャ要求の分析・テストアーキテクチャの設計・テストアーキテクチャの評価と改善導くテスト要求・制約の発生・変更ビジネス/マネジメント/ 開発/品質保証/テストテスト活動結果のフィードバックテスト計画・分析テスト設計テスト実装・環境構築テスト実行

Slide 52

Slide 52 text

Slide 53

Slide 53 text

テストアーキテクチャ要求の分析 ◼テストアーキテクチャへのニーズ・シーズ・制約を分析する • テストの要求・制約のうち、テストアーキテクチャに影響するものを分析する • テストの要求・制約の詳細な分析は、各テストレベルのテスト分析で実施 • 特にASR(Architecturally significant requirements。アーキテクチャに重要な影響を与える要求)の識別に注力する • ASRがテストアーキテクチャの基本構造・基本方針を決定する。これをミスすると後からのリカバリが大変になる ◼構成作業 1. ステークホルダの分析 2. テストアーキテクチャ要求の収集と分析

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

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

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

テストアーキテクチャ要求の分析テストアーキテクチャ要求の収集と分析 ◼重要度に応じてテストアーキテクチャ要求を分析する • テストアーキテクチャを取り巻く要求は膨大。全体俯瞰の分析観点と重点部分を深掘りする分析観点を組み合わせて、テストアーキテクチャに必要な情報を獲得する重視する目的の例目的に対応したテストアーキテクチャ要求分析の重要点必要なテストレベルを識別する開発プロセス分析、テストベース分析、テスト対象のアーキテクチャ分析法規制・標準の適合保証に必要なテストを明らかにするテストに関わる法規制・標準の識別、法規制・標準の中でのテストへの要求項目の分析テスト実施タイミングおよびそこでのテスト十分性基準を明らかにするリリーススケジュールの調査、リリースごとの品質目標の分析、テスト要求分析システムテストのテストタイプを分析するテスト要求分析、システムを構成する品質特性の分析、機能構造（インターフェースや静的データなど）の分析テスト自動化の適用範囲を明らかにするテスタビリティの調査、リソース計画の分析、保有するテスト自動化技術の調査テストによるリスクコントロールが妥当か調査する品質リスクの分析、プロジェクトリスクの分析結合テストのテストタイプを分析するテスト対象のアーキテクチャ調査、インテグレーションプロセスの分析、コンポーネントセットごとの品質目標とテスタビリティの評価

Slide 58

Slide 58 text

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

テストアーキテクチャの設計テスト戦略・方針の策定 ◼テストアーキテクチャ設計を含む、テスト全体の戦略を具体化し、テストアーキテクチャ設計を方向づけする • 重要な要求に基づく戦略で、テストアーキテクチャの基本骨格を構築する • 後付けで対応困難な問題対応を適時のタイミングで実施する • 重大なアーキテクティングの誤りを避ける ASR・重要な目的テスト戦略サービスの頻繁な改善・変更に対応するテスト自動化（実行および生成の自動化）の促進により、変更対応を効率化するテスタビリティ向上により、テスト対象の安定性を向上させる手動テストについて、探索的アプローチの拡大により、変更対応を効率化する例：アジャイル開発でのテスト戦略テストアーキテクチャ設計テスト戦略・方針の策定設計連携設計責務分割構造設計環境設計すり合わせ

Slide 61

Slide 61 text

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

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

【閑話】チームが遂行可能なテストタイプ（テストケイパビリティ）を日頃から蓄積する ◼日頃の技術蓄積がテストアーキテクチャの選択の幅を左右する ◼チームの技術資産として、遂行可能なテストタイプを蓄積していこうモータ制御の正確性テスト性能計測イーサネットのペネトレーションテスト静的解析機械制御のロードテスト機械制御のロードテストウェブサービスのストレステスト OSS脆弱性評価機能調停の組み合わせテストハードウェア互換性テスト UXバリデーション障害注入テストマニュアル合致性テスト耐タンパ性評価資源効率性評価アクセシビリティ評価ビジュアルテスト障害回復性テスト

Slide 65

Slide 65 text

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

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

テストアーキテクチャの設計「最初の一歩」の設計アプローチ ◼パターンベース • 問題・コンテキスト・フォースに合致する、成功したテストアーキテクチャパターンを用いて設計する ◼経験ベース • 過去の成功したテストアーキテクチャ構造を参考にして設計する ◼標準・方法論ベース • テストアーキテクティングに関わる標準や方法論に基づいて設計する ◼集合知ベース • 様々なテスト関係者の知見を積み上げ、構造化してアーキテクチャ構造を得る

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

テストアーキテクチャの設計責務分割 ◼テストの責務を実行可能な粒度まで分割するテストアーキテクチャ設計テスト戦略・方針の策定設計連携設計責務分割構造設計環境設計すり合わせデジタルカメラのテストユニットテスト・コード解析開発工程に対応してテストを実施する結合テストシステムテスト開発組織に応じてテストを実施する内製コンポーネントおよびシステム結合以降のテスト外製コンポーネントのテスト開発組織ごとに受け入れテストを実施する MMシステム受け入れテスト RTOS 受け入れテスト

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

テストアーキテクチャの設計：連携設計 ◼テストアーキテクチャ要求に基づいて、テスト活動をどう連携させるか設計する連携の設計を通してテストアーキテクチャの構成要素を検討する • 特に影響が重大なASRに基づいて、テストアーキテクチャの骨格を構成するテストアーキテクチャ要求の種類の例テストアーキテクチャ要求に対応した設計作業様々なテストベースの実現性保証各テストベースとテストレベル・テストタイプのマッピング想定される欠陥の検出検出したい欠陥タイプとテストタイプのマッピング品質レベルがリリースできる水準であることの確認品質リスク分析推測されるプロジェクトトラブルへの対応プロジェクトリスク分析開発スケジュールに応じたテストアーキテクチャの段階的拡張テストアーキテクティングの発展原則の具体化

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

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

Slide 76

Slide 76 text

テストアーキテクチャの設計：構造設計 ◼テストアーキテクチャの構造（依存関係、順序、関係性）を設計し、構成要素や連携を導出する • 構造パターン：重ね合わせ、分業、横断的連携、繰り返し • 例：パイプラインモデル（orプロセスモデル）とシナリオ記述で構造を設計インテグレーション結合テストシステムテストユニットテスト実装サービスデプロイスプリントテストスプリント(2週間)ごとに実施リリースごとに実施 CIとして実施セキュリティテストシナリオユニットテスト結合テストスプリントテストシステムテストセキュリティテストスプリントリリース全実行全実行全実行実施しない実施しない通常デプロイ全実行全実行全実行全実行全実行 Hotfix&デプロイ全実行全実行全実行追加変更分に対するテスト＋影響範囲のリグレッションテストリスクベースドテスト

Slide 77

Slide 77 text

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

Slide 78

Slide 78 text

テストアーキテクチャの設計：環境設計 ◼テストアーキテクチャ要求に基づいてテストシステムの基本設計を行う • テストアーキテクティング要求対応に注力。詳細なテスト環境設計は各テストレベルで実施 • OOD、SysML/UMLなどシステムやソフトのアーキテクチャ設計手法を活用できる制御 PC テスト対象モニタ撮影装置被写体モデルタッチパネルエミュレータテスト管理サーバ CIサーバテストドライバ CI クライアント DIO コンバータ SDカードマルチプレクサ映像/USB-C ●必要なテストシステムを識別するテストシステム使用するテストシステムテスト自動化環境自動システムテストスモークテストレフ制御耐久テスト環境レフ制御耐久テスト Rustユニットテスト環境 MMアプリユニットテスト・・・ ●テストアーキテクチャ要求に対応するテストシステムを具体化する

Slide 79

Slide 79 text

テストアーキテクチャの設計：環境設計：テスト設計とテスト環境設計は不可分 ◼テストアーキテクティングにおいて、テストシステム設計とテスト設計は一緒に検討しなければならない • テスト自動化やCI/CDインフラ、IasC、仮想化をはじめとした現代のテストシステムの技術は、テスト設計の進め方に強く影響する • 例：キーワード駆動テスト • また上記の技術の活用の程度が、テストの生産性に直結する。そのためテスト活動の責務設計の重要な判断基準となる ◼例：テスト自動化の活用 • 前提 • テスト自動化ツールの指定する形式に合わせてテスト設計方針を立てなければならない • ROIに優れた自動テストの責務を増やすテストアーキテクチャ設計が有効になる • テストアーキテクチャ設計での必要なアクション • テストシステム設計を通して自動化ツールを明確化。ツールにあったテスト設計方針を具体化する • テストシステム設計を通してテストのROIを明確化。それに沿ってテストの責務設計を調整する

Slide 80

Slide 80 text

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

Slide 81

Slide 81 text

個人ワーク1

Slide 82

Slide 82 text

【個人ワーク1】テストの責務構成の明示 ◼背景 • カメラの開発プロジェクト • テストタイプ「完成品に対するユーザビリティテスト」のテスト設計方針を検討している ◼ワーク課題 • テストタイプ「完成品に対するユーザビリティテスト」がどのような詳細なテストタイプで構成されているかモデリングする • 責務構造ツリーを作成する ◼目的 • 「完成品に対するユーザビリティテスト」がどのようなテストタイプで細分化できるか、全体像をわかりやすく共有可能にする

Slide 83

Slide 83 text

【個人ワーク1】テストの責務構成の明示 ◼「完成品に対するユーザビリティテスト」についての要求： • 外部評価者および内部テストチームで対応する必要がある • 外部評価者によるテスト：複数のタイプの評価者ごとにテストを実施。以下が必要 • ユーザテスト：選出した想定ユーザに基本的なユーザビリティを評価してもらう • 専属プロテスト：継続契約している専属プロに評価してもらう • エキスパートテスト：メインターゲットのプロおよびハイエンドユーザに、プロユースに耐えられるか評価してもらう • 内部テストチームによるテスト：ユーザビリティ要件およびユーザビリティガイドラインに基づいてテストを実施。以下が必要 • 内部ユーザビリティテスト：ユーザビリティ要件を実現しているか評価 • アクセシビリティテスト：UIがアクセシビリティガイドラインに適合しているか評価 • ブランディングレビュー：ブランドポリシーに適合しているか評価 • ユーザビリティガイドラインテスト：社内ユーザビリティガイドラインに適合しているか評価課題：親ノードを「完成品に対するユーザビリティテスト」として、上記で提示されているテストタイプを責務構造ツリーでモデリングしてください

Slide 84

Slide 84 text

個人ワーク1 解答例

Slide 85

Slide 85 text

【個人ワーク1】テストの責務構成の明示解答例（一例です）アクセシビリティテストエキスパートテストブランディングレビューユーザテストユーザビリティガイドラインテスト内部ユーザビリティテストテストベースごとにテストする専属プロテスト内部テストチームによるテスト外部評価者によるテスト完成品に対するユーザビリティテスト内部テストチーム、外部評価者それぞれでテストする異なる種別のユーザごとにテストする

Slide 86

Slide 86 text

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

Slide 87

Slide 87 text

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

Slide 88

Slide 88 text

テスト担当者とのすり合わせ/ステークホルダとのすり合わせテスト担当者とのすり合わせ ◼各テストの責任者や専門家とすり合わせ、テストアーキテクチャ設計を必要な水準まで作りこむユニットテスト動的・静的それぞれでテストする動的解析静的解析ユニットテスト・コード解析静的要求タイプごとにテストするコーディング規約チェックハイリスクなコード解析

Slide 89

Slide 89 text

テスト担当者とのすり合わせ/ステークホルダとのすり合わせステークホルダとのすり合わせ ◼テストアーキテクトとステークホルダで相互に要求・制約をすり合わせ、プロジェクトの要求・制約を満たす妥当なテストアーキテクチャを実現するすり合わせ相手すり合わせ内容ビジネスビジネス・ユーザ要求、ビジネス成否、テストのフィージビリティマネジメントコスト、リソース、スケジュール、スコープ、体制開発テスタビリティ、アーキテクチャ、インテグレーション、開発プロセス、テストベース、開発技術品質保証テストの代替・補完手段、品質マネジメントテストテストアーキテクチャ（各テストの目的、設計方針、担当など）テスト活動のフィードバック、テスト技術

Slide 90

Slide 90 text

テスト担当者とのすり合わせ/ステークホルダとのすり合わせトレードオフの調整 ◼テストアーキテクチャ比較や、トレードオフ分析で妥当なテストアーキテクチャを分析し、妥協点を導く • 比較やトレードオフ評価のアプローチ： • GQM法などメトリクス指標の抽出 • ATAM、意思決定マトリクス、Pros/Cons 評価指標フレームワークAベースフレームワークBベース構築容易性＋＋＋保守性＋＋＋ツールロックインの低さーー－パフォーマンス＋＋・・・

Slide 91

Slide 91 text

Slide 92

Slide 92 text

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

Slide 93

Slide 93 text

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

Slide 94

Slide 94 text

テストアーキテクチャの評価と改善：テスト活動実施後の評価手段 ◼プロトタイピングや反復開発時の実施時や、保守・派生開発で実施できる評価手段（一部） • 多数の設計評価手段がある。目的やASRに基づいて評価方法・評価基準を設定する • 評価指標の抽出にはGQM法といったメトリクスやKPI導出手法が有効検証手法進め方欠陥流出率評価各構成活動ごとに、自活動で検出すべきだったが流出させてしまった欠陥の程度で評価するフォールトインジェクション意図的に欠陥を混入させ、それを検出できたか評価するテスト網羅性評価各構成要素ごとに、仕様カバレッジ、コードカバレッジなど、テストの網羅性の程度で評価するテスト生産性評価各構成要素ごとに、実際にかかったコストやリソースが妥当か評価するビジネス妥当性評価ビジネスのKPI達成度、SLA順守度（MTTF、実際のパフォーマンス計測結果など）、ユーザアンケートなど、市場やユーザからのフィードバックを用いてテストの有効性が妥当か評価する

Slide 95

Slide 95 text

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

Slide 96

Slide 96 text

テストアーキテクチャの評価手段の一例：シナリオウォークスルー ◼レビューによるアーキテクチャの評価手段の一つ ◼手順 1. シナリオ形式で実例をピックアップ 2. シナリオを実行した際に、テストアーキテクチャが目標を達成できるか、テストアーキテクチャに問題がないか、机上にて、ウォークスルーレビューで評価する ◼シナリオのピックアップ方法 • 重要度に応じて体系的に導き出す • 導出方法の例： • リスクベース：リスクレベルの高いものについてリスクシナリオをピックアップする • 不具合タイプ：不具合を種類で分類し、各種類ごとに代表的な不具合をピックアップする • 目的ベース：テスト目的を細分化し、それぞれの目的を具体化したシナリオをピックアップする

Slide 97

Slide 97 text

テストアーキテクチャの評価手段の一例：シナリオウォークスルー（欠陥分類を用いるアプローチ）欠陥分類代表的な欠陥の実例欠陥発生のシナリオ文言の正確性フランス語の誤翻訳仕様作成時のフランス語翻訳を誤り、誤翻訳文言が埋め込まれる文言描画 A形式レイアウトモニタでの文字切れ描画領域不足で、幅広フォント文字を最大数入力したら描画領域を超過する・・・ (1)欠陥分類ごとに欠陥の実例が発生するシナリオをピックアップ (2)「欠陥発生のシナリオ」にテストアーキテクチャが対応できるか、ウォークスルーレビューする「外国語の誤翻訳は本来システムテストでピックアップすべきだが、フランス語が分かる担当者確保が検討されておらず見逃す可能性がある」「文字切れは結合テストでのエミュレータによる自動テストで検出される」

Slide 98

Slide 98 text

個人ワーク2

Slide 99

Slide 99 text

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

Slide 100

Slide 100 text

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

Slide 101

Slide 101 text

【個人ワーク2】シナリオウォークスルーによるテストアーキテクチャの評価と改善 ◼シナリオウォークスルーで用いるリスクシナリオプロジェクトリスクリスクシナリオ要求分析の誤りによる不要な機能の実装ＰＯがユーザからの要求を誤解し、ユーザが必要としない冗長な機能を追加してしまった不適切な設計による性能の不足性能要求について、POは必要な要求と認識していたが、ユーザストーリー（仕様）として明文化ができていなかったため、開発者が性能要求に気づけなかった。結果としてその性能要求が未達成のサービスを開発してしまった

Slide 102

Slide 102 text

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

Slide 103

Slide 103 text

個人ワーク2 解答例

Slide 104

Slide 104 text

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

Slide 105

Slide 105 text

Slide 106

Slide 106 text

テストアーキテクティングの反復による作りこみ ◼テストアーキテクティングの活動の中で、テストの要求・制約の追加変更、テスト活動結果のフィードバックを継続的に監視し、それらに基づいてテストアーキテクチャを維持・変更するトリガ事例対応方針テストの要求の追加変更開発途中の仕様変更変更リスクへの対応方針の検討テストアーキテクチャの変更検討テストの制約の変更開発遅延によるテスト工数削減工数削減を加味したテストの責務調整テスト削減に対するリスクコントロール手段を検討し組み込みテスト技術開発のフィードバック自動化技術の獲得テスト活動間の責務の比重の見直し(自動化比率を上げるなど) テスト活動失敗のフィードバック許容できない欠陥の見逃し判明どのテスト活動で欠陥を検出すべきかを明確化し、それに応じた責務調整テストの網羅度目標の改善

Slide 107

Slide 107 text

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

Slide 108

Slide 108 text

テストアーキテクチャの改善 ◼テストアーキテクチャの改善を継続的に行う • 要求制約の変更対応、問題対応、テスト技術獲得・改善 ◼時に必要に応じてリアーキテクティングやビッグリライトを実施する • タイミング： • レガシーなテストアーキテクチャの引継ぎ時 • 抜本的なテスト技術の新導入 • テスト対象のリアーキテクティングやビッグリライトへの対応 • レガシーなテストアーキテクチャのリアーキテクティングでは、テストアーキテクチャのリバースモデリングや設計根拠の具体化を、今回紹介したテストアーキテクチャの表現方法を活用して実施する

Slide 109

Slide 109 text

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

Slide 110

Slide 110 text

テストスケジュールテストアーキテクティングのテストへの展開以後のテスト活動への展開 ◼マネジメントと連携し、テストアーキテクチャの発展原則や各テスト活動の実施タイミングをスケジュールに反映する結合テスト・スプリントテストリリーステストリリーステストリリーステスト ●施策HW環境の構築 ●試作基板環境の構築 ●本番環境の構築自動システム試験環境開発テストアーキテクチャ構築施策環境向け自動システム試験環境開発エミュレータ環境開発ツールFS コンポーネントテスト・結合テスト設計方針確立テストアーキテクチャ PoC リリーステスト構築リリーステスト構築スプリントテスト確立

Slide 111

Slide 111 text

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

Slide 112

Slide 112 text

質疑応答