Nghiệm thu & kiểm thử
Kịch bản nghiệm thu (AC) theo baseline hiện hành, vai trò trách nhiệm và readiness checklist trước release.
1. Nguyên tắc nghiệm thu
Mỗi mốc pass bằng bằng chứng bám FR/NFR/AC hiện hành. Không dùng wording cũ đã defer hoặc non-goal làm điểm chặn. Decision còn status “Mở” là điểm chặn nghiệm thu của AC liên quan.
| Vai trò | Trách nhiệm |
|---|---|
| Chủ thương hiệu / Product | Duyệt phạm vi/change request và nghiệm thu business behavior |
| Tech lead / đơn vị phát triển | Implementation, architecture/schema, test bằng chứng, technical baseline, runbook |
| QA | Chạy AC + FR/NFR tests, negative/error paths và lưu bằng chứng |
| Vận hành | Xác nhận workflow vận hành thủ công (nếu có) |
2. Kịch bản nghiệm thu (AC)
Register: data/ac.yaml. Mỗi AC gồm scenario, expected behavior đầy đủ (gồm negative paths) và các bước kiểm thử có thể lặp lại.
AC là acceptance baseline của dự án. Chưa AC nào được coi là đã chốt khi còn phụ thuộc decision D-xx đang Mở.
AC-00 — [VÍ DỤ] Kịch bản nghiệm thu end-to-end
Kịch bản: Tình huống kiểm thử: ai, làm gì, trên thiết bị/môi trường nào.
Kết quả đạt
Behavior mong muốn đầy đủ, gồm cả nhánh negative.
Thủ tục kiểm thử (đề xuất)
- Bước kiểm thử 1.
- Bước kiểm thử 2 (gồm negative path).
3. Readiness checklist trước release
- TODO: mọi AC đã pass có bằng chứng.
- TODO: permission matrix + audit test pass.
- TODO: backup/restore drill có bằng chứng.
- TODO: deployment inputs (config/credentials) đã seed cho môi trường release.
4. Deployment inputs không phải điểm chặn code
Thiếu giá trị thật (config/credentials/dữ liệu seed) có thể chặn release tương ứng, nhưng không phải lý do thay đổi domain behavior hay quay lại hỏi lại spec.