Tuần 3 - UI Testing & Lập Bug Report

Bắt đầu nhìn thấy lỗi như một QC, không chỉ nhìn thấy điều “trông có vẻ sai”. Tuần 3 là thời điểm học viên rời khỏi vùng an toàn của requirement note và test case để bước vào “hiện trường” của chất lượng thực tế. Ở tuần này, học viên không chỉ nhìn giao diện để xem nó có đẹp hay lệch, mà phải quan sát xem nó có đang khiến người dùng hiểu sai, thao tác sai, hoặc hệ thống phản hồi sai hay không. Đây cũng là tuần đầu tiên học viên phải mô tả lỗi theo cách mà dev, BA và mentor có thể dùng ngay để xử lý hoặc đánh giá. Nếu không vững tuần này, học viên có thể vẫn nhìn thấy bug, nhưng sẽ không log đủ rõ để team xử lý, hoặc log được bug nhưng không chỉ ra đúng impact và bản chất của vấn đề.

UI testing không phải là đi soi lệch pixel cho đủ. Bug report không phải là ghi lại “bị lỗi”. Đây là kỹ năng quan sát, xác minh và giao tiếp lỗi theo chuẩn làm việc thật.

​

Snapshot

​

Mục Tiêu Tuần

​

1. Kiến thức cần hiểu

Học viên cần hiểu UI testing không chỉ là kiểm layout, alignment hay màu sắc. Một màn hình có thể “đẹp” nhưng vẫn sai về trạng thái, validation, thông điệp, điều hướng hoặc hành vi nghiệp vụ. Tuần này cũng giúp học viên hiểu bug report là một tài liệu giao tiếp kỹ thuật, không phải ghi chú cảm tính về lỗi. Hết tuần, học viên cần hiểu rõ:

• UI bug, validation bug và business bug khác nhau ở đâu.
• Một bug có thể chạm nhiều lớp cùng lúc, không nên nhìn quá bề mặt.
• Severity và priority có liên quan nhưng không phải luôn giống nhau.
• Evidence tốt giúp bug report đáng tin hơn và giảm thời gian hỏi lại.

​

2. Kỹ năng cần làm được

Kết thúc tuần, học viên phải làm được các việc có thể dùng ngay trong team:

• Review một form hoặc list page theo checklist có cấu trúc.
• Quan sát và mô tả hiện tượng lỗi bằng ngôn ngữ rõ ràng, không suy diễn mơ hồ.
• Dùng DevTools để hỗ trợ xác minh request, response, status code, console error hoặc storage behavior.
• Viết bug report đủ để người khác tái hiện, đánh giá impact và xử lý.
• Gán severity và priority có lý do, không theo cảm giác.

​

3. Tư duy cần hình thành

Tuần 3 xây một tư duy rất quan trọng: không phải cứ nhìn thấy điều lạ là đã hiểu bug. QC tốt phải tách được:

• biểu hiện đang thấy trên UI,
• điều kiện tạo ra lỗi,
• hành vi hệ thống đang xảy ra,
• hành vi đúng lẽ ra phải xảy ra,
• và impact thật của lỗi đối với user hoặc dữ liệu.

Tư duy này là nền để sang các tuần API, DB, workflow và permission, nơi lỗi thường không còn lộ ra hết trên giao diện.

​

Vì Sao Tuần Này Cực Kỳ Quan Trọng

Tuần 3 là tuần đầu tiên học viên chuyển từ “thiết kế test” sang “ghi nhận chất lượng thực tế”. Nếu tuần 2 tạo ra artifact để hướng dẫn kiểm thử, thì tuần 3 kiểm tra xem học viên có thật sự biết quan sát, xác minh và giao tiếp lỗi hay chưa.

​

Đây là tuần bắt đầu đụng vào chất lượng thật của sản phẩm

Trên giấy, test case có thể rất gọn và đúng form. Nhưng khi đứng trước UI thật, học viên phải đối diện với những thứ ít rõ ràng hơn:

• Trạng thái loading có ổn không?
• Message lỗi có đúng và hữu ích không?
• Button disable có hợp lý không?
• List page khi empty, search sai, filter rỗng hoặc sort nhiều cột sẽ phản hồi ra sao?
• Hành vi nhìn như UI bug nhưng có phải gốc là validation hoặc nghiệp vụ không?

Đây là nơi kỹ năng quan sát bắt đầu quan trọng ngang với kỹ năng test design.

​

Bug report ảnh hưởng trực tiếp tới tốc độ xử lý của team

Một bug report yếu không chỉ làm “xấu tài liệu”, mà làm team chậm đi thật:

• Dev phải hỏi lại vì không tái hiện được.
• BA hiểu sai phạm vi vấn đề.
• Mentor không đánh giá được học viên đang hiểu bug ở mức nào.
• Retest bị lệch vì thông tin đầu vào không đủ.

Bug report tốt giúp người nhận hiểu nhanh 4 thứ:

• bug xảy ra ở đâu,
• tái hiện như thế nào,
• hệ thống đang làm gì sai,
• và vì sao lỗi này đáng xử lý.

​

Những lỗi QC mới ở tuần 3 rất hay mắc

• Log bug kiểu bị lỗi, không đúng, không chuẩn.
• Actual Result và Expected Result viết chồng lên nhau.
• Thiếu precondition nên người khác không tái hiện được.
• Steps quá ngắn, bỏ mất điều kiện quan trọng.
• Title không nói rõ module và hành vi lỗi.
• Severity gán theo cảm xúc, không theo impact.
• Chỉ nhìn thấy lỗi UI mà không nhận ra đằng sau là validation hoặc business bug.
• Thấy bug nhưng không lưu screenshot, video, console error hoặc request evidence.

Tuần này rất quan trọng vì nó dạy học viên một năng lực nền: nhìn thấy lỗi là chưa đủ, phải mô tả lỗi theo cách team có thể hành động.

​

UI Bug vs Validation Bug vs Business Bug

Một bug có thể chạm nhiều lớp cùng lúc. Ví dụ: form cho submit khi bỏ trống trường bắt buộc là validation bug; nếu sau đó vẫn tạo record thì nó đồng thời là business/data integrity bug.

​

Một Bug Report Tốt Trông Như Thế Nào

Bug report tốt không cần dài, nhưng bắt buộc phải dùng được:

• Title cụ thể: đọc là hiểu module và hành vi lỗi.
• Environment rõ: browser, môi trường, role, version nếu có.
• Precondition đủ: điều kiện cần có trước khi tái hiện.
• Steps tái hiện được: đi đúng đường để người khác làm lại.
• Actual Result mô tả hiện tượng: ghi điều đang xảy ra, không nhảy sang kết luận.
• Expected Result bám requirement hoặc behavior đúng: nói rõ điều lẽ ra phải xảy ra.
• Severity có lý do: phản ánh mức độ ảnh hưởng, không phải mức khó chịu cá nhân.
• Evidence đủ dùng: ảnh, video, request dump, console error, response lỗi.

​

Bug Title Tốt vs Bug Title Yếu

Title tốt giúp dev/mentor hiểu bug trước khi mở toàn bộ report.

​

Severity vs Priority

Người mới hay gán nhầm hai thứ này thành một. Một bug UI lệch nhẹ có thể severity thấp nhưng priority cao nếu nằm ở màn hình đang release. Ngược lại, một bug nghiệp vụ sai số liệu có thể severity cao dù chưa chắc được fix ngay nếu đang nằm ngoài phạm vi sprint.

​

DevTools Dùng Cho QC Để Làm Gì

DevTools không biến QC thành dev, nhưng giúp QC quan sát bug chính xác hơn:

• kiểm request đã gửi hay chưa,
• xem payload có đúng không,
• xem response lỗi hoặc status code,
• kiểm console warning/error,
• đối chiếu hành vi UI với dữ liệu backend trả về,
• kiểm local storage hoặc session storage khi cần xác minh auth/session issue.

Mục tiêu không phải “debug code”, mà là thu thập đủ tín hiệu để mô tả bug tốt hơn.

​

Kế Hoạch Theo Ngày

​

Ngày 15 - UI Testing Basics

Chủ đề: Review giao diện theo hệ thống, không theo cảm giác Mục tiêu của ngày

• Hiểu UI testing bao gồm layout, trạng thái, khả năng thao tác và tính nhất quán.
• Vượt qua ngộ nhận “UI testing chỉ là nhìn xem có lệch không”.
• Biết review một form theo checklist thay vì soi ngẫu nhiên.

Học gì

• Label, placeholder, required mark.
• Button state: enabled, disabled, loading.
• Message lỗi, helper text, inline validation.
• Alignment, spacing, visual consistency.
• UX consistency: thứ tự tab, focus, trạng thái khi submit, reset, cancel.

Thực hành gì

• Chọn 1 form bất kỳ như Login, Tạo nhân viên hoặc Tạo sản phẩm.
• Review form theo checklist gồm:
  • text hiển thị,
  • input state,
  • button state,
  • validation message,
  • consistency giữa label, placeholder và action.
• Ghi rõ đâu là quan sát, đâu là bug giả định cần log tiếp.

Output cần nộp

• day15_ui_review.md

Dấu hiệu đã hiểu bài

• Bạn review theo nhóm điểm kiểm, không nhìn màn hình kiểu ngẫu hứng.
• Bạn thấy được cả lỗi hiển thị và lỗi hành vi UI.
• Bạn phân biệt được đâu là note review, đâu là bug cần tách ra log.

Lỗi thường gặp

• Chỉ soi alignment và màu sắc.
• Không để ý trạng thái disabled/loading.
• Kết luận có bug nhưng không ghi lại dấu hiệu quan sát cụ thể.

Mentor review note

• Hỏi: Trong note của em, đâu là quan sát UI, đâu là bug đã đủ dữ kiện để log?
• Kiểm tra xem học viên có dùng checklist hay đang review bằng cảm giác.

​

Ngày 16 - Test List Page

Chủ đề: Nhìn list page như một hệ hành vi, không chỉ là một bảng dữ liệu Mục tiêu của ngày

• Biết list page có nhiều trạng thái cần test hơn một bảng hiển thị đơn thuần.
• Nhận ra empty state, loading state, search, filter, sort, pagination đều là vùng dễ có bug.
• Vượt qua ngộ nhận “list page đơn giản nên chỉ cần kiểm vài thao tác cơ bản”.

Học gì

• Search: keyword hợp lệ, keyword đặc biệt, keyword không có kết quả.
• Filter: một filter, nhiều filter, reset filter.
• Sort: tăng/giảm, trạng thái sort mặc định.
• Pagination: đầu trang, cuối trang, page size nếu có.
• Empty state, loading state, no permission state, no data state.

Thực hành gì

• Chọn một màn hình danh sách như Employee List hoặc Product List.
• Viết checklist test list page theo nhóm:
  • load list,
  • empty state,
  • search,
  • filter,
  • sort,
  • pagination,
  • action visibility cơ bản.
• Chọn 3 điểm trong checklist có khả năng phát sinh bug nghiệp vụ chứ không chỉ UI.

Output cần nộp

• day16_list_page_checklist.md

Dấu hiệu đã hiểu bài

• Bạn không bỏ quên empty state, loading state hoặc disabled state.
• Checklist có nhóm rõ ràng, mentor đọc là biết phạm vi kiểm.
• Bạn nhìn ra list page cũng có business implication như visibility, total count, trạng thái dữ liệu.

Lỗi thường gặp

• Chỉ test search ra kết quả mà không test không có kết quả.
• Không kiểm sort/pagination ở biên cuối.
• Không để ý action button hiển thị sai role hoặc sai trạng thái record.

Mentor review note

• Hỏi: Nếu chỉ test happy path của list page, em sẽ bỏ sót những state nào quan trọng nhất?
• Xem học viên có thật sự nhìn list page như một cụm trạng thái hay chỉ như một bảng dữ liệu.

​

Ngày 17 - Browser DevTools Cho QC

Chủ đề: Dùng tín hiệu kỹ thuật để mô tả bug chính xác hơn Mục tiêu của ngày

• Biết DevTools hỗ trợ QC quan sát bug, không phải để debug code.
• Dùng được Network, Console, Storage ở mức thực dụng cho QC.
• Vượt qua ngộ nhận “QC không cần mở DevTools”.

Học gì

• Network tab: request, response, status code, payload, timing.
• Console: warning, error, stack trace ở mức đọc hiện tượng.
• Local storage / session storage: token, session, key trạng thái cơ bản.
• Cách dùng DevTools để đối chiếu UI với backend response.

Thực hành gì

• Mở một website demo hoặc feature nội bộ có thể quan sát được.
• Chụp lại 5 request quan trọng và mô tả:
  • action nào tạo ra request,
  • request có gửi không,
  • status code là gì,
  • response có gì đáng chú ý,
  • console có lỗi gì không.
• Viết 2 ví dụ bug mà DevTools giúp mô tả rõ hơn.

Output cần nộp

• day17_devtools_notes.md

Dấu hiệu đã hiểu bài

• Bạn mô tả được mối liên hệ giữa thao tác UI và request.
• Bạn biết dùng status code/response để làm bug report rõ hơn.
• Bạn không cố diễn giải code, chỉ tập trung vào tín hiệu có ích cho QC.

Lỗi thường gặp

• Chụp nhiều request nhưng không biết request nào quan trọng.
• Lẫn lộn giữa console warning không liên quan và lỗi thực sự.
• Ghi DevTools note như tài liệu dev thay vì ghi theo góc nhìn QC.

Mentor review note

• Hỏi: Trong 5 request em chụp, request nào thực sự giúp em chứng minh bug?
• Kiểm tra xem DevTools được dùng để tăng độ rõ của bug report hay chỉ để cho có.

​

Ngày 18 - Bug Là Gì?

Chủ đề: Nhận diện lỗi đúng lớp và đánh giá đúng mức độ Mục tiêu của ngày

• Phân biệt defect, bug, issue trong ngữ cảnh làm việc thực tế.
• Phân biệt UI bug, validation bug và business bug.
• Hiểu severity và priority để tránh gán theo cảm tính.

Học gì

• Defect, bug, issue trong thực tế team thường dùng thế nào.
• Severity: Critical / High / Medium / Low.
• Priority và sự khác nhau với severity.
• Cách nhìn bug từ hiện tượng -> điều kiện -> impact.

Thực hành gì

• Tạo 10 bug giả định từ module Login hoặc một module CRUD đơn giản.
• Với mỗi bug, ghi:
  • loại bug,
  • biểu hiện,
  • impact,
  • severity đề xuất,
  • vì sao không phải loại bug khác.

Output cần nộp

• day18_bug_examples.xlsx

Dấu hiệu đã hiểu bài

• Bạn không gán mọi lỗi hiển thị sai thành UI bug.
• Bạn có thể giải thích vì sao severity là High hay Medium.
• Bạn mô tả bug theo hiện tượng trước khi kết luận nguyên nhân.

Lỗi thường gặp

• Gán severity theo mức khó chịu cá nhân.
• Thấy biểu hiện ở UI rồi kết luận luôn là UI bug.
• Không nói được impact thật đối với user hoặc data.

Mentor review note

• Hỏi: Bug này nhìn như UI nhưng tại sao em cho là business bug?
• Xem học viên có giải thích được logic gán severity hay chỉ chọn theo cảm giác.

​

Ngày 19 - Cách Log Bug Chuẩn

Chủ đề: Viết bug report để team có thể dùng ngay Mục tiêu của ngày

• Viết bug report đủ để người khác tái hiện và xử lý.
• Biết title, precondition, steps, actual/expected, severity và attachment phải rõ đến mức nào.
• Vượt qua ngộ nhận “viết dài là bug report tốt”.

Học gì

• Cấu trúc bug report chuẩn:
  • Title
  • Environment
  • Preconditions
  • Steps to Reproduce
  • Actual Result
  • Expected Result
  • Severity
  • Priority
  • Attachment / Evidence
  • Impact / Note
• Cách viết actual result theo hiện tượng quan sát được.
• Cách viết expected result bám requirement hoặc behavior chuẩn.
• Cách chọn title rõ module + vấn đề + bối cảnh.

Thực hành gì

• Tạo file template bug report.
• Chuyển 10 bug giả định từ ngày 18 thành bug report chuẩn.
• Với ít nhất 3 bug, đính kèm evidence dạng screenshot/video hoặc ghi chú request/status code liên quan.

Output cần nộp

• bug_report_template.xlsx
• day19_bug_reports.xlsx

Dấu hiệu đã hiểu bài

• Title của bạn đọc là hiểu ngay lỗi gì ở đâu.
• Steps có thể được người khác làm lại mà không cần hỏi thêm.
• Actual và Expected tách bạch, không trộn cảm nhận cá nhân.

Lỗi thường gặp

• Title quá chung kiểu Lỗi login.
• Steps thiếu role, dữ liệu hoặc precondition.
• Actual Result và Expected Result viết thành hai câu giống nhau nhưng đổi chữ.
• Không đính kèm evidence dù bug khó tái hiện.

Mentor review note

• Chọn ngẫu nhiên 2 bug report và thử tái hiện theo đúng steps. Nếu còn phải hỏi lại, report chưa đạt.
• Hỏi: Nếu dev chỉ đọc title và actual result, họ đã hiểu được bao nhiêu phần của bug?

​

Ngày 20 - Retest Và Bug Lifecycle

Chủ đề: Theo dõi lỗi đến khi đóng, không coi bug report là điểm kết thúc Mục tiêu của ngày

• Hiểu bug không kết thúc ở lúc log xong.
• Nắm được lifecycle cơ bản: New -> Assigned -> In Progress -> Fixed -> Retest -> Reopen -> Closed.
• Biết retest không phải chạy lại máy móc, mà là kiểm xem fix có đúng và có side effect không.

Học gì

• Ý nghĩa từng trạng thái của bug lifecycle.
• Khi nào reopen là hợp lý.
• Sự khác nhau giữa verify fix và regression xung quanh vùng fix.
• Vì sao bug report tốt giúp retest nhanh hơn rất nhiều.

Thực hành gì

• Mô phỏng vòng đời của 5 bug.
• Với mỗi bug, ghi:
  • trạng thái đầu,
  • vì sao chuyển trạng thái,
  • retest cần kiểm lại gì,
  • khi nào cần reopen,
  • có cần regression lân cận không.

Output cần nộp

• day20_bug_lifecycle.md

Dấu hiệu đã hiểu bài

• Bạn không coi Fixed là đã xong.
• Bạn biết retest cần bám bug cũ nhưng vẫn nhìn rủi ro xung quanh.
• Bạn hiểu reopen không phải vì “thấy chưa ổn”, mà vì bug chưa thực sự được xử lý đúng.

Lỗi thường gặp

• Nghĩ retest chỉ là chạy lại đúng steps cũ.
• Không phân biệt retest và regression.
• Không ghi rõ điều kiện để reopen.

Mentor review note

• Hỏi: Bug đã chuyển Fixed, em retest xong thấy symptom cũ hết nhưng sinh lỗi mới gần vùng đó, em xử lý thế nào?
• Xem học viên có hiểu lifecycle như một quy trình phối hợp team hay chỉ như sơ đồ trạng thái.

​

Ngày 21 - Tổng Kết Tuần 3

Chủ đề: Gói lại năng lực quan sát lỗi và giao tiếp lỗi thành một package dùng được Mục tiêu của ngày

• Kết nối review UI, DevTools note, bug examples, bug report và lifecycle thinking thành một bộ output hoàn chỉnh.
• Tự đánh giá chất lượng bug report trước khi mentor review.
• Chuẩn bị nền để sang các lớp kiểm thử sâu hơn như API, DB, workflow.

Học gì

• Một bug report mạnh luôn đứng trên ba chân:
  • quan sát đúng,
  • tái hiện đúng,
  • diễn đạt đúng.
• UI testing, DevTools note và bug report không tách rời nhau; chúng là chuỗi hỗ trợ lẫn nhau.

Thực hành gì

• Chọn 1 màn hình thật.
• Review UI, viết checklist, log tối thiểu 10 bug mô phỏng hoặc bug quan sát được.
• Đóng gói:
  • UI review note,
  • list page/form checklist,
  • DevTools note,
  • bug reports,
  • summary ngắn về logic phân loại bug và severity.
• Tự rà lại bug set trước khi nộp:
  • title có rõ không,
  • steps có tái hiện được không,
  • actual/expected có phân minh không,
  • severity có lý do không,
  • evidence có đủ chưa.

Output cần nộp

• week03_ui_bug_review/

Dấu hiệu đã hiểu bài

• Package của bạn thể hiện được cách nhìn lỗi có hệ thống.
• Bạn không chỉ nộp bug report, mà cho thấy vì sao bug đó được quan sát, phân loại và mô tả như vậy.
• Bạn tự chỉ ra được bug report nào của mình còn yếu và tại sao.

Lỗi thường gặp

• Nộp đủ file nhưng không có mối nối giữa review UI và bug report.
• Log nhiều bug nhưng chất lượng title/steps thấp.
• Không chứng minh được vì sao severity được gán như vậy.

Mentor review note

• Hỏi: Trong bug set của em, bug nào mô tả rõ nhất impact, và bug nào còn mơ hồ nhất? Vì sao?
• Đánh giá package ở góc độ team có thể dùng để xử lý và retest hay không.

​

Deliverables Cần Nộp

​

KPI & Focus

​

KPI tối thiểu để qua tuần 3

• Hoàn thành 100% deliverable bắt buộc.
• day19_bug_reports.xlsx có tối thiểu 10 bug đúng format chuẩn.
• Ít nhất 80% bug title thể hiện rõ:
  • module hoặc màn hình,
  • hành vi lỗi,
  • và bối cảnh đủ hiểu.
• Tối thiểu 80% bug report có:
  • precondition rõ,
  • steps tái hiện được,
  • actual/expected tách bạch,
  • severity có lý do ngắn gọn.
• Tối thiểu 5 bug có evidence dạng screenshot/video/console/request note.
• day16_list_page_checklist.md không được bỏ quên empty state, loading state và ít nhất một nhóm action visibility.

​

Focus của tuần

• Observe before conclude: mô tả hiện tượng trước, đừng nhảy ngay tới kết luận.
• Bug report for action: viết để dev/BA/mentor dùng được ngay.
• Evidence matters: nếu bug khó tái hiện hoặc severity cao, evidence gần như là bắt buộc.
• Impact over drama: severity phải bám ảnh hưởng thật tới user, chức năng hoặc dữ liệu.

​

Mini Rubric Cho Tuần 3

Strong = 3, Pass = 2, Need Improvement = 1 Khuyến nghị qua tuần khi điểm trung bình từ 2.0 trở lên và không có tiêu chí trọng yếu nào ở mức Need Improvement, đặc biệt là Bug title, Steps to reproduce, Actual/Expected và Severity.

​

Common Mistakes

​

Mentor Review Guide

​

Mentor cần nhìn gì khi review UI checklist

• Checklist có đang bao phủ đủ state và interaction không.
• Học viên có chỉ ra được chỗ nào là UI issue, chỗ nào có thể là validation/business issue không.
• Từng item có đủ rõ để thấy học viên đang review có hệ thống hay không.

​

Mentor cần nhìn gì khi review bug report

• Title có rõ module và hành vi lỗi không.
• Preconditions và environment có đủ để tái hiện không.
• Steps có tuần tự và thực dụng không.
• Actual Result có mô tả đúng hiện tượng đang xảy ra không.
• Expected Result có bám requirement hoặc behavior hợp lý không.
• Severity có dựa trên impact hay chỉ là cảm tính.
• Evidence có đủ giúp dev/mentor verify nhanh không.

​

Câu hỏi mentor nên hỏi để kiểm tra hiểu thật

• Em đang nhìn bug này là UI bug hay business bug? Vì sao?
• Nếu bỏ evidence khỏi report này, phần nào sẽ trở nên khó tin nhất?
• Severity của bug này là Medium chứ không phải High ở điểm nào?
• Actual result của em đang mô tả hiện tượng hay đang suy luận nguyên nhân?
• Nếu giao bug này cho dev chưa biết feature, họ có tái hiện được ngay không?

​

Dấu hiệu học viên đang “bắt lỗi cho có” vs thật sự hiểu vấn đề

​

Khi feedback nên ưu tiên sửa gì trước

1. Sửa bug report không tái hiện được trước.
2. Sửa Actual/Expected mơ hồ trước khi chỉnh câu chữ.
3. Sửa nhầm severity hoặc nhầm loại bug trước khi tối ưu format.
4. Chỉ khi bug report đã dùng được mới tối ưu độ gọn và độ đẹp của file.

​

Self-Check Cuối Tuần

Trước khi nộp bài, học viên nên tự tick:

• Tôi có thể review một form theo checklist thay vì nhìn ngẫu hứng.
• Tôi có nhớ kiểm empty state, loading state, disabled state và action visibility của list page.
• Tôi có dùng DevTools để hỗ trợ quan sát thay vì chỉ nhìn UI bề mặt.
• Bug title của tôi có nói rõ module hoặc màn hình và vấn đề lỗi chưa.
• Steps của tôi có đủ để người khác tái hiện mà không cần hỏi thêm.
• Actual Result và Expected Result của tôi có phân minh và kiểm được.
• Severity tôi gán có lý do theo impact, không phải theo cảm giác.
• Tôi đã lưu evidence đủ cho các bug khó tái hiện hoặc bug quan trọng.
• Tôi biết bug nào trong bộ bug set của mình còn yếu nhất và cần mentor review sâu hơn.

​

Mapping Review

• Bug template chuẩn: /templates/bug-report-template
• Rubric chính để review bug report: /evaluation/bug-report-rubric
• Mentor review checklist chung: /mentor-guide/review-checklist
• Quy tắc feedback của mentor: /mentor-guide/feedback-rules
• Weekly scoring tracker: /templates/weekly-assessment-template
• Tự đánh giá cuối tuần: /templates/self-assessment-template

​

Kết Thúc Tuần

Sau tuần 3, học viên đã đi qua một bước trưởng thành rất rõ: từ chỗ biết viết test, sang chỗ biết quan sát lỗi, xác minh lỗi và giao tiếp lỗi theo chuẩn làm việc thật. Đây là lần đầu tiên học viên phải chịu trách nhiệm không chỉ với “cái mình thấy”, mà với “cái mình ghi ra để người khác xử lý được”. Khi bước sang các lớp kiểm thử sâu hơn như API, DB, workflow và permission, hãy giữ ba mindset này:

• đừng chỉ nhìn biểu hiện, hãy truy tới điều kiện và impact;
• đừng chỉ log cho đủ, hãy log để team có thể hành động;
• đừng chỉ tin mắt nhìn, hãy dùng thêm tín hiệu từ request, response, state và evidence.

Giữ được ba điều đó, các tuần sau sẽ chắc hơn rất nhiều, vì bạn đã có nền quan sát lỗi và bug communication đủ tốt để đi vào những lớp sâu hơn của hệ thống.