Nghề Tester ở Việt Nam khổ vì định kiến

nghe-tester

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.

Xem thêm QA QC là gì? Automation Tester là gì?

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”.

Ví dụ, cùng một sản phẩm, trong thời gian hai giờ, Tester chăm và “có tâm” có thể test đến 50 cases, nhưng Tester lười thì chỉ kiểm thử 30 cases. Và, cả hai trường hợp này đều có thể vẫn còn sót bug.

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.

Ví dụ, “trong kiểm thử hồi quy” (regression test), đối với việc bảo trì, thay đổi chức năng của các hệ thống có sẵn, việc Dev chỉ mất nửa giờ để thêm/bớt/chỉnh sửa một tính năng, sau đó Tester phải bò ra test cả tuần là thường gặp.

Tester sợ nhất những dự án nâng cấp hệ thống kiểu như thế này, khi mà sửa một dòng code có thể làm chết cả hệ thống (cười).

Bởi vì đối với những hệ thống lớn/lâu đời, một thay đổi nhỏ có thể gây ảnh hưởng phức tạp đến nhiều phần khác nhau, hoặc thậm chí toàn bộ hệ thống.

  • 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.

Chỉ như vậy, Tester mới có thể: 1) hiểu cách hệ thống hoạt động, từ đó biết cách để làm hệ thống KHÔNG hoạt động. 2) hiểu công việc của Dev hơn, hợp tác ăn ý hơn với nhóm.

Xem thêm Kỹ năng cần thiết cho 1 QC giỏi

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?

Xem thêm 6 công việc lương cao nhất trong ngành IT

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.

Đồng nghĩa, khi sản phẩm gần hoàn thiện, test sẽ ra ít bug hơn, tiết kiệm nguồn lực hơn.

  • 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ý.

Ví dụ: Tài liệu đề cập đến cùng một tính năng, song tại trang 1 nói A, đến trang 8 lại nói C.

Hoặc, với kinh nghiệm kiểm thử các sản phẩm tương tự trước đó, Tester nhận ra rằng thông thường người dùng chỉ cần click 2 lần để đạt được mong muốn, song trong với thiết kế hiện tại, chương trình yêu cầu người dùng click tới 4-5 lần.

Đây chỉ là những lỗi UX đơn giản nhưng sẽ ảnh hưởng lớn đến việc “hấp dẫn” người dùng sử dụng hệ thống.

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ở.

Ví dụ, khi Dev muốn sử dụng công nghệ/kỹ thuật mới để thực hiện một chức năng đơn giản theo yêu cầu của khách hàng, Tester có thể hỏi:

1) Liệu kỹ thuật mới có áp dụng được cho việc phát triển sản phẩm này hay không?

2) Thuận lợi, khó khăn khi áp dụng kỹ thuật mới so với kỹ thuật hiện tại đang dùng?

Xem thêm 3 lời khuyên giúp bạn thành công trong nghề Tester

nghe-tester

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:

1) Không đầu tư thời gian để trau dồi kiến thức, phát triển nghề nghiệp.

2) Làm qua quýt đối phó, ảnh hưởng xấu tới chất lượng sản phẩm.

  • 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.

Dĩ nhiên, nếu muốn, ai cũng có thể bắt đầu công việc Tester ở mức thấp nhất, cơ bản nhất. Song, nếu không nỗ lực gấp 2-3 lần, các bạn sẽ không thể đi xa hơn được những Tester có nền tảng kiến thức về IT.

  • 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.

Hiện nay, mọi người thường hình dung Developer vs. Tester ở hai bên chiến tuyến:

Dev lập trình – Tester tìm lỗi – Dev sửa – Tester tìm lỗi.v.v… Vòng lặp cứ liên tục như vậy cho đến khi Tester không tìm thấy lỗi nữa hoặc đến ngày phát hành/giao sản phẩm thì mới tạm kết thúc.

Mối quan hệ căng thẳng giữa Tester – Developer sẽ gây ảnh hưởng xấu đến tinh thần của nhóm và chất lượng sản phẩm.

Ngoài ra, Dev dễ có tâm lý ỷ lại “kệ, cứ code vậy đi, Tester phát hiện lỗi thì sửa sau”. Đây là sai lầm nguy hiểm vì trên thực tế, không Tester nào có thể tìm thấy 100% lỗi của chương trình.

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.

nghe-tester

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.

Ví dụ, Tester A phát hiện được 100 bug, so với Tester B chỉ phát hiện được 10 bug. Như vậy có phải Tester A giỏi gấp 10 lần Tester B không? (cười)

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.
  • 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.
  • kỹ năng chuyên mônkiế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ì:

1) Giúp bạn có nhiều cơ hội công việc tốt hơn.

2) Có lợi thế để thương lượng lương cao hơn.

3) Bạn có kiến thức kiểm thử phần mềm chuẩn hơn (nếu bạn học/tự học đàng hoàng chứ không phải chỉ luyện giải đề để thi lấy chứng chỉ này).

nghe-tester

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.

Lần đó, từ đầu tới cuối một dự án, mình (Tester duy nhất) chỉ kiểm thử hệ thống trên server của công ty. Lúc UAT, khách hàng cũng kiểm thử trên server này luôn.

Tuy nhiên, khi phát hành sản phẩm thì nhiều user báo lỗi: họ bị bắt đăng nhập một cách ngẫu nhiên, dù đã đăng nhập rồi. Cả mình và Dev loay hoay mấy ngày liền vẫn không sao tái hiện được lỗi trên môi trường dev.

Cuối cùng, Dev xem logs và phát hiện: môi trường mà khách hàng triển khai hệ thống khác với môi trường mình dùng để kiểm thử. Chính vì vậy, lúc test mình đã không phát hiện lỗ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.

Nếu muốn trao đổi thêm về nghề Tester, cứ ping mình ở skype hoangliensonmt hoặc email admin@testing.vn nhé. Mình rất vui được trò chuyện, chia sẻ kinh nghiệm cùng các bạn để học hỏi lẫn nhau.

Bạn muốn theo nghề Tester và đang có muôn vàn thắc mắc? Hay bạn là một Senior Tester với vô số kinh nghiệm quý báu? Hãy cùng chia sẻ ở phần bình luận bên dưới!

Và tham khảo ngay việc làm Tester chất tại ITviec!

About the Author:

Storyteller

After nearly 10 years working in the online industry, Anh eventually found her strong passion for content marketing and storytelling. Read more...

Comments