🤖 Bạn đã bao giờ copy một prompt trên mạng, chạy thử… và nhận về một đống test case không dùng được chưa?
Sau nhiều năm làm tester, và vài năm gần đây dùng AI gần như mỗi ngày, mình nhận ra một điều khá thú vị: prompting thực chất chỉ là cách bạn đặt yêu cầu. Giống cách bạn hay trao đổi với DEV, PM, hay với các bạn trong nhóm dự án. Chỉ khác một điều, bây giờ người “nghe” bạn là AI.
Và giống như khi làm việc với DEV hay PM, bạn không thể copy nguyên câu hỏi của người khác và mong nhận được kết quả phù hợp với hệ thống của mình. Với AI cũng vậy.
Prompting là gì
Theo góc nhìn của một tester, mình không định nghĩa theo kiểu sách vở. Có thể hiểu theo cách đơn giản:
Prompt = cách bạn mô tả vấn đề + kỳ vọng đầu ra cho AI.
- Trước đây bạn nói: “Viết giúp mình test case cho màn hình tạo user”
- Thì bây giờ bạn nói: “Generate test cases for Create User screen with validation rules…”
Nghe rất quen đúng không?
Vì sao tester cần học prompting?
AI chỉ hiểu cách bạn diễn đạt. Vì AI không ‘hiểu ý bạn’, nó chỉ suy luận dựa trên những gì bạn viết. Nên, cùng một yêu cầu nghiệp vụ, prompt tốt và prompt kém sẽ cho ra kết quả hoàn toàn khác nhau.
Nếu prompt kém, bạn sẽ mất nhiều thời gian sửa lại kết quả của AI hơn so với tự viết test case.
Ví dụ với màn hình “Tạo user mới”:
- Prompt kém: “Viết test case cho create user”
- Prompt tốt hơn:
“Bạn là tester 5 năm kinh nghiệm. Hãy viết test case cho màn hình Create User gồm các trường Name (required), Email (format), Password (min 8 ký tự). Bao gồm positive, negative, và edge cases.”
👉 Sự khác biệt nằm ở:
- Mức độ bao phủ đầy đủ nghiệp vụ và các khía cạnh cần kiểm thử
- Mức độ bám sát thực tế, theo đúng yêu cầu nghiệp vụ cụ thể
- Khả năng dùng được ngay mà không cần chỉnh sửa, viết lại nhiều
Trước đây mình nghĩ: “AI sẽ làm việc giúp mình”
Nhưng sau một thời gian, mình nhận ra: AI chỉ tốt khi bạn hỏi tốt.
Prompting không phải là “ra lệnh”, mà là trao đổi, cộng tác, chỉnh sửa. Nó giống như các hoạt động thường ngày: bạn review test case của đồng nghiệp hoặc bạn pair testing với Tester hoặc DEV.
So sánh kết quả
| Prompt kém | Prompt tốt |
| TC01 – Create user successfully | TC01 – System creates a new user successfully with valid data |
| TC02 – Invalid email | TC02 – System shows error message and prevents user creation when email format is invalid |
| TC03 – Password error | TC03 – System rejects password shorter than 8 characters |
Một prompt tốt không phải “viết dài”, mà là “viết đúng cấu trúc”
Sau khi đọc thêm tài liệu bao gồm ISTQB Testing with Generative AI (CT-GenAI), mình thấy có một cấu trúc rất đáng để nhớ: Một prompt tốt thường có 6 thành phần. Điều thú vị là bạn đã dùng gần hết rồi, chỉ là chưa gọi tên.
Những sai lầm phổ biến khi viết prompt
Đây là một số sai lầm thường gặp trong prompting. Mình từng mắc gần hết 😄
- Prompt quá ngắn: sẽ cho ra kết quả chung chung
- Không có ngữ cảnh: AI sẽ đoán mò và kết quả thì hên xui
- Không có format: Kết quả phải được sửa lại rất nhiều trước khi sử dụng được
- Kỳ vọng AI hiểu domain nhưng chúng ta lại không cung cấp thông tin cụ thể
6 thành phần của một prompt “chuẩn chỉnh”
Mình vẫn dùng ví dụ quen thuộc: viết test case cho màn hình Create User screen.
1. Role – AI đang đóng vai trò gì?
Khi được cung cấp vai trò, Role giúp AI trả lời “giống tester hơn”.
Ví dụ: “Bạn là tester 7 năm kinh nghiệm” Hoặc cụ thể hơn: “Bạn là QA chuyên về web application”
2. Context – Bối cảnh hệ thống
Ngữ cảnh càng rõ, kết quả càng sát thực tế và mong muốn của bạn.
Ví dụ: “Màn hình Create User cho phép admin tạo user mới gồm:
- Name (required)
- Email (hợp lệ)
- Password (min 8 ký tự)
- Confirm Password
- Role (Admin/User)”
3. Instruction – Bạn muốn AI làm gì?
Mô tả hướng dẫn ngắn gọn, rõ ràng theo dạng mệnh lệnh.
Ví dụ: “Hãy viết test case bao gồm các khía cạnh: positive, negative và edge cases”
4. Input Data – Dữ liệu đầu vào
Đây là phần giúp AI hiểu đúng nghiệp vụ cụ thể. Nếu trong mô tả yêu cầu có phần này, thì bạn nên cân nhắc đưa vào prompt. Mình cũng có thể yêu cầu AI phân tích tài liệu mô tả yêu cầu để liệt kê thông tin này. (tham khảo kỹ thuật Prompt Chaining bên dưới).
Ví dụ:
“User story: As an admin, I want to create a new user…”
“Acceptance criteria:
- Email phải hợp lệ và không tồn tại trong hệ thống
- Password phải có ít nhất 1 chữ hoa, 1 chữ thường, và 1 số”
5. Constraints – Ràng buộc
Nếu không có “constraints”, AI sẽ tối ưu theo ‘độ đầy đủ’, không phải ‘độ hữu dụng’. Và đó là lý do kết quả trả về thường dài (trông có vẻ đầy đủ) nhưng khó dùng được ngay.
Ví dụ:
- “Giới hạn 20 test case”
- “Chỉ tập trung vào validation”
- “Test case không trùng lặp”
6. Output Format – Định dạng đầu ra
Nếu không mô tả định dạng mong muốn, AI sẽ trả về ngẫu nhiên. Nếu cung cấp thông tin này, sẽ giúp bạn dùng được kết quả ngay.
Ví dụ: “Test case được trình bày theo dạng bảng bao gồm các thông tin sau: Test ID, Test Description, Test Steps, Expected Result”
🍀 Checklist giúp bạn viết prompt nhanh
Bạn nên ghi checklist ngắn gọn này và dán nó lên màn hình sẽ giúp bạn viết prompt tốt hơn. Sau khi viết xong 1 prompt, hãy tự hỏi:
- Đã có Role chưa?
- Context đã đủ chưa?
- Instruction rõ chưa?
- Có Constraints chưa?
- Output có dùng được ngay không?
Một prompt hoàn chỉnh (có thể dùng ngay)
Đây là một phiên bản mình thấy khá “chuẩn”, với prompt này, mình thường dùng được ngay 80%.
- “Bạn là một tester 6 năm kinh nghiệm (Role).
- Màn hình Create User cho phép admin tạo user với các field: Name, Email, Password, Confirm Password (Context).
- User story: As an admin, I want to create a new user (Input Data).
- Hãy viết test case bao gồm positive, negative và edge cases (Instruction).
- Giới hạn 20 test case, không trùng lặp, sắp xếp giảm theo độ ưu tiên (Constraints).
- Trả về dạng bảng: Test ID | Test Description | Test Steps | Expected Result (Output Format).”
3 Kỹ thuật Prompting quan trọng với kiểm thử
Prompt có cấu trúc tốt thôi thì chưa đủ. Trong thực tế, mình thấy có 3 kỹ thuật prompting cực kỳ hữu ích khi áp dụng vào các hoạt động kiểm thử.
Prompt Chaining – Chia nhỏ yêu cầu
Đừng cố nhồi nhét mọi thứ trong một prompt. Rất dễ làm cho AI gặp hiện tượng ảo giác (hallucinate) và tạo ra kết quả không sử dụng được. Thay vào đó, bạn có thể chia nhỏ yêu cầu của bạn thành nhiều bước.
Ví dụ như:
- Bước 1: “Liệt kê validation rule của Create User” (thực tế: phân tích tài liệu)
- Bước 2: “Tạo test case từ các rule trên” (thực tế: viết test case)
- Bước 3: “Loại bỏ test case trùng lặp” (thực tế: review lại test case đã viết)
Kết quả cuối thường sẽ chính xác và dễ kiểm soát hơn. Điều này giống như cách bạn làm testing thực tế ngoài đời. Để áp dụng tốt kỹ thuật này, tester cần phải có tư duy hệ thống. Bạn suy nghĩ mọi công việc hằng ngày của mình theo hướng các bước cụ thể. Từ đó có thể hướng dẫn AI làm việc tốt hơn.
Few-shot Prompting – Cho AI xem ví dụ
AI học rất nhanh khi được cung cấp mẫu. Kỹ thuật này mang lại lợi ích rất lớn đó là kết quả do AI tạo ra, ví dụ test case, sẽ có định dạng/cách trình bày nhất quán và phù hợp với phong cách viết test case trong dự án. Tăng khả năng dùng được ngay.
Thực tế, few-shot không chỉ giúp AI ‘viết giống bạn’, mà còn giúp bạn định nghĩa thế nào là một test case tốt trong dự án của mình. Thay vì chỉ yêu cầu AI viết test case, bạn nên cung cấp thêm một số ví dụ về cách trình bày hoặc test case mẫu, như sau:
“Ví dụ:
TC01 – Prevent user creation and display error message for invalid email
TC02 – Prevent user creation and display error message for password shorter than 8 characters
Hãy viết thêm test case tương tự”
Meta Prompting – Nhờ AI viết prompt
Khi bạn không biết viết prompt sao cho tốt, hãy hỏi AI. Giống như bạn đang pairing với AI. Meta prompting đặc biệt hữu ích khi bạn chưa rõ mình cần gì. AI có thể giúp bạn làm rõ yêu cầu trước khi thực hiện. Nhiều khi, prompt tốt nhất không phải do bạn viết, mà là do AI giúp bạn viết.
Ví dụ như:
- Trước tiên, bạn prompt: “Hãy giúp tôi viết prompt tối ưu để generate test case cho Create User”
- Sau đó, điều chỉnh: Bạn cung cấp thêm thông tin vào prompt theo cấu trúc chuẩn (đã đề cập ở đầu bài viết này), dùng tiếp, và cải thiện dần.
Kết lại
Không phải lúc nào cũng nên dùng AI. Khi làm việc với nghiệp vụ phức tạp, liên quan đến nhiều chức năng khác nhau, hoặc phụ thuộc nhiều vào kiến thức chuyên ngành, chúng ta nên tự phân tích yêu cầu trước. Khi đã nắm vững yêu cầu nghiệp vụ, bạn nên chia nhỏ ra và nhờ AI phân tích viết test case cho mình. Bạn chỉ xem xét và chọn những test case phù hợp.
Nếu bạn mới bắt đầu áp dụng AI vào công việc, đừng quá áp lực với prompting.
Thực ra bạn đã làm điều này từ lâu rồi:
- Cách bạn tư duy, suy nghĩ khi phân tích yêu cầu và viết test case
- Cách bạn thu thập thông tin để post bug (báo cáo lỗi cho developer)
- Cách bạn trao đổi, thảo luận, và tranh luận với developer hay PM khi mô tả yêu cầu không rõ ràng.
Chỉ là bây giờ, bạn đang làm những điều này với AI.
Nếu bạn áp dụng đúng cách, chỉ riêng màn hình Create User thôi, bạn đã có thể tiết kiệm hàng giờ viết test case mỗi tuần.
Và điều quan trọng nhất mình rút ra là:
- Tester giỏi không phải là người viết nhiều test case nhất.
- Mà là người biết đặt câu hỏi tốt nhất, kể cả với con người hay AI.
Nên nhớ rằng, AI không thay thế tester. Nhưng tester biết dùng AI sẽ thay thế tester không biết dùng AI.
