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

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 – QA Tech Lead của công ty Ansarada và là nhà sáng lập 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

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ả. Chẳng hạn 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ử.
• Thao tác đượ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 Developer.

Ví dụ như 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, Developer chỉ mất nửa giờ để thêm/bớt/chỉnh sửa một tính năng. Trong khi Tester phải bò ra test cả tuần sau đó là chuyện không hiếm 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 Developer 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 8 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 Developer 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

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 với Tester ở hai bên chiến tuyến:

Developer lập trình – Tester tìm lỗi – Developer 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, Developer 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.

Thư giãn với video phản ánh thực tế mối quan hệ giữa QC và Developer

Đ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 Developer 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ơ hội nghề nghiệp của Tester ở thời điểm hiện tại?

Cơ hội nghề nghiệp thì rất nhiều. Nhiều bạn đã từng học tại TESTING VN, giờ liên hệ và nói “bên em đang tuyển ## vị trí Tester 1-2 năm” hay “anh Sơn ơi, có bạn nào vừa học xong lớp Fresher Tester không, giới thiệu em với”. Ví dụ vậy, nhiều lắm (cười). 

Một số công ty thì cần người có kinh nghiệm để có thể tự làm việc một mình. Không cần kiến thức về automation testing (kiểm thử tự động) thì họ cần người vững về manual testing (kiểm thử thủ công) và kỹ năng quản lý công việc cũng như quản lý thời gian.

Học viên hay nhờ tư vấn nên chọn công ty nào. Mình thì không bênh vực hay ghét bỏ công ty nào hết. Công ty nào cũng có cái hay cái dở riêng của nó. Mình chỉ đặt câu hỏi để làm rõ mong đợi của các bạn học viên ấy.

Có bạn thì cần công ty có thời gian làm việc linh hoạt, được cấp máy tính xách tay; có bạn thì muốn làm cho công ty gần nhà; có bạn thì muốn làm công ty nào có sử dụng Tiếng Anh; có bạn muốn làm công ty nào có cơ hội đi onsite ở nước ngoài… Sau khi phân tích các khía cạnh, các bạn ấy tự chọn nơi mà bạn ấy thấy phù hợp nhất.

Xem ngay hàng trăm việc làm Tester

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

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à Developer 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 Developer 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:

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

Cuối cùng, Developer 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 có thể bắt đầu lại, anh có chọn theo đuổi nghề này không? Hoặc anh sẽ làm điều gì đó khác hơn?

Nếu có thể bắt đầu lại, mình vẫn sẽ chọn công việc này. Nếu mình có thể làm một điều gì đó khác thì mình sẽ bắt đầu công việc kiểm thử phần mềm này sớm hơn nữa.

Nhưng mình vẫn không tiếc khoảng thời gian mình phụ trách bộ phận dịch vụ hậu mãi của một siêu thị điện máy lớn, trước khi bắt đầu sự nghiệp Tester.

Công việc đó giúp mình học hỏi và rèn luyện kỹ năng đàm phán với khách hàng. Khả năng giữ bình tĩnh khi khách hàng đang rất bực mình vì sản phẩm lỗi hoặc do chưa biết sử dụng và lầm tưởng là sản phẩm bị lỗi.

Ngoài ra, nó còn giúp mình hiểu được rằng: mỗi sản phẩm làm ra, ngoài chức năng phong phú thì phải dễ hiểu và dễ sử dụng, nhất là đối với khách hàng lần đầu tiên sử dụng sản phẩm.

Những kinh nghiệm trên rất có ích cho công việc của mình hiện tại. Mình đang hằng ngày tận dụng những kiến thức và kinh nghiệm này vào công việc hỗ trợ nhóm phát triển phần mềm phát triển ra một hệ thống có ích cho người dùng. Giúp họ thấy thoải mái như đang làm chủ cái phần mềm này, chứ không phải cái phần mềm này gây khó dễ cho họ.

Vậy điều gì khiến anh thấy thích thú ở nghề Tester?

Cho đến bây giờ, mình vẫn thấy thích nhất một điều ở nghề Tester này là “chất lượng phần mềm không đến từ quá trình kiểm thử, mà đến từ quá trình phát triển.”

Nghĩa là, dù đã lên kế hoạch và làm việc tốt đến mấy thì vẫn có thể có rủi ro. Nhóm Tester giúp phát hiện rủi ro sớm bằng cách đọc và phân tích kỹ tài liệu yêu cầu xem nó có thiếu sót, mô tả không rõ ràng hoặc mô tả sai, không hợp lý, v.v… hoặc cũng có thể tham gia kiểm thử sản phẩm được tạo ra từ nhóm phát triển để xem sản phẩm có đáp ứng yêu cầu đã cho hay không, hoặc là sản phẩm có đáp ứng nhu cầu của người dùng hay chưa, v.v…

Công việc trên nghe có vẻ hay và hợp lý, nhưng nếu như:

• chất lượng tài liệu kém. Ví dụ: BA không có kinh nghiệm đi lấy yêu cầu và chịu trách nhiệm viết tài liệu cho cả hệ thống quản lý chuỗi cửa hàng

hoặc 

• chất lượng code kém. Do nhóm lập trình viên không có nhiều kinh nghiệm hoặc code giỏi nhưng không cẩn thận, hoặc họ nghĩ rằng người chịu trách nhiệm cho chất lượng sản phẩm là Tester chứ không phải là họ

thì dù Tester có giỏi đến mấy đi nữa, sản phẩm cũng sẽ còn sót rất nhiều lỗi, khả năng dự án thất bại cũng rất cao.

Làm sao để nâng cao chất lượng sản phẩm được phát triển ra bởi một nhóm phát triển phần mềm?

Tester phải hợp tác, phối hợp với nhóm lập trình. Ngoài công việc kiểm thử như mình nói ở trên, thì Tester cũng nên tìm cách “coach” cho các bạn BA, Developer cái “quality mindset” (tư duy về chất lượng). Từ đó, họ luôn nghĩ đến chất lượng trong lúc đang phân tích nghiệp vụ.

Điều này giúp BA phân tích kỹ hơn và đánh giá trên nhiều trường hợp, có xem xét đến khía cạnh dễ sử dụng của sản phẩm (chứ không phải chỉ nghĩ đến chức năng của nó). Lập trình viên thì lập trình tốt hơn do đã bao phủ nhiều khía cạnh của một vấn đề (cả các trường hợp hợp lệ và không hợp lệ).

Có điều gì mà gần đây anh mới nhận ra về nghề Tester và anh ước giá như mình biết sớm hơn?

Gần đây mình phát hiện rằng, các bạn Tester chuyên về kiểm thử tự động cũng phải nắm vững kiến thức nền tảng về kiểm thử phần mềm, và có thể làm tốt công việc kiểm thử thủ công (manual).

Nếu một Automation Tester không biết phải kiểm thử những trường hợp nào đối với một yêu cầu hoặc chức năng cụ thể thì khó có thể thành công trong công việc.

Nếu một Automation Tester hiểu được một yêu cầu cụ thể cần phải kiểm thử những trường hợp nào thì họ sẽ dễ dàng biết được nên tự động hóa trường hợp nào, và tại sao. Cũng có thể họ sẽ hiểu nên viết test case tự động (automated tests) ở những mức nào thì phù hợp nhất theo ngữ cảnh cụ thể của dự án.

Những tài liệu mà anh cho là hữu ích cho những ai muốn theo đuổi nghề Tester?

Tùy vào công việc cụ thể của các bạn mà nhu cầu của mỗi người sẽ khác nhau. Ngày nay thì rất nhiều công ty đang áp dụng các mô hình phát triển phần mềm Agile như Scrum hay Kanban. Tester cũng nên tìm hiểu để có thể đáp ứng nhu cầu công việc của nhóm.

Mình đã đọc các tài liệu sau, các bạn có thể tham khảo:

• Foundations of Software Testing ISTQB Certification, 3rd edition : Kiến thức tổng quan về kiểm thử phần mềm thông qua các ví dụ và giải thích chi tiết của nhóm tác giả. (Mình rất vui vì đã có cơ hội tham gia đội ngũ dịch giả cho cuốn sách khi ĐH FPT muốn Việt hóa sách này).
• Testing in Scrum: A Guide for Software Quality Assurance in the Agile World: Sách trình bày chi tiết về cách hoạt động của kiểm thử Agile, trong đó các kỹ thuật kiểm thử truyền thống vẫn cần thiết đối với môi trường Agile và làm sao để áp dụng chúng theo cách tiếp cận Agile.
• Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing: Cuốn sách được chia thành 3 phần:  (1) Thiết lập nền tảng, (2) Bổ sung đa chiều, (3) Khám phá theo ngữ cảnh. Giúp Tester phát triển khả năng khám phá, trên các ứng dụng hiện có và cả các phần mềm không có giao diện người dùng.

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.

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 10 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í QA Tech Lead 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.

Nếu bạn nghĩ những chia sẻ này có thể giúp ích cho bạn bè hoặc đồng nghiệp thì đừng ngại nhấn nút Share bên dưới nhé!

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