Tester – Nghề cho muôn người?

“Tester thì ai mà chả làm được?” câu nói tưởng chừng nhẹ tênh nhưng lại nặng trĩu mỗi khi nhắc tới nghề kiểm thử.

Tester – Nghe thì đơn giản, chỉ “bấm bấm, click click” là xong. Nhưng thực tế, phía sau lớp vỏ tưởng nhẹ nhàng ấy là một công việc đòi hỏi phương pháp, tiêu chuẩn, sự tỉ mỉ và trách nhiệm rất rõ ràng: kiểm chứng chất lượng phần mềm, giảm rủi ro lỗi khi vận hành và cung cấp thông tin xác thực để đội ngũ ra quyết định.

Tester là gì?

Tester (nhân sự kiểm thử) là người xác thực chất lượng sản phẩm trước khi đưa tới người dùng. Công việc không chỉ đơn thuần là “manual” hay chỉ “automation”, mà còn là sự kết hợp bổ trợ giữa hai cách tiếp cận. 

Kiểm thử thủ công mạnh ở khả năng khám phá, đánh giá trải nghiệm/UX và bối cảnh thực tế, những thứ kịch bản tự động khó bao quát. Ngược lại, kiểm thử tự động phát huy ở các vòng hồi quy, kiểm tra hiệu năng và các tác vụ lặp, giúp tiết kiệm thời gian và tăng độ ổn định qua nhiều bản build. 

Vai trò và chức năng của Tester trong các dự án công nghệ

Trong dự án công nghệ, Tester sẽ là “bộ lọc chất lượng” của dự án: họ phân tích yêu cầu để xác định phạm vi, tiêu chí chấp nhận và rủi ro, rồi lập kế hoạch kiểm thử, chuẩn bị dữ liệu phù hợp. 

Trong thực thi, Tester triển khai các lớp kiểm thử (hộp đen/hộp trắng, tích hợp, hệ thống, UAT), ghi nhận lỗi với bước tái hiện, mức độ nghiêm trọng/ưu tiên và lập báo cáo chất lượng dễ hiểu. 

Sau khi sửa lỗi, họ xác nhận bản vá, chạy hồi quy để tránh tác dụng phụ và theo dõi tiến độ. Xuyên suốt vòng đời dự án, vai trò của Tester không chỉ là kết nối Dev–BA–PM, làm rõ yêu cầu, phản hồi rủi ro mà còn phải bảo đảm cải tiến chất lượng qua từng phiên bản.

Để hiểu rõ hơn về nghề Tester cũng như góc nhìn về những định kiến xoay quanh nghề này, trong số thứ hai của 1 phút log out, hãy cùng lắng nghe những chia sẻ của tester Lê Thị Hương Giang tại SiciX về các vấn đề trên.

“Là một Tester, tôi thường nghe câu ‘Tester ai cũng làm được’, nhưng càng làm, tôi càng thấy nghề này không hề đơn giản, mình càng thấy kiểm thử không phải chuyện “ngồi bấm bấm là ra lỗi” – Chị Giang hào hứng chia sẻ.

Theo chị Giang, muốn tìm đúng lỗi và nói đúng vấn đề, Tester phải hiểu logic nghiệp vụ, nắm các nguyên lý cơ bản của hệ thống, từ database tới API, để trao đổi với Developer cho trúng ý và trúng chỗ. Cùng với đó là tư duy bao phủ để không bỏ sót bug, và kỹ năng giao tiếp đủ rõ ràng để mô tả lỗi sao cho Dev fix nhanh. Đặc biệt trong những hệ thống liên quan đến tiền như ngân hàng, việc nắm chắc nghiệp vụ là bắt buộc bởi chỉ cần sót một case, hệ quả có thể là thất thoát số tiền rất lớn.

Vậy “tiêu chuẩn tối thiểu” cho một người tự nhận là Tester là gì?

Theo chị Giang, đó phải là nền tảng kiểm thử: hiểu khái niệm, các loại kiểm thử cơ bản, biết viết test case và thực thi dựa trên test case của chính mình. Trên nền đó, Tester cần tư duy kiểm thử, khả năng phân tích yêu cầu, viết test case rõ ràng và thực thi chính xác. Cuối cùng, không thể thiếu kỹ năng giao tiếp và kiến thức dữ liệu ở mức cơ bản để làm việc với API hoặc database khi cần.

Chị Giang chia sẻ một kỷ niệm khi tham gia dự án app Khai báo, đăng ký thông tin. Tính năng upload ảnh chân dung và CCCD bị giới hạn ở mức 3MB, trong khi yêu cầu khách hàng là tối thiểu 5MB. Khi test và log bug, Dev phản hồi rằng tăng dung lượng sẽ làm thời gian upload chậm, người dùng dễ tưởng hệ thống lỗi, nên muốn giữ nguyên 3MB. Cuộc trao đổi về sau càng trở nên căng thẳng khi Dev bảo vệ quan điểm hiệu năng, còn Tester bám theo yêu cầu tài liệu. Để giải quyết vấn đề, chị Giang đã phối hợp với BA, đưa ra số liệu thực tế về nhu cầu upload và đề xuất giải pháp kỹ thuật để giảm rủi ro trải nghiệm. Cuối cùng, team thống nhất: cho phép 5MB đúng yêu cầu kèm thanh tiến trình upload để người dùng thấy hệ thống đang xử lý. Với hướng xử lý này, khách hàng đã khá hài lòng và đánh giá cao tính năng và hiệu năng của giải pháp. “Đó là ví dụ điển hình cho cách một cuộc tranh luận “căng mà tích cực” giúp sản phẩm tốt lên” – chị Giang vui vẻ nhận định.

Điều mà một Tester như chị Hương Giang yêu nhất ở nghề là cảm giác bắt được lỗi trước người dùng. Điều này giống như đặt một lớp bảo vệ cho trải nghiệm khách hàng, cho uy tín của team và của công ty. Mỗi dự án lại mở ra kiến thức mới, công nghệ mới, giúp cá nhân  lớn lên nhanh trong chuyên môn.

Ở góc nhìn từ phía Developer (Lập trình viên) – người trực tiếp viết mã nguồn (code) để xây dựng các tính năng và chức năng của sản phẩm phần mềm theo yêu cầu – anh Bùi Trọng Hoàn nhận định kiểm thử như một “bài tập nâng trình”. 

Theo anh Hoàn, bắt lỗi càng kỹ giúp lập trình viên nhận ra các vấn đề trong mã nguồn, từ đó tăng chất lượng code, tránh cả lỗi lớn lẫn “lặt vặt” ở các task sau này. Các lỗi do Tester chỉ ra sẽ được các Dev thận trọng xem xét miễn là lỗi được nêu có cơ sở và hợp lý. 

Ở khía cạnh phối hợp, anh Hoàn cho biết: Bản thân không tin vào “bí kíp” nào quá thần thánh mà tin rằng làm việc với nhau đủ nhiều thì sẽ hiểu nhau. Developer và Tester không phải là “phe đối lập” mà là hai vai trò bổ trợ lẫn nhau trong quy trình phát triển phần mềm. Developer xây dựng sản phẩm, còn Tester đảm bảo sản phẩm đó đáp ứng yêu cầu chất lượng và không có lỗi nghiêm trọng trước khi đến tay người dùng. Sự hợp tác lâu dài giữa Developer và Tester xây dựng sự thấu hiểu, giúp quá trình làm việc trơn tru hơn.

Sau cùng, anh Trọng Hoàn gửi tặng một thông điệp đầy thân thương đến các Tester của SiciX “Chúc các anh chị em bắt lỗi hiệu quả!”.

Từ những chia sẻ của chị Lê Thị Hương Giang và góc nhìn của anh Bùi Trọng Hoàn, có thể thấy Tester không phải “phe đối lập” của Dev mà là mắt xích bảo chứng về chất lượng trong việc hiểu nghiệp vụ, nắm dữ liệu/API, giao tiếp rõ ràng và ưu tiên theo rủi ro để sản phẩm tốt hơn, ra phiên bản nhanh hơn. Vì vậy, “Tester – nghề cho muôn người” chỉ đúng nếu được hiểu là ai cũng có thể bắt đầu, nhưng không phải ai cũng làm tốt, bởi chỉ những người chịu học, chịu tỉ mỉ và hợp tác bền bỉ mới đi đường dài trong nghề này.