Tuần 8 - Dự Án Cuối Khóa & Đánh Giá Readiness

Tuần cuối không đo bạn nhớ được bao nhiêu. Nó đo bạn có thể làm gì, chứng minh gì và sẵn sàng được giao việc ở mức nào. Tuần 8 là điểm tổng hợp của toàn bộ chương trình QC System Training. Đây không chỉ là tuần nộp bài cuối, mà là lúc học viên phải chứng minh mình có thể đọc requirement, tách flow, thiết kế test, thực thi kiểm thử, ghi nhận bug, verify dữ liệu, nhìn workflow hoặc permission khi scope cần, và kết thúc bằng một summary đủ trưởng thành để mentor ra quyết định readiness. Nếu không làm tốt tuần này, bạn có thể đã học khá nhiều kỹ thuật rời rạc nhưng vẫn chưa chứng minh được khả năng làm việc thật. Tuần 8 chính là nơi biến quá trình học thành năng lực có thể bàn giao task.

Final project là mô phỏng gần nhất với công việc thật. Readiness assessment không chỉ chấm bài, mà chấm khả năng làm, khả năng giải thích và khả năng được đưa vào team với mức giám sát phù hợp.

​

Snapshot

​

Mục Tiêu Tuần

​

1. Kiến thức cần huy động

Tuần này không dạy thêm một kỹ thuật mới tách biệt. Nó yêu cầu học viên huy động lại toàn bộ năng lực đã học từ Tuần 1 đến Tuần 7 và nối chúng thành một gói làm việc hoàn chỉnh. Học viên cần biết khi nào dùng requirement analysis, khi nào cần flow diagram, khi nào nên viết scenario hay test case chi tiết, khi nào cần API mapping, lúc nào cần verify DB hoặc workflow/permission, và cuối cùng phải biết tổng hợp thành summary có thể dùng để ra quyết định.

​

2. Kỹ năng cần chứng minh

Kết thúc tuần, học viên phải chứng minh được các kỹ năng có thể dùng ngay trong môi trường nội bộ:

• Chọn scope mini project đủ rõ để làm xong, đủ rộng để thể hiện năng lực.
• Tạo được test artifact có logic nối nhau, không rời rạc.
• Execute test có bằng chứng, log bug usable, verify bổ sung đúng chỗ.
• Viết final summary report có risk statement, không chỉ có số lượng bug.
• Trình bày được vì sao mình chọn flow, case, bug severity và vùng cần regression.

​

3. Tư duy cần thể hiện

Điểm quan trọng nhất của tuần 8 là tư duy làm việc có cấu trúc. Học viên phải cho thấy:

• mình hiểu scope đang làm tới đâu và cố ý bỏ qua phần nào;
• mình biết chọn đúng chỗ để đi sâu, không cố làm “mọi thứ một ít”;
• mình nhìn bài cuối như một gói giải quyết vấn đề chất lượng, không phải một tập file rời rạc;
• mình tự nhìn ra điểm yếu còn lại thay vì chờ mentor nói hết.

​

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

Tuần 8 là tuần quyết định readiness vì đây là nơi mentor không chỉ nhìn xem bạn “có làm bài không”, mà nhìn bạn có thể làm việc như một QC hệ thống ở mức nào. Một package tốt cho thấy học viên hiểu requirement, biết thiết kế test, biết execute, biết báo cáo và biết tự bảo vệ logic. Một package yếu thường vẫn có đủ file, nhưng khi nối lại thì không thành một câu chuyện chất lượng hoàn chỉnh.

​

Final project không phải là “làm cho đủ file”

Nhiều học viên tuần cuối rơi vào bẫy gom file:

• có requirement analysis nhưng không kéo sang flow;
• có test case nhưng không bám scenario;
• có bug report nhưng không thấy relation với scope đã test;
• có summary report nhưng không nói được release risk.

Final project tốt không được đánh giá bằng số file nhiều hay ít. Nó được đánh giá bằng việc các artifact có nối được với nhau và có chứng minh được năng lực làm việc thật hay không.

​

Readiness assessment chấm cái gì thật sự

Mentor đang nhìn learner qua 4 lớp: Nếu một trong bốn lớp này quá yếu, package vẫn có thể trông “đầy đủ” nhưng chưa đủ để qua gate.

​

Output đẹp không đồng nghĩa output usable

Một file trình bày đẹp nhưng:

• title mơ hồ,
• scope không rõ,
• expected result không chạy lại được,
• summary không có recommendation,

thì vẫn là file yếu. Tuần 8 buộc learner vượt qua thói quen “làm đẹp để bù logic”. Độ rõ và khả năng dùng được vẫn quan trọng hơn hình thức.

​

Biết kỹ thuật riêng lẻ chưa đủ

Đây là tuần kiểm tra xem bạn có ghép được những kỹ thuật đã học thành một gói làm việc thật không. Một learner có thể viết test case ổn ở tuần 2 hoặc log bug ổn ở tuần 3, nhưng nếu tuần 8 không nối được: scope -> flow -> scenario -> case -> execute -> bug -> summary thì vẫn chưa đạt độ trưởng thành cần thiết cho task thật.

​

Những lỗi người mới rất hay mắc ở tuần 8

• Làm nhiều file nhưng thiếu kết nối logic.
• Chọn scope quá lớn nên cuối cùng artifact nào cũng nửa vời.
• Chọn scope quá nhỏ nên không thể hiện được năng lực tổng hợp.
• Không ghi assumption nên mentor không biết bạn đang test theo giả định nào.
• Bug report yếu hơn phần test design.
• Final summary report không phản ánh risk thật.
• Không biết tự nói rõ mình đang mạnh ở đâu, yếu ở đâu.

​

Một final package tốt trông như thế nào

Một final package tốt thường có cấu trúc rõ theo các lớp:

1. Scope
2. Requirement & Assumptions
3. Flow
4. Scenario / Test Case
5. Execution & Bugs
6. API / DB / Workflow / Permission Evidence
7. Summary & Recommendation
8. Defense Readiness

Người review mở package ra phải nhìn được ngay bài toán là gì, bạn test thế nào, bạn tìm thấy gì, còn rủi ro gì, và bạn đang sẵn sàng ở mức nào.

​

Kế Hoạch Theo Ngày

​

Ngày 50 - Chọn Đề Tài Mini Project

Chủ đề: Chọn scope đủ để thể hiện năng lực, nhưng vẫn hoàn thành được trong thời gian còn lại Mục tiêu của ngày

• Chốt được một scope mini project rõ ràng.
• Tránh bẫy chọn quá lớn hoặc quá nhỏ.
• Xác định được critical flow đầu tiên của mini project.

Học gì / làm gì

• Chọn 1 đề tài như:
  • Login + User Management
  • Employee Management
  • Product Management
  • Leave Request Workflow
  • Order Management đơn giản
• Chốt phạm vi theo nguyên tắc:
  • có ít nhất 1 flow chính;
  • có 1-2 điểm đủ để thể hiện test design;
  • có chỗ để log bug, summary, và nếu phù hợp thì verify API/DB/workflow/permission;
  • không ôm quá nhiều module không kịp test.
• Ghi rõ đâu là in-scope, đâu là out-of-scope.

Output cần nộp

• day50_project_scope.md

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

• Bạn nói rõ module nào đang làm và vì sao chọn scope đó.
• Scope đủ để thể hiện năng lực tổng hợp, không phải một màn hình quá nhỏ.
• Bạn biết phần nào sẽ không làm và ghi rõ ngay từ đầu.

Lỗi thường gặp

• Scope quá lớn khiến ngày sau không thể đi sâu.
• Scope quá nhỏ nên không thể hiện được logic QC hệ thống.
• Không ghi out-of-scope, làm mentor khó đánh giá.

Mentor review note

• Hỏi: Vì sao em chọn scope này thay vì scope lớn hơn hoặc nhỏ hơn?
• Kiểm scope có đủ để đo readiness, nhưng không khiến learner vỡ kế hoạch.

​

Ngày 51 - Requirement Analysis

Chủ đề: Biến scope thành bài toán QC có cấu trúc Mục tiêu của ngày

• Phân tích actor, flow, rule, assumption và vùng rủi ro.
• Xác định critical path của mini project.
• Chốt requirement theo cách phục vụ test, không chỉ mô tả tính năng.

Học gì / làm gì

• Viết requirement analysis cho scope đã chọn.
• Ghi rõ:
  • actor chính;
  • flow chính và flow phụ;
  • assumption;
  • risk areas;
  • điều kiện đầu vào và đầu ra quan trọng.
• Tạo flow diagram hoặc flow note đủ để người khác theo logic của module.

Output cần nộp

• day51_project_analysis.md
• flow diagram export kèm trong package cuối tuần ở thư mục scope/

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

• Bạn không chỉ mô tả màn hình, mà mô tả được logic nghiệp vụ.
• Assumption được viết explicit, không để ẩn trong đầu.
• Flow chính và risk area đủ rõ để đi tiếp sang scenario.

Lỗi thường gặp

• Requirement analysis chỉ là bản chép lại UI.
• Không có assumption nên mọi thứ mơ hồ khi mentor review.
• Flow chưa rõ nên ngày 52 và 53 viết scenario/case rời rạc.

Mentor review note

• Hỏi: Nếu requirement thiếu chỗ này, em đang chọn assumption nào và vì sao?
• Kiểm learner có nhìn requirement như nguồn để ra quyết định test hay không.

​

Ngày 52 - Viết Test Scenarios

Chủ đề: Bao phủ scope theo logic flow và risk, không liệt kê rời Mục tiêu của ngày

• Tạo bộ scenario có cấu trúc theo flow/module.
• Bao phủ đúng các vùng chính, phụ và rủi ro cao.
• Tránh viết scenario theo kiểu checklist lỏng hoặc trùng lặp.

Học gì / làm gì

• Từ requirement analysis và flow, viết scenario theo nhóm:
  • happy path;
  • negative path;
  • alternate flow;
  • permission/workflow path nếu scope có.
• Gắn scenario với flow hoặc module cụ thể.
• Chỉ ra scenario nào sẽ cần viết test case chi tiết vào ngày 53.

Output cần nộp

• day52_project_scenarios.xlsx

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

• Scenario của bạn bám flow, không phải danh sách ý tưởng rời nhau.
• Bạn phân biệt được case nào chỉ cần scenario, case nào cần test case chi tiết.
• Coverage thể hiện đúng trọng tâm scope đã chọn.

Lỗi thường gặp

• Scenario trùng logic nhau nhưng khác wording.
• Scenario quá chi tiết thành test case trá hình.
• Coverage không bám critical flow đã chốt ở ngày 50-51.

Mentor review note

• Hỏi: Vì sao em chọn viết chi tiết flow này mà không phải flow kia?
• Kiểm learner có ưu tiên theo risk hay đang chia effort theo cảm tính.

​

Ngày 53 - Viết Test Cases

Chủ đề: Đi từ coverage khái quát sang artifact có thể chạy lại Mục tiêu của ngày

• Viết test case chi tiết cho phần scope chính.
• Expected result phải usable, không mơ hồ.
• Bám flow và assumption đã chốt từ ngày 51.

Học gì / làm gì

• Chọn các scenario quan trọng nhất để viết case.
• Viết rõ:
  • precondition;
  • steps;
  • test data;
  • expected result;
  • note nếu có dependency workflow/permission/API.
• Tránh viết full case cho mọi scenario nếu không cần; tập trung chiều sâu ở scope chính.

Output cần nộp

• day53_project_test_cases.xlsx

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

• Test case của bạn đủ để người khác chạy lại.
• Expected result không dùng câu mơ hồ kiểu “hệ thống đúng”.
• Case bám flow thật của mini project, không bị “generic hóa”.

Lỗi thường gặp

• Viết nhiều case nhưng không rõ cái nào critical.
• Expected result yếu hơn phần scenario.
• Test case không phản ánh assumption hoặc rule đã chốt.

Mentor review note

• Hỏi: Nếu chỉ giữ lại 30% số case này để chạy trước, em giữ case nào và vì sao?
• Kiểm learner có biết ưu tiên và có hiểu mình đang viết case để làm gì hay không.

​

Ngày 54 - Chuẩn Bị Test Data Và API Notes

Chủ đề: Chuẩn bị dữ liệu và mapping đủ để execution có bằng chứng thật Mục tiêu của ngày

• Chốt test data đủ để chạy flow chính.
• Nối UI action với API call hoặc data point quan trọng nếu scope có.
• Chuẩn bị nền để ngày 55 execute không bị đứt mạch.

Học gì / làm gì

• Tạo test data sheet bám flow.
• Viết API mapping/note cho những bước quan trọng:
  • request nào cần quan sát;
  • response nào cần verify;
  • field nào cần đối chiếu nếu có DB.
• Nếu scope không có API hoặc DB rõ ràng, ghi explicit out-of-scope.

Output cần nộp

• day54_project_test_data.xlsx
• day54_project_api_mapping.md

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

• Test data phục vụ đúng flow đã chọn.
• API notes không chỉ liệt kê endpoint, mà nói rõ đang verify gì.
• Bạn biết chỗ nào cần evidence bổ sung ngoài UI.

Lỗi thường gặp

• Test data không đủ điều kiện để chạy flow.
• API mapping rời requirement và case.
• Không nói rõ out-of-scope khi scope không có lớp verify bổ sung.

Mentor review note

• Hỏi: Ở flow này, nếu UI pass nhưng data backend sai thì em định phát hiện bằng đâu?
• Kiểm learner có nhìn data flow hay vẫn chỉ nhìn UI.

​

Ngày 55 - Execute Test Và Log Bug

Chủ đề: Biến artifact thiết kế thành bằng chứng kiểm thử thật Mục tiêu của ngày

• Chạy test có trọng tâm.
• Log bug usable cho dev và mentor.
• Gắn execution với scope và case đã thiết kế, không test cảm tính.

Học gì / làm gì

• Execute các flow, case và checkpoints quan trọng.
• Log bug với:
  • title rõ;
  • steps reproducible;
  • actual/expected rõ;
  • severity có lý do;
  • evidence tối thiểu.
• Nếu không có bug thật, có thể dùng bug mô phỏng nhưng phải dựa trên logic scope đang test.

Output cần nộp

• day55_project_bug_reports.xlsx

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

• Bug report usable và gắn đúng vào bài toán của mini project.
• Bạn biết bug nào là symptom, bug nào có thể là root issue.
• Bạn không test lan man ngoài scope đã chốt.

Lỗi thường gặp

• Bug report yếu hơn chất lượng test case.
• Bug title, actual, expected không sắc.
• Execute nhiều nhưng không có trace về case hoặc flow.

Mentor review note

• Hỏi: Bug này nếu đưa cho dev, họ có đủ để làm việc chưa?
• Kiểm bug set có phản ánh năng lực observe và reproduce thật hay không.

​

Ngày 56 - Permission / Workflow / DB Verify

Chủ đề: Gắn lớp verify sâu hơn vào đúng chỗ, không cố làm cho đủ Mục tiêu của ngày

• Verify thêm workflow, permission hoặc DB nếu scope thực sự có.
• Ghi rõ out-of-scope nếu module không cần lớp đó.
• Chứng minh learner biết dùng công cụ đúng chỗ, không “nhồi kỹ thuật”.

Học gì / làm gì

• Nếu scope có workflow:
  • kiểm state, transition, history hoặc notify.
• Nếu scope có permission:
  • kiểm role/action quan trọng trên UI hoặc API.
• Nếu scope có DB:
  • verify field, status, audit field hoặc soft delete khi cần.
• Nếu một lớp không có trong scope, ghi rõ lý do không test.

Output cần nộp

• day56_permission_workflow_db_notes.md

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

• Bạn dùng workflow/permission/DB vì nó có giá trị cho scope, không phải vì muốn đủ kỹ thuật.
• Notes nói rõ đã verify gì, phát hiện gì, và chỗ nào không áp dụng.
• Bạn phân biệt được evidence chính và evidence bổ sung.

Lỗi thường gặp

• Cố nhét workflow hoặc DB vào scope không cần thiết.
• Verify rất mỏng nhưng ghi như đã cover sâu.
• Không nói rõ out-of-scope làm mentor khó chấm.

Mentor review note

• Hỏi: Nếu bỏ lớp verify này đi, scope của em mất gì?
• Kiểm learner có biết chọn đúng depth thay vì khoe nhiều kỹ thuật.

​

Ngày 57 - Retest / Regression / Final Summary

Chủ đề: Khóa vòng test bằng risk statement và recommendation có trách nhiệm Mục tiêu của ngày

• Phân biệt rõ retest, regression và final summary.
• Tạo regression scope có logic impact.
• Viết final summary report đủ trưởng thành để lead đọc và ra quyết định.

Học gì / làm gì

• Nếu có bug fix giả lập hoặc bug loop, viết retest note ngắn.
• Xác định regression scope dựa trên vùng ảnh hưởng.
• Viết summary theo template với:
  • scope;
  • coverage;
  • defect picture;
  • key risks;
  • decision recommendation;
  • phần nào đã thực thi thật và phần nào chỉ ở mức note/evidence bổ sung.

Output cần nộp

• day57_final_summary_report.md

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

• Summary không chỉ có số lượng bug.
• Bạn nói được risk còn lại nếu release.
• Recommendation bám vào evidence, không theo cảm tính.

Lỗi thường gặp

• Không có risk statement.
• Regression scope chọn quá chung chung.
• Summary đẹp nhưng không usable cho người ra quyết định.

Mentor review note

• Hỏi: Nếu PM hỏi có nên release không, em trả lời thế nào và dựa trên đâu?
• Kiểm learner có đứng được ở góc nhìn chất lượng tổng thể hay chưa.

​

Ngày 58 - Đóng Gói Portfolio

Chủ đề: Chuyển toàn bộ quá trình tuần 8 thành một package review độc lập được Mục tiêu của ngày

• Đóng gói final package rõ ràng, có điều hướng.
• Đảm bảo mọi artifact mở ra là hiểu vai trò của nó.
• Sẵn sàng cho phần defense với mentor.

Học gì / làm gì

• Tạo week08_final_portfolio/ theo cấu trúc hợp lý.
• Bổ sung README.md nếu cần để điều hướng.
• Kiểm lại naming, link giữa artifact, evidence và summary.
• Chuẩn bị ngắn:
  • scope đã chọn;
  • logic test chính;
  • bug hoặc risk đáng chú ý nhất;
  • mức sẵn sàng hiện tại của bản thân.

Output cần nộp

• week08_final_portfolio/

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

• Package review độc lập được, không cần mentor tự đi đoán.
• Artifact nối logic với nhau.
• Bạn có thể giải thích nhanh 3-5 phút về mini project của mình.

Lỗi thường gặp

• Package chỉ là gom file, không có điều hướng.
• Thiếu artifact cốt lõi hoặc naming lộn xộn.
• Learner không tự nói được điểm mạnh, điểm yếu và lý do chọn scope.

Mentor review note

• Hỏi: Nếu em phải tự giới thiệu package này trong 3 phút, em sẽ nói theo thứ tự nào?
• Kiểm learner có thật sự sở hữu logic của package hay chỉ gom lại cho xong.

​

Deliverables Cần Nộp

​

KPI & Focus

• KPI Học Viên: Hoàn thành full package với artifact cốt lõi, final project đạt tối thiểu 70/100, và không còn blocker thuộc nhóm core competence.
• KPI Chất Lượng: Chuỗi scope -> flow -> scenario -> case -> execution -> bug -> summary phải nối logic với nhau.
• KPI Summary: day57_final_summary_report.md bắt buộc có Key Risks và Decision Recommendation.
• KPI Readiness: Learner phải bảo vệ được vì sao chọn scope, vì sao test flow đó, vì sao bug này đáng chú ý, và vì sao coverage bổ sung là đủ hoặc chưa đủ.
• Mentor Focus: Readiness không dựa vào số file hay độ đẹp trình bày, mà dựa vào tính usable, tính logic và khả năng làm việc có cấu trúc.

​

Mini Rubric Cho Tuần 8

Rubric dưới đây là bản tóm tắt để learner tự soi. Điểm chính thức vẫn bám theo Rubric Bảo Vệ Dự Án Cuối Khóa.

​

Strong vs Pass vs Need Improvement khác nhau ở đâu

• Strong: Package chặt, usable, defense rõ, mentor có thể nhìn thấy mức sẵn sàng cao hơn chỉ một bài nộp đúng mẫu.
• Pass: Đạt các năng lực cốt lõi, package đủ để giao việc có giám sát, nhưng vẫn còn vài điểm cần mentor kèm thêm.
• Need Improvement: Có output nhưng logic còn hở, evidence yếu hoặc chưa bảo vệ được lựa chọn QC.

​

Sau khóa học, học viên nên nhận loại task nào đầu tiên

​

Common Mistakes

​

Mentor Review Guide

​

Thứ tự review final package nên dùng

1. Scope + assumption
2. Flow + scenario/test case logic
3. Execution evidence + bug reports
4. Coverage bổ sung API / DB / workflow / permission
5. Final summary report
6. Defense / readiness

​

Mentor cần nhìn gì để xác định readiness

• Học viên có hiểu thật bài toán mình chọn không.
• Artifact có usable và nối logic với nhau không.
• Những phần learner bỏ qua có được ghi out-of-scope hợp lý không.
• Summary và defense có trưởng thành đủ để bước vào task thật chưa.

​

Câu hỏi nên hỏi để phân biệt làm theo mẫu hay hiểu thật

• Vì sao em chọn scope này mà không chọn rộng hơn?
• Flow nào là critical nhất và vì sao?
• Nếu có thêm 2 giờ, em sẽ test phần nào tiếp theo?
• Bug nào trong bộ bug của em đáng quan tâm nhất và vì sao?
• Phần nào em cố ý không cover và lý do là gì?
• Nếu giao em task thật sau khóa, em thấy mình phù hợp mức nào và cần mentor hỗ trợ gì?

​

Dấu hiệu nên giao supervised tasks vs simple independent tasks

• Supervised tasks: Artifact usable nhưng learner còn phụ thuộc mentor ở prioritization, risk statement hoặc defense depth.
• Simple independent tasks: Artifact rõ, case và bug usable, summary có góc nhìn chất lượng, learner tự giải thích được đa số quyết định.

​

Feedback nên ưu tiên gì sau buổi review

1. Sai logic hoặc sai scope
2. Thiếu artifact cốt lõi hoặc thiếu evidence
3. Summary / defense chưa trưởng thành
4. Format, naming và độ gọn của package

​

Self-Check Cuối Tuần

• Tôi có thể giải thích scope mini project của mình trong 2-3 phút.
• Requirement, flow, scenario, test case, bug và summary của tôi có nối logic với nhau.
• Tôi có thể nói vì sao mình chọn test case này thay vì test case khác.
• Bug report của tôi đủ usable cho dev hoặc mentor review lại.
• Tôi đã dùng API / DB / workflow / permission đúng chỗ, hoặc ghi rõ vì sao out-of-scope.
• Final summary của tôi có Key Risks và Decision Recommendation.
• Tôi nhìn ra được điểm mạnh và điểm yếu còn lại của mình.
• Tôi có thể tự đánh giá mình đang phù hợp mức A, B hay C và nêu được lý do.

​

Mapping Review

• Test case template: /templates/test-case-template
• Bug report template: /templates/bug-report-template
• Workflow / permission templates: /templates/workflow-matrix-template, /templates/permission-matrix-template
• Test summary template: /templates/test-summary-template
• Final package contract: /learner-guide/portfolio-guide
• Final project rubric: /evaluation/final-project-rubric
• Graduation & readiness gate: /program/graduation-and-readiness
• Final readiness checklist: /mentor-guide/final-readiness-checklist

​

Kết Thúc Tuần

Tuần 8 là nơi xác nhận bạn đã đi được từ việc học từng kỹ thuật riêng lẻ sang khả năng xử lý một bài toán QC có cấu trúc. Sau 8 tuần, điều giá trị nhất không phải là số file bạn tạo ra, mà là việc bạn có thể nhìn một module, bóc tách được scope, thiết kế test hợp lý, execute có evidence, log bug usable, viết summary có trách nhiệm và nói rõ mức sẵn sàng của mình. Khi bước vào dự án thật, hãy giữ mindset này: làm có cấu trúc, chọn đúng trọng tâm, nói bằng evidence, và luôn biết mình đang bảo vệ chất lượng ở đâu.