Tuần 1 - Tư Duy QC & Phân Tích

Không học để nhớ thuật ngữ. Học để nhìn một hệ thống bằng con mắt kiểm thử. Tuần 1 là tuần dựng nền cho toàn bộ chương trình QC System Training. Ở tuần này, học viên chưa cần chạy nhiều tool phức tạp, nhưng bắt buộc phải xây đúng cách nhìn: một màn hình không chỉ có field và button, mà còn có người dùng, dữ liệu, trạng thái, rule, permission và rủi ro. Nếu nền này không chắc, các tuần sau vẫn có thể tạo ra test case, bug report hoặc flow diagram, nhưng chất lượng sẽ mỏng, thiếu chiều sâu và rất dễ bỏ sót lỗi nghiệp vụ. Mục tiêu thật của tuần 1 là chuyển học viên từ trạng thái “đọc giao diện” sang trạng thái “đọc hệ thống”.

Nếu không vững requirement analysis, QC questioning và flow thinking ở tuần này, tuần 2 sẽ viết test case thiếu lực, các tuần workflow hoặc permission sẽ trở nên mơ hồ, và bài mini project cuối khóa sẽ chỉ đúng form chứ chưa đúng tư duy kiểm thử.

​

Snapshot

​

Mục Tiêu Tuần

​

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

Học viên cần hiểu QC không phải vai trò “đi test ở cuối”, mà là người quan sát hệ thống dưới góc nhìn rủi ro và tính đúng đắn của hành vi. Tuần này cũng đặt nền cho các khái niệm cốt lõi sẽ dùng suốt chương trình: SDLC, STLC, test types, requirement, validation, business rule, permission, workflow và flow nghiệp vụ. Hết tuần, học viên cần hiểu rõ:

• QC tạo giá trị cho team ở đâu trước, trong và sau khi development diễn ra.
• Requirement không chỉ là mô tả UI, mà là nguồn để bóc tách rule, hành vi và blind spot.
• Validation, business rule, permission và workflow là bốn lớp khác nhau, không thể gộp làm một.

​

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

Tuần 1 không kết thúc bằng “đã đọc xong”, mà kết thúc bằng khả năng làm được các tác vụ nền tảng:

• Đọc một màn hình hoặc user story và tách ra được actor, mục tiêu, input, output, trạng thái và rule.
• Đặt được câu hỏi QC có giá trị, thay vì chỉ hỏi những điều hiển nhiên trên UI.
• Vẽ được một flow nghiệp vụ đơn giản có decision point, flow phụ và flow lỗi.
• Diễn đạt được phân tích của mình thành output mà mentor có thể review và sử dụng tiếp.

​

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

Tư duy cốt lõi của tuần 1 là: mỗi chức năng đều là một phần của hệ thống đang vận hành, không phải một màn hình đứng riêng lẻ. QC tốt không dừng ở câu hỏi “bấm nút này có chạy không”, mà sẽ hỏi sâu hơn:

• Ai được làm thao tác này?
• Thao tác này chỉ hợp lệ ở trạng thái nào?
• Nếu dữ liệu sai hoặc trùng thì hệ thống phải xử lý ra sao?
• Sau khi thao tác xong, trạng thái nào đổi, dữ liệu nào đi tiếp, ai bị ảnh hưởng?

Đây là lớp tư duy quyết định chất lượng của test scenario và test case ở các tuần tiếp theo.

​

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

Phần lớn lỗi của QC mới không nằm ở chỗ thiếu tool, mà nằm ở chỗ đặt sai điểm nhìn. Người mới thường nhìn một tính năng như một tập thao tác UI, trong khi QC hệ thống phải nhìn nó như một tập hành vi có điều kiện, có vai trò, có dữ liệu và có hệ quả.

​

Những lỗi nền của QC mới

• Chỉ test happy path: vì không chủ động đặt câu hỏi về dữ liệu sai, trạng thái sai, role sai hoặc điều kiện ngoại lệ.
• Đọc requirement như mô tả giao diện: thấy field và button nhưng không thấy intent, rule, dependency và risk.
• Không phân biệt validation với business rule: test format rất kỹ nhưng bỏ sót logic nghiệp vụ thực sự quyết định hệ thống đúng hay sai.
• Không nhìn ra permission/workflow implication: thấy một nút Approve nhưng không hỏi ai được bấm, ở trạng thái nào mới được bấm, bấm xong kéo theo thay đổi gì.

​

Hậu quả nếu học hời hợt tuần này

• Sang tuần 2: test case sẽ biến thành danh sách click-fill-submit, thiếu tư duy kiểm thử.
• Sang tuần 3-4: khi chạm tới UI test và API test, học viên có thể đọc response nhưng không biết điều gì mới thật sự đáng ngờ.
• Sang tuần 6: workflow và permission sẽ trở thành vùng mù, vì học viên chưa quen nhìn trạng thái và quyền như các điều kiện kiểm thử.
• Sang tuần 8: output cuối khóa có thể đầy đủ file nhưng rời rạc, thiếu kết nối và thiếu giá trị review.

​

Một QC hệ thống phải nhìn cùng lúc nhiều lớp

Nếu học viên chưa nhìn ra sự khác biệt giữa các lớp này ở tuần 1, gần như chắc chắn sẽ test sai trọng tâm ở các tuần sau.

​

Kế Hoạch Theo Ngày

​

Ngày 01 - QC là gì?

Mục tiêu của ngày

• Định nghĩa đúng bản chất của QC trong bối cảnh hệ thống nội bộ.
• Phân biệt được QC, QA và Tester theo vai trò thực tế chứ không theo câu chữ sách vở.
• Hiểu QC tạo giá trị cho team từ rất sớm, không chỉ ở giai đoạn “vào test”.

Học gì

• QC là người quan sát hệ thống theo góc nhìn rủi ro, dữ liệu, hành vi và nghiệp vụ.
• QC hệ thống khác với kiểu kiểm thử bề mặt ở chỗ luôn gắn màn hình với quy trình và rule phía sau.
• QC tạo giá trị khi giúp team phát hiện lỗ hổng requirement, blind spot nghiệp vụ và rủi ro release từ sớm.

Thực hành

• Viết một note ngắn trả lời câu hỏi: QC hệ thống tạo giá trị ở đâu trong một dự án admin/ERP?
• Nêu 3 điểm khác nhau giữa “người click thử tính năng” và “QC có tư duy phân tích hệ thống”.
• Chọn 1 ví dụ lỗi production giả định và mô tả QC có thể giúp chặn lỗi đó từ giai đoạn nào.

Output cần nộp

• day01_qc_overview.md

Dấu hiệu đã hiểu

• Bạn giải thích được QC bằng ngôn ngữ công việc thật, không cần chép định nghĩa.
• Bạn nhắc được tới requirement, flow, risk, business logic hoặc user role.
• Bạn hiểu QC không chỉ “tìm bug”, mà còn giúp ngăn bug hình thành từ sớm.

Lỗi thường gặp

• Chép lại định nghĩa QC/QA/Tester từ Internet.
• Mô tả QC chỉ là người “đi test cuối quy trình”.
• Không nói tới giá trị phân tích requirement hoặc giảm blind spot cho team.

Mentor review note

• Hỏi: Nếu team không có QC ở giai đoạn review requirement, hậu quả đắt nhất sẽ xuất hiện ở đâu?
• Quan sát xem học viên nói về QC bằng logic dự án thật hay chỉ bằng từ khóa.

​

Ngày 02 - SDLC và STLC

Mục tiêu của ngày

• Hiểu SDLC và STLC như hai dòng chảy công việc có liên hệ nhưng không trùng nhau.
• Xác định được QC đang tham gia ở phase nào, với đầu ra gì và mục tiêu gì.
• Hình thành tư duy: testing bắt đầu từ lúc hiểu requirement, không phải từ lúc có build.

Học gì

• SDLC: Requirement -> Design -> Development -> Testing -> Release -> Maintenance.
• STLC: Analysis -> Planning -> Design -> Execution -> Report -> Closure.
• Artifact QC có thể tạo theo từng phase: note requirement, checklist câu hỏi, test case, bug report, test summary, retest note.

Thực hành

• Vẽ sơ đồ SDLC và STLC.
• Ghi chú dưới từng phase: QC làm gì, tạo output gì, và nếu vào quá muộn thì rủi ro gì phát sinh.
• So sánh nhanh: một bug bị phát hiện ở giai đoạn requirement khác gì với bug bị phát hiện lúc UAT.

Output cần nộp

• day02_sdlc_stlc.md
• day02_sdlc_stlc.png

Dấu hiệu đã hiểu

• Bạn không chỉ vẽ được chuỗi bước, mà còn nói rõ QC đóng góp gì ở từng bước.
• Bạn hiểu testing là hoạt động xuyên suốt, không phải “một box sau development”.
• Bạn lý giải được vì sao phát hiện lỗi càng sớm thì chi phí sửa càng thấp.

Lỗi thường gặp

• Vẽ sơ đồ đẹp nhưng không gắn vai trò QC.
• Gộp SDLC và STLC thành cùng một thứ.
• Bỏ qua report, retest và closure như thể testing chỉ có execute.

Mentor review note

• Hỏi: QC nên đặt câu hỏi mạnh nhất ở phase nào để giảm rework nhiều nhất?
• Kiểm tra học viên có đang hiểu lifecycle theo logic vận hành hay chỉ theo sơ đồ lý thuyết.

​

Ngày 03 - Các loại test cơ bản

Mục tiêu của ngày

• Phân biệt đúng từng loại test theo mục đích sử dụng.
• Không gọi tên test type theo thói quen mơ hồ.
• Biết cùng một chức năng có thể được nhìn qua nhiều lớp test khác nhau.

Học gì

• Functional test
• UI test
• Integration test
• System test
• Smoke test
• Sanity test
• Regression test
• UAT

Thực hành

• Dùng ví dụ màn hình Login hoặc Tạo nhân viên để mô tả từng loại test sẽ tập trung vào điều gì.
• Tạo 3 bug giả định và chỉ ra bug đó thường nên bị bắt ở lớp test nào.
• Viết 1 đoạn ngắn phân biệt smoke, sanity và regression bằng ngữ cảnh release thực tế.

Output cần nộp

• day03_test_types.md

Dấu hiệu đã hiểu

• Bạn giải thích được vì sao cùng một màn hình vẫn có thể được test dưới nhiều góc nhìn khác nhau.
• Bạn mô tả được mục tiêu của từng loại test, không chỉ lặp lại định nghĩa.
• Bạn dùng được ví dụ release/staging/UAT để minh họa.

Lỗi thường gặp

• Xem mọi bài test đều là functional test.
• Nhầm smoke với regression.
• Chỉ nói “test cái gì” mà không nói “test để quyết định điều gì”.

Mentor review note

• Hỏi: Một build vừa deploy lên staging thì em chọn smoke hay regression trước? Vì sao?
• Tìm xem học viên có thật sự hiểu intent của test type, hay chỉ nhớ tên.

​

Ngày 04 - Requirement là gì?

Mục tiêu của ngày

• Đọc requirement như một QC, không như một người đang xem giao diện.
• Tách requirement thành actor, mục tiêu, dữ liệu, rule, dependency và risk.
• Bắt đầu phân biệt rõ validation rule với business rule.

Học gì

• PRD, BRD, User Story, Acceptance Criteria.
• Mockup/Figma, flow chart, ghi chú nghiệp vụ.
• Cách bóc tách một màn hình thành các lớp phân tích QC: actor, precondition, input, output, validation, business rule, permission, dependency, open question.

Thực hành

• Chọn 1 màn hình như Login, Tạo nhân viên hoặc Tạo đơn.
• Phân tích theo khung:
  • Ai dùng?
  • Dùng để làm gì?
  • Điều kiện trước khi dùng là gì?
  • Input và output là gì?
  • Validation nào thuộc UI/data format?
  • Business rule nào quyết định hành vi thật?
  • Có permission hay dependency module nào liên quan?
  • Chỗ nào requirement còn mơ hồ?

Output cần nộp

• day04_requirement_analysis.md

Dấu hiệu đã hiểu

• Bạn không dừng ở liệt kê field UI.
• Bạn chỉ ra được ít nhất 1 business rule, 1 điểm mơ hồ và 1 câu hỏi cần hỏi lại.
• Bạn bắt đầu thấy màn hình gắn với role, trạng thái hoặc module khác.

Lỗi thường gặp

• Chỉ mô tả field và label.
• Gộp validation với business rule.
• Không chỉ ra dependency, open question hoặc risk.

Mentor review note

• Hỏi: Rule nào ở đây là validation, rule nào là business rule, và vì sao?
• Nếu output không có câu hỏi mở hoặc dependency, khả năng cao học viên mới đọc bề mặt.

​

Ngày 05 - Tư duy đặt câu hỏi như QC

Mục tiêu của ngày

• Hình thành phản xạ đặt câu hỏi trước khi viết test.
• Mở rộng góc nhìn từ UI sang rule, permission, workflow, duplicate, data consistency và failure handling.
• Hiểu rằng câu hỏi tốt là nền trực tiếp của test scenario và test case tốt.

Học gì

• Các nhóm câu hỏi QC cơ bản:
  • Input/validation
  • Duplicate/data consistency
  • Permission
  • Workflow/state transition
  • Side effect/notification/logging
  • Error handling/exception path

Thực hành

• Chọn 1 màn hình CRUD.
• Viết tối thiểu 30 câu hỏi QC.
• Phân loại câu hỏi theo nhóm: UI, validation, business rule, permission, workflow, data, exception.
• Chọn ra 10 câu hỏi quan trọng nhất và giải thích vì sao chúng có giá trị kiểm thử cao.

Output cần nộp

• day05_qc_questions_checklist.md

Dấu hiệu đã hiểu

• Câu hỏi của bạn không chỉ xoay quanh required field.
• Bạn đặt được câu hỏi về role, trạng thái, dữ liệu trùng, side effect hoặc hành vi sau submit.
• Bạn biết câu hỏi nào là critical, không chỉ liệt kê nhiều cho đủ số lượng.

Lỗi thường gặp

• Câu hỏi quá hiển nhiên hoặc chỉ cần nhìn UI là biết.
• Toàn bộ câu hỏi dồn vào validation field.
• Không hỏi gì về permission, workflow hoặc dữ liệu downstream.

Mentor review note

• Hỏi: Trong danh sách của em, 5 câu hỏi nào nếu được trả lời sớm sẽ giúp tránh bug production rõ nhất?
• Ưu tiên review chiều sâu câu hỏi hơn số lượng câu hỏi.

​

Ngày 06 - Phân tích flow nghiệp vụ

Mục tiêu của ngày

• Nhìn được một thao tác như một hành trình có điều kiện và trạng thái.
• Phân biệt main flow, alternate flow, exception flow và edge case.
• Hiểu flow analysis là nền cho workflow test và end-to-end test ở các tuần sau.

Học gì

• Main flow
• Alternate flow
• Exception flow
• Edge case
• Các thành phần nên có trong flow: actor, action, decision point, precondition, postcondition, state change, side effect

Thực hành

• Chọn flow Tạo tài khoản, Tạo nhân viên hoặc Gửi đơn.
• Vẽ flow từ lúc người dùng mở form đến lúc dữ liệu được lưu và phản hồi được trả về.
• Đánh dấu rõ:
  • bước nào cần validation,
  • bước nào có business rule,
  • bước nào có thể fail,
  • bước nào liên quan permission hoặc trạng thái.

Output cần nộp

• day06_business_flow.md
• day06_business_flow.png

Dấu hiệu đã hiểu

• Flow của bạn có decision point thật, không phải một đường thẳng.
• Bạn nhìn ra ít nhất 1 flow phụ và 1 flow lỗi.
• Bạn giải thích được nếu fail ở một điểm nào đó thì hệ thống và người dùng chịu tác động gì.

Lỗi thường gặp

• Chỉ vẽ flow chính, bỏ qua nhánh phụ và nhánh lỗi.
• Vẽ flow theo thao tác UI mà không có state hoặc rule.
• Không gắn actor hoặc điều kiện quyền vào flow.

Mentor review note

• Hỏi: Ở flow này, bước nào dễ phát sinh bug nghiêm trọng nhất và tại sao?
• Kiểm tra xem học viên có nhìn ra transition logic hay chỉ mô tả thao tác của người dùng.

​

Ngày 07 - Tổng kết tuần 1

Mục tiêu của ngày

• Kết nối toàn bộ nội dung tuần 1 thành một chuỗi tư duy hoàn chỉnh.
• Tự nhận diện điểm mạnh, điểm mù và lỗ hổng cần sửa trước khi sang tuần 2.
• Chuẩn bị nền cho phần scenario và test case bằng tư duy kiểm thử đúng.

Học gì

• Review lại toàn bộ output của tuần như một chuỗi liên thông:
  • hiểu QC,
  • hiểu lifecycle,
  • hiểu test types,
  • biết đọc requirement,
  • biết hỏi,
  • biết nhìn flow.
• Hiểu mối nối từ tuần 1 sang tuần 2: câu hỏi tốt và flow rõ sẽ tạo ra test scenario và test case tốt.

Thực hành

• Viết 1 trang tổng kết: tuần này mình đã xây được gì, còn yếu ở đâu, nếu sang tuần 2 ngay thì phần nào dễ hổng nhất.
• Tự tạo mini quiz 20 câu để kiểm tra lại mức hiểu.
• Rà lại output của tuần và chỉnh sửa 1 vòng nếu mentor đã feedback.

Output cần nộp

• week01_summary.md
• week01_quiz.md

Dấu hiệu đã hiểu

• Bạn có thể tự diễn đạt tuần 1 bằng logic của mình.
• Bạn chỉ ra được output nào yếu nhất và lý do tại sao.
• Bạn nói được rõ tuần 2 cần mang theo tư duy gì, không chỉ nói “học test case”.

Lỗi thường gặp

• Tổng kết bằng cách chép lại bullet của tài liệu.
• Quiz chỉ hỏi định nghĩa, không kiểm tra hiểu.
• Không dám chỉ ra điểm yếu thật của bản thân.

Mentor review note

• Hỏi: Nếu bắt đầu viết test case ngay bây giờ, em sẽ dễ viết hỏng ở chỗ nào nhất?
• Xem học viên có tự nhìn ra lỗ hổng nhận thức của mình hay không.

​

Deliverables Cần Nộp

​

KPI & Focus

​

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

• Hoàn thành 100% deliverable bắt buộc.
• week01_quiz.md đạt từ 80%.
• day04_requirement_analysis.md phải chỉ ra được ít nhất:
  • 1 business rule,
  • 1 dependency hoặc permission implication,
  • 3 câu hỏi mở cần làm rõ.
• day05_qc_questions_checklist.md phải có tối thiểu 30 câu hỏi, trong đó có nhóm permission hoặc workflow.
• day06_business_flow.* phải có ít nhất 1 nhánh phụ và 1 nhánh lỗi.

​

Focus của tuần

• Depth over quantity: ít output hơn nhưng phải có chiều sâu còn hơn nhiều file mỏng.
• Think before test: tuần này ưu tiên tư duy phân tích trước khi chạm vào kỹ thuật viết case.
• Use business language: diễn đạt theo logic hệ thống thật, tránh sao chép định nghĩa.
• Reviewable output: mọi output phải đủ rõ để mentor đọc là review được ngay.

​

Mini Rubric Cho Tuần 1

Strong = 3, Pass = 2, Need Improvement = 1 Điều kiện khuyến nghị để qua tuần: điểm trung bình từ 2.0 trở lên, không có tiêu chí trọng yếu nào ở mức Need Improvement, đặc biệt là Phân tích requirement, Đặt câu hỏi và Phân tích flow.

​

Common Mistakes

​

Mentor Review Guide

​

Mentor cần nhìn gì trước

• Học viên có đang nhìn hệ thống bằng logic kiểm thử hay chưa.
• Output có chạm tới rule, role, state, dependency và risk không.
• Câu hỏi học viên đặt ra có giúp ngăn bug production hay chỉ dừng ở các chi tiết UI hiển nhiên.
• Flow học viên vẽ có thực sự phản ánh hành vi hệ thống hay chỉ phản ánh thao tác người dùng.

​

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

• Màn hình này phục vụ ai và rủi ro lớn nhất của nó nằm ở đâu?
• Rule nào ở đây là validation, rule nào là business rule?
• Nếu user sai role vẫn vào được màn hình hoặc gọi API trực tiếp thì điều gì phải xảy ra?
• Flow này có thể fail ở bước nào và hậu quả lớn nhất là gì?
• Nếu viết test case cho màn hình này vào ngày mai, em sẽ bắt đầu từ insight nào của tuần 1?

​

Dấu hiệu học viên “học thuộc” và “đã hiểu”

​

Khi feedback nên tập trung vào điều gì trước

1. Sửa tư duy trước, sửa format sau.
2. Ưu tiên kéo học viên từ “mô tả UI” sang “phân tích rule và flow”.
3. Nếu học viên hỏi chưa sắc, hãy feedback vào chất lượng câu hỏi trước khi feedback hình thức output.
4. Chỉ ra đúng chỗ học viên đang nhìn nông, thay vì sửa câu chữ lan man.

​

Self-Check Cuối Tuần

Học viên nên tự tick checklist này trước khi nộp bài:

• Tôi đã hiểu QC hệ thống là vai trò nhìn rủi ro, rule và hành vi chứ không chỉ là đi test.
• Tôi có thể phân biệt SDLC và STLC bằng ngôn ngữ công việc thật.
• Tôi có thể lấy một ví dụ thực tế để giải thích smoke, sanity và regression.
• Tôi có thể đọc một màn hình và chỉ ra actor, mục tiêu, input, output và rule chính.
• Tôi có thể phân biệt validation rule và business rule trên cùng một chức năng.
• Tôi có thể đặt câu hỏi về permission, workflow, duplicate và side effect.
• Tôi có thể vẽ một flow đơn giản có flow chính, flow phụ và flow lỗi.
• Tôi biết output nào của mình còn yếu nhất và cần mentor feedback ở đâu.
• Tôi hiểu tuần 1 đang chuẩn bị gì cho phần scenario và test case ở tuần 2.

​

Mapping Review

• Requirement note, summary note và quiz: dùng khung chấm chung trong /evaluation/scoring-framework
• Self-review cuối tuần: dùng /templates/self-assessment-template
• Weekly mentor review: dùng /templates/weekly-assessment-template
• Checklist review của mentor: dùng /mentor-guide/review-checklist
• Quy tắc feedback: dùng /mentor-guide/feedback-rules

​

Kết Thúc Tuần

Sau tuần 1, điều giá trị nhất học viên mang theo không phải là một tập file đã nộp, mà là một cách nhìn mới về hệ thống. Bạn bắt đầu hiểu rằng đằng sau một field, một button, một popup hay một status luôn có rule, role, flow và dữ liệu cần được kiểm tra. Khi nền này đủ chắc, tuần 2 sẽ không còn là bài tập “viết test case cho đủ form”, mà trở thành bước đầu tiên của việc thiết kế kiểm thử một cách có chủ đích. Sang tuần 2, hãy mang theo 3 thứ:

• thói quen đọc requirement bằng logic QC,
• phản xạ đặt câu hỏi trước khi viết test,
• và kỷ luật luôn nhìn cả flow chính, flow phụ lẫn flow lỗi.

Nếu giữ được ba điều đó, tuần 2 sẽ đi đúng hướng ngay từ đầu.