QAアーキテクチャの設計で品質保証の全体像を整理しよう

こんにちは！QAエンジニアの入間川です。
株式会社COMPASSという小中学生向けAI型教材「Qubena（キュビナ）」を開発・提供する会社でプロダクトの品質保証を担当しています。

本記事では「QAアーキテクチャ」と呼ばれる品質保証の基本構造・基本方針を設計するための考え方について、西康晴 QAアーキテクチャの設計による説明責任の高いテスト・品質保証　2016 電気通信大学 から学んだ内容をアウトプットしていければと思います！

品質保証における課題

　QAとして日々活動する中、下記のようなQA組織の課題を感じることがあります。

・個別にテストは実施しているが、何を品質保証しているのかがはっきりしない
　→　QAは品質活動に対する説明責任を持つという前提での活動ができていない。
　→　品質特性に沿った適切なテスト戦略、明確な品質目標が立てられておらず、前例踏襲・対症療法的な対応となってしまっている。

・高速で価値創造を行う開発スタイルの中で、様々なQA活動を高度に連携させ、全体の品質保証の整合性を確保しながらの継続的な品質担保ができていない

・テストやQA組織が品質向上のための知見を蓄積したり、テスト活動による品質への直接的な効果を明確に開発組織に示せていない。

・QA組織の目指す姿について活動の全体像をうまく開発組織に向けて説明できていない。

　これらの課題を解決していくため、「QAアーキテクチャ」という考え方を自分たちのQAチームの活動にも取り入れていくのが良いのではと考えました。

QAアーキテクチャとは

　QAアーキテクチャとは？の概要についてはgoyokiさんのブログのQAアーキテクチャの概要の記事が参考になりました。

QAアーキテクチャ概要

QAアーキテクチャは、電通大の西康晴さんが先導的に整備している考え方で、「品質をどこでどう確実に作り込んで確実に保証するか」「どんなQA観点を作り込んで保証できているのか」の基本構造・基本方針を設計したものです。

引用：goyokiさんのブログ 千里霧中 「QAアーキテクチャの概要 QAアーキテクチャの定義」より抜粋

QAアーキテクチャの役割

・予測。以降のQA活動に大きな影響を与える判断を示し、準備や計画を支える
・先導。QAの方針を示し、状況が流動的に変化するソフトウェア開発ライフサイクルのあらゆる局面で、QA活動がどこに進むべきかを先導する。
・橋渡し。ビジネス、マネジメント、開発、QAなど様々なステークホルダ・関係者からのQAへの要求・制約の調停を行い、妥当なQAの実現を支える。
・協調。複雑・大規模なリスクや問題に対応するために、各QA手段をどう協調させるかを示す。また複雑・大規模な問題を対応可能にするために、具体化・分割する。
・全体整合の確保。QAの適切な全体像を構築し、その実現・維持を支える。

引用：goyokiさんのブログ 千里霧中 「QAアーキテクチャの概要 QAアーキテクチャの役割」より抜粋

コミュニケーションツールとしてのQAアーキテクティング

・様々なステークホルダからの要求や制約を調停し、ステークホルダが納得するQA活動を実現する
・様々なQA活動関係者からの納得を確保し、QA担当者の協力を促しその力を結集する

引用：goyokiさんのブログ 千里霧中 「コミュニケーションツールとしてのQAアーキテクティング」より抜粋

QAアーキテクチャの設計により得られるメリット

得られるメリットとしては下記が挙げられます。

・品質は何によって決まるかがQA観点モデルによりはっきりする。

・様々なQA活動を総体として扱うことで、アジャイル開発のスピードに耐えうる品質保証の整合性を取ることができる。

・仕様書に全て記載がない場合でもテストケースを漏らさずにテスト設計ができる。

・QAアーキテクチャに従ってプロセスとメトリクスを導出すると、それによってどの様に品質が向上していき理想に近づくかの根拠が示せる。

具体的な活動イメージ

　それでは具体的にどの様にQAアーキテクチャの設計が行われていくのか、まずはQAアーキテクチャのサブアーキテクチャの中で一番着手がしやすいテストアーキテクチャの設計から見ていきたいと思います。

１．テストアーキテクチャの設計
　テストアーキテクチャを設計するには、まずテスト観点を挙げ、挙げた観点をテストコンテナに適切に割り振っていけば実現が可能です。

引用元：西康晴 QAアーキテクチャの設計による説明責任の高いテスト・品質保証　2016 電気通信大学 スライド13, 14

　テストアーキテクチャの設計のためにはテストレベル(単体テスト、結合テスト、システムテストなど)、テストタイプ：負荷テスト、動作環境変更テスト、性能テスト、セキュリティテストなど、テストサイクル：1回目の回帰テスト、2回めの性能テストなどを事前に定義しておく必要があります。

これらを適切にテストコンテナに割り振っていくことでテストアーキテクチャの設計が可能になります。

引用元：西康晴 QAアーキテクチャの設計による説明責任の高いテスト・品質保証　2016 電気通信大学 　スライド16
上記の図のように、テストプロセスの中で、テスト設計としていた部分がテストアーキテクチャ設計を行う事でさらに細分化がされていきます。
テストレベル-テストタイプの定義、テスト要求分析、テストコンテナへの割り振り、の順で着手をしていけそうと思いました。

２．レビューアーキテクチャの設計
　テストアーキテクチャの設計がうまく行ったら、続いてレビューアーキテクチャの設計に着手します。どのようなタイプやレベルのレビューを行うことによって、どんな品質をどのように保証するのか／どんなバグを検出するのかの全体像を描く活動をレビューアーキテクチャと呼びます。

　テストで検証を行うよりもレビューで検証する方が早期に低コストで不具合を検出可能な場合がありますが、テストケースの改善とレビューケース改善を同等に行っている組織はあまり無いのではないでしょうか。

　設計手順としてはテストアーキテクチャとほぼ同様で、事前にレビューレベル(要求レビュー、仕様レビュー、設計レビュー、コードレビューなど)、レビュータイプ(ウォークスルー、インスペクション)、レビューサイクル(〇〇レビュー第2回、やり直しレビューなど)を定義しておき、レビュー観点を挙げた後にレビューコンテナへ割り振っていくという流れになります。

（その他、レビューを行う事で、不具合の指摘にとどまらず、副次的な役割も期待できます。）

引用元：西康晴 QAアーキテクチャの設計による説明責任の高いテスト・品質保証　2016 電気通信大学 　スライド67

３．QAアーキテクチャの設計
　テストアーキテクチャ、レビューアーキテクチャの設計が完了したら、最後に全体のQAアーキテクチャの設計に着手します。QAアーキテクチャには大きく3つのアイテムが存在します。

①QA観点モデル
　品質担保のためにどのような観点が必要なのかを全て書き出して整理したもの。レビュー観点、テスト観点やISO品質特性、不具合分析の結果も含みます。テストケースやレビューケースとシームレスに対応付けられるように粒度を細かくしていくことが求められます。

②アシュアランスパイプライン(保証の網)
　続いてQA工程の責務を整理するためのネットワーク図を作成します。（QC工程表のイメージと近い。）①で出したQA観点と工程との関係をうまく割り当てることで、特定の意図のQA観点を含む工程を繋げたアシュアランスパイプラインを構築することができます。(下記はパイプラインのイメージ(上図) 個々のQAフローイメージ(下図)）

西康晴 QAアーキテクチャの設計による説明責任の高いテスト・品質保証　2016 電気通信大学　スライド74、75

　パイプライン内の個々のQAフローは、どのQA観点をどの工程でどのように作り込み、どの工程でどのように検証するかを記述したものです。

　QA観点ごとに品質をどう作り込むか、どうやって欠陥が入り込んでしまうか、それらをどのように検証するか、のメカニズムを明らかにし、粒度の細かいQA観点の保証を積み上げていきます。アシュアランスパイプラインを構築し、個々のQAフローのメカニズムがきちんと機能しているかを測定して管理することで全体のQAプロセスの改善が可能となります。個々のQAフローの内容を整理していくための情報としても、不具合分析結果が役立つことがあります。
　また、自動化できる観点の工程のみのパイプライン、手動での確認が必要な観点の工程が区別できるので、メリハリのあるQAが可能になります。

③テックシェルフ(技術の棚)
　QAプロセスには観点、手順だけでなく技法や方法論も含める必要があります。ある工程で効果を発揮するためには適切な技術の供給が必要です。
　テックシェルフは概念的なもので、ドメイン技術、要素技術、エンジニアリング技術、マネジメント技術をQA観点と適切に組み合わせ、実際に現場で効果のあった技術のみ棚に乗せていく作業を行います。この作業はQAアーキテクチャの中で、アシュアランスパイプラインとは分離して行っていく必要があるものです。

　QAプロセスの中でのポジティブナレッジ(デザインパターン、開発プロセス等)　ネガティブナレッジ(不具合パターン、リスクパターン等)をうまくテックシェルフに蓄積していく→テックシェルフからQAプロセスに適切な技術を供給していく、という循環が重要です。

QAアーキテクチャは組織構造、開発プロセスに大きく依存する

　ここまでテストアーキテクチャ／レビューアーキテクチャ／QAアーキテクチャの設計について見てきましたが、QA観点と工程が対応した活動の責務分割を行う際、どのチームがどの工程でどの責務を受け持つか、というところでQAが所属する開発組織の組織構造および開発プロセスにもQAアーキテクチャは大きく依存します。
　QAチームのみで品質が担保されるということはなく、開発チーム、SREチーム、デザインチーム、コンテンツチーム等、プロダクト開発に関わるチーム全体での協調によって初めて全体の品質保証の整合性を確保しながらの継続的な品質担保が可能となります。
　私達はQAアーキテクチャの設計に取り掛かる前に、まずは現状の組織構造および開発プロセス、各チームで担保頂いている品質をよく理解し、既存の枠組みに囚われない品質保証の形を目指して行く必要があるかと思います。

まとめ

　記事のはじめに私達QAチームが抱える課題をいくつか挙げましたが、「各品質特性の品質は何によって決まるか」、「その質をどこで、どのように作り込んで実証するか」、を現場にフィットした形でモデリング・アーキテクチャ設計で明確にしていくことによってこれらの大部分が解決していくのではないかと感じました。

　QAアーキテクチャで扱うアイテムの中で、現在私達のQAチームで具体的に着手ができているのがテストレベル-テストタイプ対応表作成(テストアーキテクチャ設計のためのインプット)、不具合分析(QA観点モデル、アシュアランスフロー構築のためのインプット、テックシェルフへのネガティブナレッジの蓄積)、テスト自動化(アシュアランスパイプラインの活用)になります。

　QAアーキテクチャの全体像を描くためにはまだまだインプットと小さい実践の繰り返し、開発組織の理解と密な連携が必要と感じるため、まずはボトムアップで着手可能なアイテムから実現していくことを積み重ねて行ければと思います。

　テストレベル-テストタイプ対応表作成、不具合分析、テスト自動化のCOMPASSでの取り組みについても記事にしていければと思います！