Bài 1 — Bối cảnh & vấn đề: Vì sao BA cần AI cho Test Case và UAT
Business Analyst đang "chảy máu" thời gian ở đâu?
Trong đa số dự án, Business Analyst (BA) là người hiểu rõ nghiệp vụ nhất, nên khi cần viết test case hay chuẩn bị UAT (User Acceptance Testing), việc đó thường rơi vào tay bạn. Vấn đề là công việc này rất tốn công nhưng lặp đi lặp lại:
- Đọc từng acceptance criteria (AC), tách thành các trường hợp kiểm thử.
- Nghĩ ra các trường hợp biên (boundary), trường hợp âm (negative), trường hợp ngoại lệ.
- Soạn dữ liệu test, bảng ma trận coverage, checklist nghiệm thu cho khách hàng.
- Viết lại cùng một format cho hàng chục user story mỗi sprint.
AI thay đổi cuộc chơi như thế nào?
AI ngôn ngữ lớn (như ChatGPT, Claude, Gemini) rất mạnh ở đúng những việc BA thấy nhàm: đọc AC, liệt kê tổ hợp, sinh biến thể, trình bày theo bảng. Điều quan trọng cần nhớ: AI không thay bạn quyết định, nó tăng tốc phần "cơ bắp" — còn phần "phán đoán nghiệp vụ" vẫn là của bạn.
Một quy trình BA + AI điển hình:
- Bạn cung cấp AC rõ ràng cho AI.
- AI sinh bộ test case nháp (positive/negative/boundary).
- Bạn rà soát, cắt bỏ case sai bối cảnh, bổ sung case nghiệp vụ đặc thù.
- AI định dạng lại thành bảng/CSV nhập vào Jira, TestRail.
Ví dụ cụ thể
Giả sử bạn có AC cho tính năng đăng nhập: "Người dùng nhập đúng email và mật khẩu thì đăng nhập thành công; sai quá 5 lần thì khóa tài khoản 15 phút." Thay vì tự ngồi nghĩ, bạn đưa AC này cho AI và yêu cầu liệt kê mọi trường hợp kiểm thử. AI sẽ trả về ngay các case: đăng nhập đúng, sai mật khẩu, email không tồn tại, khóa sau lần thứ 5, mở khóa sau 15 phút, nhập email sai định dạng...
Prompt mẫu khởi động
Bạn là chuyên gia QA hỗ trợ tôi (một Business Analyst).
Dưới đây là acceptance criteria của một user story:
"""
[Dán AC của bạn vào đây]
"""
Hãy liệt kê tất cả trường hợp kiểm thử cần có, phân nhóm:
1) Trường hợp hợp lệ (positive)
2) Trường hợp không hợp lệ (negative)
3) Trường hợp biên (boundary)
Mỗi trường hợp ghi: mục tiêu kiểm thử, tiền điều kiện, dữ liệu đầu vào, kết quả mong đợi.
Nếu AC còn mơ hồ, hãy đặt câu hỏi làm rõ trước khi sinh test case.
Các bước áp dụng ngay hôm nay
- Chọn 1 user story bạn đang phải viết test case.
- Copy AC vào prompt mẫu ở trên.
- Đọc kết quả, gạch bỏ case không đúng nghiệp vụ, đánh dấu case còn thiếu.
- Yêu cầu AI bổ sung phần còn thiếu và xuất ra bảng.
- So sánh thời gian với cách làm cũ — ghi lại để thuyết phục team.
Template checklist "AI-ready" trước khi nhờ AI
- [ ] AC đã đủ rõ (có điều kiện, ngưỡng, thông báo lỗi cụ thể)?
- [ ] Đã nêu vai trò/persona sử dụng tính năng?
- [ ] Đã che/ẩn dữ liệu thật (tên khách, số điện thoại, tài khoản)?
- [ ] Đã yêu cầu AI hỏi lại khi thiếu thông tin?
- [ ] Đã xác định định dạng đầu ra mong muốn (bảng, CSV)?
Sai lầm thường gặp
- Tin AI vô điều kiện (ảo giác): AI có thể bịa ra quy tắc nghiệp vụ không có trong AC, ví dụ tự thêm "khóa tài khoản sau 3 lần" trong khi AC ghi 5 lần. Luôn đối chiếu từng case với AC gốc.
- Rò rỉ dữ liệu: Dán AC chứa dữ liệu khách hàng thật, thông tin nội bộ, tài khoản test có mật khẩu thật lên công cụ AI công cộng. Hãy ẩn danh dữ liệu và tuân thủ chính sách công ty.
- Phụ thuộc quá mức: Xem AI như "chân lý" và bỏ luôn bước rà soát. AI không hiểu bối cảnh ngầm (quy định pháp lý ngành, thói quen người dùng nội địa). BA vẫn là người chịu trách nhiệm cuối cùng.
Template sẵn dùng: UAT Test Cases
| Mã TC | Mô tả kịch bản | Bước thực hiện | Dữ liệu thử | Kết quả mong đợi | Kết quả thực tế | Trạng thái | Ghi chú |
|---|---|---|---|---|---|---|---|
| TC-01 | Đăng nhập đúng mật khẩu | 1. Mở trang login 2. Nhập user/pass đúng 3. Bấm Đăng nhập | user hợp lệ | Vào được trang chủ | — | Pass/Fail | — |
| TC-02 | Đăng nhập sai mật khẩu | 1. Nhập sai pass 3 lần | pass sai | Hiện cảnh báo, khóa tạm | — | Pass/Fail | — |
| — | — | — | — | — | — | — | — |
| — | — | — | — | — | — | — | — |
| — | — | — | — | — | — | — | — |
| — | — | — | — | — | — | — | — |