✎ Nếu bạn đang tự hỏi “WYSIWYG là gì?” có thể bạn chưa có nhiều cơ hội làm việc với phần này. Hoặc nếu bạn chỉ test WYSIWYG bằng cách “nhìn xem UI hiển thị đúng không”, thì khả năng cao bạn đang bỏ sót bug.
WYSIWYG là gì?
WYSIWYG là viết tắt của “What You See Is What You Get” – Hiểu đơn giản là bạn thấy gì thì sẽ nhận được đúng như vậy.
Trong nhiều ứng dụng web như Confluence và Jira, WYSIWYG thường là một editor (trình soạn thảo) cho phép người dùng chỉnh sửa nội dung trực tiếp trên giao diện. Khi bạn bôi đậm chữ, chèn hình ảnh, tạo bảng hay xuống dòng, tất cả đều hiển thị ngay lập tức theo đúng định dạng cuối cùng mà người dùng sẽ thấy sau khi lưu.
Chẳng hạn, khi soạn bài viết trên Facebook, bạn thấy chữ đậm → nhưng sau khi đăng lên lại mất định dạng.
Theo kinh nghiệm kiểm thử của bản thân, mình thấy đây là một phần rất khó. Bởi vì đằng sau chức năng WYSIWYG không chỉ là xử lý giao diện, mà còn liên quan đến cách dữ liệu được lưu trữ, xử lý và render lại. Ví dụ, trên giao diện, người dùng thấy chữ đậm, nhưng về mặt dữ liệu thì chữ đó có thể đang được lưu dưới dạng HTML như <b>text</b> hoặc <strong>text</strong>, hoặc thậm chí là một dạng cấu trúc khác.
ℹ️ Render: là một thuật ngữ rất thường gặp khi bạn kiểm thử liên quan đến UI. Đây là quá trình trình duyệt “biến dữ liệu thành thứ bạn nhìn thấy trên màn hình”.
5 lỗi WYSIWYG thường gặp
Khi chỉ “nhìn bề ngoài” (chỉ kiểm tra những trường hợp happy case) thì editor của bạn có vẻ hoạt động ổn, nhưng đi sâu vào một chút là vấn đề bắt đầu lộ ra. Kinh qua nhiều dự án liên quan đến WYSIWYG, dưới đây là 5 lỗi mình thường gặp ở mọi hệ thống.
1. Định dạng không nhất quán
Đầu tiên là lỗi “đúng bản chất WYSIWYG” nhất. Những gì bạn thấy trong lúc nhập thông tin, chỉnh sửa định dạng và những gì hệ thống hiển thị sau khi lưu hoàn toàn khác nhau.
Trong lúc chỉnh sửa, mọi thứ trông rất ổn, ví dụ: chữ đậm vẫn đậm, gạch đầu dòng vẫn ngay ngắn. Nhưng khi chuyển sang chế độ XEM (view), định dạng có thể thay đổi, xuống dòng khác đi, thậm chí tổng gạch đầu dòng bị lệch, v.v…
Ở chế độ chỉnh sửa, thấy một kiểu, và ở chế độ xem lại thấy một kiểu. Lúc này, đó là “What You See Is NOT What You Get” 🤣.
2. Lưu dữ liệu bị sai
Một lỗi tương tự khác, vẫn liên quan đến kết quả hiển thị khác với lúc chỉnh sửa. Nhưng lỗi lúc này thì liên quan đến giai đoạn lưu dữ liệu.
Bạn có thể thấy mọi thứ hiển thị đúng ở cả hai chế độ: chỉnh sửa và xem lại, nhưng dữ liệu thực tế được lưu vào hệ thống lại không chính xác hoặc không đầy đủ. Người dùng có thể mất toàn bộ nội dung sau khi tải lại trang (reload/ refresh) vì chức năng lưu tự động không hoạt động, hoặc định dạng bên dưới nội dung đã bị thay đổi.
Ví dụ, một đoạn văn có cả chữ in đậm và danh sách gạch đầu dòng (bullet), nhìn hoàn toàn bình thường ở chế độ chỉnh sửa, nhưng sau khi lưu thì phần gạch đầu dòng bị mất hoặc hiển thị lộn xộn, không như mong muốn.
Những lỗi kiểu này không dễ phát hiện ngay, vì chỉ xảy ra với một số loại định dạng nhất định, nhưng lại ảnh hưởng trực tiếp đến trải nghiệm và niềm tin của người dùng.
3. Định dạng sai khi copy & paste
Và một câu chuyện muôn thuở nữa là copy & paste. Nó như ăn vào máu của mọi tester, khi kiểm thử ứng dụng web và trên điện thoại, các bạn luôn muốn thử dán dữ liệu cả hợp lệ (valid) và không hợp lệ (invalid) vào các ô nhập liệu trên màn hình.
Mình gần như luôn mặc định rằng bất cứ lỗi (bug) nghiêm trọng nào liên quan đến editor, đều có thể liên quan đến việc dán dữ liệu từ đâu đó.
Khi người dùng copy một đoạn chữ từ MS Word, Google Docs, hay từ một trang web nào đó, thì nội dung trong bộ nhớ tạm không chỉ là “đoạn chữ” mà họ nghĩ. Ngoài đoạn chữ đó, nội dung được copy mang theo cả một “đống hành lý đi kèm” gồm ‘inline style’, các ‘thuộc tính CSS’, thậm chí là những đoạn HTML cực kỳ phức tạp.
Kết quả, editor có những “hành vi” kỳ lạ như: kích thước chữ nhảy loạn, bố cục nội dung bị vỡ, hoặc tệ hơn là đứng luôn. Do editor trộn lẫn mọi dữ liệu nó có được sau hành động paste (dán) với dữ liệu bạn đang nhập ở đó, và cách nó xử lý dữ liệu đầu vào (ví dụ thao tác chuyển định dạng cho tập dữ liệu đã có định dạng rồi).
Trong kiểm thử, mình luôn chọn copy & paste dữ liệu có định dạng và dữ liệu không định dạng (plaintext). Bạn có thể tham khảo thêm lorem ipsum để có những đoạn chữ dùng cho mục đích kiểm thử.
4. Undo & redo là “ác mộng”
Một hành động khác mà người dùng thường thực hiện khi làm việc với dữ liệu nhiều (ví dụ khi nhập một đoạn mô tả trong ô ‘Description’), là thao tác undo và redo ⬅️.
Nghe thì đơn giản, nhưng phần mềm phụ thuộc rất nhiều vào cách editor quản lý trạng thái. Khi chỉnh sửa liên tục một đoạn văn bản, đôi khi bạn muốn lấy lại nội vừa rồi, hoặc “lúc nãy” thì bạn phải undo. Tuy nhiên, không phải lúc nào chức năng undo và redo cũng hoạt động mượt mà.
Chỉ cần một bước xử lý không chính xác, chức năng undo có thể không quay lại đúng trạng thái trước đó, hoặc redo không khôi phục được nội dung như người dùng mong đợi.
Lỗi mình thường gặp là, khi bạn paste một lượng lớn dữ liệu (ví dụ 2000 ký tự), rồi bấm nút undo thì toàn bộ nội dung biến mất. Hoặc bạn thử undo sau khi đã xoá vài gạch đầu dòng (bullet).

5. Dữ liệu nhiều và phức tạp
Khi dữ liệu trở nên lớn và phức tạp, editor thường bắt đầu xuất hiện lỗi khi nội dung trở nên phức tạp hơn.
Khi kiểm thử với dữ liệu đơn giản, editor thường hoạt động ổn. Nhưng với nội dung dài, nhiều kiểu định dạng khác nhau, có hình ảnh, hoặc nhiều cấu trúc lồng nhau, v.v… mọi thứ bắt đầu trở nên khó kiểm soát. Bạn nên thử sử dụng chức năng gạch đầu dòng với nhiều mức, xoá rồi undo sẽ sớm phát hiện lỗi.
Bố cục nội dung có thể bị vỡ, editor trở nên chậm, hoặc thậm chí chương trình bị treo. Đây là lúc sự khác biệt giữa “demo chạy được nhưng sử dụng thực tế thì…” trở nên rất rõ ràng.
Nhìn chung, WYSIWYG không chỉ là một phần UI đơn giản mà là nơi giao nhau của rất nhiều yếu tố: cách người dùng tương tác với phần mềm, cách dữ liệu được xử lý và lưu trữ, và cách nội dung được render. Chính vì vậy, đây là một trong những khu vực dễ có bug, nếu không được kiểm thử kỹ.
Kinh nghiệm kiểm thử với WYSIWYG
Như đã đề cập ở trên, với dữ liệu đơn giản, editor thường hoạt động rất ổn. Nhưng khi bạn đưa vào các trường hợp phức tạp hơn như bảng lớn, bảng lồng nhau, hình ảnh kích thước lớn, hoặc một trang nội dung dài vài ngàn dòng, mọi thứ bắt đầu bộc lộ vấn đề.
Sau tất cả, điều mình rút ra là WYSIWYG chưa bao giờ chỉ là một hạng mục UI đơn giản. Nó là sự kết hợp của rất nhiều thứ phía sau: cách dữ liệu được lưu trữ, cách dữ liệu được chuyển đổi qua lại giữa các định dạng khác nhau, cách nó được render, và cả cách từng trình duyệt xử lý nội dung đó khi hiển thị đến người dùng cuối. Vì vậy, nếu chỉ nhìn vào việc “hiển thị có đúng không” thì gần như chắc chắn bạn sẽ bỏ sót bug.
10 test case khi kiểm thử với WYSIWYG
Dưới đây là 10 test cases không thể thiếu khi kiểm thử một chức năng liên quan đến editor:
- Kiểm tra định dạng (bold, italic, list, v.v…) ở chế độ chỉnh sửa và chế độ xem
- Kiểm tra nội dung sau khi lưu và tải lại có giống hoàn toàn với trước đó
- Kiểm tra chức năng tự động lưu hoạt động khi tải lại trang hoặc mất kết nối tạm thời
- Copy 1 đoạn chữ từ MS Word/ Google Docs, rồi dán vào editor, kiểm tra định dạng và bố cục nội dung
- Thử dán chữ bình thường (plain text) và chữ có định dạng (rich text), kiểm tra editor xử lý định dạng đầu vào hợp lý chưa
- Thực hiện undo/redo sau nhiều thao tác liên tiếp (edit, delete, format, v.v…)
- Undo ngay sau khi dán một lượng dữ liệu lớn, kiểm tra mất dữ liệu hoặc sai trạng thái
- Nhập nội dung dài (ví dụ 1000+ ký tự) với nhiều định dạng khác nhau (gồm link và hình ảnh), kiểm tra bố cục và hiệu năng – thời gian xử lý của editor
- Tạo nội dung phức tạp (list nhiều cấp, table, image), kiểm tra bố cục sau khi render
- Kết hợp nhiều thao tác (ví dụ: dán → thay đổi định dạng chữ → xóa vài thứ → undo → save), kiểm tra tính toàn vẹn dữ liệu
Và nếu có một nguyên tắc mình luôn ghi nhớ, thì nó rất đơn giản: chỗ nào trên phần mềm, người dùng có thể tương tác nhiều nhất (đặc biệt là dán vào (paste), undo, và tạo bản nháp) thì chỗ đó gần như luôn “xứng đáng được nghi ngờ nhiều nhất.”
Nếu chỉ kiểm thử WYSIWYG bằng mắt, bạn sẽ bỏ sót bug. Nhưng nếu bạn test nó như một người dùng ‘khó tính’, bạn sẽ thấy nó không hề đơn giản như vẻ ngoài.




