QA’s Roles Vs Goals: How to Balance Both to Achieve Your Goals

Đã qua rồi cái thời mà các QA đã từng có nhiều thời gian để chờ đợi các bản build và sau đó mới bắt đầu kiểm thử, báo lỗi và sau đó lại chờ dev sửa chúng.

Họ sẽ dành phần lớn thời gian để thực hành tiếng Anh ! Có nghĩa là dành thời gian để viết, review và hoàn thiện Test Case để sử dụng cho việc kiểm thử.

Thời gian đã thay đổi và các vai trò cũng vậy. Có thể là may mắn nếu bạn tồn tại chỉ bằng việc kiểm thử thủ công khi làm việc cùng với các đại gia CNTT lớn như Infosys, Wipro, TCS, Accdvisor, v.v.

Nếu ở trong một công ty cỡ vừa hoặc nhỏ, bạn cần lưu ý một số kỹ năng đặc biệt ngoài việc kiểm thử thủ công cơ bản. Nó có thể là bất cứ thứ gì như kiểm thử API, Postman, SOAP, Kiểm thử DB, xác thực phía máy client đến những thứ phức tạp hơn như kiểm thử tự động và kiểm thử hiệu năng.

Trong xu hướng hiện nay, bạn có thể nhận thấy rằng yêu cầu tuyển dụng ngay cả đối với những người kiểm thử có 2-4 năm kinh nghiệm, vẫn liệt kê ra rất nhiều thứ.

Dưới đây là ví dụ mô tả công việc đối với vai trò của một người thử nghiệm với 2-4 năm kinh nghiệm làm việc:

• Kiến thức tốt về Java.
• Selenium - Bắt buộc.
• Phải giỏi về Kiểm thử hiệu năng - Jmeter / LoadRunner với sự hiểu biết rõ ràng về các khái niệm điều chỉnh hiệu năng và hệ điều hành.

Đây chỉ là liệt kê các kỹ năng cơ bản nhưng ngoài ra còn nhiều hơn nữa được thêm vào danh sách. Những ngôn ngữ như Python, Perl, Groovy, vv tìm chỗ đứng riêng của họ trong phần lớn các cơ hội việc làm.

Vậy thì chúng ta kết luận được gì ở đây? Đây là ngành công nghiệp chuyển sang vai trò SDET (Software Development Engineer in Test) hay sao? Tôi sẽ đồng ý về một số điểm nhất định như - một người thử nghiệm cần có kiến thức cơ bản về ngôn ngữ lập trình và nên sẵn sàng tự động hóa “khi có sự yêu cầu”. Chắc hẳn bạn đang tự hỏi tại sao thuật ngữ “khi có sự yêu cầu” được in đậm chứ?

Rất nhiều công ty thuê người cho kiểm thử tự động, nhưng bạn nên cảm thấy may mắn nếu bạn có thể tìm được một dự án kiểm thử tự động trong tổ chức đó đấy nhé. Bạn sẽ chỉ được chuyển tới một dự án thủ công khác nơi mà sẽ chẳng cảm thấy học hỏi được thêm gì sau vài tháng làm dự án đó. Tin tôi đi đó là sự thật mà nhiều người đang gặp phải hiện nay đúng không.

Lý do chính mà bạn muốn đổi công ty hiện tại có lẽ là “ Tôi không thể có được kinh nghiệm kiểm thử tự động”. Bạn có thể phải nỗ lực hết sức mình để học tự động hóa và sau đó thay đổi công ty vì bạn muốn thay đổi từ kiểm thử thủ công sang kiểm thử tự động. Vì vậy, bạn ở đây !!

Bạn lại bị lừa rồi!!!

Một điều tồi tệ nhất mà tôi đã nhận thấy trong nhiều tổ chức là ngay cả một QA Lead hoặc QA Manager làm công việc gần tương tự như một người junior tester. Nó không phải là toàn bộ ở các công ty đều như vậy, nhưng việc thăng chức như một QA Lead cũng không đảm bảo rằng bạn sẽ nhận được các vai trò mà bạn đang tìm kiếm.

Hệ thống phân cấp trong dự án của bạn có thể khiến cho bạn cũng phải làm cùng một công việc giống như các junior đang thực hiện. Vai trò như là một QA Manager gần như chẳng thấy đâu cả. Vậy một QA Lead nên nhìn thấy chính mình ở đâu trong tương lai?

Cuối cùng thì, hầu hết mọi người trong nhóm ngành IT đều mơ ước được đi onsite. Nếu bạn so sánh các cơ hội onsite mà các BA hay Dev có được so với các QA, thì bạn sẽ cảm thấy buồn khi QA là những người bị thua cuộc. Tôi đã làm việc với nhiều các tổ chức khác nhau và có một số từ phổ biến tôi thường nghe từ bộ phận Nhân sự hoặc Quản lý cấp cao.

Đó là những từ khiến tôi buồn như - “Không có onsite cho các QA”. Một lần nữa, đây không phải là tất cả mọi nơi đều như vậy, tuy nhiên, tôi chỉ trích dẫn các xu hướng chung trong ngành.

Vì vậy, chúng ta hãy xem lại tiêu đề của bài viết này ‘Vai trò vs Mục tiêu của QA”.

Điểm mấu chốt mà tôi cố gắng nêu bật ở đây là “Vai trò của chúng ta có đang tập trung vào các Mục tiêu không”. Tôi chắc chắn rằng hầu hết mọi người sẽ nói KHÔNG ! Khi thời gian trôi qua, với sự gia tăng kinh nghiệm qua từng năm, đôi khi chúng ta cảm thấy mình có đang làm cái gì mới hay không nhỉ? Câu trả lời sẽ là chúng ta đang làm cùng một công việc mà chúng ta đã làm 3-4 năm trước.

Tôi đã xem qua hồ sơ của một số người kiểm thử thậm chí với hơn 10 năm kinh nghiệm nhưng họ vẫn đang làm việc với tư cách là “Test Analyst” hay “Senior Test Analyst”, trong khi các Dev có cùng kinh nghiệm thì đang trở thành “Project Managers” hay “Product Managers”.

Nếu bạn xem lại các vai trò mà bạn đã thực hiện trong suốt sự nghiệp của mình, thì bảng dưới đây sẽ nghe có vẻ thú vị nhưng cũng chán nản kém. Bạn sẽ thấy rằng bạn không học được gì sau 7-8 năm kinh nghiệm làm việc.

Vì vậy, tôi sẽ nói rằng khung thời gian 5-7 năm là rất quan trọng trong sự nghiệp QA. Thế nên bạn cần phải làm việc dựa trên điểm mạnh và yếu của mình để chọn ra con đường phù hợp với bản thân mình.

• Nếu bạn không có hứng thú với lập trình và cũng không hiểu Tự động hóa, nhưng bạn cảm thấy rằng bạn có kỹ năng phân tích tốt và kỹ năng giao tiếp tốt, thì tốt hơn là nên chuyển sang vai trò BA sau 5 năm.
• Nếu bạn thích lập trình điên cuồng thì hãy chắc chắn là đi theo hướng tự động hóa. Đừng dừng lại ở Thủ công thôi. Hãy chuyển công ty cho tới khi bạn tìm được vai trò hoàn hảo
• Nếu bạn không thích lập trình điên cuồng nhưng lại hiểu logic tốt thì hãy học hỏi về các công nghệ trên thị trường, và tốt hơn là chuyển sang hướng Manager Delivery hơn là Manager QA. Và bạn sẽ học được nhiều điều từ nó đấy.

Nói chung, mọi người nói rằng chúng ta không nên chuyển đổi công ty một cách thường xuyên nhưng nếu chúng ta không hài lòng với vai trò của mình thì sao? Chúng ta có nên thỏa hiệp với những gì đang xảy ra? Tiếp tục làm công việc tương tự nếu bạn không thích ư? Vào cuối ngày, lại tiếp tục vòng luẩn quẩn suy nghĩ tôi đang làm cái quái gì thế này?

Hey guys ! Hãy chắc chắn rằng vai trò của bạn làm cho bạn đạt được mục tiêu của mình. Nếu không, bạn chỉ đơn thuần là đang thỏa hiệp với cuộc sống và sự nghiệp của mình mà thôi. Nếu bạn không hài lòng về chuyên môn của mình thì cũng chính là đang hủy hoại cuộc sống cá nhân của mình đó.

Bài viết được dịch từ link: https://www.softwaretestinghelp.com/qa-roles-vs-goals/