Bạn có bao giờ:

• Viết bug report 30 phút, nhận lại 3 chữ "Cannot Reproduce"?
• Ngồi im khi dev nói "It's not a bug, it's a feature"?
• Mở DevTools rồi đóng ngay vì không biết nhìn gì?

Nếu những câu hỏi trên nghe quen thuộc, thì bài viết này chính là dành cho bạn. Mục tiêu của chúng ta không phải là 'bắt lỗi' của dev, mà là cùng nhau xây dựng một sản phẩm chất lượng.

Trong bài viết này, bạn sẽ học được:

• 📝 Viết Bug Report hiệu quả: Để dev có thể hiểu vấn đề ngay từ đầu.
• 🔍 Làm quen với DevTools: Nhìn vào đâu để tìm manh mối khi có lỗi.
• 💬 Giao tiếp khéo léo: Vài cách xử lý cho những tình huống khó nói.
• 🤝 Xây dựng Mindset "win-win": Từ "người tìm lỗi" trở thành "người cùng xây dựng".

Trước khi đi vào nội dung chính, mình muốn làm rõ "DEBUGGING" trong bài viết này:

📝 Bug Report - Vũ khí mạnh nhất của bạn

Một bug report rõ ràng giúp dev hiểu ngay vấn đề, tiết kiệm thời gian cho cả hai bên. Ngược lại, một bug report thiếu thông tin sẽ gây khó khăn, dễ bị bỏ sót hoặc kiểm tra sai. Vì vậy, hãy luôn ghi nhớ:

Thần chú:

"Dev đọc xong không cần phải hỏi lại bất cứ điều gì."

Mục tiêu:

"Cụ thể từng bước – Đủ thông tin – Có bằng chứng – So sánh rõ ràng – Ngắn gọn súc tích"

• Cụ thể từng bước: Đây là phần quan trọng nhất của một báo cáo lỗi. Hãy ghi lại các bước tái hiện lỗi một cách rõ ràng và theo thứ tự (1, 2, 3...) để dev có thể làm theo một cách chính xác.

  • Mẹo: Đối với chức năng quen thuộc, bạn có thể viết ngắn gọn. Với luồng mới hoặc phức tạp, hãy viết chi tiết như đang hướng dẫn người dùng lần đầu. Luôn tự thực hiện lại các bước trước khi gửi.

• Đủ thông tin môi trường: Cung cấp đầy đủ thông tin môi trường để dev dễ dàng tái hiện lỗi, tránh trường hợp lỗi chỉ xảy ra ở một môi trường mà dev không kiểm tra được. Các thông tin cần có:

  • URL hoặc tên server: Đang test ở môi trường nào? (Development, Staging, UAT, Production…)
  • Trình duyệt: Chrome, Firefox, Edge, Safari… (kèm phiên bản cụ thể)
  • Hệ điều hành: Windows, macOS, Linux, iOS, Android… (kèm phiên bản)
  • Thiết bị: PC, laptop, điện thoại, máy tính bảng (ghi rõ model nếu là mobile)
  • Phiên bản ứng dụng: Số version, số build
  • Tài khoản test: Tên đăng nhập, vai trò (nếu có)

• Có bằng chứng: Nên đính kèm hình ảnh, video hoặc log lỗi để minh họa rõ ràng cho bug.

  • Đính kèm hình ảnh khi lỗi liên quan đến giao diện (UI), hiển thị thông báo, trạng thái button hoặc các lỗi mà chỉ cần nhìn là thấy ngay vấn đề. Nhớ khoanh tròn vùng bị lỗi.
  • Đính kèm video khi lỗi có nhiều bước, luồng phức tạp, liên quan đến hiệu ứng động, hoặc không ổn định. Lưu ý khi quay: Giữ video ngắn (10-60s), bật hiển thị con trỏ và timestamp, ghim DevTools bên cạnh nếu cần, và che thông tin nhạy cảm trước khi gửi.
  • Đính kèm log lỗi khi lỗi liên quan chức năng/ API/ backend có thông tin ở console/ network/ server hoặc khó thấy qua UI nhưng log cung cấp chi tiết để dev debug nhanh.

• So sánh rõ ràng giữa thực tế và mong muốn: Đây là phần quan trọng nhất. Hãy chỉ rõ điểm khác biệt giữa thực tế và mong muốn, mô tả khách quan thay vì chỉ nói "bị lỗi".

  • Mô tả khách quan: Thay vì phán xét, hãy mô tả chính xác hành vi bạn quan sát được.
  • Dùng con số cụ thể: Con số là bằng chứng rõ ràng nhất về mức độ sai lệch.
  • Nêu rõ nguồn của "Mong muốn": Cho dev biết yêu cầu này đến từ đâu (ví dụ: theo file thiết kế, theo tài liệu đặc tả).

  Ví dụ:

  • ❌ Không nên:

    Thực tế: Tổng số lượng không đúng.

    Mong muốn: Phải hiển thị đúng.

  • ✅ Nên:

    Thực tế: Label hiển thị là "52 users".

    Mong muốn: Phải hiển thị là "53 users" (theo dữ liệu trong database).

• Ngắn gọn súc tích: Hãy mô tả bug một cách rõ ràng, chính xác, tránh các từ mơ hồ như "thỉnh thoảng", "có vẻ" hay "không hoạt động.

  Ví dụ:

  • ❌ Không nên:

    Có vẻ hệ thống thông báo bị chậm, hôm qua tôi cũng không nhận được.

  • ✅ Nên:

    Sau khi gửi yêu cầu phê duyệt lúc 10:30 AM, tài khoản duyệt không nhận được thông báo.

Tóm lại, khi dev nhận bug report, họ sẽ ưu tiên xem các thông tin quan trọng dưới đây. Vì vậy, một báo cáo chỉn chu sẽ giúp quá trình xử lý bug nhanh và hiệu quả hơn:

1. Tóm tắt lỗi/ Tiêu đề (Summary/Title)
2. Các bước tái hiện (Steps to Reproduce)
3. Kết quả mong đợi (Expected Result) và Kết quả thực tế (Actual Result)
4. Bằng chứng kèm theo (Attachment)
5. Thông tin môi trường (Environment)
6. V.v ...

💡 Thực hành ngay: Trước khi gửi bug report, hãy tự hỏi: "Nếu là dev, mình có cần hỏi thêm gì không?" Nếu không, bạn đã viết tốt rồi!

🛠️ DevTools cho người "sợ code"

DevTools (F12) là công cụ kiểm tra lỗi có sẵn trên trình duyệt. Bạn không cần biết lập trình, chỉ cần biết cách lấy thông tin cần thiết.

Tại sao Tester cần DevTools?

• Báo cáo bug rõ ràng hơn: Thay vì mô tả triệu chứng ("trang trắng"), bạn có thể chỉ ra nguyên nhân gốc rễ ("API login trả về lỗi 500").
• Phân loại bug chính xác: Giúp xác định nhanh vấn đề thuộc về Front-end hay Back-end, từ đó dev có thể debug và fix nhanh hơn thay vì mất thời gian investigate.
• Tăng sự tin tưởng với dev: Khi bạn nói chuyện bằng "ngôn ngữ kỹ thuật" (status code, API endpoint, lỗi console), dev sẽ đánh giá cao bạn hơn.
• Tiết kiệm thời gian cho cả hai bên: Báo cáo rõ ràng giúp dev sửa nhanh, bạn kiểm thử lại sớm, dự án tiến triển tốt.

Cách mở DevTools:

Nhấn F12, hoặc Ctrl+Shift+I (Windows) / Cmd+Option+I (Mac), hoặc chuột phải vào trang và chọn Inspect.

3 Tab quan trọng nhất cho Tester:

1. Elements: Kiểm tra giao diện (HTML, CSS) và các lỗi hiển thị.
2. Console: Xem các lỗi JavaScript (lỗi logic, chức năng không chạy).
3. Network: Theo dõi các yêu cầu mạng (API) để xem dữ liệu gửi/nhận có thành công không.

DevTools - Tab Elements (Phần tử)

Khi nào dùng? Khi gặp lỗi hiển thị như sai màu, sai font, lệch layout, nút bị che, khoảng cách không đều... tab này giúp bạn kiểm tra và xác định nguyên nhân giao diện bị lỗi.

Cách sử dụng tab Elements:

1. Nhấn Ctrl + Shift + C (hoặc biểu tượng 🔍 ở góc trên DevTools).
2. Chọn phần tử bị lỗi trên trang web.
3. Trong tab Elements sẽ hiển thị hai khung: HTML (trái) và CSS (phải).

Khung trái - HTML Structure

Hiển thị cấu trúc HTML của trang web dưới dạng cây thư mục, giúp bạn thấy rõ các phần tử được sắp xếp và lồng nhau như thế nào.

Thao tác hữu ích:

• Test nhanh: Xóa/sửa HTML trực tiếp để kiểm tra UI.

• Lấy thông tin cho dev:

  • Chuột phải vào dòng code → Copy → Copy outerHTML: Lấy toàn bộ mã HTML của phần tử đó.
  • Chuột phải → Copy → Copy selector: Lấy một selector CSS duy nhất trỏ đến phần tử này, cực kỳ hữu ích cho việc mô tả bug hoặc viết kịch bản test tự động.

Khung phải - CSS

Hiển thị các thuộc tính CSS đang áp dụng lên phần tử. Bạn có thể kiểm tra rule nào đang gây lỗi, thử bật/tắt thuộc tính để xem giao diện thay đổi ra sao. Bạn sẽ làm việc chủ yếu với 2 tab: Styles và Computed.

1. Tab Styles: Là nơi bạn tìm ra "thủ phạm" – rule CSS nào đang gây ra lỗi. Nó liệt kê tất cả các rule CSS đang tác động lên phần tử bạn đã chọn.

• Cách đọc tab Styles:

  • Rule đang áp dụng: Các thuộc tính không bị gạch ngang. Đây chính là những gì đang hiển thị trên màn hình.
  • Rule bị ghi đè (override): Các thuộc tính bị gạch ngang (do có rule khác ưu tiên hơn).
  • Nguồn file và dòng code: Bên phải mỗi rule sẽ có tên file CSS và số dòng (ví dụ: app.css:1345). Đây là thông tin cực kỳ quý giá cho dev!

• Kỹ năng debug nhanh:

  • Bật/tắt rule: Bỏ dấu tick ở checkbox bên cạnh một thuộc tính để xem giao diện thay đổi ra sao. Đây là cách nhanh nhất để xác nhận "thủ phạm".
  • Mô phỏng trạng thái: Click vào nút :hov để ép phần tử vào các trạng thái như :hover (di chuột), :active (nhấn giữ), :focus (được chọn). Cực kỳ hữu ích khi debug menu dropdown hoặc hiệu ứng của nút.

2. Tab Computed: Đôi khi, nhiều rule CSS phức tạp tác động lên một phần tử. Tab Computed sẽ hiển thị giá trị CSS cuối cùng đã được tính toán và áp dụng.

• Mục đích sử dụng:

  • Xác nhận giá trị cuối cùng của một thuộc tính (ví dụ: color: rgb(53, 113, 175)).

    • Tab Styles có thể hiển thị nhiều rules: color: blue, color: #3571af, color: inherit...
    • Tab Computed chỉ hiển thị MỘT giá trị: color: rgb(53, 113, 175) - đây chính là màu thực tế bạn đang thấy trên màn hình

  • Kiểm tra Box Model: Đây là phần để debug lỗi layout. Nó hiển thị trực quan các kích thước:

    • Content: Vùng nội dung thực tế.
    • Padding: Khoảng đệm bên trong giữa nội dung và viền.
    • Border: Đường viền.
    • Margin: Khoảng trống bên ngoài, tạo khoảng cách với phần tử khác.

• Kỹ năng debug nhanh: Hover chuột vào từng vùng trong Box Model, phần tử tương ứng trên trang sẽ được highlight.

Áp dụng vào thực tế, debug lỗi với các tình huống sau:

Tình huống 1 - Lỗi sai màu sắc: Nút "Add" hiển thị màu nền #3571af, nhưng thiết kế yêu cầu #0e74dd.

Các bước debug và lấy thông tin:

1. Inspect phần tử: Dùng công cụ chọn phần tử (Ctrl+Shift+C) và click vào nút "Add".

2. Phân tích tab Styles:

• Tìm thuộc tính background-color. Bạn sẽ thấy rule background-color: #3571af; đang được áp dụng.
• Ghi lại selector của rule này (ví dụ: .btn-primary) và nguồn của nó (ví dụ: app.css:1345).
• Kiểm tra xem có rule nào chứa màu đúng (#0e74dd) nhưng đang bị gạch ngang (bị override) không.

3. Thử nghiệm: Bỏ tick ở rule background-color: #3571af;. Nếu nút chuyển sang màu đúng, bạn đã tìm ra chính xác nguyên nhân.

4. Tổng hợp báo cáo: Chụp lại màn hình tab Styles và chuẩn bị thông tin gửi cho dev.

Mẫu thông tin gửi cho dev:

• Selector áp dụng: .btn-primary (app.css:1345)
• background-color: #3571af
• Rule đúng #0e74dd có trong theme.css:220 nhưng bị override
• OuterHTML: Add

Tình huống 2 - Lỗi khoảng cách: Padding giữa label "Content" và thành phần kế bên là 20px, nhưng thiết kế yêu cầu 10px.

Mẫu thông tin gửi cho dev:

• Selector áp dụng: .btn-group .btn (buttons.css:34)
• padding-left: 20px
• Rule đúng: padding-left: 10px

• OuterHTML: <th>Contents</th>

Lợi ích khi Dev nhận được thông tin này:

• Dev biết ngay CSS nào đang áp dụng sai và ở file nào, dòng nào.
• Dev thấy rõ rule đúng bị ghi đè, dễ tìm nguyên nhân và sửa nhanh.
• Có mã HTML và class nút để kiểm tra trực tiếp trên code.
• Giảm thời gian trao đổi lại với tester, giúp tiết kiệm thời gian sửa bug.

💡 Thực hành ngay: Hãy thử mở DevTools trên một trang web bất kỳ, đổi màu một tiêu đề, ẩn một hình ảnh, hoặc kiểm tra khoảng cách các phần tử để làm quen với công cụ này.

DevTools - Tab Console (Bảng điều khiển)

Khi nào dùng? Khi chức năng không hoạt động, form không gửi được, hoặc trang trắng, hãy kiểm tra tab Console để xem lỗi JavaScript.

Những gì cần tìm:

• Lỗi màu đỏ (Errors): Đây là thông tin quan trọng nhất! Nó thường chỉ rõ nguyên nhân. Ví dụ:

  • Uncaught TypeError: Cannot read properties of undefined: Lỗi kinh điển, nghĩa là code đang cố đọc một thứ không tồn tại.
  • ReferenceError: function is not defined: Code đang gọi một hàm chưa được định nghĩa.

• Cảnh báo màu vàng (Warnings): Không phải lỗi nghiêm trọng ngay lập tức, nhưng là những vấn đề tiềm ẩn cần được xem xét.

• Log từ dev (console.log): Các dòng chữ màu trắng/xanh do dev in ra để gỡ lỗi. Đôi khi chúng cũng cung cấp thông tin hữu ích.

Áp dụng vào thực tế: Khi chức năng "chết lặng"

Tình huống: Vào trang sản phẩm, click nút "Thêm vào giỏ hàng". Nút loading mãi mà không thêm sản phẩm.

Các bước debug:

1. Mở DevTools, chọn tab Console.
2. Click lại vào nút "Thêm vào giỏ hàng".
3. Bạn thấy một dòng lỗi màu đỏ xuất hiện.
4. Hành động: Click vào mũi tên nhỏ bên cạnh lỗi để xem chi tiết (stack trace), sau đó chuột phải và chọn "Copy message".

Thông tin gửi dev:

*Hành động: Click nút "Thêm vào giỏ hàng" ở trang chi tiết sản phẩm. Vấn đề: Nút loading mãi, sản phẩm không được thêm vào giỏ. Console log:

Copy

Uncaught TypeError: Cannot read properties of undefined (reading 'productId')
    at addToCart (product.js:150)
    at HTMLButtonElement.onclick (product.html:45)

Lợi ích: Dev nhìn vào log này sẽ biết ngay lỗi nằm ở file product.js, dòng 150, liên quan đến việc lấy productId. Họ có thể sửa ngay mà không cần hỏi bạn thêm một câu nào.

💡 Thực hành ngay:

• Trở thành "hacker" trong 1 phút: Mở tab Console trên một trang bất kỳ, gõ alert('Hello, I am a tester!'); rồi nhấn Enter. Bạn vừa thực thi đoạn mã JavaScript đầu tiên của mình!
• Quan sát: Mở một ứng dụng web phức tạp (Google Docs, Figma, Trello), mở Console và thực hiện vài thao tác (gõ chữ, kéo thả...). Bạn sẽ thấy rất nhiều thông tin được log ra, không chỉ là lỗi.

DevTools - Tab Network (Mạng)

Khi nào dùng? Khi chức năng liên quan đến việc tải hoặc gửi dữ liệu gặp vấn đề: không tải được danh sách, đăng nhập thất bại dù đúng mật khẩu, lưu form không thành công... hãy kiểm tra tab Network để xem các request bị lỗi.

Cách sử dụng:

1. Mở DevTools, chọn tab Network.
2. Thực hiện hành động gây lỗi (ví dụ: nhấn nút Đăng nhập).
3. Một danh sách các yêu cầu (request) sẽ hiện ra.

Những gì cần tìm:

• Dòng màu đỏ: Đây là các request bị lỗi, là "nghi phạm" số một.

• Cột Status:

  • 2xx (ví dụ: 200 OK): Yêu cầu thành công.
  • 4xx (ví dụ: 404 Not Found, 400 Bad Request, 401 Unauthorized): Lỗi từ phía client (trình duyệt của bạn gửi sai dữ liệu, hoặc bạn chưa đăng nhập). Đây chắc chắn là bug.
  • 5xx (ví dụ: 500 Internal Server Error): Lỗi từ phía server. Đây cũng là bug nghiêm trọng.

• Click vào dòng request bị lỗi và xem các tab con:

  • Headers: Chứa thông tin chung về request (URL, method...).
  • Payload: Dữ liệu bạn đã gửi đi (ví dụ: username, password).
  • Response: Dữ liệu server trả về. Đây là nơi thường chứa thông báo lỗi chi tiết

Tab này ghi lại tất cả các "giao tiếp" giữa trình duyệt và máy chủ (server).

Áp dụng vào thực tế:

• Tình huống: Đăng nhập với username/password đúng, nhưng màn hình chỉ báo "Có lỗi xảy ra, vui lòng thử lại" mà không nói rõ lỗi gì.

• Các bước debug:

  1. Mở tab Network.
  2. Nhập username/password và nhấn "Đăng nhập".
  3. Tìm request login (hoặc tương tự) trong danh sách, bạn thấy nó có màu đỏ và Status là 500.
  4. Click vào request đó, chọn tab Response. Bạn thấy một thông báo lỗi chi tiết hơn: {"error": "Database connection failed"}.

• Thông tin gửi dev:

  Hành động: Đăng nhập với tài khoản tester01@gmail.com. Vấn đề: UI báo lỗi chung chung, nhưng Network cho thấy API bị lỗi. Thông tin API:

  Endpoint: POST /api/v1/auth/login

  Status Code: 500 Internal Server Error

  Response Body: {"error": "Database connection failed"}

  Em đã đính kèm screenshot của tab Network trong bug report.

  Lợi ích: Bạn đã giúp dev khoanh vùng vấn đề từ một lỗi chung chung trên UI thành một lỗi cụ thể ở backend (mất kết nối database).

💡 Thực hành ngay: Hãy mở DevTools trên các trang web bạn thường dùng, thử thay đổi CSS, kiểm tra API, và quan sát các lỗi. Thực hành thường xuyên sẽ giúp bạn thành thạo công cụ này. Bài viết này chỉ là khởi đầu - hãy tìm thêm các video hướng dẫn DevTools trên YouTube để nâng cao kỹ năng của mình nhé!

💬 Giao tiếp "ăn ý" với Dev

Bạn đã có bug report chuẩn và biết dùng DevTools. Bây giờ, hãy học thêm kỹ năng giao tiếp để phối hợp hiệu quả với dev.

Giao tiếp không chỉ là lời nói, mà là cách bạn trình bày vấn đề, đặt câu hỏi và thể hiện thái độ hợp tác. Dưới đây là cách xử lý một số tình huống "khó đỡ" thường gặp để biến chúng thành cơ hội hợp tác hiệu quả.

Tình huống 1: Bug bị trả về với lý do "Cannot Reproduce"

• Tư duy sai thường gặp: Im lặng test lại một mình, cảm thấy bối rối hoặc tự trách "chắc mình làm sai ở đâu đó".

• Hướng xử lý khéo léo: Chủ động tìm kiếm sự đồng bộ. Hãy xem đây là cơ hội để cả hai cùng nhìn về một hướng.

  • Bước 1 - Cung cấp lại bối cảnh: Khẳng định lại môi trường, tài khoản, và dữ liệu bạn đã dùng để test. Điều này giúp loại trừ khả năng hai người đang test trên hai điều kiện khác nhau.
  • Bước 2 - Đặt câu hỏi mở: Thay vì nói "Anh/chị test lại đi", hãy hỏi "Anh/chị có thể chia sẻ giúp em các bước hoặc dữ liệu cụ thể mà anh/chị đã dùng để kiểm tra không ạ?".
  • Bước 3 - Đề nghị hợp tác trực tiếp: Nếu vẫn chưa tìm ra điểm khác biệt, hãy đề nghị: "Hay là mình call nhanh 5-10 phút để em chia sẻ màn hình và tái hiện lại nhé?".

• Tại sao nó hiệu quả? Cách tiếp cận này thể hiện sự chuyên nghiệp, chủ động và tinh thần đồng đội. Bạn không đổ lỗi, mà đang tìm cách giải quyết vấn đề CÙNG NHAU.

Tình huống 2: Phân vân "Đây là Bug hay Feature?"

• Tư duy sai thường gặp: Tự đoán rồi log bug (dễ bị reject và tốn thời gian) hoặc im lặng bỏ qua (có thể bỏ sót lỗi nghiêm trọng).

• Hướng xử lý khéo léo: Đóng vai trò người làm rõ yêu cầu.

  • Bước 1 - Trình bày quan sát: Mô tả ngắn gọn hành vi thực tế bạn thấy. Ví dụ: "Em thấy sau khi nhấn Save, popup không tự động đóng."
  • Bước 2 - Đối chiếu với "sự thật": Dẫn nguồn tài liệu gốc (thiết kế, đặc tả, user story,...) và nêu lại kết quả mong muốn theo hiểu biết của bạn. Ví dụ: "Theo bản thiết kế, popup phải tự động đóng và hiển thị thông báo thành công."
  • Bước 3 - Đặt câu hỏi xác nhận: Kết thúc bằng một câu hỏi rõ ràng: "Anh/chị xác nhận giúp em đây có phải là hành vi đúng không để em báo bug nhé."

• Tại sao nó hiệu quả? Bạn cho thấy mình là một tester cẩn thận, bám sát yêu cầu và tôn trọng thời gian của cả team bằng cách tránh tạo ra các bug report không cần thiết.

Tình huống 3: Cần dev hỗ trợ debug một lỗi phức tạp

• Tư duy sai thường gặp: Bỏ cuộc và báo bug với mô tả "lỗi không ổn định", "thỉnh thoảng bị".

• Hướng xử lý khéo léo: Thể hiện bạn đã nỗ lực hết sức và cần sự trợ giúp chuyên môn.

  • Bước 1 - Tóm tắt nỗ lực: Nói rõ bạn đã thử những gì. Ví dụ: "Em đang gặp một lỗi khá lạ ở chức năng X. Em đã thử tái hiện trên Chrome, Firefox, với cả tài khoản admin và user thường nhưng lỗi chỉ xuất hiện ngẫu nhiên."
  • Bước 2 - Đề nghị hỗ trợ và nhấn mạnh lợi ích chung: "Anh/chị có rảnh khoảng 15 phút trong hôm nay không ạ? Em nghĩ nếu mình debug chung trực tiếp trên máy em thì sẽ tìm ra nguyên nhân nhanh hơn."

• Tại sao nó hiệu quả? Dev sẽ đánh giá cao việc bạn đã cố gắng khoanh vùng vấn đề. Lời đề nghị "debug chung" cho thấy bạn xem họ là đồng đội chứ không phải người để "quăng" bug qua.

Tình huống 4: Phát hiện bug mới sau khi dev đã fix (Regression Bug)

• Tư duy sai thường gặp: Comment vào bug report cũ đã đóng: "Anh fix cái này lại làm hỏng cái kia rồi!". Cách này vừa mang tính đổ lỗi, vừa làm rối loạn quy trình quản lý lỗi.

• Hướng xử lý khéo léo: Tách bạch vấn đề và giữ thái độ trung lập.

  • Bước 1 - Tạo một bug report mới: Luôn luôn tạo một bug report mới cho lỗi regression. Điều này giúp việc theo dõi, quản lý và báo cáo được rõ ràng.
  • Bước 2 - Liên kết thông tin: Trong bug report mới, hãy ghi rõ: "Lỗi này phát sinh sau khi áp dụng bản vá cho bug [#ID bug cũ]." Việc này cung cấp bối cảnh cực kỳ quan trọng cho dev.
  • Bước 3 - Mô tả như một bug bình thường: Cung cấp đầy đủ các bước tái hiện, kết quả mong đợi/thực tế cho lỗi MỚI mà không nhắc lại chuyện cũ một cách không cần thiết.

• Tại sao nó hiệu quả? Quy trình rõ ràng giúp mọi người không bị rối. Việc tạo bug report riêng thể hiện sự chuyên nghiệp, tập trung vào vấn đề hiện tại thay vì đổ lỗi cho quá khứ.

Tình huống 5: Tìm thấy bug nghiêm trọng ngay trước giờ G (Release)

• Tư duy sai thường gặp: Hoảng loạn và báo cáo một cách chung chung, hoặc tệ hơn là im lặng vì sợ làm "người mang tin xấu" và cản trở tiến độ.

• Hướng xử lý khéo léo: Giữ bình tĩnh, hành động nhanh và cung cấp thông tin chính xác.

  • Bước 1 - Báo cáo ngay lập tức: Đừng chat hay tạo bug report rồi chờ. Hãy đến gặp trực tiếp hoặc gọi ngay cho những người có quyền quyết định (PM, Tech Lead).
  • Bước 2 - Cung cấp thông tin "siêu tốc": Chuẩn bị sẵn câu trả lời cho các câu hỏi: Lỗi là gì? Tác động ra sao? Tỷ lệ người dùng bị ảnh hưởng? Có cách nào tái hiện 100% không? Có giải pháp tạm thời không?
  • Bước 3 - Giữ vai trò người cung cấp thông tin: Nhiệm vụ của bạn là cung cấp sự thật một cách khách quan nhất có thể. Việc quyết định có release hay không thuộc về người quản lý.

• Tại sao nó hiệu quả? Sự chuyên nghiệp và bình tĩnh của bạn trong tình huống căng thẳng sẽ được đánh giá rất cao. Bạn giúp team có đủ dữ liệu để đưa ra một quyết định khó khăn một cách nhanh chóng.

💡 Thực hành ngay: Hãy nhớ lại một lần bạn gặp khó khăn khi giao tiếp với dev về một con bug. Nếu được làm lại, bạn sẽ áp dụng hướng xử lý nào ở trên? Việc suy ngẫm về các tình huống đã qua là cách tốt nhất để chuẩn bị cho tương lai.

🧠 Mindset đúng - Từ "tìm lỗi" thành "build cùng nhau"

Công cụ và kỹ năng là cần thiết, nhưng thứ quyết định bạn có trở thành một đối tác "ăn ý" hay không nằm ở mindset (tư duy). Nhiều tester mới thường mang tâm lý "tôi phải tìm ra lỗi của dev". Tư duy này vô hình trung tạo ra một bức tường ngăn cách, biến mối quan hệ hợp tác thành đối đầu.

🔄 Hãy thay đổi góc nhìn:

Làm thế nào để xây dựng mindset "build cùng nhau"?

1. Hiểu rằng ai cũng có thể mắc lỗi: Dev cũng là con người. Mục tiêu của bạn không phải là để chứng minh ai sai, mà là để giúp sản phẩm tốt hơn.
2. Báo bug một cách trung lập: Tập trung vào sự thật và dữ liệu, không thêm cảm xúc hay phán xét cá nhân. Thay vì nói "Giao diện này xấu quá", hãy nói "Giao diện này chưa khớp với thiết kế ở điểm A, B, C".
3. Khen ngợi khi dev làm tốt: Khi một chức năng phức tạp hoạt động trơn tru, hoặc một bug khó được sửa nhanh chóng, đừng ngần ngại gửi một lời cảm ơn hoặc khen ngợi. Điều này xây dựng mối quan hệ tích cực.
4. Chủ động tìm hiểu về sản phẩm: Khi bạn hiểu rõ hơn về kiến trúc hệ thống, về những khó khăn kỹ thuật, bạn sẽ thông cảm hơn và báo bug cũng "chất" hơn.
5. Xem mình là tuyến phòng thủ cuối cùng cho người dùng: Bạn và dev cùng một chiến tuyến, bảo vệ người dùng khỏi những trải nghiệm tồi tệ.

💡 Thực hành ngay: Trong tuần này, hãy đặt cho mình một mục tiêu nhỏ: Tìm một cơ hội để khen ngợi hoặc cảm ơn một dev trong team. Đó có thể là vì họ đã sửa một bug rất nhanh, hoặc xây dựng một chức năng hoạt động rất mượt mà. Một lời động viên nhỏ có sức mạnh rất lớn trong việc xây dựng mối quan hệ.

🎯 Lời kết

Trở thành một tester "ăn ý" với dev không phải là một tài năng thiên bẩm, mà là kết quả của việc rèn luyện từng ngày: từ cách viết một bug report chỉn chu, cách sử dụng DevTools để tìm thêm thông tin, cho đến cách giao tiếp khéo léo và một tư duy luôn hướng về chất lượng chung của sản phẩm.

Hy vọng bài viết này sẽ là một cuốn cẩm nang nhỏ gọn, giúp bạn tự tin hơn trên con đường sự nghiệp của mình. Hãy nhớ rằng, mục tiêu cuối cùng của chúng ta là cùng nhau tạo ra những sản phẩm tuyệt vời.

🚀 Chúc bạn thành công!