回答。

質問の背景

受け入れ基準とは、作業（リリース、タスク、テストケース）が完了と見なされるために満たすべき要件のセットです。手動テストにおいて明確に定義された条件は、エラーや誤解、「隠れた」未完了の作業を回避することを可能にします。

問題

透明性のない基準は、「完了」の異なる解釈を引き起こします：開発者はタスクをクローズしたと考え、テスターはまだ全ては明らかではなく、顧客はビジネスロジックへの適合を待っています。

解決策

測定可能で理解しやすく矛盾のない基準（例えば、「ボタンが機能する」、「ページ更新時にデータが保存される」、「バリデーションエラーが発生しない」など）を作成します。DoDを顧客、テスター、開発者間で合意し、要件の変更を反映し、各ストーリー/イシューの基準の達成を記録することが重要です。

主な特徴：

• 誤解や余計な期待を避けることができます。
• 手動テストのためのチェックリストを形成します。
• 重要なことに集中するのを助けます。

落とし穴のある質問。

タスクをクローズするためにすべての基準を満たす必要がありますか？

はい、それがDoDの本質です — タスクはすべての基準が満たされた場合にのみ完了と見なされます。

テストやリリースの過程でDoDを変更できますか？

はい、要件が変更されたり新しい詳細が追加された場合は可能ですが、チームのすべてのメンバー、特にテスターがその点を知っている必要があります。

DoDを決定するのは誰ですか？

チーム全体で、一緒にテスター、開発者、ビジネスアナリスト、顧客の代表者が参加します。

一般的なエラーとアンチパターン

• 「機能が動作する」などの一般的であいまいな表現。
• 基準の変更がその場で行われること。
• リリースまたは受け入れ時にDoDを無視すること。

実生活の例

ネガティブケース

形式的な基準なしでタスクが受け入れられました：同僚はすべてが機能すると考えていました。顧客は翌日「隠れた」バグを見つけます。テスターはバグはタスクに関係ないと主張します。

利点：

• タスクの迅速なクローズ

欠点：

• 重大な欠陥の見落とし
• 顧客との対立の状況

ポジティブケース

テスト前に具体的な基準が設定され、手動での実行後には実施のチェックが行われます。変更はすべて記録され、チームと合意されます。

利点：

• 結果への透明性と信頼性
• 論争的な状況の減少

欠点：

• 基準策定にかかる時間の増加