Kiểm thử ngôn ngữ, trong nghề gọi là LQA (linguistic quality assurance), là bước người hiểu tiếng đích dùng thử ứng dụng đã dịch trên thiết bị thật để tìm lỗi mà chỉ nhìn tệp chuỗi không thấy được: chữ đúng nghĩa nhưng sai chỗ, nút bị cắt, câu ghép mảnh, xưng hô lệch giữa hai màn hình, ngày giờ sai định dạng, chuỗi còn sót tiếng gốc. Nó khác với biên tập bản dịch ở chỗ đối tượng kiểm là sản phẩm đang chạy, không phải văn bản.
Một đợt kiểm thử tốt cần ba thứ: bản dựng có đủ dữ liệu mẫu để đi tới mọi màn hình, danh sách luồng thao tác cần kiểm, và cách ghi lỗi đủ rõ để lập trình viên và người dịch sửa được ngay mà không phải hỏi lại. Bài này đi qua từng phần, kèm những chỗ mà người kiểm thử lần đầu hay bỏ sót.
LQA khác biên tập bản dịch ở đâu
Biên tập là đọc bản dịch đối chiếu với bản nguồn, trong công cụ dịch hoặc bảng tính, để sửa nghĩa, thuật ngữ, chính tả. Người biên tập thấy từng chuỗi riêng lẻ theo thứ tự trong tệp. Kiểm thử ngôn ngữ thì nhìn từ phía người dùng: mở ứng dụng, đăng ký, tìm kiếm, mua hàng, gặp lỗi mạng, nhận thông báo. Người kiểm thử thấy chuỗi trong bối cảnh thật — cạnh chuỗi nào, trên nút hay trong đoạn, có bị cắt không, giọng có khớp với màn hình trước không.
Vì vậy hai bước tìm ra hai loại lỗi khác nhau. Biên tập bắt được dịch sai nghĩa của một câu dài, lệch thuật ngữ so với bảng, lỗi chính tả. Kiểm thử bắt được "Open" bị dịch là "Mở" trong khi trên màn hình nó là trạng thái "Đang mở", nút "Tiếp theo" bị cắt còn "Tiếp th", tiêu đề màn hình gọi người dùng là "quý khách" mà nút bên dưới gọi là "bạn". Không bước nào thay được bước kia.
Người làm LQA lý tưởng là người dịch đã làm bản dịch đó hoặc một người dịch khác cùng ngôn ngữ có kinh nghiệm phần mềm, ngồi cạnh hoặc liên lạc được với một người kiểm thử chức năng. Người dịch biết vì sao chọn chữ này; người kiểm thử biết cách đưa ứng dụng vào trạng thái hiếm gặp.
Chuẩn bị một đợt kiểm thử ngôn ngữ
Phần lớn thời gian lãng phí trong LQA đến từ việc không vào được màn hình cần kiểm. Chuẩn bị tốt những thứ sau trước khi gọi người kiểm thử:
- Bản dựng đúng: đã nhập bản dịch mới nhất, ghi rõ số phiên bản để lỗi báo về khớp với mã.
- Tài khoản thử có dữ liệu bản xứ: tên người Việt có dấu, địa chỉ theo đơn vị hành chính hiện hành, số tiền bằng đồng Việt Nam, lịch sử đơn hàng đủ dài để thấy danh sách nhiều trang.
- Danh sách luồng cần đi: đăng ký, đăng nhập, quên mật khẩu, luồng chính của sản phẩm, thanh toán, huỷ, xoá tài khoản, cài đặt, trợ giúp.
- Cách tạo trạng thái hiếm: tắt mạng, nhập sai mật khẩu nhiều lần, danh sách rỗng, thẻ bị từ chối, phiên hết hạn. Lập trình viên có thể cung cấp màn hình gỡ lỗi để bật các trạng thái này.
- Thiết bị và cài đặt: ít nhất một máy màn hình nhỏ, một máy lớn; ngôn ngữ hệ thống đặt sang tiếng đích; một lượt với cỡ chữ hệ thống lớn nhất.
- Bảng thuật ngữ và hướng dẫn văn phong để người kiểm thử đối chiếu.
- Nơi ghi lỗi thống nhất, có trường cho khoá chuỗi và ảnh chụp.
Dữ liệu mẫu là thứ hay bị coi nhẹ nhất. Kiểm giao diện tiếng Việt bằng tài khoản thử tên "Test User" sống ở "123 Main St" thì không bao giờ thấy lỗi tên dài bị cắt, dấu bị xén trong ô tên, hay địa chỉ có tên tỉnh dài vỡ dòng.
Các nhóm lỗi cần soi trên từng màn hình
Mỗi lỗi nên được xếp vào một nhóm để chuyển đúng người sửa. Bảng dưới dùng được làm khung cho trường "loại lỗi" trong công cụ quản lý lỗi:
| Nhóm lỗi | Ví dụ | Ai sửa |
|---|---|---|
| Sai nghĩa theo ngữ cảnh | "Post" dịch là "Bài viết" trên nút đăng bài | Người dịch |
| Thuật ngữ không thống nhất | Cùng tính năng, màn hình này gọi "Ví", màn hình kia gọi "Tài khoản tiền" | Người dịch, cập nhật bảng thuật ngữ |
| Giọng, xưng hô lệch | Lúc "bạn" lúc "quý khách", lúc ra lệnh cộc lốc lúc lịch sự | Người dịch |
| Cắt chữ, tràn, chồng chữ | Nút "Tiếp th…", nhãn đè lên biểu tượng | Lập trình viên hoặc người dịch rút gọn |
| Chuỗi chưa dịch | Hộp thoại xin quyền vẫn tiếng Anh | Lập trình viên kiểm chuỗi viết cứng hoặc tệp khai báo |
| Câu ghép mảnh | Thứ tự từ ngượng vì ba chuỗi nối nhau | Lập trình viên gộp chuỗi, người dịch dịch lại |
| Định dạng vùng | Ngày theo kiểu tháng trước ngày sau, tiền đặt ký hiệu sai chỗ, giờ 12 tiếng | Lập trình viên dùng thư viện định dạng |
| Hiển thị ký tự | Dấu bị xén, phông thay thế lẫn lộn, ô vuông thay chữ | Thiết kế, lập trình viên |
Tách "ai sửa" ngay từ khi ghi lỗi giúp tránh vòng lặp quen thuộc: người dịch nhận báo lỗi cắt chữ, rút gọn một cách gượng ép, trong khi thứ cần sửa là chiều rộng nút. Khi lỗi có thể sửa ở cả hai phía, người kiểm thử nên ghi đề xuất và để trưởng nhóm quyết định.
Những chỗ người kiểm thử hay bỏ sót
Trạng thái lỗi và trạng thái rỗng. Ai cũng kiểm luồng thành công; ít ai cố tình làm sai để xem thông báo lỗi. Trong khi đó thông báo lỗi là nơi người dùng bực nhất và cần chữ rõ nhất.
Chữ của hệ điều hành và của thư viện. Hộp thoại xin quyền, bàn phím, bộ chọn ngày, màn hình thanh toán của bên thứ ba. Một phần do hệ điều hành dịch, một phần do ứng dụng khai báo; cần biết phần nào thuộc trách nhiệm của mình.
Thông báo đẩy, email và tin nhắn. Chúng không nằm trong giao diện nên hay bị kiểm muộn. Cần kích hoạt thật để xem tiêu đề có bị cắt trên màn hình khoá không, tên người gửi email đã dịch chưa.
Thời gian tương đối và lịch. "Vừa xong", "5 phút trước", "Hôm qua", tên thứ trong tuần, tuần bắt đầu từ thứ Hai hay Chủ nhật. Những chuỗi này thường do thư viện sinh ra và có thể vẫn ở tiếng gốc.
Nhãn trợ năng. Mỗi nút biểu tượng có một nhãn ẩn để trình đọc màn hình đọc cho người khiếm thị. Nhãn này nằm trong tệp chuỗi nhưng không hiện trên màn hình, nên hay bị dịch qua loa hoặc quên. Bật trình đọc màn hình của hệ điều hành và đi thử một luồng là thấy ngay.
Nội dung từ máy chủ. Tên gói, khuyến mãi, danh mục, câu hỏi khảo sát. Chúng có thể đổi hằng tuần mà không qua bản dựng mới, nên cần một quy trình kiểm riêng với đội vận hành nội dung.
Ghi lỗi sao cho sửa được ngay
Một báo lỗi ngôn ngữ tốt cho phép người sửa làm xong mà không phải hỏi lại. Mỗi lỗi nên có:
- Ảnh chụp màn hình, khoanh vùng chỗ lỗi.
- Khoá chuỗi nếu tìm được; nếu không, đường đi tới màn hình (từ màn hình chính bấm gì, theo thứ tự).
- Nội dung hiện tại và nội dung đề xuất, viết đủ, không viết "sửa lại cho hay hơn".
- Lý do ngắn: sai nghĩa, lệch thuật ngữ, cắt chữ, chưa dịch…
- Mức nghiêm trọng theo thang thống nhất trước.
- Thiết bị, phiên bản hệ điều hành, cỡ chữ hệ thống nếu lỗi liên quan hiển thị.
- Ghi chú nếu lỗi lặp ở nhiều màn hình, để sửa một lần cho cả nhóm.
Đề xuất cụ thể là phần quan trọng nhất. "Câu này nghe chưa tự nhiên" không sửa được; "Đổi 'Thực hiện thanh toán' thành 'Thanh toán' vì nút đã nằm trong màn hình thanh toán và đang bị cắt" thì sửa được ngay. Người kiểm thử không chắc đề xuất của mình đúng thuật ngữ thì ghi rõ để người dịch quyết.
Khi tiếng Việt là ngôn ngữ đích: lỗi đặc thù cần soi
Kiểm giao diện tiếng Việt có vài điểm riêng mà danh mục kiểm thử chung không nhắc. Đầu tiên là xưng hô. Phần mềm nước ngoài khi vào Việt Nam hay dao động giữa "bạn", "quý khách", "người dùng" và câu không chủ ngữ, tuỳ người dịch từng đợt. Người kiểm thử nên đọc liền một luồng — từ màn hình chào tới xác nhận đơn — và đánh dấu mọi chỗ giọng đổi. Một quy ước đơn giản thường đủ: nút là động từ không chủ ngữ ("Lưu", "Gửi"), câu thông báo dùng "bạn", văn bản pháp lý dùng "người dùng".
Thứ hai là viết hoa. Tiếng Anh giao diện hay viết hoa mọi từ trong tiêu đề; bản dịch tiếng Việt chép theo thành "Cài Đặt Tài Khoản", trái với chính tả tiếng Việt thông dụng là chỉ viết hoa chữ đầu. Thứ ba là dấu câu và khoảng trắng: dấu hai chấm, dấu chấm hỏi dính liền chữ trước, không có dấu cách thừa kiểu tiếng Pháp. Thứ tư là chuỗi nửa Việt nửa Anh do thư viện: "5 minutes trước", "Thứ Hai, Jan 3". Thứ năm là kiểu gõ dấu: "hoà" hay "hòa", "thuỷ" hay "thủy" — cả hai kiểu đều được chấp nhận, nhưng một ứng dụng nên dùng một kiểu, ghi vào hướng dẫn văn phong và kiểm cho thống nhất. Những lỗi này nhỏ từng cái nhưng làm người dùng Việt nhận ra ngay sản phẩm được dịch chứ không được viết cho họ.
Mức nghiêm trọng và quyết định phát hành
Không phải lỗi nào cũng chặn phát hành. Một thang bốn mức thường đủ dùng. Nghiêm trọng: sai nghĩa có thể gây thiệt hại thật — số tiền, thời hạn, nút xoá dữ liệu, điều khoản, hướng dẫn an toàn — hoặc làm người dùng không đi tiếp được. Cao: sai nghĩa ở luồng chính, chuỗi chưa dịch ở màn hình nhiều người thấy, cắt chữ làm không hiểu nút. Trung bình: lệch thuật ngữ, xưng hô không thống nhất, câu ngượng nhưng hiểu được. Thấp: chính tả nhỏ, dấu câu, khoảng trắng.
Quy tắc phát hành hợp lý là không còn lỗi nghiêm trọng và lỗi cao ở luồng chính; lỗi trung bình và thấp có thể vào danh sách sửa ở bản sau, miễn là có người theo dõi. Điều cần tránh là để danh sách lỗi thấp dồn qua nhiều bản: từng lỗi nhỏ thì không sao, nhưng ba mươi lỗi nhỏ cùng lúc làm người dùng bản xứ cảm thấy sản phẩm không dành cho họ.
Một chỉ dấu hữu ích sau phát hành là đánh giá của người dùng trên cửa hàng ứng dụng và tin nhắn hỗ trợ có nhắc tới chữ, dịch, khó hiểu hay không. Gom các phản hồi đó lại theo từng ngôn ngữ, đưa vào vòng kiểm thử kế tiếp, là cách rẻ nhất để bản dịch tốt dần lên theo thời gian. Dịch Hay nhận cả vòng kiểm thử ngôn ngữ trên bản dựng của bạn, kể cả khi bản dịch do bên khác làm; hãy gửi yêu cầu trong mẫu đăng ký kèm danh sách luồng cần kiểm.
Câu hỏi thường gặp
Người kiểm thử ngôn ngữ có cần biết ngôn ngữ nguồn không?
Nên biết, để phân biệt được lỗi dịch với lỗi của chính bản nguồn. Nếu chỉ biết tiếng đích, người kiểm thử vẫn tìm được lỗi hiển thị, câu ngượng và chỗ chưa dịch, nhưng khó nói chắc một câu đúng nghĩa hay không. Cách thường dùng là người bản xứ kiểm, người dịch xác nhận.
Kiểm thử ngôn ngữ mất bao lâu so với dịch?
Phụ thuộc số màn hình và độ phức tạp của luồng hơn là số chữ. Ứng dụng ít chữ nhưng nhiều trạng thái có thể tốn thời gian kiểm hơn thời gian dịch. Khi lên kế hoạch, hãy ước theo số luồng cần đi và số thiết bị, không ước theo số chuỗi.
Có tự động hoá được kiểm thử ngôn ngữ không?
Một phần. Chụp màn hình tự động cho mọi ngôn ngữ, phát hiện chữ bị cắt bằng so khung chữ với khung thành phần, so biến và tìm chuỗi chưa dịch đều tự động được. Đánh giá nghĩa, giọng và sự tự nhiên thì vẫn cần người đọc, nhưng ảnh chụp tự động giúp người đọc làm nhanh hơn nhiều.
Nên kiểm trên máy thật hay máy ảo?
Máy ảo đủ cho phần lớn lỗi chữ và bố cục, và tiện để chụp hàng loạt. Nhưng nên có ít nhất một lượt trên máy thật cho thông báo đẩy, bàn phím tiếng Việt, cỡ chữ hệ thống và phông chữ của hãng máy, vì những thứ này hay khác giữa máy ảo và máy thật.
Ai nên chịu trách nhiệm chốt danh sách lỗi trước khi phát hành?
Một người duy nhất ở phía sản phẩm, thường là người quản lý sản phẩm hoặc trưởng nhóm bản địa hoá. Người dịch và lập trình viên đề xuất, nhưng phải có người quyết lỗi nào chặn phát hành, lỗi nào để sau, và người đó chịu trách nhiệm theo dõi danh sách để sau.
Nhãn trợ năng tiếng Việt cần viết thế nào?
Ngắn, mô tả hành động hoặc nội dung, không lặp lại vai trò mà trình đọc màn hình đã tự đọc. Ví dụ nút thùng rác nên có nhãn "Xoá", không phải "Nút biểu tượng thùng rác". Ảnh mang thông tin cần mô tả nội dung; ảnh trang trí nên đánh dấu để trình đọc bỏ qua.
