Mở đầu — vì sao bài này quan trọng
Trong hầu hết các dự án phần mềm, phần "test scenario" (kịch bản kiểm thử) thường được coi là việc của QA. Nhưng sự thật ít ai nói thẳng: rất nhiều bug lọt ra production không phải vì QA làm ẩu, mà vì requirements được viết ra thiếu các tình huống mà người dùng thật sự gặp phải. BA chính là người nắm chìa khóa ở đây. Một BA giỏi không chỉ viết acceptance criteria (tiêu chí chấp nhận) cho "happy path" — luồng lý tưởng khi mọi thứ diễn ra đúng — mà còn phải chỉ ra được các kịch bản edge case, luồng lỗi, và những cách dùng "bất thường" mà người dùng thực tế sẽ tạo ra.
Và đây chính là nơi bạn — một người từ Customer Service (CS) chuyển sang BA — có lợi thế gần như không thể sao chép được. Trong khi một BA xuất thân từ IT phải tưởng tượng xem người dùng có thể làm sai điều gì, thì bạn đã tận mắt chứng kiến hàng nghìn lần người dùng làm sai trong quãng thời gian làm support. Bạn đã đọc những ticket kiểu "tôi nhập số điện thoại có dấu cách ở giữa nên hệ thống báo lỗi", "tôi bấm nút thanh toán hai lần vì trang load chậm nên bị trừ tiền hai lần", hay "tôi copy mã giảm giá từ email nên dính thêm khoảng trắng ở cuối". Đó chính là kho vàng test scenario mà không tài liệu requirements nào dạy được.
Bài học này sẽ giúp bạn biến kinh nghiệm CS thành một kỹ năng BA cụ thể: viết test scenario dựa trên dữ liệu thực tế từ trải nghiệm hỗ trợ khách hàng. Đây là kỹ năng giúp bạn nổi bật trong đội ngũ và tạo ra giá trị đo đếm được — ít bug hơn, ít ticket support hơn, ít rework hơn.
Khái niệm cốt lõi
Test scenario là gì và khác gì với test case
Trước khi đi sâu, cần phân biệt rõ hai thuật ngữ hay bị nhầm.
- Test scenario (kịch bản kiểm thử): mô tả tình huống hoặc luồng nghiệp vụ cần được kiểm tra, ở mức tương đối cao. Ví dụ: "Kiểm tra việc khách hàng thanh toán khi mạng bị gián đoạn giữa chừng".
- Test case (ca kiểm thử): chi tiết hóa từng bước cụ thể, dữ liệu đầu vào, và kết quả mong đợi của một scenario. Một scenario có thể sinh ra nhiều test case.
Ba loại kịch bản mà mọi BA cần bao phủ
Một tập scenario đầy đủ luôn có ba nhóm:
- Happy path (luồng thuận lợi): người dùng làm đúng, hệ thống chạy đúng. Đây là phần dễ nhất, ai cũng nghĩ ra được.
- Alternative path (luồng thay thế): người dùng đi con đường khác nhưng vẫn hợp lệ. Ví dụ: thanh toán bằng ví MoMo thay vì thẻ, hoặc dùng địa chỉ giao hàng khác địa chỉ mặc định.
- Exception / negative path (luồng lỗi và ngoại lệ): người dùng nhập sai, hệ thống gặp trục trặc, hoặc điều kiện bên ngoài thay đổi (mất mạng, hết hàng, session hết hạn). Đây là nơi 80% bug thật sự nằm, và cũng là nơi ex-CS tỏa sáng.
Vì sao ex-CS có lợi thế "không thể dạy được"
Kinh nghiệm CS cho bạn ba loại hiểu biết mà tài liệu requirements không bao giờ có:
Thứ nhất, bạn đã thấy edge case từ đời thật. Không phải edge case tưởng tượng trong phòng họp, mà là edge case có người thật kêu than, có screenshot, có số ticket. Bạn biết rằng "sinh nhật 29/02" không phải chuyện lý thuyết mà là ticket có thật mỗi bốn năm. Bạn biết có người đặt tên con là "Nguyễn Văn A." với dấu chấm cuối, và hệ thống nào đó sẽ hiểu nhầm.
Thứ hai, bạn biết người dùng "sáng tạo" workaround như thế nào. Khi hệ thống không cho họ làm điều họ muốn, người dùng không bỏ cuộc — họ tìm đường tắt. Họ nhập "0" vào ô số lượng để "xóa" sản phẩm thay vì bấm nút xóa. Họ dùng ô ghi chú đơn hàng để "chat" với shop. Họ đặt hai đơn hàng rồi hủy một đơn để né phí ship. Những hành vi này phá vỡ giả định của designer, và bạn là người duy nhất trong phòng biết chúng tồn tại.
Thứ ba, bạn biết hành vi khách hàng bất thường theo bối cảnh. Bạn biết rằng vào ngày sale lớn (như 12/12, Black Friday), người dùng sẽ bấm nút liên tục vì sốt ruột, tạo ra double-submit. Bạn biết khách hàng lớn tuổi hay để Caps Lock khi nhập email. Bạn biết người dùng ở tỉnh dùng mạng chậm nên hay bị timeout giữa chừng. Đây là kiến thức ngữ cảnh (contextual knowledge) cực kỳ giá trị.
Tình huống thực tế
Tình huống 1: Double-submit thanh toán tại một sàn TMĐT
Lan từng làm CS cho một sàn thương mại điện tử nội địa (giả định gọi là ShopViet) trong 3 năm trước khi chuyển sang BA. Trong sprint đầu tiên, đội của cô làm tính năng "thanh toán một chạm" cho ví điện tử.
Dev và QA viết scenario chuẩn: nhập đủ thông tin → bấm thanh toán → nhận xác nhận. Happy path hoàn hảo. Nhưng Lan nhớ lại: hồi làm CS, mỗi đợt Flash Sale cô nhận trung bình 40-50 ticket/ngày về việc "bị trừ tiền hai lần". Nguyên nhân: khi mạng chậm, nút thanh toán không phản hồi ngay, người dùng bấm lại 2-3 lần.
Lan bổ sung ngay scenario này vào phần acceptance criteria:
> Scenario: Người dùng bấm nút "Thanh toán" nhiều lần liên tiếp trong vòng 3 giây do phản hồi chậm. Kết quả mong đợi: hệ thống chỉ tạo đúng 1 giao dịch; các request trùng lặp bị chặn ở mức idempotency (không tạo giao dịch mới).
Dev khi nghe scenario này mới nhận ra API thanh toán chưa có cơ chế idempotency key (khóa đảm bảo một thao tác gửi nhiều lần chỉ tạo một kết quả). Họ bổ sung ngay trong sprint. Kết quả: sau khi ra mắt, tỉ lệ ticket "trừ tiền hai lần" giảm về gần 0.
Bài học rút ra: Một scenario duy nhất, xuất phát từ trí nhớ CS, đã ngăn một lỗi tài chính nghiêm trọng. BA xuất thân IT thuần rất khó nghĩ đến tình huống này vì họ test trên mạng văn phòng nhanh, không bao giờ thấy nút "treo".
Tình huống 2: Mã giảm giá dính khoảng trắng tại một chuỗi F&B
Minh chuyển từ CS của một app đặt đồ ăn (giả định gọi là FoodNow) sang làm BA. Đội của anh làm lại tính năng nhập voucher.
QA test bằng cách gõ tay mã voucher "SUMMER2026" — chạy ngon. Nhưng Minh nhớ rất rõ: hồi làm CS, có cả một loại ticket phổ biến là "mã giảm giá không hợp lệ" dù mã còn hạn. Sau nhiều lần điều tra, anh phát hiện người dùng thường copy mã từ email hoặc tin nhắn, và thao tác copy hay kéo theo một khoảng trắng thừa ở đầu hoặc cuối (ví dụ "SUMMER2026 " hoặc " SUMMER2026"). Hệ thống so khớp chính xác nên báo không hợp lệ.
Minh viết scenario:
> Scenario: Người dùng dán mã giảm giá có khoảng trắng thừa ở đầu/cuối, hoặc viết hoa/thường không đồng nhất (ví dụ "summer2026 "). Kết quả mong đợi: hệ thống tự động trim khoảng trắng và chuẩn hóa hoa/thường trước khi so khớp; mã vẫn được chấp nhận nếu hợp lệ.
Anh còn thêm scenario về ký tự Unicode "vô hình" (như dấu space không ngắt ) mà một số ứng dụng chat chèn vào khi copy. Đây là chi tiết cực kỳ đắt giá mà chỉ người từng lội trong ticket mới biết.
Bài học rút ra: Người dùng không tương tác với hệ thống trong môi trường "phòng lab sạch". Họ copy, paste, gõ nhầm, dùng bàn phím có bộ gõ tiếng Việt. Ex-CS mang được sự "bẩn" thực tế đó vào scenario.
Tình huống 3: Hủy đơn để né phí — hành vi lách luật tại một sàn logistics
Trang từng làm CS cho một nền tảng giao hàng (giả định gọi là GiaoNhanh). Khi chuyển sang BA, cô tham gia dự án chính sách phí ship theo ngưỡng đơn hàng: đơn trên 300.000đ được miễn phí ship.
Đội sản phẩm rất hào hứng với happy path. Nhưng Trang cảnh báo về một hành vi cô đã thấy vô số lần: khách hàng gộp đơn để đạt ngưỡng miễn phí, nhận hàng, rồi hủy phần không muốn — biến chính sách khuyến mãi thành lỗ hổng. Cô cũng biết một nhóm khách "chuyên nghiệp" đặt đơn lớn rồi hủy bớt ngay sau khi được xác nhận miễn ship.
Trang viết loạt scenario "gian lận / lạm dụng" (abuse scenario):
> Scenario: Người dùng đặt đơn đạt ngưỡng miễn ship, sau đó hủy một phần sản phẩm khiến giá trị đơn tụt xuống dưới 300.000đ. Kết quả mong đợi: hệ thống tính lại phí ship và thông báo cho người dùng trước khi xác nhận hủy; nếu đã giao thì áp dụng chính sách thu phí bổ sung.
Bài học rút ra: Test scenario không chỉ để bắt bug kỹ thuật, mà còn để bắt lỗ hổng nghiệp vụ (business logic loophole). Ex-CS là người hiểu rõ nhất động cơ và mánh khóe của khách hàng, nên viết được nhóm abuse scenario mà không ai khác nghĩ ra.
Hướng dẫn từng bước
Đây là quy trình cụ thể để bạn biến kinh nghiệm CS thành test scenario chất lượng cho mỗi feature.
Bước 1 — Lấy happy path làm khung. Bắt đầu với luồng lý tưởng: người dùng làm đúng từ A đến Z. Viết 1-2 scenario cho luồng này. Đây là điểm neo để bạn không đi lạc.
Bước 2 — "Khai quật" ký ức và dữ liệu CS. Đặt câu hỏi: "Nếu feature này ra mắt, tôi sẽ nhận loại ticket gì?" Hãy lục lại ba nguồn:
- Các loại ticket lặp đi lặp lại mà bạn từng xử lý.
- Báo cáo tổng hợp ticket theo tag/category (nếu công ty cũ có).
- Nhóm câu hỏi "how do I..." — nơi người dùng bối rối vì hệ thống không rõ ràng.
- Dữ liệu đầu vào bất thường: khoảng trắng thừa, ký tự đặc biệt, dấu tiếng Việt, số quá lớn/quá nhỏ, để trống, dán từ nguồn khác.
- Hành vi người dùng bất thường: bấm nhiều lần, bấm back giữa chừng, mở nhiều tab, để idle quá lâu (session timeout), làm ngược thứ tự.
- Điều kiện môi trường: mất mạng, mạng chậm, hết hàng đúng lúc thanh toán, hết hạn khuyến mãi trong khi đang thao tác.
- Lạm dụng / gian lận: người dùng cố lách chính sách, khai thác lỗ hổng để trục lợi.
- Given (bối cảnh): trạng thái hệ thống ban đầu.
- When (hành động): người dùng làm gì.
- Then (kết quả mong đợi): hệ thống phản ứng ra sao.
Bước 5 — Ước lượng độ ưu tiên. Không phải scenario nào cũng ngang nhau. Dùng công thức đơn giản: Tần suất xảy ra × Mức độ nghiêm trọng. Một scenario xảy ra thường xuyên và gây thiệt hại tiền bạc (như double-charge) phải ưu tiên cao nhất. Ở đây kinh nghiệm CS lại giúp bạn: bạn biết tần suất thực tế của mỗi loại lỗi vì bạn từng đếm ticket.
Bước 6 — Đưa scenario vào tài liệu và bàn giao. Gắn scenario vào acceptance criteria của user story, hoặc tạo một mục "Edge cases & Negative scenarios" riêng. Ngồi lại 15 phút với QA và dev để review — đây là lúc bạn "truyền" kiến thức ngữ cảnh CS cho cả đội.
Lỗi thường gặp & mẹo
Lỗi 1 — Chỉ viết happy path vì nó dễ và nhanh. Đây là cái bẫy lớn nhất. Happy path cho cảm giác "đã xong việc" nhưng thực chất bỏ trống 80% rủi ro. Mẹo: đặt quy tắc cá nhân "mỗi happy path phải kèm ít nhất 2 exception scenario".
Lỗi 2 — Liệt kê quá nhiều scenario vụn vặt không ưu tiên. Ngược lại với lỗi 1, một số ex-CS nhiệt tình quá mức, liệt kê 50 scenario ngang hàng khiến đội dev choáng và cuối cùng bỏ qua hết. Mẹo: luôn gắn mức ưu tiên Cao/Trung/Thấp, và chỉ đưa nhóm Cao vào must-have của sprint.
Lỗi 3 — Mô tả scenario bằng ngôn ngữ CS thay vì ngôn ngữ BA. Viết "khách kêu bị lỗi lung tung" thì dev không làm được gì. Mẹo: luôn cụ thể hóa đầu vào, hành động, và kết quả mong đợi bằng cấu trúc Given–When–Then.
Lỗi 4 — Quên nhóm abuse/gian lận. Nhiều BA chỉ nghĩ đến lỗi vô tình, quên rằng có người dùng cố ý phá luật. Mẹo: với mọi feature liên quan tiền, khuyến mãi, hoặc giới hạn, luôn hỏi "làm sao để lách cái này?".
Mẹo vàng — Xây "thư viện edge case" cá nhân. Ngay từ hôm nay, hãy lập một file (Notion, Excel, tùy bạn) ghi lại mọi loại edge case bạn từng gặp thời CS, phân theo chủ đề: nhập liệu, thanh toán, tài khoản, khuyến mãi, giao hàng... Đây sẽ là tài sản đi theo bạn suốt sự nghiệp BA, dùng lại cho mọi dự án.
Mẹo — Dùng dữ liệu thay vì cảm tính khi thuyết phục đội. Thay vì nói "tôi nghĩ nên test cái này", hãy nói "loại lỗi này chiếm khoảng 15% ticket ở công ty cũ, mỗi tháng khoảng 200 ticket". Con số làm scenario của bạn có sức nặng gấp nhiều lần.
Bài tập thực hành
Bài tập 1 — Khai quật ký ức CS. Chọn một tính năng bạn quen thuộc (ví dụ: đăng ký tài khoản, đặt hàng, đổi mật khẩu). Liệt kê ít nhất 8 loại ticket bạn từng gặp (hoặc có thể hình dung) liên quan đến tính năng đó. Với mỗi loại, ghi rõ nguyên nhân gốc.
Bài tập 2 — Chuyển ticket thành scenario. Lấy 5 loại ticket ở bài 1, viết lại thành 5 test scenario theo cấu trúc Given–When–Then. Đảm bảo mỗi scenario có kết quả mong đợi rõ ràng, đo được.
Bài tập 3 — Phân loại và ưu tiên. Với 5 scenario ở bài 2, phân loại theo 4 trục (đầu vào bất thường / hành vi bất thường / điều kiện môi trường / lạm dụng), rồi gán mức ưu tiên Cao/Trung/Thấp dựa trên công thức Tần suất × Mức nghiêm trọng. Viết một câu giải thích cho mỗi mức ưu tiên.
Bài tập 4 — Tình huống lạm dụng. Chọn một tính năng có yếu tố khuyến mãi hoặc giới hạn (voucher, freeship, giới hạn số lần dùng). Nghĩ như một khách hàng "ranh mãnh" và viết ít nhất 3 abuse scenario mô tả cách họ có thể lách luật, kèm kết quả mong đợi mà hệ thống nên xử lý.
Bài tập 5 — Bắt đầu thư viện edge case. Tạo một bảng với các cột: Chủ đề | Mô tả edge case | Nguồn (ticket thật/giả định) | Tần suất ước lượng. Điền tối thiểu 15 dòng dựa trên toàn bộ kinh nghiệm CS của bạn. Cam kết cập nhật bảng này mỗi tuần trong 3 tháng đầu làm BA.
Tóm tắt
Test scenario writing là một trong những nơi mà nền tảng Customer Service mang lại lợi thế rõ rệt nhất cho một BA. Trong khi người khác phải tưởng tượng cách người dùng làm sai, bạn đã sống trong hàng nghìn ticket lỗi thật. Ba lợi thế cốt lõi của bạn là: đã thấy edge case từ đời thật, biết cách người dùng "sáng tạo" workaround, và hiểu hành vi khách hàng bất thường theo bối cảnh.
Để biến lợi thế đó thành kỹ năng BA cụ thể, hãy nhớ: mọi tập scenario tốt phải bao phủ happy path, alternative path, và đặc biệt là exception/negative path — nơi 80% bug ẩn náu. Quy trình sáu bước — từ happy path, khai quật ký ức CS, phân loại theo 4 trục, viết Given–When–Then, ưu tiên theo Tần suất × Mức nghiêm trọng, đến bàn giao — giúp bạn làm việc này một cách có hệ thống thay vì tùy hứng.
Cuối cùng, hãy xây cho mình một thư viện edge case cá nhân và luôn dùng dữ liệu ticket thật để thuyết phục đội. Đó không chỉ là cách viết test scenario tốt hơn — đó là cách bạn định vị mình như một BA hiểu người dùng sâu sắc hơn bất kỳ ai khác trong phòng.