Quality Control(QC)
Hoạt động soi sản phẩm đã làm ra để tìm chỗ sai so với yêu cầu: chạy test case, log bug, verify lại sau khi dev fix. Ở Việt Nam, QC còn là tên gọi của chính người làm việc đó.
Định nghĩa
Ở phần lớn công ty Việt Nam, "QC" là bạn ngồi cách bạn hai cái bàn, nhận build từ dev, chạy test case rồi log bug lên Jira. Còn theo ISTQB, QC hẹp hơn cái nghĩa đó: nó là nhóm hoạt động nhằm phát hiện lỗi trên sản phẩm đã được tạo ra. Soi kết quả, chứ không sửa quy trình.
QC kiểm tra thứ đã làm xong để tìm chỗ sai; nó chỉ bắt đầu khi đã có cái gì đó để soi.
QC, QA và Tester khác nhau chỗ nào
| Tiêu chí | QA | QC | Tester |
|---|---|---|---|
| Mục tiêu | Ngăn lỗi phát sinh | Tìm lỗi đã phát sinh | Thực thi việc tìm lỗi |
| Hướng tới | Quy trình, chuẩn làm việc | Sản phẩm, build cụ thể | Test case, bug report |
| Thời điểm | Từ lúc lập kế hoạch | Sau khi có sản phẩm | Sau khi có build |
| Đầu ra | Checklist, template, biên bản review | Kết quả test, danh sách defect | Ca test đã chạy |
| Thực tế VN | Hiếm có vị trí QA thuần | Thường gọi luôn là QC | Nhiều nơi dùng thay QC |
QA sửa cái khuôn, QC soi cái đúc ra từ khuôn đó, còn Tester là người trực tiếp cầm sản phẩm lên xem. Ba chữ này ở nước ngoài phân vai rõ, ở VN thì tin tuyển dụng ghi "QA/QC Engineer" rồi mô tả công việc toàn là chạy test case. Đi phỏng vấn cứ hỏi thẳng: bên mình QA có làm audit quy trình không, hay chủ yếu test.
Ai làm, làm lúc nào
QC vào cuộc sớm hơn nhiều người tưởng. Chuẩn thì ngay khi có bản đặc tả đã đọc và soi được, chứ không đợi build.
- Giai đoạn phân tích: đọc FRD, hỏi ngược lại BA. Một QC giỏi tìm ra luồng xử lý còn thiếu trước cả khi dev viết dòng code đầu tiên.
- Thiết kế test: scenario, test case, dữ liệu.
- Thực thi: chạy trên SIT, log defect, theo dõi tới lúc đóng.
Khúc cuối mới là khúc hay bị cắt vì hết giờ: chạy regression trước khi phát hành, rồi smoke ngay trên PROD sau khi deploy, kể cả deploy lúc nửa đêm.
Ví dụ thực tế
"Ví trừ tiền rồi mà đơn vẫn báo thất bại." QC nhắn vào nhóm gần trưa ngày thứ chín của đợt SIT, kèm mã giao dịch và một đoạn log. Hóa đơn 1.850.000đ, callback từ nhà cung cấp về chậm quá 30 giây, hệ thống đánh dấu thất bại mà không hoàn tiền.
Dự án là cổng thu hộ hóa đơn điện nước cho 118 cửa hàng tiện lợi. Ba QC, hai tuần SIT, 337 test case, 87 defect trong đó 9 cái Critical.
Không QC nào tìm ra nó bằng cách bấm thử cho vui. Họ tìm ra vì có test case cố tình làm chậm callback. Và cả 9 lỗi nặng nhất đều nằm ở luồng ngoại lệ — luồng chính thì dev tự test cũng thấy.
Lỗi hay gặp
- Coi QC là chốt chặn cuối, dồn hết trách nhiệm chất lượng cho họ. Bug lọt lên PROD thì đổ tại QC, trong khi nguyên nhân gốc là spec viết mơ hồ.
- Đưa QC vào dự án lúc đã code xong 80%. Họ không kịp hiểu nghiệp vụ, test case viết ra chỉ soi được giao diện.
- Không cho QC quyền chặn release. Có QC mà bảo gì cũng "cứ lên đi, lỗi nhỏ mà" thì thà không có.
- Đo hiệu suất QC bằng số bug log được. Kiểu đo này đẻ ra hàng chục bug rác về căn lề và màu chữ.
BA phối hợp với QC thế nào cho đỡ mệt
Gửi cho QC bản draft tài liệu trước khi chốt, đừng đợi bản final. Họ đọc theo kiểu tìm chỗ hở, khác hẳn cách dev đọc. Ngồi review test case với họ ít nhất một buổi cho mỗi module lớn — chính lúc đó bạn sẽ phát hiện mình quên mô tả trường hợp người dùng bấm nút hai lần.
Và khi dev với QC đẩy qua đẩy lại một defect vì tài liệu không rõ, người phân xử là BA. Né thì cái defect đó nằm im đúng bằng số ngày bạn im lặng. Trả lời dứt khoát: tài liệu có mô tả mà dev làm khác, hoặc tài liệu thiếu thật, mình nhận rồi bổ sung ngay hay mở CR.
