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

QAアーキテクティング概要 /QA Architecting

32fe1b1b174c69d06b455799ed1fb285?s=47 h.iseri
December 21, 2021

QAアーキテクティング概要 /QA Architecting

32fe1b1b174c69d06b455799ed1fb285?s=128

h.iseri

December 21, 2021
Tweet

More Decks by h.iseri

Other Decks in Technology

Transcript

  1. QAアーキテクティング概要 Agile Tour Osaka 2021 井芹 洋輝

  2. この解説について ◼QA(品質保証)活動をアーキテクティングで支えるアプローチを解説します ◼資料は公開しています • https://speakerdeck.com/goyoki/qa-architecting

  3. 前提の用語定義:アーキテクチャとは ◼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.」 (対象の環境におけるシステムの基本的な概念や特性を、システムの要素、関係、設計 原則・発展原則として具体化したもの)
  4. 本解説における用語定義 ◼QAアーキテクチャ • 「品質をどう保証するか」の基本的な概念・特性であり、それを品質保証の原則、基本方 針、手段の構成で具体化したもの ◼QAアーキテクティング • QAアーキテクチャを実現し、改善・維持する活動全般

  5. QAアーキテクチャの実体 ◼次の基本的な概念や特性 • 品質保証を構成するQA活動 • QA活動の連携方針と構造 • QA活動を支えるインフラ • QA活動を支えるチーム

    • QA活動の構築・発展方針 ◼表現方式の例 • QA活動の目的や責務、基本作業 • QA活動のビジョン・原則・方針 • プロセス • インフラやリソースの設計 • チームルール ▪トップダウンのQAアーキテクティング ・QAの責務分掌、課題のブレークダウン ・問題や課題に対する連携設計 ・プロセス設計 ・横断的なインフラ設計・組織設計 ・監視とコントロール ▪ボトムアップのQAアーキテクティング ・自発的な互助・補完アプローチの形成 ・QAの文化とリテラシーの醸成 ・学習・改善フィードバックループの促進 ・チームスキルの獲得・向上 ・自発的なインフラの拡充 ・QAアーキテクチャのセルフヒーリング
  6. なぜQAアーキテクティングが重要になるのか ◼様々なQA活動を高度に連携させ、開発全体で優れた価値創造やアジリティ、 持続性を実現する開発スタイルが求められている • 【継続的デリバリ、DevOps】様々なQA活動を包含するデプロイメントパイプラインを洗練 させ、開発と運用・ビジネスの距離を縮める ◼創発的・イテレーティブなQAアプローチが求められている • 【アジャイル】イテレーションごとにQA活動を積み重ねつつ、全体の品質保証としての整 合性を確保し、継続的にプロダクトの品質を保証する

    →様々なQA活動の総体をアーキテクチャとして扱い、アーキテクティングで その構造やメカニズムを工夫するアプローチが有効である
  7. QAアーキテクティングの役割 ◼要求実現ツール • ステークホルダやQA担当者からのQAへのシーズ・要求・制約をすり合わせし、チームを 成功させるQAの実現を導く ◼問題解決ツール • 個々のQA活動のみの努力では対応できない、困難な問題への対応方法を編み出し、 問題解決を導く ◼先導役

    • 開発ライフサイクルの中での流動的な状況変化に対応し、QA活動を先導し続ける ◼コミュニケーションツール • 必要なQA活動について、QA関係者の納得を確保し、QA活動が円滑に遂行されるよう にする。チーム全体アプローチを実現する
  8. QAアーキテクティングの担当:チーム全体アプローチ ◼品質保証は難易度の高いチャレンジ • 対象のごく一部しか品質を確認できない • 本当の妥当性や品質リスクは開発中には分からない • 利益の最大化に合わせてQAリソースは最小化される • QAへの要求や制約は流動的で確定しない

    • 開発活動と比べ、QA活動の多くは単独でプロダクトを生産しないため優先度を低くされる ◼QAマネージャやQAアーキテクト単独による管理では支えられない ◼→QA活動を支えるQA当事者それぞれの主体的協力によって、QAアーキテクチャを 構築し、QA活動を推進・改善していく必要がある • QAアーキテクトはその土台作りとファシリテートが主な役割 • これから解説するQAアーキテクティング活動も推進者はチームのQA当事者全員
  9. 開発ライフサイクルとQAアーキテクティング プロジェクト最初期 立ち上げ/初期計画立案 /体制構築 プロジェクト初期 各計画具体化/ PoC/開発開始 プロジェクト中期以降 開発本格化/保守・派生 プロジェクトフェーズ

    QAアーキテクティングの活動 QAアーキテクティングで フォーカスする活動 ・体制・計画・戦略の基礎の構築を 導く チーム戦略/あるべき体制/計画の基礎の材 料を提供する ・QA計画・戦略の具体化を導く ・QA活動の基本方針・基本構造の 確立を導く ・QA活動を導く ・QA活動のフィードバックを活用する ・QA成果物の再利用を導く
  10. QAアーキテクティングは継続的な活動 すり合わせで構築・維持・改善する QAアーキテクティング ステークホルダ QA担当 QA要求の発生・変更 QA活動の先導 QAからの要求・制約の提示 QA活動からのフィードバック

  11. QAアーキテクティングのすり合わせの例: 組織設計 ◼前提:組織構造とQAアーキテクチャは強い相互依存関係をもつ (例:コンウェイの法則) • →QAアーキテクティングであるべき組織要求を示し、時には組織設計を代行する QA活動に必要な組織要求を提示する 結果としての組織構造を制約として示す 組織を活用したQA活動を先導する 管理者層

  12. アーキテクティング技術によるQA活動の改善 ◼QA活動の責務についての関心事の分離/モジュール性改善の推進 • QAの責務を分割し、単独で活動を勧められる粒度まで細分化する • QA活動を円滑に推進できるように、QAの責務配置の凝集性を高める ◼全体整合性の確保/パイプラインの最適化 • 様々なQA活動を重ね合わせ・分業させ、QAの有効性を確保する •

    QA活動のムリ・ムダ・ムラをなくす ◼中長期視点のライフサイクル設計 • 開発ライフサイクルでQA活動をどう実現し、拡張させていくかの設計戦略を構築し、QAの適時性を確保 する ◼構造的工夫によるQA技術/QAリソース活用の拡大 • 有益なQA技術/QAリソースの適用範囲を拡大する ◼QA成果物の保守性の作りこみ • QA成果物の保守性を支える設計を組み込み、QAアーキテクチャの評価・維持・改善を効率化する ◼QAインフラの品質の作りこみ • QAインフラに性能効率性や信頼性、保守性など品質を支える設計を組み込み、QAの適時性や信頼性を 改善する
  13. QAアーキテクティングの基本活動 QAアーキテクチャ要求分析 QAアーキテクチャ設計 方向づけ 設計 連携検討と構造化 責務分割 リソース検討 すり合わせ 評価と改善

    構築方針検討
  14. QAアーキテクチャの要求分析 QAアーキテクチャ要求分析 QAアーキテクチャ設計 方向づけ 設計 連携検討と構造化 責務分割 リソース検討 すり合わせ 評価と改善

    構築方針検討
  15. QAアーキテクチャの要求分析 ◼QAアーキテクチャへのニーズ・シーズ・制約を分析する • QAのへの要求・制約のうち、QAアーキテクチャに影響するものを分析する • 詳細な分析は、各QA活動で実施 • 特にASR(Architecturally significant requirements。アーキテクチャに重要な影響を与

    える要求)の識別に注力する • ASRがQAアーキテクチャの基本構造・基本方針を導く ◼要求分析により設計を駆動し、設計の方向づけに合わせて要求を深掘りする • QAアーキテクチャ要求は巨大で流動的であり、最初から全てをやりきれない 全てをシーケンシャルプロセス的に分析しようとするとASRが埋没する QAアーキテクチャ要求分析 QAアーキテクチャ設計 要求・制約に基づいて設計を進める 設計の方向づけに合わせて要求分析を深掘りする
  16. QAアーキテクチャの要求分析 ◼重要度に応じて要求を分析する • QAアーキテクチャを取り巻く要求は膨大。全体俯瞰の分析観点と重点部分を深掘りす る分析観点を組み合わせて、QAアーキテクチャに必要な情報を獲得する 重視する目的の例 目的に対応したQAアーキテクチャ要求分析の重要点 必要なテストレベルを識別する 開発プロセス分析、テストベース分析、テスト対象のアーキテクチャ分析 法規制・標準の適合保証に必要なQA活動を

    明らかにする 法規制・標準の識別、法規制・標準の中でのQAへの要求項目の分析 QA活動のタイミングおよびそこでの十分性基 準を明らかにする リリーススケジュールの調査、リリースごとの品質目標の分析、QA要求分析 テスト自動化の適用範囲を明らかにする テスタビリティの調査、リソース計画の分析、保有するテスト自動化技術の調査 QAによるリスクコントロールが妥当か調査する 品質リスクの分析、プロジェクトリスクの分析 結合テストのテストタイプを分析する テスト対象のアーキテクチャ調査、インテグレーションプロセスの分析、 コンポーネントセットごとの品質目標とテスタビリティの評価
  17. QAアーキテクチャ設計:方向づけ QAアーキテクチャ要求分析 QAアーキテクチャ設計 方向づけ 設計 連携検討と構造化 責務分割 リソース検討 すり合わせ 評価と改善

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

    QAアーキテクティング方針 サービスの頻繁な 改善・変更に対応 する テスト自動化(実行および生成の自動化) の促進により、変更対応を効率化する テスト対象のテスト自動化容易性の向上。テスト自動化可 能な領域を拡大し、それを活用する自動テストの責務を広 げる テスタビリティ向上により、テスト対象の安 定性を向上させる テスト対象の変動部分を局所化し、安定性の高い領域を 拡大する。 安定性の高い領域に高網羅度のテスト責務を配置する 手動テストについて、探索的アプローチの 拡大により、変更対応を効率化する 探索的テスト人材の育成を促進するプロセスを構築する。 またそれを促進するリソースマネジメント・スケジュールをマ ネジメントに要求する。 システムテストは探索的テスト主体の方針を取る 例:戦略検討および方向づけの例
  19. QAアーキテクチャ設計 QAアーキテクチャ要求分析 QAアーキテクチャ設計 方向づけ 設計 連携検討と構造化 責務分割 リソース検討 すり合わせ 評価と改善

    構築方針検討
  20. QAアーキテクチャ設計:責務分割 ◼QA活動の責務を個別遂行可能な粒度まで分割する デジタルカメラのテスト ユニットテスト・ コード解析 開発工程に対応して テストを実施する 結合テスト システム テスト

    開発組織に応じて テストを実施する 内製コンポーネントおよび システム結合以降のテスト 外製コンポーネントのテスト 開発組織ごとに受け入 れテストを実施する MMシステム 受け入れテスト RTOS 受け入れテスト 例はGSN
  21. QAアーキテクチャ設計:連携検討と構造化 ◼QAアーキテクチャ要求に基づいて、QA活動をどう連携させるか設計する • 特に影響が重大なASRに基づいて、QAアーキテクチャの骨格を構成する ◼QAアーキテクチャ要求の例: 「リリース可能なリスクレベルまでリスクをコントロールする」 リスク リスク レベル QAでの対策

    遠隔アップロード機能の不正利用によるソフトウェアの不正 書き換え 6 認証機能評価:システムテスト コンフィグレーション評価:セキュリティテスト 全体のセキュリティアセスメント:SQA監査 シャッター制御過剰制御による駆動部分の劣化の加速 4 システムテストで対応 加速度テスト、ロングランテストでテストする 品質リスク
  22. QAアーキテクチャ設計:連携検討と構造化 ◼QAアーキテクチャの構造(依存関係、順序、関係性)を設計し、構成要素や連 携を導出する • 構造パターン:重ね合わせ、分業、横断的連携、繰り返し インテグレー ション 結合テスト システム テスト

    ユニット テスト 実装 サービス デプロイ スプリント テスト スプリント(2週間)ごとに実施 リリースごとに実施 CIとして実施 セキュリティ テスト
  23. QAアーキテクチャ設計 QAアーキテクチャ要求分析 QAアーキテクチャ設計 方向づけ 設計 連携検討と構造化 責務分割 リソース検討 すり合わせ 評価と改善

    構築方針検討
  24. QAアーキテクチャ設計:リソース検討 ◼アーキテクチャレベルでQA活動に必要なインフラやリソースを検討する 制御 PC テスト 対象 モニタ撮影 装置 被写体 モデル

    タッチパネル エミュレータ テスト管理 サーバ CIサーバ テストドライバ CI クライアント DIO コンバータ SDカード マルチプレクサ 映像/USB-C •必要なテストシステムを識別する QAインフラ 使用するQA活動 システムテスト自動化環境 自動システムテスト スモークテスト レフ制御耐久テスト環境 レフ制御耐久テスト Rustユニットテスト環境 MMアプリユニットテスト ・・・ •QAアーキテクチャ要求に対応する システムを具体化する
  25. QAアーキテクチャ設計:リソース検討 ◼QAアーキテクティングにおいてリソースの構築戦略は重要 • 自動化やCI/CDインフラ、IasC、仮想化をはじめとしたインフラ・リソース関連技術は、 QA活動の進め方に影響し、またそのROIに直結する ◼例:テスト自動化の活用 • 方向性 • テスト自動化ツールの指定する形式に合わせてテスト設計方針を立てなければならない

    • ROIに優れた自動テストの責務を増やすテストアーキテクチャ設計が有効になる • QAアーキテクチャ設計で有効なアクション • テストシステム設計を通して自動化ツールを明確化。ツールにあったテスト設計方針を具体化する • テストシステム設計を通してテストのROIを明確化。それに沿ってテストの責務設計を調整する
  26. QAアーキテクチャ設計:構築方針検討 ◼開発ライフサイクルにおいて、QAアーキテクチャをどのように実現し、維持・改 善していくか方針付けする スケジュール 結合テスト・スプリントテスト リリーステスト リリーステスト リリーステスト •施策HW環境の構築 •試作基板環境の構築

    •本番環境の構築 自動システム試験環境開発 QAアーキテクチャ 構築 施策環境向け 自動システム試験環境開発 エミュレータ 環境開発 ツールFS コンポーネントテスト・ 結合テスト 設計方針確立 テストアーキテクチャ PoC リリーステスト構築 リリーステスト構築 スプリントテスト確立
  27. QAアーキテクチャ設計:すり合わせ QAアーキテクチャ要求分析 QAアーキテクチャ設計 方向づけ 設計 連携検討と構造化 責務分割 リソース検討 すり合わせ 評価と改善

    構築方針検討
  28. QAアーキテクチャ設計:すり合わせ ◼ステークホルダすり合わせ、QAアーキテクチャの妥当性を高める ◼QA担当者とすり合わせ、詳細化を行う ユニットテスト 動的・静的それぞれで テストする 動的解析 静的解析 ユニットテスト・コード解析 静的要求タイプごとに

    テストする コーディング 規約チェック ハイリスクな コード解析
  29. QAアーキテクチャの評価と改善 QAアーキテクチャ要求分析 QAアーキテクチャ設計 方向づけ 設計 連携検討と構造化 責務分割 リソース検討 すり合わせ 評価と改善

    構築方針検討
  30. QAアーキテクチャの評価と改善 ◼QAアーキテクチャを評価し、そのフィードバックで洗練させる • QAアーキテクチャ設計時の評価(事前評価)の例 • ATAM、SAAMなど既知のアーキテクチャ評価手法を適用できる • QA活動実施後の評価(事後評価)の例 • 多数の評価手段がある。評価指標抽出にはGQM法といった既知の導出手法を適用できる

    検証手法 進め方 シナリオウォークスルー 具体的なシナリオにQAアーキテクチャが対応できるか検証する リスク分析 リスクに対しQAアーキテクチャによるリスクコントロール結果が妥当か検証する アーキテクチャブリーフィング ステークホルダや担当者にアーキテクチャを説明し、QCC(Question-Comment-Concern)や改善点を募る アーキテクチャ比較 類似・参考アーキテクチャとPors/Cons分析などで比較し、相対的に問題点・改善点を検出する 検証手法 進め方 欠陥流出率評価 各構成活動ごとに、自活動で検出すべきだったが流出させてしまった欠陥の程度で評価する フォールトインジェクション 意図的に欠陥を混入させ、それを検出できたか評価する 網羅性評価 各構成要素ごとに、仕様カバレッジ、コードカバレッジなど、QAの網羅性の程度で評価する
  31. ご清聴ありがとうございました QAアーキテクチャ要求分析 QAアーキテクチャ設計 方向づけ 設計 連携検討と構造化 責務分割 リソース検討 すり合わせ 評価と改善

    構築方針検討