HÀNH TRÌNH TRỞ THÀNH BUSINESS ANALYST (BA) TỪ QUALITY CONTROL (QC/QA)
Chào mọi người, mình thường thấy trên các group về BA mọi người thường đăng: “Hiện tại em đang là ABC em muốn trở thành BA thì em nên bắt đầu từ đâu?” Thật ra đối với câu hỏi này thì sẽ không có câu trả lời chung nào cho tất cả, mỗi người sẽ có điểm mạnh điểm yếu riêng thì lộ trình bắt đầu của mỗi người sẽ khác nhau.
Với bài viết này mình chia sẻ về hành trình trở thành BA từ QA/QC và mình hy vọng nó có thể giúp ích được các bạn một phần nào đó.
Ok, let’s get started!!!
1. Bạn đã có những gì?
1.1. Analytical Thinking (Tư duy phân tích)
QC có nhiệm vụ phân tích các tài liệu đặc tả yêu cầu SRS để viết ra các Test Case/Test Scenario để bao phủ toàn bộ các yêu cầu của phần mềm. Quá trình review và phân tích SRS để bắt “bug” BA:
- SRS có thông tin nào bị sai không, thiếu trường hợp nào mà BA bị miss không
- Các yêu cầu non-functional như hiệu suất/bảo mật đã được đề cập
- Đánh giá tính khả thi của yêu cầu
- Bất cứ yêu cầu ambiguous nào cũng phải được clear đến tận chân tơ kẽ tóc
1.2. Kỹ năng giao tiếp
Việc communicate với developer để giải quyết các issue bug, với technical lead về solution, với BA để clarify requirement là chuyện “như cơm bữa” với QC.
Ngoài ra, bạn có thể tận dụng các cơ hội để cải thiện communicate của mình và làm tiền đề cho con đường tiến lên BA:
- Demo các tính năng team làm được trong buổi Sprint Review, đã và chưa hoàn thành được gì trong sprint vừa rồi
- Support khách hàng test UAT, lên production
- Triển khai vận hành
1.3. Quy trình làm việc
Dù làm bất kỳ trong Waterfall, V model hay Scrum thì bạn cũng hiểu rõ quy trình làm việc trong một dự án phần mềm là như thế nào. Đây là một lợi thế to lớn khi việc nắm rõ giúp bạn có thể làm việc với development team smooth hơn, biết cách giải quyết các vấn đề nội bộ
Hiểu được output của mỗi quy trình, role involve như:
- Lập Project Master Plan
- Phân tích yêu cầu
- Thiết kế hệ thống
- Xây dựng hệ thống
- Kiểm thử
- Triển khai và bảo trì
2. Bạn cần làm gì: Clear một phần mindset
2.1. Bắt đầu với “WHY?” thay vì “WHAT?”
Với mindset của QC, khi nhận được bất cứ yêu cầu phần mềm nào thì QC 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?
- Etc.
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.
2.2. Không nên đi vào chi tiết quá sớm
Đứng dưới góc nhìn của QC 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.
2.3. Chất lượng phần mềm quan trọng nhưng không phải là nhất
QC 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ủ…
Vậy là mình đã trình bày cơ bản xong phần 1 của series “Hàng trình trở thành BA từ QC”. Hẹn gặp lại các bạn trong phần tiếp theo của series này nhé.
