3 phút đọcRead in English
Thiết kế test trước, viết code sau
Thiết kế test case trước khi viết code: Tokay biến yêu cầu thành bảng các trường hợp dễ review, và VibeQA đo coverage bằng một quy tắc cố định.
Khi một AI viết test cho bạn, cách nhanh nhất là để nó viết thẳng ra code. Bạn nhận về một file Playwright vài trăm dòng, chạy xanh, và câu hỏi quan trọng nhất vẫn chưa có lời giải: bộ test này đã thử những trường hợp nào, và bỏ sót trường hợp nào?
Đọc code để trả lời câu hỏi đó rất mệt. Vì vậy trong VibeQA, thiết kế test case đi trước: Tokay viết test design, người duyệt design, rồi mới tới code.
Một bản thiết kế test case gồm những gì
Test design đi từ yêu cầu tới từng dòng dữ liệu test:
- Yêu cầu: lấy từ ticket hoặc tài liệu, ví dụ "Thông tin giao hàng được kiểm tra trước khi thanh toán".
- Cây phân lớp: mỗi input được chia thành các lớp tương đương, hợp lệ và không hợp lệ, có đánh dấu giá trị biên.
- Kịch bản Gherkin với bảng Examples: mỗi dòng trong bảng là một trường hợp test cụ thể.
Lấy ví dụ ô số điện thoại:
| Lớp | Loại |
|---|---|
| Số di động 10 chữ số | Hợp lệ |
| Định dạng +84 | Hợp lệ |
| 9 chữ số | Không hợp lệ, giá trị biên |
| 11 chữ số | Không hợp lệ, giá trị biên |
| Có chữ cái | Không hợp lệ |
Đọc bảng này mất mười giây, và một QA có kinh nghiệm sẽ thấy ngay nếu thiếu gì, ví dụ số có khoảng trắng hay có dấu gạch ngang.
Coverage do quy tắc tính, không do ai tự khai
Tokay không được tự nói "coverage đủ rồi", và người review cũng không. Coverage được tính bằng một quy tắc cố định:
- Mỗi lớp xuất hiện ít nhất một lần trong bảng Examples.
- Mọi giá trị biên đều được test.
- Mỗi dòng có tối đa một lớp không hợp lệ. Nếu một dòng vừa sai số điện thoại vừa sai địa chỉ, form báo lỗi ở ô đầu tiên và lỗi ở ô thứ hai không bao giờ được kiểm.
- Với yêu cầu rủi ro cao, mọi cặp lớp hợp lệ thuộc hai input khác nhau phải được test cùng nhau ít nhất một lần (pairwise).
Một lớp có thể được loại trừ khỏi coverage, nhưng phải ghi lý do, và lý do đó nằm ngay trong design để người sau còn đọc được.
Người duyệt từng trường hợp
Bạn review design như review một tài liệu: bấm "Đúng rồi" cho từng trường hợp, sửa tay, hoặc gắn
@Tokay vào một comment để nó đề xuất thay đổi, và bạn chấp nhận hay từ chối đề xuất đó. Nếu một
dòng bị sửa sau khi đã duyệt, nó cần được duyệt lại.
Chỉ khi coverage đủ và mọi trường hợp đã được một người duyệt ở dạng hiện tại, Tokay mới sinh code:
mỗi dòng Examples thành một test() có tên như TC-2.3. Code đó được chạy thử một lần, và kết quả
được map ngược lại từng dòng trong design. Nhờ vậy khi TC-2.3 fail, bạn biết ngay đó là trường hợp
"9 chữ số", không phải một dòng nào đó trong file 400 dòng.
Cái giá phải trả
Viết design trước chậm hơn viết code thẳng, vài phút với một form nhỏ. Đổi lại, thứ bạn duyệt là thứ bạn đọc được, và câu "bộ test này đã thử những gì" luôn có câu trả lời mà không cần mở code.