sfdipot-product-factors

SFDIPOT 製品要素分析

<default_to_action> 要件を分析する際：

1. ドキュメントの種類を特定します（エピック、ユーザーストーリー、仕様書、アーキテクチャドキュメント）
2. ドメインのコンテキストを検出します（eコマース、医療、金融など）
3. 各 SFDIPOT カテゴリを体系的に分析します
4. 動作を表す動詞でテストアイデアを作成します（「Verify」で始めるパターンは使用しません）
5. 優先度（P0～P3）と自動化適性を割り当てます
6. カバレッジの不足を補うための確認質問を提示します
7. 指定された形式で出力します（HTML、JSON、MD、Gherkin）

品質ゲート：

• 人による探索的テストを10％以上含めます
• 「Verify X」形式のテストパターンは使用しません
• 優先度の分布：P0（8～12％）、P1（20～30％）、P2（35～45％）、P3（20～30％） </default_to_action>

クイックリファレンスカード

7つの製品要素

要素	質問	注目する領域の例
Structure（構造）	それは何ですか？	コンポーネント、コード、依存関係
Function（機能）	何をしますか？	機能、計算、エラー
Data（データ）	何を処理しますか？	入力、出力、永続化
Interfaces（インターフェース）	どのようにつながりますか？	UI、API、連携
Platform（プラットフォーム）	何に依存しますか？	OS、ブラウザー、ハードウェア
Operations（運用）	どのように使用しますか？	ワークフロー、管理、復旧
Time（時間）	物事はいつ発生しますか？	並行処理、スケジューリング

このスキルを使用する場面

シナリオ	優先度	出力
新しいエピックの計画	高	SFDIPOT の包括的な評価 + テストアイデア
スプリント要件のレビュー	中	対象を絞った分析 + 確認質問
テスト戦略の策定	高	包括的なテストカバレッジ計画
リスク評価	高	ドメインの重要度に応じた優先度の割り当て
カバレッジの不足の分析	中	踏み込んだ質問 + 推奨事項

---

SFDIPOT 分析フレームワーク

構造（製品とは何か）

サブカテゴリ：

• コードの整合性：コードの品質、複雑さ、保守性
• ハードウェア：物理コンポーネント、デバイス、周辺機器
• 実行可能でないファイル：設定ファイル、データファイル、ドキュメント
• 実行可能ファイル：バイナリ、スクリプト、ライブラリ
• 依存関係：サードパーティ製ライブラリ、外部サービス

テストアイデアの例：

• 重要なモジュールの循環的複雑度を分析し、10を超える関数にフラグを立てます
• 破損した設定ファイルを注入し、適切に縮退動作することを確認します
• 依存関係のバージョンをアップグレードし、互換性を損なう変更がないことを検証します

機能（製品が行うこと）

サブカテゴリ：

• アプリケーション：中核となるビジネス機能
• 計算：数学的処理、変換
• エラー処理：例外の管理、復旧
• セキュリティ：認証、認可、暗号化
• 状態遷移：ワークフローの状態、データのライフサイクル
• メッセージング：通知、イベント、キュー
• データ変換：形式変換、マッピング

テストアイデアの例：

• 1000件の明細項目を含む注文を送信し、処理時間を測定します
• 検索フィールドに SQL を注入し、サニタイズによって実行が防止されることを確認します
• 状態遷移のタイムアウトを発生させ、再試行の動作を観察します

データ（製品が処理するもの）

サブカテゴリ：

• 入力：ユーザー入力、ファイルアップロード、API ペイロード
• 出力：応答、レポート、エクスポート
• 永続化：データベースへの保存、キャッシュ
• ストレージ：ファイルシステム、クラウドストレージ
• 境界：最小値／最大値、エッジケース
• 検証：形式のルール、ビジネスルール
• 形式：JSON、XML、CSV の処理

テストアイデアの例：

• 100MB のファイルをアップロードし、チャンク処理が完了することを確認します
• テキストフィールドに絵文字を挿入し、保存と取得ができることを検証します
• 境界日付（2038-01-19）をクエリし、タイムスタンプの処理を確認します

インターフェース（製品がどのようにつながるか）

サブカテゴリ：

• ユーザーインターフェース：Web、モバイル、デスクトップ UI
• API：REST、GraphQL、gRPC エンドポイント
• 連携：サードパーティサービスとの接続
• プロトコル：HTTP、WebSocket、MQTT
• CLI：コマンドラインインターフェース

テストアイデアの例：

• ブラウザーの幅を320pxに変更し、レスポンシブブレークポイントが機能することを確認します
• 不正な JSON を API に送信し、詳細情報を含む400応答を検証します
• トランザクションの途中で WebSocket を切断し、再接続の動作を観察します

プラットフォーム（製品が依存するもの）

サブカテゴリ：

• ブラウザー：Chrome、Firefox、Safari、Edge
• OS：Windows、macOS、Linux、iOS、Android
• ハードウェア：CPU、メモリ、ストレージの制約
• 外部ソフトウェア：データベース、メッセージキュー
• ネットワーク：レイテンシー、帯域幅、オフライン

テストアイデアの例：

• 1GB RAM のデバイスで実行し、メモリ使用量をプロファイリングする
• ネットワークレイテンシーを 500ms にして実行し、ユーザーエクスペリエンスを測定する
• iOS 15 の Safari でテストし、CSS grid のサポートを検証する

運用（製品がどのように使用されるか）

サブカテゴリ：

• 一般的な使用：通常のワークフロー
• 極端な使用：エッジケース、ストレス条件
• ユーザー管理：ロール、権限、プロフィール
• 管理者操作：設定、監視
• 復旧：バックアップ、復元、災害復旧

テストアイデアの例：

• 10,000 件の同時ユーザーセッションを実行し、リソース使用量を監視する
• セッション中に管理者アクセス権を取り消し、ただちに反映されることを確認する
• 24 時間前のバックアップから復元し、データの整合性を検証する

時間（物事がいつ発生するか）

サブカテゴリ：

• 同時実行：並列操作、競合状態
• スケジューリング：Cron ジョブ、時間指定イベント
• シーケンス：操作の順序、依存関係

テストアイデアの例：

• 2 人のユーザーが同じレコードを同時に更新し、競合が正しく解決されることを確認する
• DST の切り替え時にスケジュール済みジョブを実行し、タイミングが正しいことを検証する
• シーケンスの途中で操作をキャンセルし、部分的な状態の処理を観察する

---

品質ルール

テストアイデアの品質

「Verify X」というパターンは絶対に使用しないでください。常に動作を表す動詞を使ってください。

悪いパターン	良いパターン
ログインが機能することを検証する	認証情報を送信し、セッションが作成されることを確認する
API が 200 を返すことを検証する	リクエストを送信し、200 のレスポンスをアサートする
エラーが表示されることを検証する	エラーを発生させ、メッセージを確認する

優先度の配分

優先度	割合	基準
P0（クリティカル）	8-12%	セキュリティ、データ損失、規制
P1（高）	20-30%	コア機能、ユーザーへの影響
P2（中）	35-45%	標準機能、エッジケース
P3（低）	20-30%	仕上げ、軽微な改善

自動化への適性

種類	割合	用途
ユニット	30-40%	独立したロジック、計算
インテグレーション	15-25%	API 契約、データフロー
E2E	<=50%	ユーザージャーニー、ワークフロー
人による探索	>=10%	ユーザビリティ、エッジケース

---

エージェントの統合

// Full SFDIPOT assessment
await Task("SFDIPOT Assessment", {
  input: epicDocument,
  outputFormat: "html",
  domains: ["ecommerce"],
  brutalHonesty: true
}, "qe-product-factors-assessor");

// Transform verify patterns
await Task("Rewrite Test Ideas", {
  inputFile: assessmentHtml,
  preserveMetadata: true
}, "qe-test-idea-rewriter");

---

メモリ名前空間

aqe/sfdipot/
├── assessments/*     - Assessment results
├── patterns/*        - Learned domain patterns
├── test-ideas/*      - Generated test ideas
└── questions/*       - Clarifying questions

---

関連スキル

• brutal-honesty-review - 品質の検証
• risk-based-testing - 優先度の割り当て
• context-driven-testing - ドメインの把握
• exploratory-testing-advanced - セッションの設計

---

覚えておくこと

SFDIPOT は、7 つの異なる視点から製品を検討することで、包括的なテストカバレッジを実現します。 各カテゴリからは、ほかの視点では見落とされる可能性のあるリスクが明らかになります。ドメイン検出を使って、優先度を適切に調整してください。