# 🧪 Checklist Rèn Luyện Kỹ Năng Mềm — Fresher Tester (Người Trái Ngành) > **Dành cho ai:** Bạn đang chuyển ngành sang QA/Tester, chưa có kinh nghiệm IT chuyên sâu. > **Cách dùng:** Tick checkbox khi hoàn thành. Đừng bỏ qua phần *"Tại sao?"* — đó là lý do thực tế nhất để bạn làm việc này. --- ## 📅 GIAI ĐOẠN 1 — TUẦN 1–2: Foundation (Nền Tảng Giao Tiếp) > **Mục tiêu:** Học cách diễn đạt vấn đề rõ ràng — bằng văn bản, bằng câu hỏi, và bằng lời nói đơn giản. --- ### 📝 Phần 1.1 — Viết Bug Report Đúng Chuẩn > **Tại sao quan trọng?** > Bug report là "sản phẩm" chính của tester. Viết mơ hồ → dev không hiểu → bug không được sửa → bạn mất uy tín. Người trái ngành thường viết theo cảm tính — phần này giúp bạn viết có cấu trúc từ sớm. - [ ] **Học cấu trúc bug report chuẩn** gồm 7 trường: Title, Environment, Steps to Reproduce, Expected Result, Actual Result, Severity, Priority - *Ghi chú: Mỗi trường đều có lý do tồn tại. Thiếu 1 trường = dev phải hỏi lại = lãng phí thời gian cả team.* - [ ] **Viết 5 bug report giả lập** từ app thực tế (thử dùng: Shopee, Grab, hoặc bất kỳ app nào trên điện thoại) - *Ghi chú: Không cần app bị lỗi thật — bạn có thể tưởng tượng "nếu nút này không hoạt động thì tôi sẽ viết gì?"* - [ ] **Tự review lại bug report của mình** theo checklist nhỏ sau: - [ ] Title có đủ: **[Màn hình] + [Hành động] + [Kết quả sai]** không? - [ ] Steps to Reproduce có ai đọc lần đầu cũng làm theo được không? - [ ] Expected vs Actual Result có rõ ràng, không bị trùng nhau không? - [ ] Không dùng ngôn ngữ cảm tính như *"bị lỗi kỳ lạ"*, *"trông sai sai"* không? - [ ] **Nhờ 1 người bạn KHÔNG làm IT** đọc bug report của bạn và làm theo Steps — nếu họ tái hiện được bug → bạn viết tốt - *Tại sao: Đây là bài test thực tế nhất. Nếu người ngoài ngành hiểu được, dev chắc chắn hiểu.* - [ ] **Đọc 3 bug report mẫu** trên các forum như GitHub Issues, Jira public boards để học cách người thật viết - *Ghi chú: Tìm từ khóa "bug report example Jira" hoặc vào repo mã nguồn mở trên GitHub, tab Issues.* - [ ] **Lập 1 file Google Sheet** để lưu toàn bộ bug bạn tìm được — tập thói quen ghi chép có hệ thống - *Tại sao: Tester không chỉ tìm bug — tester phải quản lý bug. Thói quen này giúp bạn quen với tool quản lý sau này.* --- ### ❓ Phần 1.2 — Đặt Câu Hỏi Về Requirement (Yêu Cầu Phần Mềm) > **Tại sao quan trọng?** > Tester giỏi không chỉ test theo spec — họ phải biết hỏi khi spec mơ hồ. Người trái ngành hay ngại hỏi vì sợ "câu hỏi ngốc". Thực tế: câu hỏi không hỏi mới gây ra bug production. - [ ] **Học phân biệt 3 loại requirement** thường gặp: - Functional (chức năng): *"Người dùng có thể đăng nhập bằng email"* - Non-functional (phi chức năng): *"Trang load trong vòng 3 giây"* - Edge case (trường hợp biên): *"Điều gì xảy ra nếu email có 200 ký tự?"* - *Tại sao: Biết phân loại giúp bạn đặt câu hỏi đúng loại, đúng người.* - [ ] **Thực hành: Lấy 1 tính năng đơn giản** (VD: form đăng ký tài khoản) và tự đặt tối thiểu **10 câu hỏi requirement** - *Gợi ý câu hỏi kiểu: "Nếu người dùng bỏ trống trường X thì hệ thống làm gì?", "Số điện thoại có hỗ trợ số quốc tế không?"* - [ ] **Học template đặt câu hỏi chuyên nghiệp:** ``` "Tôi đang xem phần [tên tính năng]. Tôi không chắc về [điểm mơ hồ cụ thể]. Behavior mong muốn là [A] hay [B]? Vì nếu là [A] thì tôi cần test thêm case [X]." ``` - *Tại sao: Template này cho thấy bạn đã suy nghĩ trước khi hỏi — không hỏi vô tội vạ.* - [ ] **Tập đặt câu hỏi theo mô hình 5W1H** áp dụng vào requirement: - [ ] **Who** — Ai dùng tính năng này? (User thường / Admin / Guest?) - [ ] **What** — Chính xác tính năng làm gì? - [ ] **When** — Tính năng này kích hoạt khi nào? - [ ] **Where** — Xuất hiện ở màn hình nào / platform nào? - [ ] **Why** — Business logic phía sau là gì? - [ ] **How** — Hệ thống xử lý dữ liệu như thế nào? - [ ] **Thực hành roleplay:** Viết 5 câu hỏi requirement dạng email/message chuyên nghiệp, đọc lại và tự chấm: *"Câu này có thể bị hiểu lầm không?"* - [ ] **Xây dựng thói quen "Assumption List"** — trước khi test, liệt kê tất cả điều bạn đang *giả định* là đúng về tính năng đó - *Tại sao: Assumption chưa được confirm = nguồn gốc của bug bị miss.* --- ### 🗣️ Phần 1.3 — Giải Thích Bug Cho Người Không Làm Kỹ Thuật > **Tại sao quan trọng?** > Trong thực tế, bạn sẽ phải báo cáo bug với PM, BA, thậm chí client — những người không hiểu kỹ thuật. Nếu bạn chỉ biết nói với dev, bạn đang thiếu nửa kỹ năng giao tiếp cần thiết. - [ ] **Học nguyên tắc ELI5** (Explain Like I'm 5) — giải thích kỹ thuật bằng ngôn ngữ đời thường - *VD thay vì nói "API trả về 500 error", hãy nói "Khi bạn bấm nút thanh toán, hệ thống bị lỗi và không xử lý được đơn hàng của bạn"* - [ ] **Thực hành: Lấy 3 bug bạn đã viết ở Phần 1.1**, viết lại mỗi bug thành **2 phiên bản:** - Phiên bản kỹ thuật (cho dev) - Phiên bản đơn giản (cho PM / khách hàng) - [ ] **Thực hành giải thích impact của bug** — không chỉ mô tả bug xảy ra, mà nói rõ hậu quả: - *Template: "Bug này ảnh hưởng đến [ai] khi họ [làm gì], dẫn đến [hậu quả kinh doanh/trải nghiệm]"* - *VD: "Bug này ảnh hưởng đến người dùng lần đầu đăng ký, khiến họ không thể hoàn tất tạo tài khoản, dẫn đến mất khách hàng tiềm năng."* - [ ] **Thực hành nói thành tiếng:** Giải thích 1 bug cho người thân không làm IT, không dùng từ kỹ thuật - *Feedback cần hỏi: "Bạn có hiểu chuyện gì xảy ra không? Bạn thấy bug này có nghiêm trọng không?"* - [ ] **Học phân biệt Severity vs Priority bằng ví dụ thực tế** để giải thích với stakeholder: - *Severity cao / Priority thấp: "Tính năng xuất báo cáo bị lỗi, nhưng hiện tại không ai dùng tính năng đó."* - *Severity thấp / Priority cao: "Logo bị hiển thị sai màu — về kỹ thuật không ảnh hưởng, nhưng ngày mai là ngày demo cho khách hàng lớn."* --- ## 📅 GIAI ĐOẠN 2 — TUẦN 3–4: Team Simulation (Môi Trường Nhóm Giả Lập) > **Mục tiêu:** Làm quen với nhịp làm việc Agile, học cách giao tiếp trong team thật sự, không bị "shock văn hóa" khi đi làm. --- ### 🕐 Phần 2.1 — Thực Hành Daily Standup > **Tại sao quan trọng?** > Daily standup là cuộc họp ngắn (~15 phút) diễn ra mỗi sáng ở hầu hết công ty Agile. Nói sai format hoặc nói quá dài → mất điểm ngay từ tuần đầu đi làm. - [ ] **Học và thuộc 3 câu hỏi standup chuẩn:** 1. *"Hôm qua tôi đã làm gì?"* 2. *"Hôm nay tôi sẽ làm gì?"* 3. *"Tôi có đang bị block bởi vấn đề gì không?"* - [ ] **Thực hành viết standup update hàng ngày** trong 5 ngày liên tiếp (dù bạn chưa đi làm, hãy viết về việc học của bạn) - *VD: "Hôm qua: Hoàn thành 5 bug report giả lập. Hôm nay: Học cách đặt câu hỏi requirement. Block: Chưa hiểu rõ sự khác biệt giữa Severity và Priority."* - [ ] **Học các lỗi phổ biến trong standup** và tự kiểm tra: - [ ] Không kể chi tiết quá (standup không phải buổi báo cáo dài) - [ ] Không dùng giờ standup để giải quyết vấn đề kỹ thuật ngay tại chỗ - [ ] Không im lặng khi được hỏi — nếu chưa có gì, hãy nói "Hôm qua tôi đang onboard, hôm nay tôi sẽ bắt đầu task X" - [ ] Không nói "Tôi ổn, không có gì" nếu thật sự có blockers — che blockers sẽ gây hại cho cả team - [ ] **Thực hành nói standup thành tiếng, đúng 2 phút** — cài đồng hồ đếm ngược, tập nói tự nhiên, không đọc chép - *Tại sao: 2 phút/người là tiêu chuẩn thực tế. Nói quen rồi sẽ tự nhiên hơn.* - [ ] **Roleplay tình huống:** Bạn bị block vì đang chờ dev fix bug để test tiếp — tập nói câu này chuyên nghiệp: - *"Hôm qua tôi test xong module A, tìm được 3 bugs. Hôm nay tôi dự định test module B, nhưng hiện tại đang chờ [tên dev] fix bug #23 vì nó ảnh hưởng đến flow chính. Tôi sẽ chuyển sang viết test case cho module C trong lúc chờ."* --- ### 💬 Phần 2.2 — Nhận Và Phản Hồi Feedback > **Tại sao quan trọng?** > Fresher hay nhận feedback theo 2 cách sai: hoặc im lặng chịu đựng, hoặc defensive (tự bảo vệ mình). Cả 2 đều cản trở việc học. Kỹ năng nhận feedback tốt giúp bạn tiến bộ nhanh gấp đôi. - [ ] **Học framework nhận feedback: "ACT"** - **A**cknowledge (Ghi nhận): *"Cảm ơn bạn đã cho tôi biết điều này."* - **C**larify (Làm rõ): *"Bạn có thể ví dụ cụ thể hơn được không?"* - **T**ake action (Hành động): *"Tôi sẽ chỉnh lại theo hướng X."* - [ ] **Thực hành tình huống: Senior review bug report của bạn và nói "Bug này không đủ thông tin"** - Phản ứng SAI: *"Tôi nghĩ tôi đã viết đủ rồi..."* ❌ - Phản ứng ĐÚNG: *"Cảm ơn anh/chị. Phần nào thiếu thông tin nhất ạ? Để em biết cần bổ sung gì."* ✅ - [ ] Viết ra giấy phản ứng đúng theo từng tình huống feedback thường gặp - [ ] **Tập nhận feedback về kỹ năng không phải kỹ thuật** (thái độ, cách giao tiếp) — phần này khó hơn vì dễ bị tổn thương: - *Khi được nói: "Em hay ngắt lời người khác trong meeting"* - Thực hành nói: *"Cảm ơn anh/chị đã nói thẳng. Em không nhận ra điều đó. Em sẽ chú ý hơn trong các buổi họp tới."* - [ ] **Học cách cho feedback ngược lại** (upward/peer feedback) một cách xây dựng: - Template: *"Tôi nhận thấy [quan sát cụ thể, không phán xét]. Điều đó ảnh hưởng đến [kết quả cụ thể]. Bạn nghĩ chúng ta có thể [đề xuất giải pháp] không?"* - [ ] **Tạo "Feedback Journal"** — mỗi lần nhận feedback (dù trong học tập hay cuộc sống), ghi lại: - Feedback là gì? - Phản ứng ban đầu của tôi là gì? (cảm xúc thật) - Tôi đã hành động gì? - Kết quả sau đó ra sao? - [ ] **Nhờ ai đó (bạn bè, người thân) cho feedback về cách bạn giải thích một chủ đề** và thực hành nhận feedback không defensive trong ít nhất 3 lần --- ### 👥 Phần 2.3 — Làm Việc Nhóm Giả Lập > **Tại sao quan trọng?** > Testing không bao giờ là công việc solo. Bạn sẽ làm việc với dev, BA, PM, designer — mỗi người có góc nhìn khác nhau. Biết cách cộng tác từ sớm giúp bạn hòa nhập team nhanh hơn nhiều. - [ ] **Tìm 1-2 người cùng học** (bạn học, người cùng chuyển ngành) để thực hành nhóm giả lập - *Nếu không có ai: dùng các cộng đồng online như Facebook Group "Tester Việt Nam", Discord QA communities* - [ ] **Giả lập scenario: Tìm bug và escalate** - Bạn (tester) tìm bug nghiêm trọng → báo cho "BA" (người đóng vai) → BA confirm với "PM" → PM quyết định priority - [ ] Thực hành viết message escalate bug khẩn cấp đúng cách, không gây panic: - *"Anh/chị ơi, em vừa tìm thấy bug ở flow thanh toán — người dùng không thể hoàn tất đơn hàng. Em đã log bug #45 với severity Critical. Anh/chị xem xét priority và assign cho dev được không ạ?"* - [ ] **Thực hành bất đồng ý kiến chuyên nghiệp:** - Tình huống: Dev nói *"Đây không phải bug, đây là feature"* nhưng bạn không đồng ý - [ ] Học cách tranh luận dựa trên bằng chứng, không dựa trên cảm xúc: - *"Tôi hiểu góc nhìn của bạn. Nhưng theo requirement ở trang 5, section 3.2, behavior mong đợi là [X]. Hiện tại hệ thống đang làm [Y]. Bạn có thể cho tôi biết requirement đã được cập nhật chưa, hay mình cần confirm lại với BA không?"* - [ ] **Tập kỹ năng "handoff" — bàn giao công việc** khi bạn không thể tiếp tục (ốm, nghỉ phép, quá tải): - Viết 1 handoff note mẫu gồm: Đang làm đến đâu, còn lại gì chưa làm, các rủi ro cần lưu ý, file/link tài liệu liên quan - [ ] **Học cách viết message hỏi dev một cách không làm phiền:** - SAI: Ping liên tục trong 30 phút ❌ - ĐÚNG: Gửi 1 message đầy đủ thông tin và chờ response trong thời gian hợp lý ✅ - Template: *"[Tên dev], bạn có thể giúp mình confirm behavior của [tính năng X] không? Cụ thể: [mô tả ngắn]. Mình đang thấy [A] nhưng expect [B]. Khi bạn rảnh, cho mình biết nhé, không gấp."* - [ ] **Thực hành viết "meeting note" sau mỗi buổi họp nhóm giả lập** gồm: Quyết định đã thống nhất, Action items (ai làm gì, deadline khi nào), Câu hỏi còn open - *Tại sao: Người viết meeting note là người hiểu cuộc họp rõ nhất — đây là cách học tốt nhất.* --- ## 📅 GIAI ĐOẠN 3 — CHUẨN BỊ PHỎNG VẤN > **Mục tiêu:** Không bị bất ngờ với câu hỏi kỹ năng mềm. Trả lời tự tin, có cấu trúc, có ví dụ thực tế — dù ví dụ đó từ ngành cũ hoặc từ quá trình tự học. --- ### 🎯 Phần 3.1 — Câu Hỏi Phổ Biến Về Kỹ Năng Mềm > **Cách dùng phần này:** Đọc câu hỏi → tự trả lời trước → đọc ví dụ trả lời → điều chỉnh theo câu chuyện của bạn → luyện nói thành tiếng. --- #### ❓ Câu 1: "Tại sao bạn chuyển sang nghề Tester?" - [ ] Đọc và hiểu lý do câu hỏi này được hỏi: - *Interviewer muốn biết: Bạn có thật sự muốn làm tester không, hay chỉ chọn vì "dễ xin việc"? Bạn có hiểu nghề không?* - [ ] Tự viết câu trả lời theo framework **"Quá khứ → Hiện tại → Tương lai":** - Quá khứ: Bạn làm gì trước đây + có kỹ năng nào có thể dùng được - Hiện tại: Điều gì khiến bạn bị hút vào testing cụ thể - Tương lai: Bạn muốn phát triển theo hướng nào - [ ] Tham khảo ví dụ trả lời mẫu: > *"Trước đây tôi làm kế toán 3 năm — công việc đòi hỏi tôi phải kiểm tra số liệu cẩn thận và tìm ra sai lệch trước khi báo cáo. Tôi nhận ra mình có tư duy tìm lỗi khá tốt và thích cảm giác 'phát hiện ra điều gì đó sai'. Khi tìm hiểu về testing, tôi thấy đây là nghề cho phép tôi dùng đúng điểm mạnh đó trong môi trường công nghệ, một lĩnh vực tôi muốn được làm việc lâu dài. Tôi đã dành 2 tháng gần đây tự học testing, thực hành viết bug report và tìm hiểu Agile để chuẩn bị cho sự chuyển đổi này."* - [ ] Viết phiên bản trả lời cá nhân hóa theo câu chuyện của bạn --- #### ❓ Câu 2: "Bạn xử lý thế nào khi bất đồng với dev về một bug?" - [ ] Hiểu lý do câu hỏi này được hỏi: - *Interviewer muốn biết: Bạn có biết cách giải quyết conflict chuyên nghiệp không? Bạn có "cứng đầu" hoặc "nhún nhường vô lý" không?* - [ ] Học framework trả lời **STAR** (Situation → Task → Action → Result) - [ ] Tham khảo ví dụ trả lời mẫu: > *"Trong quá trình thực hành tự học, tôi đã gặp tình huống tương tự khi roleplay cùng bạn học. Tôi tìm thấy một lỗi mà 'dev' cho rằng đó là behavior bình thường. Thay vì tranh cãi, tôi quay lại tài liệu requirement, trích dẫn đúng phần mô tả behavior mong đợi và đề xuất cả hai cùng hỏi lại BA để xác nhận. Cuối cùng BA confirm đó là bug thật. Tôi học được rằng trong tranh luận kỹ thuật, bằng chứng quan trọng hơn ý kiến, và việc leo thang vấn đề lên đúng người không phải là điều tiêu cực mà là làm đúng quy trình."* - [ ] Tự viết câu trả lời theo câu chuyện thực của bạn (có thể từ công việc cũ — VD: bất đồng với đồng nghiệp về cách làm việc) --- #### ❓ Câu 3: "Bạn làm gì khi deadline gần đến nhưng còn nhiều test chưa chạy xong?" - [ ] Hiểu lý do câu hỏi này được hỏi: - *Interviewer muốn biết: Bạn có biết ưu tiên công việc không? Bạn có biết giao tiếp với team khi có rủi ro không?* - [ ] Tham khảo ví dụ trả lời mẫu: > *"Khi đó tôi sẽ làm 2 việc ngay lập tức: Thứ nhất, tôi sẽ ưu tiên test các test case liên quan đến core functionality và happy path trước — những thứ nếu lỗi thì release không được. Thứ hai, tôi sẽ thông báo ngay cho PM hoặc team lead về tình trạng thực tế: 'Tôi còn X test cases chưa chạy, trong đó Y cái thuộc phần [tính năng ít quan trọng]. Mình có muốn tôi bỏ qua phần đó để kịp deadline không, hay nên dời release?' Tôi không tự quyết định bỏ test mà không báo — đó là rủi ro cần team cùng nhận thức."* - [ ] Tự viết câu trả lời theo cách bạn thật sự sẽ xử lý --- #### ❓ Câu 4: "Hãy kể về lần bạn mắc lỗi và bạn đã học được gì?" - [ ] Hiểu lý do câu hỏi này được hỏi: - *Interviewer muốn biết: Bạn có tự nhận thức về điểm yếu không? Bạn học từ sai lầm hay đổ lỗi cho người khác?* - [ ] Tham khảo ví dụ trả lời mẫu: > *"Khi còn làm [ngành cũ], tôi từng gửi báo cáo cho sếp mà không kiểm tra lại số liệu cuối cùng vì tôi tự tin mình đã làm đúng. Hóa ra có một con số bị sai do copy-paste. Sếp phát hiện ra trước khách hàng — điều đó khiến tôi rất xấu hổ. Từ đó tôi tạo thói quen luôn có bước 'second check' độc lập trước khi gửi bất cứ thứ gì quan trọng. Tôi nghĩ kỹ năng kiểm tra kỹ lưỡng đó là một trong những lý do tôi tin mình phù hợp với nghề tester."* - *Lưu ý: Đây là ví dụ cho thấy bạn có thể dùng kinh nghiệm ngành cũ — đừng nghĩ chỉ vì bạn chưa làm IT là bạn không có ví dụ hay.* - [ ] Chuẩn bị 1-2 câu chuyện thật của bạn từ công việc hoặc cuộc sống cũ --- #### ❓ Câu 5: "Bạn tự học tester như thế nào? Bạn đã làm gì trong thời gian chuẩn bị?" - [ ] Hiểu lý do câu hỏi này được hỏi: - *Interviewer muốn biết: Bạn có chủ động học không, hay bị động chờ được dạy? Bạn có thật sự chuẩn bị hay chỉ nộp CV thử?* - [ ] Chuẩn bị câu trả lời bằng cách liệt kê cụ thể những gì bạn đã làm: - [ ] Tên khóa học / tài liệu đã học (ISTQB Foundation, Udemy, YouTube...) - [ ] Số bug report đã viết giả lập - [ ] App / website nào bạn đã practice test - [ ] Cộng đồng nào bạn tham gia để học hỏi - [ ] Project cá nhân nào bạn có (dù nhỏ) - [ ] Tham khảo ví dụ trả lời mẫu: > *"Trong 2 tháng qua, tôi đã học kiến thức nền qua khóa ISTQB Foundation online, đồng thời thực hành bằng cách tự test các app thực tế như Shopee và Grab, viết khoảng 20 bug report giả lập để quen với cấu trúc. Tôi cũng tham gia group Tester Việt Nam để đọc case study thật. Tôi biết mình vẫn còn thiếu kinh nghiệm thực tế, nhưng tôi đã chuẩn bị để có thể bắt đầu đóng góp từ ngày đầu và học nhanh nhất có thể trong môi trường thật."* --- ### 🎤 Phần 3.2 — Luyện Tập Phỏng Vấn Thực Tế - [ ] **Mock interview lần 1:** Nhờ bạn bè hỏi 5 câu trên, trả lời không nhìn notes — record lại video - *Tại sao: Nghe lại giọng mình mới nhận ra điểm cần cải thiện* - [ ] **Tự review video** theo checklist: - [ ] Tôi có dùng quá nhiều từ đệm không? (*"ừm", "thì là", "cái này nó"*) - [ ] Câu trả lời có cụ thể không hay quá chung chung? - [ ] Tôi có trả lời đúng điều họ hỏi không, hay lạc đề? - [ ] Thái độ có tự tin nhưng khiêm tốn không? - [ ] **Mock interview lần 2** sau khi đã chỉnh — so sánh với lần 1 - [ ] **Chuẩn bị 3 câu hỏi để hỏi ngược lại interviewer** (điều này cho thấy bạn chủ động và nghiêm túc): - *"Team tester hiện tại làm việc với dev theo quy trình như thế nào ạ?"* - *"Fresher tester thường cần bao lâu để có thể làm việc độc lập trong team?"* - *"Điều gì là thử thách lớn nhất mà team QA đang gặp phải?"* - [ ] **Chuẩn bị "Introduction 90 giây"** — nói về bản thân trong đúng 90 giây, đủ 4 phần: - Background cũ (ngắn, 15 giây) - Lý do chuyển ngành (cụ thể, 20 giây) - Những gì bạn đã chuẩn bị (chứng minh, 40 giây) - Mong muốn trong vị trí này (15 giây) - [ ] **Tập trả lời câu hỏi lương / negotiation cơ bản:** - *Khi được hỏi kỳ vọng lương: Nghiên cứu mức lương fresher tester tại thành phố bạn làm (ITviec, TopDev), đưa ra con số cụ thể hoặc range, không nói "tùy công ty"* --- ## 📊 BẢNG THEO DÕI TIẾN ĐỘ TỔNG QUAN | Giai đoạn | Số mục | Hoàn thành | % | |-----------|--------|------------|---| | Tuần 1-2: Foundation | ~25 mục | ___/25 | __% | | Tuần 3-4: Team Simulation | ~20 mục | ___/20 | __% | | Chuẩn bị phỏng vấn | ~20 mục | ___/20 | __% | | **Tổng** | **~65 mục** | **___/65** | **__%** | --- ## 💡 GHI NHỚ QUAN TRỌNG > **Cho người trái ngành — đây là lợi thế, không phải điểm yếu:** > > Bạn có thứ mà người học IT thẳng thường thiếu: **kinh nghiệm thực tế về góc nhìn người dùng cuối.** Người dùng không phải dev — họ là người như bạn trước đây. Hãy dùng điều đó. - 🔑 **Kỹ năng mềm không học một lần là xong** — checklist này là điểm bắt đầu, không phải đích đến - 🔑 **Mỗi ví dụ trả lời** trong file này chỉ là gợi ý — câu chuyện thật của bạn luôn tốt hơn - 🔑 **Nếu bạn stuck ở một mục** — đừng bỏ qua, hãy ghi chú "Cần hỏi/xem lại" và tiếp tục - 🔑 **Làm xong checklist này không phải để "học xong"** — mà để bạn bước vào môi trường thật với nền tảng đủ vững để học tiếp nhanh hơn --- *Checklist được tạo cho fresher tester chuyển ngành | Cập nhật và điều chỉnh theo tiến độ thực tế của bạn*