1. Giới thiệu
Trong quá trình phát triển phần mềm, Web và Mobile Testing không chỉ đơn giản là kiểm tra giao diện có hiển thị đúng hay không, hoặc các button có hoạt động hay không. Một Tester giỏi cần hiểu cách ứng dụng hoạt động, cách dữ liệu được truyền giữa các thành phần và những yếu tố có thể gây ra lỗi.
Ví dụ, khi người dùng đăng ký một khóa học, giao diện có thể hiển thị thông báo đăng ký thành công nhưng dữ liệu chưa được lưu vào Database. Hoặc một sự kiện hiển thị đúng ngày giờ tại Hong Kong nhưng lại sai khi người quản trị sử dụng hệ thống trong lúc đi du lịch ở một quốc gia khác.
Để phát hiện những lỗi như vậy, Tester cần hiểu các kiến thức cơ bản về Client–Server, UI, Responsive Design, Browser Compatibility, Session, Cookies, Local Storage, Timezone, Network và kiến trúc Frontend–Backend–Database.
2. Client–Server và Request–Response
2.1. Client–Server là gì?
Client–Server là mô hình trong đó Client gửi yêu cầu đến Server, Server xử lý yêu cầu và trả kết quả về cho Client.
Client: Thành phần người dùng tương tác trực tiếp, chẳng hạn trình duyệt Web hoặc ứng dụng Mobile.
Server: Tiếp nhận và xử lý yêu cầu từ Client, thực hiện logic nghiệp vụ và giao tiếp với Database khi cần.
Database: Nơi lưu trữ dữ liệu của ứng dụng.
Ví dụ, người dùng đăng nhập vào một hệ thống quản lý bóng đá:
- Người dùng nhập email và password trên giao diện.
- Client gửi thông tin đăng nhập đến Server thông qua API.
- Server kiểm tra thông tin đăng nhập.
- Server trả về kết quả thành công hoặc thất bại.
- Client hiển thị giao diện tương ứng với kết quả nhận được.
2.2. Tester cần kiểm tra những gì?
Tester không nên chỉ kiểm tra thông báo trên UI mà cần xem xét cả request và response khi có thể.
Các trường hợp nên kiểm tra:
Đăng nhập với thông tin hợp lệ.
Email không tồn tại.
Password không chính xác.
Thiếu email hoặc password.
Email hoặc password có khoảng trắng đầu/cuối.
Gửi request với dữ liệu không hợp lệ.
Người dùng không có quyền truy cập tài nguyên.
Server trả về lỗi hoặc phản hồi chậm.
Ví dụ:
| Test case | Expected result |
|---|---|
| Đăng nhập bằng tài khoản hợp lệ | Đăng nhập thành công |
| Password không chính xác | Hiển thị lỗi phù hợp |
| Email bỏ trống | Hiển thị validation |
| API trả về HTTP 401 | Người dùng không được xác thực |
| API trả về HTTP 500 | Hệ thống xử lý lỗi phù hợp, không bị crash |
Lưu ý: HTTP status code chỉ là một phần của kết quả. Tester cần kiểm tra thêm response body, dữ liệu trả về và trạng thái thực tế của hệ thống.
3. UI Testing, Responsive Layout và Browser Compatibility
3.1. UI Testing
UI Testing là quá trình kiểm tra giao diện có hiển thị đúng thiết kế và hoạt động đúng theo yêu cầu hay không.
Những nội dung cần kiểm tra bao gồm:
Text, label, button và icon.
Font, màu sắc, khoảng cách và căn chỉnh.
Kích thước và vị trí của các thành phần.
Trạng thái enabled, disabled, loading và error.
Nội dung khi không có dữ liệu.
Validation message và thông báo thành công.
Nội dung dài, dữ liệu đặc biệt và dữ liệu bị thiếu.
Ví dụ: Một bảng danh sách Player hiển thị đầy đủ thông tin trên màn hình Desktop nhưng cột Date of Birth bị che khuất khi trình duyệt thu nhỏ.
Đây có thể là lỗi UI hoặc responsive layout, ngay cả khi chức năng vẫn hoạt động bình thường.
3.2. Responsive Layout
Responsive Design giúp giao diện thích ứng với nhiều kích thước màn hình khác nhau.
Tester nên kiểm tra:
Desktop, tablet và mobile.
Màn hình có chiều rộng nhỏ.
Nội dung dài hoặc nhiều cột dữ liệu.
Menu, modal, dropdown và form.
Cuộn ngang, cuộn dọc và vị trí cố định.
Bàn phím ảo trên điện thoại có che mất input hoặc button hay không.
Ví dụ: Trên Desktop, nút Submit nằm cuối form. Trên Mobile, khi bàn phím ảo mở ra, nút Submit bị che khuất và người dùng không thể hoàn thành thao tác.
3.3. Browser Compatibility
Các trình duyệt có thể xử lý một số tính năng khác nhau do khác biệt về engine, phiên bản hoặc cấu hình.
Tester nên xác định các trình duyệt và phiên bản cần hỗ trợ, sau đó kiểm tra những chức năng quan trọng trên các môi trường đó.
Ví dụ:
Chrome hiển thị đúng định dạng ngày tháng.
Safari hiển thị ngày tháng khác do cách xử lý chuỗi ngày giờ.
Một tính năng hoạt động trên Desktop Chrome nhưng không hoạt động trên Safari Mobile.
Khi phát hiện lỗi, Tester nên ghi nhận trình duyệt, phiên bản, hệ điều hành, bước tái hiện và bằng chứng liên quan.
Best practice: Không cần kiểm tra mọi trình duyệt trong mọi trường hợp. Hãy ưu tiên theo phạm vi hỗ trợ, mức độ sử dụng và rủi ro của chức năng.
4. Form Validation, Session, Cookies và Local Storage
Đây là nhóm kiến thức quan trọng vì ảnh hưởng trực tiếp đến dữ liệu, trải nghiệm người dùng và bảo mật.
4.1. Form Validation
Validation là quá trình kiểm tra dữ liệu người dùng nhập trước khi hệ thống chấp nhận xử lý.
Có hai nhóm chính:
Client-side validation: Kiểm tra dữ liệu ở phía giao diện.
Server-side validation: Kiểm tra dữ liệu tại Server trước khi thực hiện nghiệp vụ.
Tester cần kiểm tra cả hai khi phù hợp. Không nên cho rằng validation trên UI là đủ, vì request có thể được gửi trực tiếp đến API mà không thông qua form.
Các trường hợp cần kiểm tra:
Field bắt buộc bị bỏ trống.
Sai định dạng email.
Giá trị nhỏ hơn hoặc lớn hơn giới hạn.
Độ dài tối thiểu và tối đa.
Ký tự đặc biệt.
Khoảng trắng đầu/cuối.
Ngày không hợp lệ.
Dữ liệu trùng lặp.
Gửi request trực tiếp với dữ liệu không hợp lệ.
Ví dụ: Trường số lượng Player chỉ chấp nhận số nguyên dương. Tester cần thử nhập 0, -1, 1.5, chữ và giá trị vượt giới hạn cho phép.
Expected result không chỉ là hiển thị thông báo lỗi mà còn phải đảm bảo hệ thống không lưu dữ liệu không hợp lệ.
4.2. Session
Session giúp hệ thống duy trì trạng thái người dùng qua nhiều request, thường được sử dụng trong quá trình đăng nhập và phân quyền.
Tester nên kiểm tra:
Người dùng đã đăng nhập có thể truy cập chức năng được phép.
Người dùng chưa đăng nhập không thể truy cập trang cần xác thực.
Đăng xuất làm mất khả năng sử dụng phiên đăng nhập cũ.
Session hết hạn được xử lý đúng.
Hai tài khoản khác nhau không bị dùng chung trạng thái đăng nhập.
Truy cập lại trang sau khi logout không làm lộ dữ liệu riêng tư.
Ví dụ: Sau khi Admin logout, người dùng nhấn nút Back của trình duyệt và vẫn nhìn thấy thông tin nhạy cảm.
Tester cần xác định liệu chỉ nội dung đã được cache hiển thị lại hay người dùng thực sự vẫn truy cập được dữ liệu từ Server. Đây là hai tình huống khác nhau và cần được điều tra riêng.
4.3. Cookies
Cookies là các dữ liệu nhỏ được trình duyệt lưu trữ và gửi theo request trong những điều kiện nhất định.
Cookies có thể được sử dụng để duy trì phiên đăng nhập hoặc lưu một số tùy chọn của người dùng.
Tester cần kiểm tra:
Cookie được tạo sau khi đăng nhập.
Cookie hết hạn theo cấu hình.
Cookie bị xóa hoặc không còn hợp lệ.
Cấu hình bảo mật như
Secure,HttpOnlyvàSameSitekhi phù hợp.Hành vi đăng nhập và đăng xuất trên nhiều tab hoặc trình duyệt.
4.4. Local Storage
Local Storage lưu dữ liệu ở phía trình duyệt và thường tồn tại sau khi đóng, mở lại trình duyệt, cho đến khi dữ liệu bị xóa hoặc ứng dụng chủ động thay đổi.
Tester có thể kiểm tra Local Storage bằng Developer Tools.
Ví dụ: Hệ thống lưu bộ lọc Year Group trong Local Storage. Khi người dùng quay lại trang, bộ lọc vẫn được áp dụng.
Các trường hợp nên kiểm tra:
Dữ liệu được lưu đúng sau thao tác.
Dữ liệu được khôi phục đúng khi mở lại trang.
Dữ liệu cũ không làm ảnh hưởng đến tài khoản khác.
Dữ liệu không hợp lệ hoặc dữ liệu từ phiên bản cũ được xử lý an toàn.
Logout có xóa các dữ liệu cần xóa theo thiết kế hay không.
Lưu ý: Session, Cookies và Local Storage không phải là một. Tester cần hiểu cơ chế thực tế của ứng dụng thay vì mặc định mọi hệ thống đều sử dụng cùng một cách lưu trạng thái.
5. Timezone, Date/Time, Locale và Data Format
Lỗi ngày giờ là một trong những lỗi khó phát hiện nếu Tester chỉ kiểm tra trên một thiết bị hoặc một múi giờ.
5.1. Timezone
Timezone là múi giờ dùng để xác định thời gian địa phương tại một khu vực.
Ví dụ, Hong Kong sử dụng UTC+8 trong khi Việt Nam sử dụng UTC+7. Tại cùng một thời điểm, giờ hiển thị tại hai khu vực có thể chênh lệch một giờ.
Tuy nhiên, Tester không nên mặc định rằng mọi ngày giờ trong hệ thống đều phải hiển thị theo timezone của thiết bị hoặc timezone của người dùng.
Cần làm rõ yêu cầu nghiệp vụ:
Hệ thống sử dụng timezone nào làm chuẩn?
Ngày giờ được lưu dưới dạng UTC hay giờ địa phương?
Người dùng ở quốc gia khác có nhìn thấy cùng một thời điểm hay không?
Các sự kiện được lên lịch theo giờ địa phương hay theo thời điểm tuyệt đối?
Báo cáo và thông báo có sử dụng cùng một quy tắc timezone không?
Ví dụ: Một trận đấu được lên lịch lúc 15:00 tại Hong Kong. Nếu Admin đang đi du lịch ở Việt Nam, hệ thống có thể hiển thị 15:00 theo giờ Hong Kong hoặc 14:00 theo giờ Việt Nam, tùy yêu cầu sản phẩm.
Cả hai cách đều có thể hợp lý nếu được thiết kế nhất quán và đáp ứng nghiệp vụ.
5.2. Date/Time và lỗi lệch ngày
Một lỗi phổ biến là ngày sinh được chọn đúng trên giao diện nhưng ngày lưu trong Database bị lệch một ngày.
Ví dụ:
Giá trị nhập:
30/12/2016Giá trị lưu:
2016-12-29
Nguyên nhân có thể liên quan đến việc chuyển đổi giữa ngày địa phương, UTC và cách phân tích chuỗi ngày. Tuy nhiên, cần kiểm tra dữ liệu thực tế và luồng xử lý trước khi kết luận nguyên nhân.
Tester nên kiểm tra:
Ngày đầu tháng và cuối tháng.
Ngày 29/02 trong năm nhuận.
Các mốc gần nửa đêm.
Ngày được nhập, lưu, truy vấn và hiển thị.
Dữ liệu được truyền qua UI, API và Database.
Các định dạng ngày khác nhau.
5.3. Locale và Data Format
Locale ảnh hưởng đến cách hiển thị ngày tháng, số, tiền tệ và một số nội dung ngôn ngữ.
Ví dụ:
12/10/2026có thể được hiểu là ngày 12 tháng 10 hoặc ngày 10 tháng 12, tùy quy ước.Số thập phân có thể sử dụng dấu chấm hoặc dấu phẩy.
Định dạng tiền tệ có thể thay đổi theo khu vực.
Tester cần xác nhận định dạng đầu vào, định dạng lưu trữ và định dạng hiển thị có nhất quán với yêu cầu hay không.
Best practice: Phân biệt giữa một ngày lịch như Date of Birth và một thời điểm cụ thể như Match Start Time. Hai loại dữ liệu này có thể cần cách xử lý timezone khác nhau.
6. Network Error, Loading, Timeout và Error Handling
Một ứng dụng không chỉ được sử dụng trong điều kiện mạng ổn định. Người dùng có thể mất kết nối, gặp mạng chậm hoặc nhận phản hồi lỗi từ Server.
6.1. Network Error
Tester nên kiểm tra:
Mất kết nối Internet.
Chuyển từ Wi-Fi sang mạng di động.
Request bị thất bại.
Server không phản hồi.
Người dùng thực hiện thao tác khi mạng không ổn định.
Khôi phục kết nối sau khi request thất bại.
Ví dụ: Người dùng nhấn Register nhưng mạng bị ngắt trước khi nhận được response.
Ứng dụng cần thông báo phù hợp và cho phép người dùng xử lý tiếp mà không làm mất dữ liệu ngoài dự kiến.
6.2. Loading State
Loading state cho người dùng biết hệ thống đang xử lý.
Tester nên kiểm tra:
Loading xuất hiện khi cần thiết.
Loading kết thúc sau khi request thành công hoặc thất bại.
Button không bị nhấn liên tục gây gửi nhiều request.
Loading không bị treo vô thời hạn.
Giao diện vẫn hiển thị đúng khi dữ liệu trả về rỗng.
Ví dụ: Khi nhấn Pay, hệ thống hiển thị loading nhưng người dùng vẫn có thể nhấn nút nhiều lần và tạo ra nhiều giao dịch.
Đây có thể là lỗi UI, nhưng cũng có thể là lỗi xử lý nghiệp vụ hoặc thiếu cơ chế chống giao dịch trùng lặp ở phía Server.
6.3. Timeout
Timeout xảy ra khi một thao tác không hoàn thành trong khoảng thời gian cho phép.
Tester nên kiểm tra:
Request vượt quá thời gian chờ.
Thông báo timeout có rõ ràng không.
Người dùng có thể thử lại hay không.
Dữ liệu đã được lưu trước khi timeout hay chưa.
Thử lại có gây tạo dữ liệu trùng không.
Điểm quan trọng là timeout không đồng nghĩa với việc thao tác chắc chắn thất bại. Ví dụ, Server có thể đã lưu đăng ký thành công nhưng response bị mất trên đường truyền.
Vì vậy, trước khi thử lại các thao tác quan trọng như thanh toán hoặc đăng ký, hệ thống cần có cách xác định trạng thái giao dịch và hạn chế xử lý trùng.
7. Hiểu Frontend, Backend và Database khi điều tra bug
Để điều tra bug hiệu quả, Tester cần hiểu vai trò của từng thành phần trong hệ thống.
7.1. Frontend
Frontend chịu trách nhiệm hiển thị giao diện và xử lý tương tác phía người dùng.
Các lỗi thường gặp:
UI hiển thị sai dữ liệu.
Validation không hoạt động.
Button không thực hiện hành động.
Dữ liệu cũ chưa được cập nhật.
Giao diện không xử lý response đúng cách.
7.2. Backend
Backend xử lý logic nghiệp vụ, xác thực, phân quyền và giao tiếp với Database hoặc dịch vụ khác.
Các lỗi thường gặp:
Tính toán sai dữ liệu.
Kiểm tra quyền không chính xác.
Validation phía Server bị thiếu.
API trả về dữ liệu sai.
Logic xử lý ngày giờ không nhất quán.
7.3. Database
Database lưu trữ dữ liệu của ứng dụng.
Các lỗi thường gặp:
Dữ liệu chưa được lưu.
Dữ liệu bị sai hoặc bị trùng.
Quan hệ giữa các bảng không đúng.
Giá trị ngày giờ bị chuyển đổi không mong muốn.
Trạng thái dữ liệu không khớp với nghiệp vụ.
7.4. Quy trình điều tra bug
Khi phát hiện một vấn đề, Tester có thể thực hiện theo trình tự sau:
Bước 1: Reproduce the issue
Tái hiện lỗi nhiều lần nếu có thể. Ghi nhận tài khoản, test data, môi trường, thời điểm và các bước thực hiện.
Bước 2: Check the UI
Xác nhận dữ liệu đầu vào, trạng thái giao diện và kết quả hiển thị.
Bước 3: Check the Network request
Dùng Developer Tools hoặc Postman để xem request, response, status code và thời gian phản hồi.
Bước 4: Check the Backend behavior
Đối chiếu kết quả API với quy tắc nghiệp vụ và log liên quan nếu được cấp quyền.
Bước 5: Check the Database
Kiểm tra dữ liệu trước và sau thao tác bằng SQL hoặc công cụ quản trị Database phù hợp.
Bước 6: Identify the failure point
Thu thập bằng chứng để xác định lỗi có khả năng nằm ở Frontend, Backend, Database hay quá trình giao tiếp giữa các thành phần.
Tester không nhất thiết phải tự xác định chính xác dòng code gây lỗi. Điều quan trọng là cung cấp đủ thông tin để Dev có thể điều tra nhanh và sửa đúng nguyên nhân.
8. Ví dụ thực tế: Điều tra lỗi Date of Birth bị lệch một ngày
Giả sử Admin cập nhật Date of Birth của một Player thành 30/12/2016. Sau khi lưu, giao diện hoặc Database hiển thị 29/12/2016.
Tester có thể điều tra theo các bước:
- Kiểm tra giá trị được chọn trên UI trước khi nhấn Save.
- Mở tab Network và kiểm tra request gửi lên Server.
- Xem giá trị Date of Birth trong request có phải
2016-12-30hay không. - Kiểm tra response từ API.
- Truy vấn Database để xác nhận giá trị thực tế được lưu.
- Tải lại trang để kiểm tra dữ liệu được lấy về và hiển thị thế nào.
- Thử thêm các ngày khác, đặc biệt là cuối tháng và các ngày gần nửa đêm.
- Kiểm tra xem lỗi chỉ xảy ra ở một trình duyệt, một timezone hay trên tất cả môi trường.
Từ kết quả thu thập được, Tester có thể khoanh vùng:
Request đã sai ngay từ Frontend.
Request đúng nhưng Backend chuyển đổi sai.
Database lưu đúng nhưng API trả về sai.
API trả về đúng nhưng Frontend hiển thị sai.
Đây là ví dụ cho thấy hiểu biết về Client–Server, Date/Time, Network và Database giúp Tester không chỉ phát hiện lỗi mà còn rút ngắn thời gian điều tra.
9. Checklist trước khi hoàn thành Web & Mobile Testing
Trước khi xác nhận một tính năng đã được test đầy đủ, hãy tự hỏi:
Tôi đã kiểm tra happy path, negative cases và edge cases chưa?
Tôi đã kiểm tra UI trên các kích thước màn hình cần hỗ trợ chưa?
Tôi đã xác nhận các trình duyệt và thiết bị nằm trong phạm vi hỗ trợ chưa?
Tôi đã kiểm tra validation ở cả Client và Server khi cần chưa?
Tôi đã xem xét Session, Cookies và Local Storage nếu chức năng có liên quan chưa?
Tôi đã kiểm tra timezone, ngày giờ và định dạng dữ liệu phù hợp với nghiệp vụ chưa?
Tôi đã kiểm tra loading, timeout, mất mạng và thử lại thao tác chưa?
Tôi đã xác nhận dữ liệu qua API hoặc Database khi cần chưa?
Tôi đã thu thập screenshot, request/response hoặc log để hỗ trợ điều tra bug chưa?
Tôi đã đánh giá tác động của lỗi đến các chức năng liên quan chưa?
10. Kết luận
Web & Mobile Testing đòi hỏi Tester hiểu cả hành vi người dùng lẫn cách hệ thống xử lý dữ liệu phía sau giao diện. Những kiến thức về Client–Server, Responsive Design, Browser Compatibility, Session, Cookies, Local Storage, Timezone, Network và Frontend–Backend–Database là nền tảng quan trọng để phát hiện lỗi phức tạp.
Đối với Tester có khoảng 2 năm kinh nghiệm, mục tiêu không chỉ là hoàn thành test case mà còn là biết đặt câu hỏi đúng, lựa chọn dữ liệu kiểm thử phù hợp, điều tra vấn đề có hệ thống và cung cấp bằng chứng rõ ràng.
Một Tester hiệu quả không chỉ trả lời được “Có bug hay không?” mà còn phải biết “Điều gì đã xảy ra, phạm vi ảnh hưởng là gì và cần kiểm tra thêm những gì để giảm rủi ro?”
