Tóm tắt nhanh
Trong nhiều dự án Nhật, chất lượng không chỉ là "chạy được". Team còn kiểm tra đúng spec, đúng wording, đúng layout, đúng quyền user, đúng dữ liệu và không ảnh hưởng chức năng khác. Vì vậy bug nhỏ như sai dấu câu trong message lỗi cũng có thể bị comment.
Bài này giúp developer Việt Nam hiểu cách công ty Nhật nhìn về 品質, test và review. Nếu bạn muốn luyện câu liên quan bug và review, hãy học bug report và review.
品質 trong dự án IT Nhật là gì?
品質 nghĩa là chất lượng. Trong dự án phần mềm, chất lượng thường gồm nhiều lớp:
- Lớp chất lượng
- Chức năng
- Cần kiểm tra gì
- Có đúng spec không
- Ví dụ
- Tính phí đúng rule
- Lớp chất lượng
- Dữ liệu
- Cần kiểm tra gì
- Input/output đúng không
- Ví dụ
- Date format, null, duplicate
- Lớp chất lượng
- UI
- Cần kiểm tra gì
- Hiển thị đúng không
- Ví dụ
- Label, message, responsive
- Lớp chất lượng
- Quyền
- Cần kiểm tra gì
- User role đúng không
- Ví dụ
- Admin thấy, normal user không thấy
- Lớp chất lượng
- Hiệu năng
- Cần kiểm tra gì
- Có chậm quá không
- Ví dụ
- Search nhiều dữ liệu
- Lớp chất lượng
- Ảnh hưởng
- Cần kiểm tra gì
- Có làm hỏng phần khác không
- Ví dụ
- Sửa API ảnh hưởng màn hình khác
- Lớp chất lượng
- Vận hành
- Cần kiểm tra gì
- Có log, monitor, rollback không
- Ví dụ
- Batch lỗi có trace được không
Một bug nhỏ ở UI có thể cho thấy team chưa kiểm tra kỹ. Với hệ thống doanh nghiệp, niềm tin vào quy trình kiểm tra rất quan trọng.
Vì sao test case chi tiết?
Test case trong dự án Nhật thường chi tiết vì tester cần căn cứ rõ để xác nhận. Không chỉ test happy path, team còn test exception, boundary, permission, browser, timezone, dữ liệu cũ và migration.
Ví dụ với trường "ngày sinh", test không chỉ nhập một ngày hợp lệ. Cần test:
- Case
- Hợp lệ
- Ví dụ
- 1995/04/10
- Case
- Trống
- Ví dụ
- Không nhập gì
- Case
- Sai format
- Ví dụ
- 1995-04-10
- Case
- Ngày không tồn tại
- Ví dụ
- 2026/02/30
- Case
- Boundary
- Ví dụ
- Ngày nhỏ nhất, ngày lớn nhất
- Case
- Quyền
- Ví dụ
- User không có quyền sửa
- Case
- Message
- Ví dụ
- Văn bản lỗi đúng spec
Nếu developer tự test được các case này trước khi gửi PR, số comment sẽ giảm nhiều.
Developer Việt Nam dễ hiểu sai điểm nào?
1. "Chạy được trên máy mình là xong"
Chạy được local chưa đủ. Cần kiểm tra môi trường test, dữ liệu khác nhau, quyền user và regression.
2. "Sai wording không nghiêm trọng"
Trong sản phẩm cho khách hàng Nhật, wording là một phần của spec. Sai 文言 có thể bị xem là bug.
3. "Tester sẽ bắt lỗi nên developer không cần test kỹ"
Tester giúp kiểm tra độc lập, nhưng developer vẫn cần tự test trước. Gửi code chưa kiểm tra làm mất thời gian review và QA.
4. "Bug nhỏ không cần phân tích nguyên nhân"
Nếu bug lặp lại hoặc ảnh hưởng production, team có thể cần 原因分析 và 再発防止. Không chỉ sửa hiện tượng.
Trước khi gửi PR nên test gì?
Bạn có thể dùng checklist ngắn:
- Đã kiểm tra case chính theo ticket chưa?
- Đã kiểm tra validation, error message, empty data chưa?
- Đã kiểm tra quyền user liên quan chưa?
- Đã kiểm tra màn hình/API bị ảnh hưởng chưa?
- Đã chạy test tự động liên quan chưa?
- PR description có ghi test đã chạy chưa?
PR tốt nên ghi rõ:
確認内容:
- ユーザー登録の正常系
- メールアドレス未入力時のエラー表示
- 権限なしユーザーのアクセス制御
- 既存テスト
Reviewer đọc vào sẽ biết bạn đã kiểm tra những gì.
Câu tiếng Nhật nên nhớ
- 日本語
- 品質を確認します。
- かな
- ひんしつをかくにんします
- Nghĩa tiếng Việt
- Tôi sẽ kiểm tra chất lượng.
- Dùng khi nào
- Khi nói chung về QA
- 日本語
- テストケースを確認しました。
- かな
- てすとけーすをかくにんしました
- Nghĩa tiếng Việt
- Tôi đã kiểm tra test case.
- Dùng khi nào
- Trước test
- 日本語
- 正常系を確認しました。
- かな
- せいじょうけいをかくにんしました
- Nghĩa tiếng Việt
- Tôi đã kiểm tra happy path.
- Dùng khi nào
- PR/test report
- 日本語
- 異常系を確認しました。
- かな
- いじょうけいをかくにんしました
- Nghĩa tiếng Việt
- Tôi đã kiểm tra error path.
- Dùng khi nào
- PR/test report
- 日本語
- 影響範囲を確認します。
- かな
- えいきょうはんいをかくにんします
- Nghĩa tiếng Việt
- Tôi sẽ kiểm tra phạm vi ảnh hưởng.
- Dùng khi nào
- Khi sửa logic chung
- 日本語
- 再現手順を教えてください。
- かな
- さいげんてじゅんをおしえてください
- Nghĩa tiếng Việt
- Vui lòng cho tôi biết bước tái hiện.
- Dùng khi nào
- Khi nhận bug
- 日本語
- 原因を調査します。
- かな
- げんいんをちょうさします
- Nghĩa tiếng Việt
- Tôi sẽ điều tra nguyên nhân.
- Dùng khi nào
- Khi fix bug
- 日本語
- 再発防止策を検討します。
- かな
- さいはつぼうしさくをけんとうします
- Nghĩa tiếng Việt
- Tôi sẽ xem xét biện pháp tránh tái phát.
- Dùng khi nào
- Bug nghiêm trọng
Học tiếp trên JLPTVN
Đọc thêm bug report tiếng Nhật, review trong dự án Nhật, non-functional requirements. Luyện mẫu câu tại bug, review và bài luyện IT.
Khi luyện xong, mở Review để giữ lại câu sai về bug, test và review.
FAQ
Bug nhỏ có cần ghi ticket không?
Tùy team. Nếu bug ảnh hưởng spec, test hoặc release, nên ghi ticket hoặc ít nhất comment rõ trong ticket/PR để truy vết.
Developer có cần viết test case không?
Nhiều team yêu cầu developer viết unit test hoặc hỗ trợ test case. Dù không viết tài liệu test, bạn vẫn nên tự kiểm tra theo checklist.
Vì sao review comment nhiều về wording?
Vì wording hiển thị cho user là một phần trải nghiệm và có thể liên quan pháp lý, nghiệp vụ hoặc guideline sản phẩm.