Quality Assurance(QA)
Tập hợp hoạt động hướng vào quy trình để lỗi ít có cơ hội sinh ra: đặt chuẩn tài liệu, review, audit, cải tiến cách làm. QA nhìn vào cách làm việc chứ không nhìn từng build.
Định nghĩa
Bạn sửa bug lần thứ ba cho cùng một màn hình. Lần nào cũng do dev hiểu sai một trường dữ liệu vì tài liệu ghi mập mờ. QC tìm ra bug đó ba lần, đúng việc của họ. QA là người hỏi câu khác: tại sao tài liệu của mình cứ mập mờ ở chỗ này, sửa cách viết tài liệu đi.
QA tác động vào cách làm việc để lỗi bớt sinh ra, thay vì đợi lỗi xuất hiện rồi bắt.
Gồm những gì
Theo ISTQB, quality assurance thuộc nhóm process-oriented, còn testing thuộc nhóm product-oriented. Công việc QA thật sự làm:
- Định nghĩa quy trình: khi nào được merge, definition of done gồm gì, defect mức nào thì được phép lên PROD.
- Chuẩn hóa tài liệu: template test plan, template bug report, checklist review FRD.
- Đo và cải tiến: theo dõi defect leakage, tổ chức retrospective, truy nguyên nhân gốc.
Còn hai phần nữa hiếm khi ghi trong tin tuyển dụng mà lại ngốn nhiều thời gian nhất: đi review và audit — ngồi dự các buổi review, đọc lại tài liệu, kiểm xem dự án có chạy đúng cái quy trình đã cam kết với khách hay không — và onboard người mới theo đúng chuẩn dự án.
Hoạt động QA và hoạt động QC đặt cạnh nhau
| Việc cụ thể | Thuộc QA | Thuộc QC |
|---|---|---|
| Viết template bug report | Có | |
| Log một bug theo template đó | Có | |
| Xây checklist review tài liệu | Có | |
| Chạy 214 test case cho bản build 2.3 | Có | |
| Phân tích vì sao tháng này defect leakage tăng | Có |
Cùng một chuyện bug, nhưng QA lo cách nó được làm ra còn QC lo cái đang nằm trên màn hình.
Vì sao ở Việt Nam chữ QA hay bị dùng sai
Vào bất kỳ trang tuyển dụng nào, gõ "QA" ra toàn tin tuyển tester. Lý do đơn giản: đội dự án ở VN đa số dưới 20 người, không đủ ngân sách nuôi một vị trí chỉ ngồi lo quy trình. Nên chức danh ghi QA nhưng công việc là QC, còn phần quy trình thì PM hoặc team lead ôm.
Về vận hành thì chẳng chết ai, nhưng có hai hệ quả. Một là bạn đi phỏng vấn dễ hố khi nhà tuyển dụng hỏi "em hiểu QA là gì" mà trả lời "là người test". Hai là dự án chạy nhiều năm mà không ai nhìn lại quy trình, cùng một loại lỗi lặp lại từ sprint này qua sprint khác.
Công ty làm outsourcing cho khách Nhật hoặc khách châu Âu thì khác hẳn. Ở đó QA là vai thật, có quyền chặn release nếu quy trình không được tuân thủ, và phía khách cử người sang audit định kỳ.
Ví dụ thực tế
Ba sprint liên tiếp, số defect lọt xuống UAT lần lượt là 14, 17 rồi 21. Một nửa trong số đó xoay quanh đúng hai thứ: làm tròn số tiền và định dạng ngày. Team fintech 17 người, sprint hai tuần, và suốt ba sprint ấy chỉ có người đi fix, chưa có ai đi hỏi vì sao.
Sang sprint 4, họ làm hai việc rất QA: thêm mục "quy ước làm tròn và định dạng ngày giờ" vào tài liệu chuẩn của hệ thống, và thêm dòng "đã kiểm tra theo quy ước format" vào definition of done. Sprint 5 và 6, nhóm lỗi đó gần như biến mất. Vẫn còn lỗi khác, nhưng ít nhất không phải cùng một lỗi lặp lại.
Câu hay bị hỏi phỏng vấn
"QA và QC khác nhau thế nào" là câu gần như chắc chắn có. Trả lời an toàn: QA hướng vào quy trình để phòng lỗi, QC hướng vào sản phẩm để phát hiện lỗi, testing là một phần của QC. Rồi nói thêm một câu về thực tế: ở nhiều công ty VN hai vai này gộp làm một, em từng làm cả hai phần và phần quy trình thường do team lead giữ.
Câu thứ hai hay theo sau: "nếu dự án gấp, cắt bớt được cái gì". Trả lời kiểu cắt QA là trượt. Nói theo hướng cắt phạm vi test theo rủi ro, giữ lại phần review tài liệu — một buổi ngồi đọc FRD vẫn chặn được nhiều lỗi hơn hai ngày test thêm ở cuối.
