·

Quy trình Thực tế: Lập kế hoạch, Thực thi & Báo cáo Test

Đi qua một quy trình thực tế dùng TestRail MCP để AI agent quản lý test case, test run và kết quả kiểm thử từ đầu đến cuối.

Sau khi đã nắm cách kết nối TestRail MCP với từng công cụ riêng lẻ (Claude Code, OpenCode, Gemini CLI, Cursor), bài cuối module này ghép mọi thứ lại thành một workflow hoàn chỉnh, đi từ lúc nhận requirement đến lúc ký duyệt (sign-off) một chu kỳ test. Đây không phải lý thuyết — đây là quy trình 3 bước mà một team QA/dev thực tế có thể áp dụng ngay từ sprint tới, với từng bước có prompt mẫu cụ thể và tiêu chí rõ ràng để biết khi nào nên tin AI, khi nào cần con người can thiệp.

Tổng Quan Workflow: Từ Requirement Đến Chu Kỳ Test Được Ký Duyệt

Trước khi đi vào từng bước chi tiết, cần nhìn tổng thể bức tranh workflow để hiểu vai trò của AI ở mỗi giai đoạn — vì đây là điều nhiều team làm sai: giao toàn quyền cho AI ở giai đoạn cần con người quyết định, hoặc ngược lại bắt con người làm thủ công ở giai đoạn AI làm tốt hơn nhiều.

Workflow gồm 3 giai đoạn chính, mỗi giai đoạn có một "cổng duyệt" (approval gate) rõ ràng:

  1. Sinh và review case (từ requirement/spec) — AI đề xuất, con người duyệt trước khi ghi vào TestRail.
  2. Tạo run và đồng bộ kết quả automation — AI thực thi việc đồng bộ máy móc, nhưng theo quy tắc đã được định nghĩa sẵn (không tự sáng tạo quy tắc).
  3. Phân tích failure, flakiness (tính không ổn định), coverage để ký duyệt release — AI tổng hợp và phân tích, con người (QA lead/release manager) ra quyết định cuối cùng.

Nguyên tắc xuyên suốt: AI làm tốt nhất ở việc tổng hợp, phân tích, và thực hiện các thao tác lặp lại có quy tắc rõ ràng. Con người giữ quyền quyết định ở những điểm có tính đánh đổi nghiệp vụ (business trade-off) hoặc rủi ro cao. Đây không phải là nguyên tắc để "làm chậm AI", mà là nguyên tắc để workflow bền vững lâu dài — một quy trình mà QA lead tin tưởng đủ để không phải kiểm tra lại thủ công từng bước.

Mẹo: Vẽ workflow này ra thành một sơ đồ đơn giản (kể cả chỉ là danh sách 3 bước có gạch đầu dòng) và dán ngay trong file README.md của thư mục test hoặc trong CLAUDE.md/.cursor/rules. Khi có thành viên mới join team, họ hiểu ngay ở đâu AI được tự chủ, ở đâu cần chờ duyệt, không cần hỏi lại nhiều lần.

Bước 1: Sinh Và Review Test Case Từ Spec

Bước này bắt đầu ngay khi có requirement hoặc spec kỹ thuật mới (có thể là file markdown, Jira ticket đã được export, hoặc Figma spec kèm mô tả). Quy trình cụ thể:

Đọc file docs/specs/loyalty-points.md.
Bước 1a: Liệt kê các business rule chính và các trường hợp biên liên quan đến
tính điểm loyalty (ví dụ: giới hạn điểm tối đa/lượt, điểm hết hạn, điểm âm khi hoàn hàng).
Bước 1b: Với mỗi rule, đề xuất case tương ứng cho suite "Loyalty Points"
(project_id=12), theo template chuẩn trong CLAUDE.md.
Bước 1c: In bảng tổng hợp: [Tên case, Section, Priority, Rule liên quan]
để tôi duyệt. KHÔNG gọi testrail_add_case ở bước này.

Điểm mấu chốt của bước này là tách rõ giai đoạn phân tích (1a, 1b) và giai đoạn ghi dữ liệu, với lệnh cấm rõ ràng "KHÔNG gọi testrail_add_case ở bước này". Sau khi bạn xem bảng tổng hợp và phản hồi (ví dụ "OK case 1-5, 7; bỏ case 6 vì rule đó chưa được xác nhận với Product"), mới tiếp tục:

Tạo các case đã được duyệt (1-5, 7) vào section tương ứng.
Sau khi tạo xong, in ra bảng case_id vừa tạo kèm tên case để tôi lưu lại tham chiếu.

Trong thực tế, đây là bước tiết kiệm thời gian rõ rệt nhất trong cả workflow — một spec dài vài trang mà trước đây QA phải mất nửa ngày để phân rã thành case, giờ AI làm bước phân rã và đề xuất trong vài phút, con người chỉ cần review và điều chỉnh, thường mất 15-20 phút cho một spec cỡ trung bình.

Mẹo: Nếu bảng đề xuất case ở bước 1c có case mà bạn thấy "thiếu logic" (case dựa trên rule sai hoặc hiểu sai spec), đừng chỉ sửa case đó — hỏi ngược lại agent "case số 6 dựa trên rule nào trong spec, trích nguyên văn đoạn đó ra". Việc này giúp bạn phát hiện agent hiểu sai spec ở gốc (thường do đoạn spec đó viết mơ hồ), có ích để cả sửa spec, không chỉ sửa case.

Bước 2: Tạo Run Và Đồng Bộ Kết Quả Automation Ngược Về

Sau khi case đã tồn tại trong TestRail (từ bước 1, kèm annotation case ID đã gắn vào code test theo cách đã nói ở các bài trước trong module), bước 2 diễn ra mỗi khi có một lần chạy CI/CD hoặc một lượt test tay theo kế hoạch:

Tạo run mới "Loyalty Points - Sprint 25 Regression" trong suite "Loyalty Points",
bao gồm toàn bộ case có annotation trong thư mục tests/e2e/loyalty/.
Sau khi tạo run, đọc file test-results/junit.xml từ lần chạy CI mới nhất
(build #517), map từng test case theo annotation "TestRail: C<số>",
ghi result: Passed nếu pass, Failed kèm nội dung lỗi đầy đủ nếu fail.
Case nào có annotation nhưng không xuất hiện trong report (có thể do bị skip
trong CI), đánh dấu status "Untested" và ghi rõ lý do trong comment.

Điểm quan trọng ở bước này là quy tắc xử lý trường hợp case bị skip trong CI — nếu không quy định rõ, agent có thể mặc định để trống hoặc gán sai status, dẫn đến báo cáo coverage sai. Việc chỉ định rõ "đánh dấu Untested kèm lý do" giữ tính minh bạch cho dữ liệu.

Với team đã trưởng thành hơn về automation, bước này thường được đưa hẳn vào CI pipeline, chạy tự động sau mỗi lần merge vào nhánh chính, không cần con người bấm tay:

claude -p "Tạo run 'Regression - build #${BUILD_NUMBER}' trong suite 'Loyalty Points',
đồng bộ kết quả từ test-results/junit.xml theo annotation TestRail." \
  --allowedTools "mcp__testrail__*" \
  --output-format json >> ci-logs/testrail-sync-${BUILD_NUMBER}.log

Mẹo: Luôn lưu log đầy đủ (--output-format json hoặc tương đương) của mỗi lần đồng bộ tự động trong CI ra file riêng theo build number. Khi có tranh cãi "sao case này lại Failed mà code đã fix rồi", bạn có ngay bằng chứng build nào, thời điểm nào, agent đã ghi result gì, không phải đoán mò dựa trên UI TestRail hiện tại (đã bị ghi đè bởi các run sau đó).

Bước 3: Phân Tích Failure, Flakiness Và Coverage Để Ký Duyệt Release

Đây là bước cuối, thường diễn ra 1-2 ngày trước buổi go/no-go meeting, và là bước có tác động quyết định nhất — nên đây cũng là bước AI đóng vai trò "chuẩn bị dữ liệu và phân tích", còn quyết định cuối cùng luôn thuộc về con người.

Chuẩn bị phân tích ký duyệt cho Release 4.0, dựa trên toàn bộ run gắn với
milestone "Release 4.0" trong suite "Loyalty Points" và "Checkout":

1. Case nào Failed ở lần chạy gần nhất VÀ đã từng Failed ít nhất 1 lần trong
   3 run trước đó (nghi ngờ bug thật, không phải flaky).
2. Case nào có kết quả không nhất quán qua các run (lúc Pass lúc Fail dù code
   không đổi giữa các lần chạy) - đây là dấu hiệu flaky test cần được dev
   điều tra riêng, không tính vào rủi ro release.
3. Case priority=High đang ở trạng thái Untested hoặc Blocked.
4. Tổng hợp thành bảng risk, xếp theo mức độ nghiêm trọng, KHÔNG tự đưa ra
   kết luận "release được" hay "không release được" - chỉ trình bày dữ kiện
   khách quan để QA lead và release manager tự quyết định trong buổi go/no-go.

So với ví dụ báo cáo release readiness ở bài Gemini CLI (nơi agent được phép đưa ra kết luận đề xuất dựa trên quy tắc cứng đã định nghĩa sẵn), ở bước ký duyệt cuối cùng này, cách làm cẩn trọng hơn là yêu cầu agent chỉ trình bày dữ kiện, không tự đưa ra kết luận go/no-go. Sự khác biệt này quan trọng: report tự động dùng nội bộ hàng ngày có thể để AI đề xuất kết luận theo rule đã thống nhất, nhưng report dùng trực tiếp trong buổi ra quyết định chính thức với stakeholder cấp cao nên giữ AI ở vai trò "chuẩn bị dữ kiện", để trách nhiệm ra quyết định luôn rõ ràng thuộc về con người có thẩm quyền.

Phân biệt flaky test và bug thật (mục 1 và 2 trong prompt trên) là giá trị lớn nhất của bước này — đây là việc mà nếu làm thủ công, QA lead phải nhớ lịch sử nhiều run trong đầu hoặc lật lại từng run một cách tốn thời gian; AI với khả năng đọc testrail_get_results_for_run của nhiều run cùng lúc, đối chiếu case theo case, làm việc này nhanh và ít bỏ sót hơn.

Mẹo: Với case bị xác định "nghi flaky" (mục 2), đừng để nó biến mất khỏi radar. Yêu cầu agent tự tạo thêm một case hoặc một ticket riêng dạng "Điều tra flaky: C" để tracking, tránh tình trạng "phát hiện flaky rồi quên" — vấn đề flaky test nếu không được theo dõi có xu hướng lặp lại y nguyên ở mỗi chu kỳ release sau.

Mẹo

Tổng kết lại toàn bộ workflow 3 bước, đây là những nguyên tắc vận hành nên áp dụng nhất quán trong suốt vòng đời của một dự án dùng TestRail MCP với AI agent:

  • Luôn giữ "cổng duyệt của con người" (human approval gate) ở đúng 2 điểm: trước khi ghi case mới vào TestRail, và trước khi kết luận go/no-go release — hai điểm này không nên bị AI tự động hoá hoàn toàn dù công cụ có mạnh đến đâu.
  • Chuẩn hoá annotation case ID trong code test là hạ tầng bắt buộc, không phải "nice to have" — toàn bộ bước 2 và bước 3 của workflow phụ thuộc trực tiếp vào việc annotation này chính xác và đầy đủ.
  • Định kỳ (mỗi quý) nhìn lại toàn bộ workflow: có bước nào giờ có thể tự động hoá thêm (vì team đã tin tưởng đủ qua thời gian sử dụng), có bước nào đang tự động hoá quá tay cần siết lại kiểm soát (vì đã có sự cố hoặc gần sự cố) — workflow AI-QA nên là một hệ thống sống, được điều chỉnh liên tục, không phải một cấu hình one-shot làm một lần rồi để nguyên.

Mẹo: Sau mỗi release lớn, tổ chức một buổi retro ngắn (15-20 phút) riêng cho phần "AI trong quy trình QA": việc gì AI làm tốt hơn kỳ vọng, việc gì cần con người can thiệp nhiều hơn dự kiến. Đưa insight này ngược lại vào file rule (CLAUDE.md, .cursor/rules) để workflow của sprint sau tốt hơn sprint trước — đây chính là cách một team thực sự "học" cách làm việc với AI agent theo thời gian, không phải chỉ setup một lần rồi mặc kệ.