✅ Dạo gần đây có khá nhiều bạn tester nhắn hỏi mình: A/B Testing là gì? Tester có cần biết A/B Testing không?
Điều thú vị là phần lớn mọi người đều nghĩ A/B Testing là chuyện của nhóm Product hoặc Marketing — và trước đây mình cũng nghĩ vậy.
Mình bắt đầu quen thuộc với A/B Testing từ thời làm việc ở Atlassian khoảng năm 2015, khi các chức năng mới của Jira và Confluence thường được thử nghiệm với nhiều nhóm người dùng khác nhau trước khi quyết định phiên bản phát hành chính thức.
Hồi đó mình nghĩ khá đơn giản: tester chỉ cần đảm bảo chức năng và giao diện hoạt động đúng theo “phiên bản A” và “phiên bản B” là xong.
Nhưng sau này làm sản phẩm nhiều hơn, mình nhận ra A/B Testing là một thứ tester rất nên hiểu. Không phải là để vận hành thử nghiệm trực tiếp, mà để hiểu sản phẩm hơn và có chiến lược kiểm thử phù hợp hơn. Bởi có nhiều hệ thống hoàn toàn không lỗi, chức năng đầy đủ. Nhưng kết quả kinh doanh lại không như kỳ vọng, vì ít tương tác, không thu hút người dùng.
A/B Testing là gì?
Hiểu ngắn gọn, A/B Testing là phương pháp so sánh hai hoặc nhiều phiên bản của cùng một tính năng, giao diện, hoặc nội dung để xem phiên bản nào mang lại kết quả tốt hơn trong thực tế.
“Tốt hơn” ở đây không phải lúc nào cũng là đẹp hơn hoặc nhiều tính năng hơn. Đôi khi chỉ đơn giản là người dùng bấm nhiều hơn, ở lại lâu hơn, hoặc mua hàng nhiều hơn.
Thay vì tranh luận bằng cảm tính, hệ thống sẽ phân phối các phiên bản khác nhau cho những nhóm người dùng thật khác nhau rồi đo lường kết quả bằng dữ liệu.
Nói đơn giản: Đừng đoán. Hãy để dữ liệu trả lời.
Điều này khá thú vị khi gần đây mình thấy YouTube cũng cho phép nhà sáng tạo nội dung thực hiện A/B Testing trực tiếp với tiêu đề và thumbnail của video.
Trên YouTube, ngay trong màn hình đăng tải video, bạn có thể tạo nhiều phiên bản tiêu đề khác nhau cho cùng một nội dung, sau đó YouTube sẽ tự phân phối và đo xem người xem phản ứng với phiên bản nào tốt hơn.
Ví dụ cùng một video về Prompt Engineering dành cho Tester.
- Một tiêu đề khá chuyên môn: “Cấu trúc Prompt Tốt và 3 Kỹ thuật Prompting dành cho Tester”
- Một tiêu đề đánh vào vấn đề người đọc đang gặp: “90% Tester đang Prompt Sai AI mà không biết”
- Hoặc một tiêu đề thiên về giải thích vấn đề: “Vì sao AI viết test case lúc đúng lúc sai?”
Điều đáng nói là nội dung video không thay đổi. Chỉ đổi tiêu đề.
Nếu là trước đây, có lẽ mình cũng sẽ chọn theo cảm tính. Nhưng làm sản phẩm đủ lâu mới thấy: thứ team mình tin là “hay hơn” đôi khi lại không phải thứ “người dùng thật” muốn.
Đó là lý do A/B Testing quan trọng.
Tester làm gì trong A/B Testing?
Theo mình thì, công việc cơ bản của tester vẫn là kiểm thử chức năng của cả hai phiên bản như bình thường.
Thông thường team sẽ cung cấp yêu cầu và thiết kế cho “version A” và “version B”. Đa số khác biệt thường nằm ở giao diện hoặc trải nghiệm người dùng, thay vì thay đổi lớn về nghiệp vụ.
Ví dụ cùng một nút CTA (Call To Action) như “Xem thêm” hay “Đăng ký”, version A đặt cuối màn hình, còn version B chuyển thành “sticky button” (nút luôn hiển thị trên màn hình khi người dùng cuộn trang).
Với tester thì phần này thật ra vẫn khá quen thuộc: kiểm tra giao diện hiển thị đúng chưa, nút bấm có hoạt động ổn không, điều hướng có chính xác không, dữ liệu có bị sai không và luồng nghiệp vụ có đúng với thiết kế không.
Nhưng khi ứng dụng có A/B Testing, việc kiểm thử sẽ phức tạp hơn một chút. Bạn không chỉ kiểm tra: Chức năng có chạy không, mà còn phải đảm bảo người dùng luôn thấy đúng phiên bản của mình từ đầu đến cuối. Ví dụ, người dùng đã được gán vào version A thì kể cả tải lại trang hoặc thao tác nhiều bước vẫn phải luôn thấy A, không tự chuyển sang B giữa chừng.
Ngoài ra, tester cũng thường cần kiểm tra thêm dữ liệu theo dõi hành vi người dùng. Ví dụ, hệ thống có ghi nhận đúng người dùng đang ở version A hay B không? Có bị ghi dữ liệu lẫn lộn giữa hai phiên bản không? Đây là những lỗi khá khó chịu, vì đôi khi khó phát hiện trong lúc kiểm thử, vì trong môi trường kiểm thử thường không có đủ dữ liệu và hành vi người dùng như thực tế.
Ví dụ, người dùng thực tế đang thấy version B nhưng hệ thống lại ghi nhận version A. Hoặc cùng một người dùng nhưng có hành động bị ghi nhận là A, có hành động lại thành B. Khi đó dữ liệu thử nghiệm sẽ bị sai lệch, và công ty có thể đưa ra quyết định sai.
Đó là lý do mình thấy tester không nên xem A/B Testing là chuyện của riêng nhóm Product hay Marketing.
Một vài công cụ phổ biến để thực hiện A/B Testing
Hiện nay có khá nhiều công cụ hỗ trợ A/B Testing, tùy vào quy mô sản phẩm và nhu cầu của từng công ty.
Một số cái tên phổ biến mà tester có thể gặp là LaunchDarkly, PostHog, Optimizely, VWO hoặc Firebase A/B Testing.
Điểm chung của các công cụ này thường là cho phép bật/tắt tính năng theo từng nhóm người dùng, phân phối các phiên bản khác nhau, và theo dõi kết quả thử nghiệm.
Trong A/B Testing, các bạn cần nắm vững hai khái niệm này:
- feature flag — tức cơ chế bật/tắt tính năng cho từng nhóm người dùng.
- experiment analytics — tức cách hệ thống ghi nhận, theo dõi, và đánh giá kết quả thử nghiệm.
Suy cho cùng, dù dùng công cụ nào thì điều tester cần kiểm tra vẫn xoay quanh ba câu hỏi:
- Người dùng có được hiển thị đúng phiên bản của mình không?
- Chức năng ở từng phiên bản có hoạt động đúng như yêu cầu không?
- Dữ liệu đo lường có được ghi nhận chính xác không?
Nếu bạn làm tester trong công ty phát triển sản phẩm, bạn sẽ càng ít chỉ tập trung vào chuyện “chức năng có chạy đúng yêu cầu hay không”. Mà sẽ quan tâm nhiều hơn đến việc dữ liệu theo dõi cách người dùng sử dụng hệ thống có đáng tin không, hệ thống có đang phản ánh đúng hành vi người dùng không, và các thay đổi mới có thực sự tạo ra giá trị hay không.
Và với mình, A/B Testing là một trong những thứ giúp mở rộng góc nhìn của tester — từ việc kiểm thử chức năng sang hiểu sâu hơn cách người dùng thực sự tương tác với sản phẩm.
