QA là gì?

QA — Quality Assurance, đảm bảo chất lượng — là việc xây dựng, giám sát quy trình sản xuất/phát triển nhằm ngăn lỗi xảy ra, thay vì chỉ bắt lỗi ở khâu cuối.

Trong phần mềm, QA gồm lập kế hoạch kiểm thử, viết test case, kiểm thử thủ công/tự động và cải tiến quy trình. QA làm việc chặt với lập trình viên để chất lượng được "xây vào" sản phẩm ngay từ đầu.

QA rộng hơn kiểm thử

Nhiều tin tuyển dụng ở Việt Nam dùng QA như tên gọi khác của tester, nhưng phạm vi thật rộng hơn: xác định tiêu chuẩn chất lượng cho sản phẩm, thiết kế quy trình để lỗi khó phát sinh, dựng bộ kiểm thử và cơ chế chạy tự động, rồi truy nguyên nhân gốc mỗi khi có lỗi lọt ra ngoài. Tìm lỗi chỉ là một phần; ngăn cùng loại lỗi đó tái diễn mới là phần tạo giá trị.

Vì vậy một QA giỏi thường là người hiểu sản phẩm và người dùng ngang với người viết ra nó — biết chỗ nào hỏng thì tốn kém nhất, và dồn công sức vào đúng chỗ đó thay vì kiểm đều tay mọi thứ.

Kiểm thử thủ công và tự động: chọn thế nào

Nguyên tắc thực dụng: tự động hoá thứ lặp lại và ổn định (luồng đăng nhập, thanh toán, các đường đi chính chạy lại mỗi lần phát hành), để con người làm thứ cần phán đoán (trải nghiệm, giao diện lạ mắt, kịch bản hiếm, kiểm thử khám phá). Tự động hoá một màn hình còn đang đổi mỗi tuần chỉ tạo ra bộ kiểm thử hỏng liên tục và mất niềm tin của cả đội.

Bộ kiểm thử tự động có một chi phí ít người tính tới: chi phí bảo trì. Một bộ 500 ca chạy 40 phút và hỏng vặt mỗi ngày tệ hơn 80 ca chạy 5 phút mà tin được.

Báo lỗi thế nào để được sửa nhanh

Một phiếu lỗi tốt có: tiêu đề nói đúng triệu chứng, các bước tái hiện đánh số, kết quả mong đợi và kết quả thực tế, môi trường (phiên bản, thiết bị, tài khoản), và bằng chứng (ảnh chụp, video, log). Thiếu bước tái hiện là lý do số một khiến lỗi bị trả về “không tái hiện được” rồi trôi mấy vòng.

Phần khó hơn kỹ thuật là xếp mức độ ưu tiên: phân biệt lỗi chặn phát hành với lỗi khó chịu nhưng chờ được. Xếp mọi thứ là khẩn cấp khiến không gì thật sự khẩn cấp, và đó là cách nhanh nhất để QA mất tiếng nói trong đội.

Vào nghề QA

Cửa vào tương đối rộng: nhiều người bắt đầu từ kiểm thử thủ công rồi học thêm cơ sở dữ liệu, đọc log, viết kịch bản tự động. Ba thứ đáng học sớm: tư duy đặt ca kiểm thử (biên, ngoại lệ, dữ liệu xấu), truy vấn cơ sở dữ liệu để tự xác minh thay vì hỏi lập trình viên, và một công cụ tự động hoá phổ biến trong ngành bạn nhắm tới.

QA và phần còn lại của đội

Nghề này sống bằng quan hệ làm việc nhiều hơn người ta tưởng. Một QA bị xem là người đi bắt lỗi sẽ nhận được ít thông tin sớm, và phát hiện vấn đề muộn hơn — đúng lúc sửa tốn kém nhất. Một QA được xem là người cùng chịu trách nhiệm chất lượng thì được kéo vào từ khâu bàn phương án, nơi một câu hỏi đúng lúc tiết kiệm cả tuần sửa chữa.

Cách xây quan hệ đó khá cụ thể: báo lỗi bằng dữ liệu chứ không bằng phán xét, xếp ưu tiên trung thực để mức khẩn cấp còn nghĩa, và chủ động đặt câu hỏi ở giai đoạn thiết kế thay vì chờ có bản chạy được. Ở tin tuyển dụng, phần “phối hợp với các bên liên quan” chính là đang nói về năng lực này, và nó thường là thứ phân biệt ứng viên ở vòng cuối.

Ví dụ: cùng một lỗi, hai cách xử lý

Khách báo: đặt hàng thành công nhưng không nhận được email xác nhận.

Chỉ dừng ở kiểm thử: dựng lại lỗi, ghi phiếu, lập trình viên sửa, đóng phiếu. Hai tháng sau lỗi tương tự xảy ra ở luồng huỷ đơn.

Làm đúng tinh thần QA: ngoài việc trên, truy tiếp — vì sao lỗi lọt ra? Hoá ra không có ca kiểm thử nào phủ trường hợp hộp thư nhà cung cấp trả lỗi tạm thời, và không có cảnh báo khi hàng đợi email tồn. Hành động: bổ sung ca kiểm thử cho nhánh lỗi, thêm cảnh báo khi hàng đợi vượt ngưỡng, và đưa mục “kiểm tra nhánh thất bại” vào danh sách rà trước mỗi lần phát hành.

Cách thứ hai tốn thêm một buổi nhưng chặn được cả họ lỗi. Đó là khác biệt giữa bắt lỗi và đảm bảo chất lượng.