Tester Kit: agent chạy kiểm thử, người quyết định

Vấn đề

Đội Tester kiểm thử 100% thủ công. Đa số thành viên không mạnh về công nghệ nên không viết được automation theo cách truyền thống. Mỗi người một ngày chỉ xong tối đa 3 đến 4 task, không đủ thời gian chạy lại case cũ, trong khi đội Dev đã dùng AI và đẩy tính năng ra nhanh hơn tốc độ kiểm thử.

Trước Tester KitBug cũ quay lại vì không ai kịp chạy lại case cũ

• Bug lặp lại
• Bug mới

• Bug của một modulekhoảng 30% là bug lặp lại

  3070

Bối cảnh và vai trò

• Team Tester bốn người, phục vụ nhiều dự án song song.
• Test case lưu trên bảng tính, nhiều case lặp lại giữa các lần phát hành.
• Tôi thiết kế quy trình, xây skill, đào tạo và theo dõi việc áp dụng, song song với vai trò BA.
• Ràng buộc: tester không viết code; agent không được tự quyết định đạt hay lỗi; mọi kết quả phải có evidence.

Bước 1: Phân loại test case

Không phải case nào cũng nên giao cho agent.

Phân loạiCase nào giao agent, case nào test tay

	Ví dụ	Giao agent	Người làm gì
Kiểm tra API và dữ liệu	Endpoint trả đúng mã, database đúng trạng thái	Có	Xác minh báo cáo
Luồng giao diện lặp lại, ổn định	Đăng nhập, tạo bản ghi, lọc danh sách	Có	Xác minh evidence
Luồng nghiệp vụ nhiều bước, có tính toán	Thanh toán một phần rồi kiểm tra công nợ	Có	Xác minh từng bước và số liệu
Cảm quan giao diện, trải nghiệm	Bố cục, màu sắc, thông điệp	Không	Test tay
Tích hợp bên thứ ba, thanh toán thật	Webhook, cổng thanh toán	Không	Test tay có kiểm soát
Khám phá	Tìm lỗi ngoài kịch bản	Không	Tester có chuyên môn

Bước 2: Thiết kế Tester Kit

Bộ kit gồm 8 skill, đóng gói để tester chỉ cần cài vào IDE là chạy được case tự động, không cần viết code. Các skill tiêu biểu nối thành một chuỗi:

Tester KitMỗi skill một việc, mỗi việc một đầu ra

1. 1Sinh test casetừ story, acceptance criteria, business rules
2. 2Kiểm tra trước khi chạymôi trường, dữ liệu mẫu, tài khoản test
3. 3Chạy bộ casetrên staging, chụp ảnh, lưu log
4. 4Regressionchạy lại case cũ của module vừa đổi
5. 5Nháp bugbước tái hiện, kỳ vọng, thực tế
6. 6Gom evidencethư mục đính kèm ticket

Quy tắcÁp cho mọi skill

• Agent chỉ đưa kết quả sơ bộ: có vẻ đạt, có vẻ lỗi, hoặc không chắc.
• Mỗi kết quả phải kèm evidence: ảnh, log, giá trị thực tế.
• Không chạm dữ liệu production. Chỉ dùng tài khoản test.
• Quyết định đạt hay lỗi cuối cùng thuộc về tester.

Bước 3: Chạy song song

Mỗi tester mở 10 đến 15 tab IDE agent (Claude Code, Codex, Antigravity), mỗi phiên chạy một nhóm case. Agent chạy trước, tester theo dõi bảng tổng hợp.

Một ngày của tester

• Tester
• Agent

1. 1TesterChia nhóm case
2. 2AgentChạy song songmỗi phiên một nhóm case10–15
3. 3AgentKết quả sơ bộkèm evidence
4. 4TesterXác minh evidence
5. 5TesterTest taycase lỗi, case không tự động được
6. ?TesterQuyết định QA

Bước 4: Tình huống “trông có vẻ đạt”

Ví dụ mô phỏng cho thấy vì sao con người vẫn phải xác minh. Case: ghi nhận 1.000.000đ cho hoá đơn 3.000.000đ, công nợ phải giảm đúng 1.000.000đ.

Bước 5: Vai trò mới của tester

Tester từ người làm thủ công mọi thứ trở thành người xác minh kết quả AI đã làm.

Vai trò mới

1. 1Thiết kế test caseAI tạo bản nháp
2. 2Chọn case giao agent
3. 3Điều phối phiên agenttheo dõi bảng tổng hợp
4. 4Xác minh evidencetest tay case lỗi, case không chắc
5. ?Quyết định đạt hay lỗi
6. 6Bug report có evidence

Kết quả

Theo đo lường nội bộ:

• Trước
• Sau

• Bug lặp lại trên cùng một module✓ 30% → 5%

  30%
  5%

Trên dự án khách hàng Mỹ, đếm từ kho tài liệu dự án:

Bộ kit đã bàn giao cho tester, kể cả một tester dùng Ubuntu, kèm hướng dẫn cho người không chuyên kỹ thuật.

Điều tôi học được

• Người không viết code vẫn điều khiển được kiểm thử tự động nếu công cụ nói ngôn ngữ của họ: test case và evidence.
• Agent không phải người quyết định đạt hay lỗi. Tester vẫn chịu trách nhiệm xác minh kết quả kiểm thử.
• Tự động hoá giá trị nhất ở chỗ giải phóng thời gian cho phần việc cần con người: case khó và kiểm thử khám phá.