Mở đầu — vì sao bài này quan trọng
Bạn đã đọc qua những bài trước về cách viết User Story, Acceptance Criteria, vẽ process flow hay phân tích stakeholder. Bạn biết lý thuyết. Nhưng khi nhà tuyển dụng BA mở CV của bạn ra và thấy dòng chữ "QA/Tester — 3 năm kinh nghiệm", câu hỏi đầu tiên trong đầu họ luôn là: "Người này biết test, nhưng đã bao giờ thực sự làm phân tích nghiệp vụ chưa?"
Đây chính là khoảng trống chết người của hầu hết người chuyển nghề. Bạn có kỹ năng, nhưng bạn không có bằng chứng. Và trong tuyển dụng BA, bằng chứng không nằm ở số năm kinh nghiệm — nó nằm ở những sản phẩm (artifact) bạn có thể đặt lên bàn và nói: "Đây, tôi đã phân tích nghiệp vụ này, đây là cách tôi suy nghĩ, đây là tài liệu tôi tạo ra."
Portfolio chính là tập hợp bằng chứng đó. Với người từ QA, portfolio còn quan trọng hơn người mới ra trường, vì nó giải quyết được nghi ngờ lớn nhất: chứng minh bạn đã thực sự tư duy như một BA chứ không chỉ "đọc sách BA". Tin tốt là bạn có lợi thế khổng lồ mà sinh viên mới không có — bạn đã từng tiếp xúc trực tiếp với hàng trăm tính năng thật, hiểu chúng hoạt động ra sao, biết chỗ nào dễ hỏng. Bài học này dạy bạn cách biến vốn liếng đó thành 3 case study portfolio đủ sức thuyết phục nhà tuyển dụng — đặc biệt là case study lõi: Acceptance Criteria + Traceability Matrix từ một tính năng bạn từng test.
Khái niệm cốt lõi
Portfolio BA khác gì so với CV?
CV nói bạn đã làm gì. Portfolio cho thấy bạn làm như thế nào. Một dòng "Viết user stories cho dự án thanh toán" trên CV là lời khẳng định không kiểm chứng được. Nhưng một file PDF chứa user story thật, có acceptance criteria rõ ràng, kèm sơ đồ luồng và ma trận truy vết, thì là bằng chứng tự nó nói lên năng lực. Trong bài này chúng ta tập trung riêng vào việc xây dựng portfolio — không bàn về cách viết CV (đó là bài khác) hay cách trả lời phỏng vấn (cũng là bài khác).
Nguyên tắc vàng: re-frame, đừng bịa
Người chuyển nghề hay mắc một trong hai sai lầm cực đoan. Một là bịa ra dự án không có thật để cho portfolio "hoành tráng". Hai là không dám đưa gì vào vì "tôi chưa từng làm BA chính thức". Cách đúng nằm ở giữa: re-frame — lấy một tính năng bạn đã thực sự test, rồi nhìn lại nó qua lăng kính BA. Bạn không bịa dữ liệu; bạn chỉ kể lại trải nghiệm thật theo góc nhìn mới.
Ví dụ, hồi làm QA bạn từng test chức năng "áp mã giảm giá" trên một sàn thương mại điện tử. Bạn biết rõ: mã hết hạn thì sao, mã dùng quá số lần thì sao, mã áp cho sản phẩm sale thì sao. Đó chính là business rules — thứ BA phải khai thác. Bạn đã nắm nó từ góc độ test; giờ bạn viết lại nó từ góc độ phân tích. Đây là re-frame chứ không phải bịa.
Ba case study chuẩn cho portfolio QA → BA
Một portfolio tốt không cần nhiều, chỉ cần 3 case study chất lượng, mỗi cái thể hiện một nhóm năng lực khác nhau:
Case study 1 — Acceptance Criteria + Traceability Matrix (lõi). Lấy một tính năng bạn từng test, re-frame qua lăng kính BA. Output gồm: User Story chuẩn, bộ Acceptance Criteria, và một Traceability Matrix nối requirement với AC và test case. Đây là case study mạnh nhất vì nó tận dụng trực tiếp kỹ năng QA cũ và biến nó thành sản phẩm BA. Nhà tuyển dụng nhìn vào sẽ hiểu ngay: người này biết cách đảm bảo không một yêu cầu nào bị bỏ sót.
Case study 2 — Process Flow / Gap Analysis. Chọn một quy trình nghiệp vụ bạn hiểu rõ (ví dụ luồng đặt hàng, luồng hoàn tiền). Vẽ AS-IS (hiện trạng), chỉ ra điểm nghẽn, đề xuất TO-BE (mong muốn). Case study này chứng minh bạn không chỉ nhìn từng màn hình mà còn thấy được bức tranh quy trình tổng thể.
Case study 3 — Requirement Elicitation / Stakeholder. Mô phỏng việc khai thác yêu cầu: bạn đặt ra câu hỏi gì với stakeholder, ghi lại giả định và rủi ro ra sao. Case study này lấp đúng điểm yếu mà nhà tuyển dụng nghi ngờ nhất ở dân QA: khả năng làm việc với con người, không chỉ với hệ thống.
Trong khuôn khổ bài này, tôi sẽ đào sâu nhất vào Case study 1, vì đó là nơi lợi thế QA của bạn tỏa sáng rõ nhất và là phần khó nhất để làm cho "ra dáng BA".
Traceability Matrix — vũ khí bí mật của dân QA
Ma trận truy vết (Traceability Matrix) là bảng nối từng yêu cầu (requirement) với các thành phần liên quan: user story, acceptance criteria, test case, và đôi khi cả màn hình thiết kế. Mục đích là đảm bảo không yêu cầu nào bị rơi rớt trong quá trình phát triển. Dân QA vốn đã quen với khái niệm này dưới dạng "test coverage" — và đó chính là lý do nó là điểm tựa hoàn hảo để bạn thể hiện sự khác biệt so với BA "tay ngang" không có nền kiểm thử.
Tình huống thực tế
Ví dụ 1 — Lan, QA tại công ty outsource ở Đà Nẵng
Lan có 4 năm test thủ công cho các dự án fintech của khách Nhật. Khi muốn chuyển sang BA, cô gửi 30 CV và chỉ nhận được 2 lời mời phỏng vấn — cả hai đều bị loại ở vòng "bạn có sản phẩm BA nào không?".
Lan ngồi lại và chọn đúng một tính năng cô thuộc nằm lòng: chức năng chuyển khoản nội bộ với hạn mức theo ngày. Cô từng viết 47 test case cho nó. Cô re-frame như sau: viết User Story ("Là người dùng, tôi muốn chuyển tiền giữa các tài khoản của mình để tôi quản lý dòng tiền"), bóc tách 8 acceptance criteria (hạn mức ngày 100 triệu, cảnh báo khi vượt, chặn khi tài khoản bị khóa, OTP cho giao dịch trên 10 triệu...), rồi dựng một Traceability Matrix nối 8 AC này với 47 test case cũ của cô.
Kết quả: trong buổi phỏng vấn tiếp theo, cô mở file PDF này ra. Người phỏng vấn — một BA Lead — dừng lại hỏi: "Cái traceability matrix này em tự làm à?" Lan giải thích cách cô đảm bảo mỗi AC đều có test case phủ. BA Lead gật gù: "Đây đúng là thứ team anh đang thiếu." Lan nhận offer với mức 18 triệu, cao hơn lương QA cũ 3 triệu.
Bài học: Đừng cố làm portfolio về lĩnh vực bạn không biết. Lan thắng vì cô chọn đúng tính năng mình thuộc nhất, và biến điểm mạnh QA (test coverage) thành điểm mạnh BA (traceability).
Ví dụ 2 — Tuấn, QA automation tại một startup e-commerce ở TP.HCM
Tuấn giỏi code test nhưng portfolio đầu tiên của cậu thất bại. Cậu nhồi vào đó 5 case study, mỗi cái sơ sài: chỉ có vài dòng user story copy từ template trên mạng, không có context, không có business rule cụ thể. Nhà tuyển dụng đọc xong nhận xét: "Em viết user story đúng cú pháp nhưng không có chiều sâu nghiệp vụ — giống như học thuộc lòng."
Tuấn làm lại. Lần này cậu chỉ giữ một case study về tính năng "voucher giảm giá theo combo sản phẩm" mà cậu từng automation test. Cậu đào sâu: liệt kê 12 business rule thật (voucher không cộng dồn với flash sale, voucher freeship yêu cầu đơn tối thiểu 199k, voucher chỉ áp cho 1 ngành hàng...), viết AC cho từng rule, và thêm một bảng edge case — đây là chỗ Tuấn ghi điểm tuyệt đối, vì tư duy edge case là siêu năng lực của dân QA. Cậu chỉ ra: "Điều gì xảy ra nếu user áp voucher rồi bỏ sản phẩm khỏi giỏ khiến đơn xuống dưới mức tối thiểu?" — một câu hỏi mà nhiều BA thuần không nghĩ tới.
Kết quả: case study duy nhất nhưng sâu này giúp Tuấn vào vòng cuối ở 3 công ty. Một interviewer nói thẳng: "Cách em phát hiện edge case trong nghiệp vụ tốt hơn nhiều BA có kinh nghiệm."
Bài học: Một case study sâu thắng năm case study nông. Và tư duy edge case của QA là tài sản hiếm — hãy phô diễn nó có chủ đích trong portfolio.
Ví dụ 3 — Nhóm học viên tự dựng portfolio chung từ app gọi xe
Một nhóm 3 học viên không có dự án thật đủ ấn tượng đã chọn cách phân tích một sản phẩm công khai: tính năng "đặt xe và hủy chuyến" của một app gọi xe phổ biến tại Việt Nam. Họ tự trải nghiệm app như người dùng, ghi lại luồng, suy luận business rule (phí hủy sau 5 phút tài xế nhận chuyến, hoàn tiền ví trong bao lâu...), rồi viết bộ user story + AC + traceability matrix dựa trên quan sát.
Họ ghi rõ trong portfolio: "Đây là reverse-engineering từ sản phẩm công khai, các business rule là giả định dựa trên quan sát, không phải tài liệu nội bộ." Sự trung thực này lại được đánh giá cao — vì nó cho thấy họ hiểu ranh giới giữa quan sát và sự thật, một phẩm chất quan trọng của BA.
Bài học: Khi không có dự án thật đủ tốt, reverse-engineering một sản phẩm công khai là hợp lệ — miễn là bạn minh bạch về giả định. Lợi thế QA ở đây là bạn đã quen "khám phá hành vi hệ thống" qua exploratory testing.
Hướng dẫn từng bước
Dưới đây là quy trình dựng Case study 1 — AC + Traceability Matrix, case study lõi của portfolio.
Bước 1 — Chọn tính năng. Chọn một tính năng bạn đã thực sự test và hiểu rõ nhất. Tiêu chí: đủ phức tạp để có business rule thú vị (5–15 rule là lý tưởng), nhưng không quá lớn đến mức không gói gọn được. Tính năng tốt: áp mã giảm giá, đăng nhập có khóa tài khoản, hạn mức giao dịch, phân quyền người dùng. Tránh tính năng quá đơn giản như "nút logout".
Bước 2 — Viết bối cảnh (Context). Mở đầu case study bằng 3–4 câu: sản phẩm là gì, người dùng là ai, vấn đề nghiệp vụ cần giải. Nhà tuyển dụng cần hiểu sân chơi trước khi đọc chi tiết. Nếu là re-frame từ dự án thật, có thể đổi tên công ty thành tên ẩn danh ("một sàn TMĐT").
Bước 3 — Viết User Story. Theo cú pháp chuẩn: "Là [vai trò], tôi muốn [mục tiêu], để [giá trị]." Một tính năng có thể tách thành vài user story nhỏ. Đừng viết một story khổng lồ ôm hết.
Bước 4 — Bóc tách Acceptance Criteria. Đây là nơi lợi thế QA tỏa sáng. Với mỗi user story, viết AC theo định dạng Given-When-Then hoặc checklist. Lôi ra cả các business rule ngầm: hạn mức, điều kiện hết hạn, trạng thái lỗi, thông báo lỗi. Cố gắng phủ cả happy path lẫn các nhánh ngoại lệ.
Bước 5 — Dựng Traceability Matrix. Tạo bảng với các cột: ID Requirement | Mô tả Requirement | User Story | Acceptance Criteria | Test Case ID | Trạng thái phủ. Mỗi dòng nối một yêu cầu xuyên suốt tới test case. Cột cuối cho thấy bạn kiểm soát được độ phủ — đúng tư duy QA.
Bước 6 — Thêm mục Edge Case & Giả định. Một bảng nhỏ liệt kê các tình huống biên bạn phát hiện và các giả định bạn đặt ra (vì BA luôn phải làm rõ điều chưa rõ). Đây là phần khiến portfolio QA-turned-BA nổi bật.
Bước 7 — Đóng gói chuyên nghiệp. Xuất file PDF sạch sẽ, có trang bìa, mục lục, đánh số trang. Đặt lên một nơi truy cập được: Google Drive (link chia sẻ), Notion public page, hoặc một repo. Trong CV và LinkedIn, gắn link tới portfolio này.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhồi nhét số lượng thay vì chiều sâu. Như câu chuyện của Tuấn: 5 case study nông thua 1 case study sâu. Nhà tuyển dụng đọc lướt rất nhanh; họ tìm chiều sâu tư duy, không tìm độ dày tài liệu. Mẹo: giữ tối đa 3 case study, mỗi cái đào tới tận business rule.
Lỗi 2 — User story đúng cú pháp nhưng rỗng nghiệp vụ. Copy template "Là người dùng, tôi muốn đăng nhập" mà không có AC cụ thể, không có business rule. Mẹo: với mỗi user story phải có ít nhất 4–5 AC chạm vào logic nghiệp vụ thật, không chỉ "đăng nhập thành công thì vào trang chủ".
Lỗi 3 — Giấu nguồn gốc hoặc bịa dữ liệu. Nếu reverse-engineer sản phẩm công khai mà nói như tài liệu nội bộ, bạn sẽ bị bắt bài ngay khi phỏng vấn sâu. Mẹo: luôn ghi rõ "giả định dựa trên quan sát". Trung thực là một điểm cộng, không phải điểm trừ.
Lỗi 4 — Bỏ phí lợi thế QA. Nhiều người chuyển nghề cố giấu nền QA vì sợ bị xem là "chỉ biết test". Sai lầm. Traceability và edge case là thứ BA thuần thiếu. Mẹo: chủ động làm nổi bật chính những phần này trong portfolio.
Lỗi 5 — Trình bày cẩu thả. File Word lộn xộn, font lung tung, không có mục lục. BA là nghề về tài liệu — portfolio cẩu thả là tự tố cáo. Mẹo: đầu tư 1–2 giờ làm template đẹp, dùng lại cho cả 3 case study.
Mẹo vàng: Mỗi case study nên kết bằng một đoạn ngắn "Tư duy của tôi" — giải thích tại sao bạn ra quyết định phân tích đó. Nhà tuyển dụng tuyển BA là tuyển cách tư duy, không phải tuyển file PDF.
Bài tập thực hành
- Chọn tính năng (15 phút): Liệt kê 3 tính năng bạn từng test và hiểu rõ nhất. Chấm điểm mỗi cái theo độ phức tạp business rule (1–5). Chọn cái điểm cao nhất làm case study lõi.
- Re-frame thành User Story (30 phút): Viết 2–3 user story cho tính năng đã chọn, theo cú pháp "Là... tôi muốn... để...".
- Bóc AC (45 phút): Với mỗi user story, viết tối thiểu 5 acceptance criteria, trong đó ít nhất 2 cái chạm tới business rule hoặc ngoại lệ.
- Dựng Traceability Matrix (45 phút): Tạo bảng nối Requirement → User Story → AC → Test Case (dùng lại test case cũ nếu có). Thêm cột trạng thái phủ.
- Bảng Edge Case (20 phút): Liệt kê 5 tình huống biên bạn phát hiện và 3 giả định cần làm rõ với stakeholder.
- Đóng gói (30 phút): Xuất tất cả thành 1 PDF có bìa, mục lục, đánh số trang. Upload lên Google Drive hoặc Notion và lấy link chia sẻ.
Tóm tắt
Portfolio là cách bạn biến nghi ngờ của nhà tuyển dụng ("dân test có làm BA được không?") thành bằng chứng không thể chối cãi. Với người từ QA, công thức thắng gồm: 3 case study chất lượng thay vì nhiều case study nông; re-frame từ tính năng đã test thật thay vì bịa; và đặc biệt là case study lõi AC + Traceability Matrix, nơi bạn biến test coverage và tư duy edge case — vốn là điểm mạnh sẵn có của QA — thành sản phẩm BA thuyết phục. Hãy nhớ bài học từ Lan và Tuấn: chọn đúng tính năng bạn thuộc nhất, đào sâu tới business rule, phô diễn lợi thế QA thay vì giấu nó, và trình bày chuyên nghiệp, trung thực. Một portfolio như thế không chỉ giúp bạn qua vòng hồ sơ — nó định hình luôn cách bạn được nhìn nhận trong suốt buổi phỏng vấn.