QA(Tester) là người kiểm tra phần mềm được phát triển để đảm bảo phần mềm đáp ứng các yêu cầu cuối cùng của khách hàng. BA cũng chịu trách nhiệm xác minh phần mềm được xây dựng và phân phối có đáp ứng các yêu cầu cuối cùng của khách hàng hay không.

Nếu BA và tester chuyển đổi vai trò của họ, thì mỗi người trong số họ có thể giải phóng bộ kỹ năng của họ có thể mang lại lợi ích cho chính dự án. Khi nói đến kiểm thử hệ thống phần mềm, cả tester và BA đều hoạt động như hai mặt của cùng một đồng tiền.

1. Tại sao lại là Business Analyst (BA)?

(Image Source: https://softwaretester.careers/how-to-transition-your-career-from-qa-to-ba)

Tester chuyên nghiệp có kiến thức và hiểu biết toàn diện về phần mềm. Kỹ năng này mở ra cánh cửa cho Tester tham gia vào nhiều vai trò trong ngành CNTT và bằng cách hiểu rõ chu kỳ phát triển và quy trình phát triển, Tester có thể chọn trở thành người quản lý phát hành, kỹ sư tự động hóa.

Có thể nói rằng, chuyển đổi nghề nghiệp trong phân tích nghiệp vụ là một trong những triển vọng của Tester. Phân tích nghiệp vụ là một vai trò lớn hơn nhiều khi so sánh với kiểm thử hoặc bất kỳ vai trò nào khác được đề cập ở trên.

Tester co những cơ hội để trở thành BA:

Một chuyên gia kiểm thử có nhiều lý do để nghĩ đến việc chuyển đổi nghề nghiệp sang BA bởi một vài lý do nhận định sau:

• Người kiểm tra chú ý đến từng chi tiết nhỏ và có hiểu biết cực kỳ sâu về hệ thống phần mềm được xây dựng
• Điều tự nhiên là một Tester giỏi luôn đặt lợi ích của khách hàng lên hàng đầu.
• Một Tester được yêu cầu đọc, phân tích và xem xét các tài liệu đặc tả yêu cầu, điều này giúp họ có thêm lợi thế trong việc theo đuổi vai trò BA.
• Kỹ năng phân tích của người kiểm tra giúp nhà phân tích kinh doanh chỉ ra sự không rõ ràng trong các đặc tả yêu cầu nếu có.
• Việc người kiểm thử trở thành một nhà phê bình trong việc kiểm tra các yêu cầu trực quan của phần mềm là điều tự nhiên. Điều này có xu hướng giúp người kiểm tra trong khi đối chiếu các yêu cầu từ khách hàng. Tester phải trực quan hóa hệ thống làm việc trong giai đoạn kích thích yêu cầu. Nhiều yêu cầu không đáng có và không hợp lý được loại trừ ở giai đoạn đầu.
• Vì những người Tester luôn suy nghĩ chín chắn, họ nhất định phải nghĩ ra một bức tranh toàn cảnh về hệ thống. Đây là đức tính lớn nhất có thể giúp ích trong phân tích kinh doanh, đặc biệt là trong quá trình kích thích yêu cầu.
• Người kiểm thử tham gia vào các dự án và ghi lại các báo cáo lỗi. Điều này giúp người kiểm tra nâng cao kỹ năng tài liệu rất cần thiết trong phân tích kinh doanh.
• Nếu người kiểm thử đang làm việc trong Agile Framework, thì việc chuyển sang phân tích kinh doanh sẽ dễ dàng hơn. Điều này đã được giải thích chi tiết trong phần tiếp theo.

Agile nằm trong danh mục ‘Iterative & Incremental’ . Cách tiếp cận khác với Waterfall trong đó sản phẩm cuối cùng được phát hành và chỉ có sẵn để thử nghiệm ở giai đoạn cuối. Trong Agile, toàn bộ yêu cầu được chia thành các nhóm requirement và thay vì phát triển toàn bộ hệ thống cùng một lúc, từng nhóm yêu cầu được phát triển, thử nghiệm và phát hành cho khách hàng. Phần mềm được phát hành có khả năng giao hàng cho khách hàng.

Nhóm Agile là “Tự tổ chức” với Product Owner (BA xác định và quản lý các yêu cầu), Master (Người quản lý và kiểm soát nhóm) & Thành viên nhóm (thường có 5 đến 9 thành viên nhóm đa chức năng bao gồm Dev Team và Tester team). Vì vậy, đó là tất cả về sự năng động của đội và tính kỷ luật cao.

Như ở hình trên, BA tham gia vào giai đoạn đầu của quy trình ngay từ đưa ra các product backlog (các yêu cầu), lập kế hoạch chạy nước rút, hỗ trợ Dev team với các yêu cầu trong quá trình phát triển phần mềm và cả kiểm tra các yêu cầu cấp cao sau khi kiểm tra xong.

Nhiều BA thường chỉ kiểm tra việc xây dựng phần mềm trong suốt chu kỳ.

Tester cũng thường tham gia ngay từ khi lập kế hoạch chạy nước rút, họp đánh giá, tương tác chặt chẽ với Dev team và thử nghiệm kỹ lưỡng.

Có sự chồng chéo về trách nhiệm của BA và Tester ở đây. Khi người kiểm thử trở thành nhà phân tích kinh doanh tức là Tester BA, sự tham gia của anh ta vào toàn bộ quá trình từ đầu đến cuối và do đó, người kiểm tra sẽ dễ dàng chuyển sang hồ sơ BA trong Agile Framework.

2. Các bước để Tester có thể trở thành BA

Step 1:

Đó là một động thái tích cực và việc chuẩn bị phải bắt đầu khi bạn vẫn còn là một Tester

Quan sát và tiếp thu trách nhiệm của một BA. Điều này trở nên dễ dàng khi bạn là một phần của Agile process. Nếu không nhanh nhẹn, hãy nỗ lực thêm để làm việc chặt chẽ với BA.

Chia sẻ khối lượng công việc của anh ấy / cô ấy. Bạn có thể nhận các nhiệm vụ nhỏ trong khi quản lý các hoạt động của riêng mình. Quan sát BA trong các tương tác với khách hàng ở nước ngoài hoặc khi khách hàng gọi điện cho quá trình giải thích yêu cầu.

Step 2:

Đọc, phân tích và xem xét các tài liệu đặc tả yêu cầu do BA cung cấp nhưng với một góc độ khác ngoài góc độ của Tester. Đọc các yêu cầu từ góc độ khơi gợi. Hãy nghĩ đến việc đặt câu hỏi về các yêu cầu như trong “Tại sao lại yêu cầu như vậy?”.

Hiểu các quy trình kinh doanh và nghĩ về chúng từ đầu đến cuối. Cố gắng ánh xạ quy trình và yêu cầu với phần mềm hiện có nếu có để tìm ra những khoảng trống yêu cầu. Nếu đó là tùy chỉnh 100%, thì hãy nghĩ đến giải pháp. Giải pháp do bạn cung cấp và giải pháp được cung cấp bởi một BA nhất định khác nhau. Giải pháp của bạn có thể tốt hơn.

Step 3:

Nếu bạn đang thích các hoạt động nêu trên thì bạn có thể nghiêm túc nghĩ đến việc tiếp tục với các kế hoạch cụ thể để trở thành một BA

Lĩnh vực đầu tiên và quan trọng nhất để làm việc là “Kỹ năng giao tiếp”. Nếu bạn cho rằng mình chưa đủ giỏi thì hãy nhanh chóng bắt tay vào việc tương tự. Kỹ năng giao tiếp bằng miệng và bằng văn bản xuất sắc là điều bắt buộc. Điều cực kỳ quan trọng là phải nắm vững tiếng Anh.

Một BA được yêu cầu phải giao tiếp với khách hàng và các bên liên quan khác nhau trong doanh nghiệp để đưa ra các yêu cầu. BA cũng được yêu cầu để truyền đạt các yêu cầu cho một nhóm phát triển. BA cần chuyển đổi các yêu cầu thành các đặc tả mà các nhà phát triển có thể dễ dàng hiểu được. Kỹ năng giao tiếp kém có thể dẫn đến sai sót trong việc thu thập và sau đó chuyển các yêu cầu từ khách hàng sang nhóm phát triển, do đó dẫn đến hệ thống phần mềm được xây dựng không chính xác.

Cải thiện kỹ năng viết và nói tiếng Anh hoàn toàn không phải là một quá trình nhanh chóng. Nó có thể đạt được một cách từ từ và đều đặn bằng cách hỗ trợ BA trong các bài tập bằng văn bản, và nỗ lực chân thành & liên tục để giao tiếp bằng tiếng Anh với các thành viên trong nhóm. Các khóa học nói tiếng Anh đôi khi có thể hữu ích.

Cách tốt nhất là giao tiếp bằng tiếng Anh cả trong môi trường cá nhân cũng như công việc với các đồng nghiệp. Nhận phản hồi và sửa chữa theo đúng tinh thần và tiếp tục cải thiện đều đặn.

Step 4:

Bước tiếp theo là mua bằng MBA hoặc bằng cấp tương đương. Bây giờ nó là BẮT BUỘC.

Thành công trong sự nghiệp của một BA mà không có bằng cấp quản lý là không đầy đủ. Mặc dù có một số cử nhân trong một số ngành không có bằng cấp quản lý nhưng bất kỳ tổ chức CNTT tốt và có uy tín nào cũng luôn xem xét một cử nhân có bằng cấp quản lý. Điều này sẽ tiếp tục đóng vai trò là một trở ngại trong con đường sự nghiệp, có thể là đối với sự phát triển hoặc đối với một gói lương béo bở.

Và có một lý do cho cùng một. MBA tạo ra sự khác biệt - 108%. MBA mang lại những điều tốt nhất trong bạn. Nó giúp nâng cao kỹ năng giao tiếp, kỹ năng giải quyết vấn đề, phát triển nhân cách, kỹ năng lãnh đạo, kỹ năng ra quyết định, kỹ năng quản lý, kỹ năng đàm phán, thuyết phục và cuối cùng nhưng không kém phần quan trọng là nó sẽ giúp bạn kiếm được mức lương cao.

Người kiểm tra có thể theo đuổi một khóa học MBA toàn thời gian, điều này có lợi hơn vì thiết kế khóa học phù hợp nhất với bạn.

Tuy nhiên, người ta cũng có thể chọn một khóa học MBA bán thời gian. Dù là bán thời gian hay toàn thời gian, bạn bắt buộc phải lấy bằng cấp từ một tổ chức quản lý tốt và có uy tín. Bằng cấp không có sự phát triển về nhân cách sẽ ít hữu ích hơn về lâu dài.

Trong nhiều tổ chức CNTT hàng đầu, MBA hoặc bằng cấp tương đương là bắt buộc đối với vai trò của Nhà phân tích kinh doanh. Khung lương cũng khác nhau đối với các ứng viên MBA và không MBA ứng tuyển vào vị trí BA. Vì vậy, ngoài việc phát triển nhân cách và nâng cao kỹ năng giao tiếp, MBA hứa hẹn sự phát triển cả về điểm số và điểm số.

Step 5:

Để theo đuổi một khóa học MBA toàn thời gian, một người rõ ràng sẽ phải rời bỏ công việc của mình. Nhưng điều đó hoàn toàn xứng đáng. Bạn sẽ được hưởng nhiều lợi ích hơn khi tiếp tục công việc sau khi hoàn thành khóa học quản lý.

Người kiểm tra có thể không phải từ chức nếu anh ta quyết định theo đuổi khóa học MBA bán thời gian. Nhưng nhiều khi việc học và làm đồng thời sẽ khiến bản thân nhận áp lực nhiều hơn. Nhưng một lần nữa, những nỗ lực và cố gắng đã được đền đáp xứng đáng.

Hoàn thành khóa học quản lý của bạn với sự chân thành và kiên nhẫn. Khoảng thời gian của hầu hết các khóa học quản lý là một hoặc hai năm.

3. Vậy Tester cần làm gì: Clear một phần mindset

Bắt đầu với “WHY?” thay vì “WHAT?”

Với mindset của Tester, khi nhận được bất cứ yêu cầu phần mềm nào thì Tester thường sẽ đặt các câu hỏi như: Tính năng này là gì? Làm thế nào để test được tính năng này? *Permission của tính năng này là gì? * Ai có quyền sử dụng tính năng này?

Thay vào đó, chúng ta nên bắt đầu bằng **“WHY?” **

• Tại sao chúng ta phải làm tính năng này?
• Mục đích của nó để làm gì?
• Current process của user là gì để xác định tại sao chúng ta phải enhance chỗ này?
• Tính năng này là CUSTOMER WANTS hay CUSTOMER NEEDS? Ở vị trí này, cái mà bạn tiếp nhận không còn là software requirement để test nữa mà là yêu cầu, mong muốn của khách hàng nên mindset đặt câu hỏi của bạn nên thay đổi.

Không nên đi vào chi tiết quá sớm

Đứng dưới góc nhìn của Tester sẽ focus rất nhiều vào unhappy case khi bất kì một tính năng nào đó được đưa ra. Tuy nhiên, trong một buổi meeting về tính năng mới với khách hàng, khách hàng chỉ muốn bạn proposed các giải pháp để giải quyết vấn đề của người ta. Một vấn đề không chỉ có một cách giải quyết, phân tích ưu nhược điểm của mỗi cái sẽ tốt hơn là chăm chăm vào các unhappy case. Mình nói vậy không có nghĩa là phân tích exception flow này không cần thiết mà là vẫn cần nhưng chưa phải ở giai đoạn này.

Chất lượng phần mềm quan trọng nhưng không phải là nhất

Tester thường có mindset đòi hỏi mọi thứ đều phải hoàn hảo cho đến khi release:

• 100% test case coverage
• 0 bug kể cả bug minor

Tuy nhiên đối với BA thì bạn nên chấp nhận sự không hoàn hảo khi release tính năng lên production, những case minor hoặc case khó có thể xảy ra có thể bỏ qua fix sau vì mục đích để đáp ứng yêu cầu khách hàng thời điểm đó như chạy campain marketing nhân dịp holiday, cạnh tranh với các đối thủ…

Refer: https://www.softwaretestinghelp.com/career-shift-from-tester-to-ba/