リソース · 61
プロジェクト承認：ニーズを評価基準と証拠に変換する
実際にテストしたタスクを通して納品を評価するために、シナリオ、期待される結果、証拠、例外処理の決定事項を準備します。
更新済み · 4 min
このガイドが達成するのに役立つこと
- タスクから始める
- テスト可能な期待値を記述する
- 証拠をシナリオに関連付ける
- 例外を解決する
クイックチェック
- 誰が納品を受け取るべきでしょうか？
- 例外は合格とみなされるか？
- 修正後、テストを再利用できるか？
手順
- 1
タスクから始める
誰が、どのような状況で、どのような制約の下で、何を達成する必要があるかを明確にする。 提案された方法は、GOV.UKのサービス評価準備を参考にしているが、非公開の承認を公的認証とはみなさない。
成果物：ニーズと優先度の高いジャーニー。
- 2
テスト可能な期待値を記述する
「速い」や「直感的」といった言葉を、観察可能な結果と測定コンテキストに置き換える。 エラー、権限、言語、アクセシビリティを含める。 基準は、機能の存在を超えて、ユーザーが何を得るかを示す。
成果物：基準と架空のテストデータ。
- 3
証拠をシナリオに関連付ける
各試行について、バージョン、環境、前提条件、アクション、結果を記録する。 スクリーンショットだけでは、テストが成功したことを証明できません。 レビュー担当者が機密情報にアクセスすることなく検証または再生できる証拠を準備してください。
成果物：再現可能な証拠記録
- 4
例外を解決する
承認前に、テストのブロック要因、許可された例外、および担当者を明確に定義してください。 承認された例外には、範囲、理由、および期限が必要です。 例外を承認しても、失敗したテストが合格になるわけではありません。
成果物：例外登録簿と決定事項
- 5
運用部門との連携完了
テストドキュメント、復旧、およびサポートの引き継ぎも行ってください。 AIサービスについては、制限事項と担当者を明確にしてください。 テスト範囲、未解決のギャップ、および再承認レビューが必要な条件を保持してください。
成果物：納品決定と例外フォローアップ
再利用可能なワークシート
承認された観察結果を記入してください。 これらのフィールドは作業用テンプレートであり、観察結果ではありません。
| フィールド | 記録する情報 |
|---|---|
| ニーズ | 担当者、タスク、コンテキスト |
| 基準 | 期待される結果と前提条件 |
| 試行 | バージョン、架空データ、観察結果 |
| 決定 | 例外、所有者、期限 |
架空の事例
具体的な状況
架空の例：フォームがケースを送信したが、モバイル端末で添付ファイルが失われた場合。
決定と期待される証拠
承認は、技術的な提出と完全なケースを区別するものです。 ニーズは、受信者が添付ファイルを取得できるようになった時点で初めて満たされます。
メカニズムの区別
| メカニズム | 目的 | 検証または制限 |
|---|---|---|
| デモンストレーション | 選択したジャーニーを理解する | 完全な網羅性として扱わない |
| ビジネス承認 | タスクと期待される結果を検証する | エラーと個別のユーザープロファイルを含める |
| 技術レビュー | 契約と動作を検査する | 結果をユーザーニーズに結びつける |
管理指標
| 指標 | 測定対象 | 最初のアクション |
|---|---|---|
| カバーされた基準 | 実際に実行された基準 | 未テスト、合格、不合格を分ける |
| 未解決の例外 | 承認済みまたはブロック中のギャップ | 担当者と期限を指定する |
| 再現可能な証拠 | 再構築可能なシナリオ | バージョンと前提条件を記録する |
よくある間違い
- 完全な網羅性として扱わない
- エラーと個別のユーザープロファイルを含める
- 結果をユーザーニーズに結びつける
よくある質問
誰が納品を受け取るべきでしょうか？
必要な専門家からのインプットを得て、ニーズの指定担当者を任命する。 テスト前にこの責任を明確にする。
例外は合格とみなされるか？
いいえ。既知のギャップのままです。 承認とは、範囲内での文書化された決定です。
修正後、テストを再利用できるか？
はい、安定したデータと前提条件があれば、新しいバージョンと影響を受ける可能性のある経路を明記して承認できます。
公式参照文献
参照文献はメソッドを裏付けるものです。 チェックは状況に合わせて調整してください。 これらは認証ではありません。 元の参照文献のタイトルやソース文書は別の言語で書かれている場合があります。
参照資料の確認日 .
