Nghề Tester ở Việt Nam khổ vì định kiến
Nghề Tester ở Việt Nam hiện nay không còn quá mới. Song, không phải ai cũng hiểu đúng, hiểu rõ về công việc của “ những người gác cổng thầm lặng ” này. Đọc bài phỏng vấn của ITviec với anh Hoàng Liên Sơn, chủ diễn đàn TestingVN, để biết: Định kiến sai lầm làm khổ Tester ở Việt Nam ...
Nghề Tester ở Việt Nam hiện nay không còn quá mới. Song, không phải ai cũng hiểu đúng, hiểu rõ về công việc của “những người gác cổng thầm lặng” này.
Đọc bài phỏng vấn của ITviec với anh Hoàng Liên Sơn, chủ diễn đàn TestingVN, để biết:
- Định kiến sai lầm làm khổ Tester ở Việt Nam ra sao.
- Nghề Tester cần những tiêu chí tối thiểu gì.
- Cách phân biệt Tester giỏi và Tester “xoàng”.
Xem thêm việc làm Tester tại ITviec
Tiểu sử: Anh Hoàng Liên Sơn tốt nghiệp khoa CNTT Trường ĐH Khoa học Tự nhiên năm 2006. Đến nay, anh đã có hơn 8 năm kinh nghiệm trong lĩnh vực kiểm thử phần mềm, trải qua nhiều vị trí từ QC, QC Lead… đến Quality Assistance Engineer. Hiện, anh đảm nhiệm vị trí Sr. Quality Assistance Engineer của công ty Ansarada.
Anh Sơn đồng thời cũng là chủ của TestingVN, một trong những diễn đàn lớn nhất về nghề Tester tại Việt Nam.
Chào anh Sơn! Anh vui lòng định nghĩa ngắn gọn về nghề Tester?
Tester là người đảm nhiệm công việc kiểm thử, đảm bảo chất lượng phần mềm tốt nhất có thể trước khi đưa ra thị trường/người dùng cuối.
Tùy từng công ty, từng vị trí công việc cụ thể mà nghề Tester có thể chia ra làm nhiều nhánh như QA, QC, Manual Tester, Automation Tester.v.v… Song, tất cả đều có thể gọi chung một cách nôm na là Tester.
Nhiều người cho rằng “nghề Tester ai làm cũng được”. Quan điểm của anh?
Sở dĩ quan niệm trên tồn tại vì có một số công ty tuyển nhân sự với yêu cầu khá đơn giản, chỉ để thực hiện những công việc kiểm thử cơ bản như:
- Thực hiện kiểm thử theo danh sách các test case có sẵn.
- Chỉ kiểm thử thuần tuý trên giao diện dựa trên yêu cầu mô tả (nhập thông tin, rồi quan sát kết quả trên màn hình).
Những việc đó thì chỉ cần hướng dẫn sơ qua là ai cũng có thể làm được.
Tuy nhiên, bạn sẽ chỉ test như một cái máy mà không hiểu nguyên nhân, cơ chế hoạt động… ở phía sau. Hệ quả là hạn chế việc tìm thấy những lỗi tiềm ẩn quan trọng khác – có thể ảnh hưởng đến việc bảo trì hoặc mở rộng hệ thống/sản phẩm sau này.
Mà theo mình, chỉ như vậy thì không thể gọi là một Tester thực thụ được.
Vậy, tiêu chuẩn tối thiểu để một người tự nhận là Tester là gì?
Tiêu chuẩn tối thiểu của một Tester là phải biết mình cần làm gì khi nhận nhiệm vụ kiểm thử. Bao gồm:
- Biết cách đọc, phân tích tài liệu yêu cầu để phát hiện lỗi / thiếu sót sớm.
- Biết cách thiết kế test case hiệu quả.
Để biết cách thiết kế test case hiệu quả, bạn cần phải có những kiến thức cơ bản như:
- Hiểu nghiệp vụ của hệ thống / chức năng sẽ kiểm thử.
- Nắm vững kỹ thuật thiết kế test case.
- Biết sử dụng một số công cụ để chuẩn bị môi trường, và tạo dữ liệu kiểm thử.
- Biết thao tác trên các hệ điều hành trên mobile (ví dụ: iOS, Android) – nếu kiểm thử trên mobile.
- Biết cách thao tác với cơ sở dữ liệu, ít nhất là để thêm, cập nhật hay truy vấn dữ liệu.
Những định kiến đáng tiếc về nghề Tester ở Việt Nam?
1. Làm Tester rất dễ.
Đúng là so với công việc của Developer thì nhiệm vụ của Tester có phần nào “nhàn” hơn, vì:
- Không có Tester thì Developer vẫn làm ra được sản phẩm phần mềm. Còn, nếu không có Developer thì không có phần mềm để kiểm thử, đồng nghĩa nghề Tester sẽ không tồn tại.
- Rất khó để định nghĩa như thế nào là “test xong”.
Tuy nhiên, nghề Tester cũng có rất nhiều áp lực riêng:
- Khối lượng công việc của Tester không hề nhẹ nhàng, cũng phải làm thêm giờ như cơm bữa chẳng khác nào Dev.
- Tester cần phải hiểu sâu rộng về lĩnh vực hoạt động của sản phẩm, về người dùng cuối, cũng như kiến thức phát triển phần mềm.
2. Lương Tester rất thấp.
Có thể đối với những vị trí Fresher, Junior thì lương của nghề Tester không thực sự cao (do yêu cầu công việc đơn giản).
Tuy nhiên, một Tester giỏi giàu kinh nghiệm hoàn toàn có thể đạt mức lương 1000-3000usd/tháng. Mức lương này không hề thấp so với các ngành nghề khác, đúng không?
3. Tester chỉ làm công việc “hậu kì”.
Theo quan niệm phổ biến, Tester chỉ tham gia vào giai đoạn cuối, khi phần mềm đã gần hoàn thiện. Trách nhiệm của Tester chỉ là đảm bảo sản phẩm cuối đạt đúng yêu cầu (requirements) đặt ra ban đầu.
Tuy nhiên, cá nhân mình cho rằng Tester nên tham gia sớm hơn, ở cả giai đoạn “tiền kì” và “sản xuất”, vì:
- Giúp giảm thiểu rủi ro và lỗi khi phát triển sản phẩm.
- Hạn chế việc phải sửa lỗi hay kiểm thử hồi quy (mất nhiều thời gian, và nguy hiểm hơn nếu xác định sai khu vực cần kiểm thử).
Cụ thể, trong công ty Outsourcing: Tester có thể giúp “giảm lỗi trong sản phẩm” từ khâu đọc và phân tích tài liệu bằng cách chỉ ra những điểm bất ổn/bất hợp lý.
Hoặc, Tester cũng có thể thu thập thông tin phân tích (analytics) của hệ thống, để cung cấp ý tưởng/dữ liệu cho nhóm phát triển/khách hàng đưa ra quyết định tốt hơn ở giai đoạn này.
Trong công ty Product: Tester nên tham gia cùng nhóm phát triển từ giai đoạn lên ý tưởng và thực hiện Proof of Concept (chứng minh khái niệm). Tester có thể “kiểm thử” ý tưởng sản phẩm bằng hàng loạt câu hỏi mở.
Tranh vui về Tester vs Developer
Hậu quả của những định kiến về nghề Tester này?
Những định kiến sai lầm này đã làm khổ anh chị em Tester ở Việt Nam nói riêng, và gây ảnh hưởng tới cả ngành phần mềm nói chung. Tại sao?
- Không chỉ người ngoài nghề, mà một số Tester cũng tự coi thường công việc của mình, dẫn đến việc:
- Ngày càng có nhiều người học trái ngành muốn làm Tester chỉ vì nghe “xúi”, mà không hề chuẩn bị các kiến thức cơ bản về lập trình phần mềm.
- Mặc định Tester chỉ làm công việc “hậu kì” khiến Tester dường như bị tách rời khỏi team phát triển sản phẩm và dễ đẩy mối quan hệ Tester – Developer vào thế đối nghịch.
Trong khi, trên thực tế, Tester và Developer (nhóm phát triển) thuộc cùng một “phe”, cùng thực hiện sứ mệnh là phát triển sản phẩm chất lượng tốt nhất có thể với thời gian nhanh nhất.
Tester và Developer không ở hai chiến tuyến như mọi người thường nghĩ
Điều gì phân biệt Tester giỏi với Tester “xoàng”?
Nhiều người hay đánh giá Tester dựa trên khả năng phát hiện bug.
Câu trả lời dĩ nhiên là: không. Bởi vì số lượng bug được phát hiện còn tùy thuộc:
- Người phát triển ra chức năng, hệ thống đang được kiểm thử (giỏi/dở, có/không có kinh nghiệm).
- Nhiều yếu tố khác, như thời gian cho phép phát triển sản phẩm (gấp/thoải mái).
- Và, ngay cả khi cùng một dev phát triển 2 tính năng y chang nhau trên 2 sản phẩm khác nhau, thì không có nghĩa bug khui ra được ở sản phẩm này cũng sẽ xuất hiện ở sản phẩm kia.
Cho nên, theo quan điểm của mình, tiêu chí để đánh giá một Tester là:
- Sự nhanh nhạy để sớm phát hiện ra những điểm bất hợp lý khi phân tích tài liệu.
- Có kiến thức sâu rộng về sản phẩm/lĩnh vực hoạt động của sản phẩm.
- Có kỹ năng chuyên môn và kiến thức kỹ thuật lập trình tốt để đóng góp cho nhóm trong việc phát triển sản phẩm chất lượng.
Nói cách khác, một Tester tốt sẽ là người hỗ trợ để team làm ra sản phẩm tốt hơn, chứ không chỉ biết cắm đầu cắm cổ test. Và để đánh giá điều này thì cần cả quá trình hợp tác, làm việc chung.
Cách tự học để trở thành Tester?
Nếu chưa có kiến thức về lập trình phần mềm, bạn cần tìm hiểu:
- Quy trình phát triển phần mềm. Những vị trí cần thiết trong một nhóm phát triển phần mềm, nhiệm vụ của từng vị trí?
- Như thế nào gọi là một phần mềm tốt? Tiêu chí đánh giá chất lượng của một hệ thống/chức năng phần mềm?
- Tester là gì? Làm công việc gì? Cần những kĩ năng nào?
- Sau đó, bạn bám vào các khái niệm cơ bản của Testing để… học thêm (cười).
Nguồn tài liệu về nghề testing trên Internet rất dồi dào, bằng cả Tiếng Việt và Tiếng Anh. Tuy nhiên, cũng vì vậy mà thượng vàng hạ cám đủ cả. Khi tự học, bạn cần phải biết sàng lọc thông tin.
Một vấn đề nữa của việc tự học là sẽ không có ai giúp bạn kiểm chứng kiến thức cả. Nếu có thể, mình nghĩ các bạn nên đăng kí một khóa học Testing cơ bản thì sẽ nắm kiến thức nhanh và hệ thống hơn. Sau đó, bạn có thể tự đào tạo mình thông qua công việc.
Ngoài ra, ISTQB là một chứng chỉ quốc tế về kiểm thử phần mềm rất hữu ích nếu bạn muốn theo đuổi nghề testing, vì:
Anh Sơn (thứ 2, từ trái qua) và đồng nghiệp
Hơn 8 năm theo nghề Tester, sai lầm đáng nhớ nhất của anh là gì?
Hồi mới vào nghề, mình rất dễ nổi cáu khi tìm ra bug mà Dev không chịu nhận bug hoặc không chịu fix. Mình đã tìm đủ mọi cách để chứng minh mình đúng, lôi đủ mọi tài liệu, chứng cứ ra để ép họ phải fix bug cho bằng được.
Cứ như vậy một thời gian thì team Dev trở nên rất “ngoan”, bug nào mình đưa ra họ cũng fix, dù không có trong requirements.
Chỉ đến khi dự án trễ deadline, khách hàng phàn nàn thì mình mới nhận ra sai lầm:
- Dev chịu fix mọi bug mình mình đưa ra nhưng chưa chắc họ thực sự vui hoặc thoải mái.
- Khách chỉ yêu cầu ABC mà mình còn bày ra A’B’C’ rồi ép cả team theo. Vì vậy, team không đủ nguồn lực giải quyết những vấn đề chính, dẫn đến trễ deadline.
Từ đó về sau, khi phát hiện bug ngoài requirements, mình chỉ nêu đề xuất. Nếu team làm xong yêu cầu của khách mà vẫn còn thời gian thì mới tính tiếp.
Hoặc, mình thảo luận với Dev Lead và PM, để xem cái nào trong phạm vi dự án và nên làm, cái nào nên để sang giai đoạn tiếp theo.
Bài học quan trọng nhất anh rút ra cho bản thân?
Mình vẫn nhớ một kỉ niệm nhớ đời.
Mình xin phép không chia sẻ chi tiết hơn về “kỉ niệm” này. Song, từ đó, bài học xương máu mình luôn nằm lòng là: Tester luôn luôn phải biết rõ môi trường mà khách hàng sẽ triển khai hệ thống đang được phát triển.
