受け入れテスト

「動く」と「使える」は違う

単体テストや機能テストが「コードが正しく動くか」を検証するのに対し、受け入れテストは「ビジネスが求めるものになっているか」を検証する。バグがなくても、要件と異なる挙動をしていればリリースはできない。

受け入れテストの記述は自然言語に近い形式をとることが多い。「管理者がログインして従業員一覧を開くと、自テナントの従業員だけが表示される」のように、ユーザーの行動と期待結果をシナリオとして記述する。Gherkin（Given-When-Then）構文はその代表的なフォーマットだ。

自動化の度合い

手動で実施する受け入れテストもあれば、Playwright 等で自動化するケースもある。ATDD（受け入れテスト駆動開発）では、受け入れ基準を先に定義し、それを自動テストとして実装してから開発に入る。手動テストに頼ると実行頻度が下がりがちなため、クリティカルなシナリオは自動化するのが実務上の定石になっている。

スプリントレビューとの関係

スクラム開発では、スプリントレビューで受け入れテストの結果を確認することが多い。プロダクトオーナーが「この機能は受け入れ可能か」を判断する材料になるため、テストシナリオはスプリント計画時にチームで合意しておくのが理想的だ。