Làm manual quá nhiều? Việc nào nên giao cho AI trước, việc nào nên giữ lại
Không phải việc manual nào cũng nên tự động hoá. Bộ lọc 4 câu hỏi giúp bạn chọn đúng việc để giao cho máy, và giữ lại phần việc cần đến não QA.
Nếu bạn là QA manual, có lẽ bạn đã nghe câu “manual testing sắp chết” không dưới chục lần. Câu đó sai. Thứ đang chết là những việc lặp lại mà ta vẫn quen gọi là manual testing: copy test case lên công cụ quản lý test, dò từng con số giữa database và giao diện, chụp màn hình đặt cạnh Figma, cập nhật trạng thái từng test run.
Những việc đó tốn thời gian nhưng không cần nhiều phán đoán. Còn việc cần phán đoán — hiểu nghiệp vụ, đoán chỗ dễ vỡ, quyết định cái gì là lỗi — thì vẫn cần bạn, và thường là bị bỏ dở vì hết giờ.
Bài này giúp bạn tách hai nhóm việc đó ra, để biết nên giao gì cho AI trước.
Testing và checking: hai việc khác nhau
James Bach và Michael Bolton có một cách phân biệt rất hữu ích:
- Checking là xác nhận một điều đã biết trước: “API trả 200”, “ô này hiển thị 1.250.000”, “nút Lưu màu xanh như Figma”. Có kết quả mong đợi rõ ràng, so khớp là xong.
- Testing là khám phá: đặt câu hỏi, thử nghiệm, quan sát, học về sản phẩm để tìm ra những điều chưa ai viết thành yêu cầu.
Phần lớn công việc “manual” trong một sprint thực chất là checking làm bằng tay. Đó chính là phần nên giao cho máy. Testing thì không giao được — nhưng sẽ có thêm thời gian cho nó.
Bộ lọc 4 câu hỏi
Trước khi tự động hoá một việc, hỏi 4 câu:
- Việc này có lặp lại mỗi Story, mỗi sprint hay mỗi release không? Việc làm một lần thì không đáng công tự động hoá.
- Kết quả mong đợi có rõ ràng không? Nếu chính bạn còn phải hỏi BA mới biết đúng sai, máy cũng không biết.
- Dữ liệu đầu vào có lấy được tự động không? Story trên Jira, design trên Figma, dữ liệu trong DB, API có doc — đều lấy được. Một yêu cầu chỉ nằm trong đầu PM thì không.
- Nếu làm sai vì mệt, hậu quả có lớn không? Dò 300 con số bằng mắt lúc 5 giờ chiều là công thức của sai sót. Máy không mệt.
Việc nào trả lời “có” cho cả 4 câu là ứng viên số một.
7 việc nên giao cho AI trước tiên
1. Nhập test case và tạo cấu trúc test
Viết test trên Excel rồi chuyển lên Xray, tạo Test Set, Test Plan, Test Execution — mỗi Story một lần. AI có thể viết bản nháp test case từ AC, xuất CSV đúng định dạng import và tạo cấu trúc. Bạn chỉ cần đọc lại và sửa.
2. Đối soát số liệu giữa nhiều nguồn
Đây là việc “nguy hiểm” nhất khi làm tay, vì dữ liệu sai thường trông vẫn hợp lý. So file nguồn với database với giao diện là việc máy làm nhanh và đều tay hơn người.
3. Kiểm API theo tài liệu
Status code, tham số bắt buộc, kiểu dữ liệu từng trường, thời gian phản hồi — tất cả đều là checking. Có API doc là có kết quả mong đợi.
4. Phát hiện chênh lệch giao diện với design
AI có thể chụp trang thật, đặt cạnh frame Figma và liệt kê chỗ khác: lệch khoảng cách, sai màu, sai font, vỡ layout ở màn nhỏ. Việc đánh giá chỗ nào là lỗi thật, chỗ nào là design chưa cập nhật thì vẫn nên để bạn duyệt.
5. Gom bằng chứng và viết bug
Chụp ảnh, quay GIF, ghi bước tái hiện, điền môi trường, gắn link Story — đều là việc thủ tục. AI viết bản nháp, bạn kiểm tra rồi mới gửi.
6. Cập nhật trạng thái test run
Test nào PASS, FAIL, BLOCKED — nếu kết quả đã có trong báo cáo thì việc click từng ô là lãng phí.
7. Hồi quy và kiểm môi trường
Chạy lại các luồng chính trước mỗi lần go-live, kiểm staging có sống không trước khi bắt đầu test. Việc lặp lại hoàn hảo cho automation.
4 việc nên giữ lại cho mình
Hiểu nghiệp vụ và đánh giá rủi ro. Tính năng này ai dùng, sai thì mất gì, chỗ nào dễ vỡ nhất? AI có thể gợi ý, nhưng người chịu trách nhiệm chất lượng là bạn.
Exploratory testing. Thử những thứ không ai viết thành yêu cầu: đổi tab thật nhanh, mở hai cửa sổ cùng lúc, nhập dữ liệu kỳ quặc, dùng như một người dùng thiếu kiên nhẫn.
Quyết định cái gì là lỗi khi yêu cầu còn mơ hồ. Đây là lúc cần nói chuyện với BA, Dev, Designer. AI có thể soạn câu hỏi giúp, nhưng chốt là việc của con người.
Cảm nhận trải nghiệm. Một màn hình có thể đúng 100% so với design mà vẫn khó dùng. Chỉ người thật mới nhận ra.
Bắt đầu từ đâu?
Đừng cố tự động hoá cả quy trình trong một tuần. Thử cách này:
- Đo trước. Trong một sprint, ghi lại thời gian bạn dành cho từng loại việc. Bạn sẽ ngạc nhiên vì việc nào chiếm nhiều nhất.
- Chọn một việc tốn thời gian nhất và qua được bộ lọc 4 câu hỏi.
- Giao cho AI nhưng giữ điểm duyệt. Ở giai đoạn đầu, đọc kỹ mọi thứ AI tạo ra trước khi nó được ghi lên Jira.
- Ghi lại chỗ AI hay sai và chỉnh hướng dẫn. Sau vài Story, bạn sẽ biết có thể tin nó tới đâu.
- Khi việc đầu tiên đã chạy ổn, mới mở rộng sang việc thứ hai.
Ba cái bẫy thường gặp
- Tự động hoá thứ chưa ổn định. Giao diện còn đổi mỗi ngày thì script hồi quy sẽ vỡ mỗi ngày. Viết automation khi tính năng đã qua vòng test đầu.
- Không có điểm duyệt. AI viết bug sai rồi tự đăng lên Jira là cách nhanh nhất để mất lòng tin của Dev.
- Tin con số AI đưa ra mà không kiểm. Hãy yêu cầu nó luôn kèm bằng chứng: câu SQL đã chạy, response API, ảnh chụp.
Kết
Mục tiêu không phải là thay QA bằng AI, mà là trả lại cho QA phần việc cần đến QA. Khi checking được làm tự động, bạn có thời gian để làm testing thật sự — và đó mới là thứ làm nên giá trị của một người kiểm thử giỏi.