0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

データ駆動型の品質保証×仮説駆動開発のためのテスト戦略フレームワーク

Posted at

前置き

ビジネス価値の創出から技術的なリスク管理、そして継続的な学習までを網羅した、
体系的されたテスト戦略のブループリントとして、自分が行きついたフレームワークを
今回は触れていきます。

これは、テストを「バグを見つける作業」から、

「事業仮説を検証するための科学的プロセス」

へと昇華させるアプローチだと勝手に思っています。

フェーズ1:価値の源泉と品質仮説の特定 (★)

このフェーズの概要

マーケティング戦略上の

「当たり前品質」から、アブダクションでシステムの外部品質をロジックブランチモデルとして特定する。

これはテスト戦略の 「Why」 を定義する、最も重要な起点です。

「当たり前品質」の特定

これは、顧客満足度モデルである狩野モデルの考え方そのものです。

顧客が「当然あるべき」と期待する品質(当たり前品質)が欠けていると、満足度は急激に低下します。
この品質を特定することは、「絶対に外してはいけないテスト」 の範囲を定義することに他なりません。

アブダクションによる仮説構築

観察される事実

「ユーザーは我々のサービスを使い続けてくれる(あるいは、離脱する)」

アブダクション

「もし、決済プロセスが3秒以内に完了するというパフォーマンス(外部品質)が提供されているならば、ユーザーの満足度は向上し、離脱しないという事実は上手く説明できる」

image.png

このプロセスで、「利用時品質(満足度)」と「外部品質(性能、セキュリティ等)」
を繋ぐ 因果関係の仮説ツリー(ロジックブランチモデル) が生まれます。

これが、テスト活動が目指すべき具体的な目標となります。

# フェーズ2:リスクの集中とテストポートフォリオの構築 (★★)

このフェーズの概要

コンテキストマップ上で品質観点ごとのリスク分析を行い、

スコアリングによってテスト対象を選択集中する。

これは、有限なリソースをどこに投下すべきかを決定する、テストにおける 「Where」と「What」 の戦略です。

コンテキストマップ上のリスク分析

DDDモデリングで考えるコンテキストマップの与えてくれる境界は、リスクが偏在する場所を示すヒートマップとして機能します。

e528368b380a-20230219.png

【顧客】ドメイン

ここは、個人情報保護の観点で、脅威分析が必須です。

STRIDE/LINDDUNによる脅威モデリングで、個人情報漏洩のリスクを重点的に分析。

【注文】コアドメイン

パフォーマンス分析で、多数のコンポーネント連携による遅延リスクを分析。

【決済】汎用サブドメイン

自社で開発しない外部サービスとの連携部分における、データ不整合や障害時の復旧(回復性)リスクを分析。

リスクスコアリングによる優先順位付け

ここは、仮説ベースでスコアリングします。一般的には、以下の2軸評価が用いられます。

リスクスコア = 影響の大きさ (Impact) × 発生可能性 (Likelihood)

影響の大きさ

そのリスクが顕在化した時に、ビジネスにどれだけ損害を与えるか。
これはフェーズ1で定義した「当たり前品質」を損なう度合いと直結します。

発生可能性

コードの複雑性、技術の新しさ、チームの習熟度などから推測します。

コードの複雑さは、RDRAで要件定義モデリングをしていれば、
バリエーション/条件 を見れば、定性的にでもわかります。

このスコアリング結果に基づき、高リスク領域に集中的にテストコストを投下する
という、合理的なテストポートフォリオが完成します。

ここでの、仮説ベースで優先順位付けしたリスクマップは、次のフェーズで検証するものなので、必ずドキュメントで残しておきましょう。

フェーズ3:仮説の検証と学習のループ

このフェーズの概要

実際のテスト結果や運用データに基づき、スコアリングの妥当性 (★★) と、そもそもの品質仮説 (★) を検証する。

これが、「生きた戦略」たらしめる、最も重要なフィードバックループです。

1. 技術的仮説の検証 (★★の検証)

問い:「我々のリスク評価は正しかったか?」

検証方法

運用フェーズで検出されたバグや障害の発生箇所と、事前に作成したリスクマップを比較します。

「低リスク」と判断した領域から重大な障害が多発した場合、我々のリスク評価モデル(発生可能性や影響度の見積もり)が間違っていたことを意味します。

この学びを次のイテレーションのリスク評価に反映させます。

2. ビジネス仮説の検証 (★の検証)

問い:「我々が重要だと信じて投資した品質は、本当にユーザーの満足度に貢献したか?」

検証方法

まさに、演繹による予測と現実の比較です。

・演繹的予測

「我々の仮説ツリー(★)によれば、もし決済パフォーマンスを3秒以内に改善したならば、
リピート率は5%向上するはずだ。」

・現実との照合

実際にパフォーマンスを改善した後、A/Bテストなどを用いてリピート率のデータを計測します。

予測通りなら
「我々の仮説は正しかった。この品質への継続的な投資は正しい。」
と判断できます。

予測と異なれば
「そもそもの大前提となる(★)仮説が間違っていた。」

→ 大前提の再定義
ユーザーはパフォーマンスよりも、例えば「使える決済手段の種類」の方を重視していたのかもしれない。

この学びは、次のプロダクトバックログの優先順位を決定するための、何物にも代えがたい貴重な情報となります。

ここまでのまとめ

このメカニズムは、まさに

「データ駆動型の品質保証 (Data-Driven Quality Assurance)」

「仮説駆動開発 (Hypothesis-Driven Development)」

を融合させた、現代のソフトウェア開発におけるテスト戦略の理想形です。

勘や慣習に頼るのではなく、

①. ビジネス価値を起点とした仮説を立て、
②. リスク分析に基づいて資源を集中し、
③. 得られた結果から学習して次の行動を決定する

という、科学的かつ合理的なサイクルを体現するための各プロセスを書いてきました。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?