Browser Inspect / DevTools

Browser Inspect / DevTools là gì?

Mọi trình duyệt đều có sẵn một bộ công cụ cho thấy trang đang thực sự làm gì bên dưới: nó tải những file nào, gọi những API nào, nhận về kết quả ra sao, và có nổ lỗi ở đâu không. Mở bằng phím F12, hoặc chuột phải rồi chọn Inspect.

Bạn không cần biết code để dùng hai tab quan trọng nhất:

Console — nơi code của trang in ra lỗi và cảnh báo. Trả lời câu: trang có nổ không?

Network — danh sách mọi request trang gửi đi, kèm kết quả và thời gian. Trả lời câu: request nào hỏng, và hỏng ở phía ai?

Hệ quả quan trọng nhất với BA/PO: "trang trắng" là mô tả chung của mười nguyên nhân khác nhau. Một phút nhìn vào hai tab này thường thu hẹp từ mười xuống một — và biến bug report của bạn từ thứ dev phải hỏi lại ba lượt thành thứ họ xử lý được ngay.

Baseline — bạn hiểu

• Inspect của trình duyệt cho thấy trang đang làm gì (request, lỗi) — đây là cách QA/dev khoanh vùng lỗi, và vì sao một "trang trắng" có thể có mười nguyên nhân.
• Console trả lời "code của trang có nổ không"; Network trả lời "request nào hỏng và hỏng ở phía ai".
• Một ảnh chụp nguyên văn dòng lỗi có giá trị hơn mọi câu mô tả bằng lời.

Working — không yêu cầu

Không yêu cầu ở mức Working. Đây là kỹ năng duy nhất trong khung này chỉ dừng ở Baseline. BA/PO không cần đọc mã nguồn, đặt breakpoint hay chỉnh sửa request. Đạt Baseline nghĩa là: mở được hai tab, đọc được dòng lỗi và mã trạng thái, chụp đúng chỗ cần chụp. Muốn đi xa hơn thì đi tiếp ở API và Caching — nhưng khung năng lực không đòi hỏi điều đó ở vai trò này.

Cơ chế hoạt động

Ví dụ theo cấp độ

Cơ bản — Mở Console và đọc dòng đỏ

Tình huống: khách hàng gửi ảnh chụp một trang trắng. Bạn mở đúng trang đó trên máy mình và cũng thấy trắng.

Bốn thao tác, không cần biết code:

1. Nhấn F12 (hoặc chuột phải rồi chọn Inspect), chọn tab Console.
2. Tải lại trang để lỗi hiện ra từ đầu. Console không giữ lại những gì đã xảy ra trước khi bạn mở nó — đây là lý do phổ biến nhất khiến người mới kết luận nhầm "không có lỗi nào".
3. Tìm dòng chữ đỏ đầu tiên tính từ trên xuống. Những dòng đỏ phía sau thường chỉ là hệ quả của nó.
4. Chụp màn hình cả dòng đó, bao gồm tên file và số dòng ở mép phải.

Ví dụ dòng bạn thấy:

Uncaught TypeError: cannot read "ho_ten" of null
    at renderProfile (profile.js:142)

Dịch sang tiếng người: code đang cố đọc trường ho_ten của một thứ mà nó tưởng là thông tin người dùng, nhưng thứ đó rỗng. Nói cách khác: dữ liệu mà trang mong đợi đã không tới. Bạn không cần sửa nó — bạn chỉ cần biết rằng có một chỗ dữ liệu bị thiếu, và ghi lại nguyên văn.

Đưa vào ticket: dán đúng hai dòng trên. Đừng viết lại thành "lỗi type gì đó ở trang hồ sơ" — câu đó không giúp được ai.

Học được: dòng đỏ đầu tiên là mẩu thông tin có giá trị nhất trong toàn bộ một bug report, và nó chỉ mất 30 giây để lấy.

Trung bình — Tab Network: request nào hỏng, và hỏng ở phía ai

Tình huống: trang không trắng, nhưng khối "Điểm thưởng" cứ quay vòng mãi không hiện số. Console không có dòng đỏ nào.

Thao tác: F12, chọn tab Network, tải lại trang, nhìn cột Status.

Bảng nghĩa mã trạng thái, đủ dùng cho BA:

• 200 — thành công.
• 401 / 403 — chưa đăng nhập, hoặc không có quyền. Thường không phải bug kỹ thuật mà là phiên hết hạn hoặc cấu hình phân quyền.
• 404 — không tìm thấy. Sai đường dẫn, hoặc bản ghi đã bị xoá.
• 400 / 422 — dữ liệu gửi lên không hợp lệ. Lỗi thường nằm ở phía gửi.
• 500 / 502 / 503 — máy chủ nổ hoặc quá tải. Đây là phía backend, không phải người dùng làm sai.
• timeout — không có câu trả lời nào. Nhìn tên miền của request: nếu là hệ thống bên ngoài (đơn vị vận chuyển, cổng thanh toán, eKYC) thì rất có thể vấn đề không nằm ở đội mình.

Điểm phân biệt quan trọng: request 500 tới /api/points là việc của đội mình. Request timeout tới tên miền của đối tác vận chuyển là việc phải xác minh với đối tác — và cách xử lý về mặt sản phẩm không phải sửa code, mà là spec một trạng thái "chưa lấy được thông tin vận chuyển, thử lại".

Học được: nhìn tên miền cộng với mã trạng thái là đủ để nói ticket này thuộc về ai. Gửi đúng đội ngay từ đầu tiết kiệm nhiều ngày hơn bất kỳ đoạn mô tả dài nào.

Nâng cao — "Trang trắng" từ mười nguyên nhân xuống một

Tình huống: 09:12 sáng, chăm sóc khách hàng dồn dập báo "trang thanh toán trắng xoá". Bạn có 10 phút trước cuộc họp và cần đưa cho đội kỹ thuật một bug report dùng được ngay.

Mười nguyên nhân đều tạo ra đúng một triệu chứng: code trang nổ; một file JS tải hỏng; API trả 500; API timeout; phiên đăng nhập hết hạn; người dùng không có quyền; dữ liệu trả về thiếu trường; bản sao cũ ở trình duyệt; một bản deploy vừa lên vài phút trước; hoặc mạng của riêng người dùng đó.

Bốn bước, mỗi bước loại bớt một nhóm:

1. Hard refresh, rồi cửa sổ ẩn danh. Ẩn danh bình thường thì đây là bản sao cũ hoặc phiên cũ của riêng bạn, không phải sự cố chung. Ẩn danh cũng trắng thì đi tiếp.
2. Console, dòng đỏ đầu tiên. Dòng đỏ nhắc tới một trường dữ liệu thì nghi dữ liệu thiếu. Dòng đỏ báo không tải được một file .js thì nghi bản deploy hoặc CDN. Không có dòng đỏ nào thì trang không nổ, nó đang chờ thứ gì đó — đi tiếp.
3. Network, tìm dòng đầu tiên không phải 200. 401 thì phiên hết hạn (và đó cũng là một lỗi trải nghiệm: đáng lẽ phải đưa về màn hình đăng nhập chứ không để trắng). 500 thì backend. Timeout tới tên miền đối tác thì phía đối tác.
4. Một câu hỏi cuối, không nằm trong trình duyệt: "có ai deploy trong 30 phút vừa rồi không?" Rất nhiều sự cố buổi sáng có câu trả lời ở ngay đây.

Bug report gửi đi sau 10 phút:

• Bắt đầu từ 09:05, hiện vẫn còn. Đã có 6 khách báo.
• Trang /checkout, tài khoản thử nghiệm 0912xxxxxx, đơn DH-88421.
• Cửa sổ ẩn danh: vẫn trắng. Máy khác, mạng 4G: vẫn trắng. Vậy không phải bản sao cũ của một máy.
• Console: Uncaught TypeError: cannot read "phi_ship" of undefined — checkout.js:88
• Network: GET /api/shipping-fee trả 500, cả 6 lần thử. Các request còn lại đều 200.
• Nghi ngờ: API tính phí ship đang lỗi, và trang không có nhánh xử lý khi thiếu phí ship nên nổ luôn thành trang trắng.
• Đã hỏi: đội hạ tầng xác nhận có một bản deploy lúc 09:02.

Cái bẫy, gọi tên thẳng: cám dỗ lớn nhất ở bước 2 là dừng lại khi thấy dòng đỏ trong Console và kết luận "lỗi frontend". Trong ví dụ trên, dòng đỏ là hệ quả chứ không phải nguyên nhân — nguyên nhân là API trả 500. Báo "lỗi frontend" sẽ khiến đội frontend mất nửa ngày tìm trong code của họ. Quy tắc: luôn xem Network trước khi kết luận từ Console, vì một lỗi dữ liệu ở backend hầu như luôn hiện ra dưới dạng một lỗi code ở frontend.

(Nhánh xử lý còn thiếu ở frontend vẫn là một ticket thật — nhưng là ticket thứ hai, mức ưu tiên khác, và không phải thứ chặn 6 khách hàng đang không thanh toán được.)

Học được: DevTools không đưa cho bạn câu trả lời, nó đưa cho bạn một thứ tự loại trừ. Giá trị của BA ở đây không phải là sửa lỗi, mà là giao cho đúng đội một bug report mà họ không phải hỏi lại câu nào.

Áp dụng khi viết spec

Những gì bạn nhìn thấy trong Console và Network phải quay ngược lại thành spec, nếu không lần sau nó lại xảy ra y hệt:

1. Mỗi khối dữ liệu đến từ API đều phải có trạng thái khi API đó lỗi hoặc chậm — thay vì để cả trang trắng vì một khối hỏng.
2. Phiên đăng nhập hết hạn (401): đưa người dùng về màn hình đăng nhập kèm thông báo, không để trang trắng.
3. Thông báo lỗi cho người dùng phải kèm một mã hoặc thời điểm để đối chiếu log. Chữ "Có lỗi xảy ra" đứng một mình không giúp được ai.
4. Đội nên có sẵn một mẫu bug report cố định gồm sáu mục: URL, tài khoản, thời điểm, dòng lỗi Console, request hỏng trong Network, và kết quả bước thử ẩn danh.

Câu hỏi nên hỏi dev

• "Dòng đỏ này là nguyên nhân hay chỉ là hệ quả của một request lỗi?"
• "Request trả 500 này thuộc service nào của mình?"
• "Tên miền này là hệ thống của mình hay của đối tác?"
• "Có bản deploy nào trong 30 phút trước khi lỗi xuất hiện không?"
• "Khi API này lỗi, trang đang được thiết kế để hiện gì? Nếu chưa có gì thì mình tạo ticket bổ sung."

Sai lầm thường gặp

• Báo "trang bị lỗi" mà không kèm URL, thời điểm và tài khoản.
• Gõ lại dòng lỗi theo trí nhớ thay vì chụp nguyên văn.
• Kết luận "lỗi frontend" ngay khi thấy dòng đỏ, chưa xem Network.
• Quên tải lại trang sau khi mở Console, rồi kết luận "không có lỗi nào".
• Không thử cửa sổ ẩn danh, để cả đội đi tìm một sự cố chỉ xảy ra trên máy mình.
• Chụp mỗi phần thông báo lỗi mà cắt mất tên file và số dòng.

Definition of done — dấu hiệu bạn đã đạt

• Bạn mở được Console và Network trên bất kỳ trang nào và đọc được kết quả trong vòng một phút.
• Mọi bug giao diện bạn gửi đi đều có dòng lỗi nguyên văn hoặc request hỏng kèm mã trạng thái, và kết quả bước thử ẩn danh.
• Bạn nói được một sự cố thuộc phía mình hay phía đối tác trước khi chuyển ticket đi.

Đi sâu hơn

• API (request/response) — hiểu chính những request bạn vừa nhìn thấy trong tab Network.