Tuần 2 - Test Scenario & Test Case

Không học để điền form test case. Học để biến requirement thành test artifact có giá trị thực tế. Tuần 2 là tuần chuyển từ phân tích sang thiết kế kiểm thử. Nếu tuần 1 giúp học viên nhìn ra actor, rule, flow và rủi ro, thì tuần 2 buộc học viên biến phần nhìn thấy đó thành artifact mà mentor, BA hoặc người test khác có thể đọc, review và chạy lại được. Đây là lần đầu tiên trong chương trình học viên tạo ra “sản phẩm kiểm thử” đúng nghĩa: scenario để bao quát nghiệp vụ, test case để hướng dẫn thực thi và checklist để rà nhanh theo phạm vi phù hợp. Nếu làm tuần này hời hợt, học viên rất dễ viết ra những bộ test case dài nhưng rỗng, nhiều dòng nhưng thiếu trọng tâm, và chỉ bao phủ happy path mà bỏ quên negative hoặc edge cases.

Nếu không vững tuần này, học viên sẽ viết test case như đang điền biểu mẫu: đủ cột nhưng không đủ tư duy, đủ số lượng nhưng không đủ giá trị 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 rõ ba artifact thường bị dùng lẫn lộn:

• Scenario dùng để bao quát nghiệp vụ và các hướng kiểm thử chính.
• Test case dùng để mô tả cách kiểm thử có thể thực thi và tái chạy.
• Checklist dùng để rà nhanh hoặc bao phủ phạm vi đơn giản ở mức khái quát.

Ngoài ra, tuần này còn giúp học viên hiểu cấu trúc một test case tốt, hiểu các lỗi phổ biến trong test design và nắm được các kỹ thuật nền như Equivalence Partitioning, Boundary Value Analysis, Decision Table và State Transition.

​

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 môi trường công ty:

• Chuyển requirement hoặc màn hình thành danh sách scenario có logic bao phủ rõ ràng.
• Viết test case đủ cụ thể để người khác có thể execute lại.
• Viết expected result theo kiểu có thể kiểm được bằng UI, message, state hoặc data outcome.
• Chọn khi nào nên dùng checklist thay vì test case chi tiết.
• Thiết kế bộ case cho một module CRUD đơn giản mà không trùng lặp quá mức và không bỏ hở scope quan trọng.

​

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

Tuần 2 không dạy tư duy “viết càng nhiều case càng tốt”, mà dạy tư duy thiết kế kiểm thử có chủ đích:

• Mỗi artifact phải phục vụ một mục tiêu rõ ràng.
• Mỗi test case phải giúp kiểm chứng một rủi ro, một rule hoặc một hành vi.
• Coverage tốt không phải là viết dài, mà là viết đúng và đủ.
• Artifact tốt là artifact người khác đọc được, review được và dùng lại được.

Đây là bước chuyển rất quan trọng từ “nghĩ trong đầu” sang “thiết kế kiểm thử thành tài sản dùng chung”.

​

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

Tuần 2 là tuần đầu tiên học viên tạo ra đầu ra kiểm thử có thể được review như một sản phẩm thật. Từ thời điểm này trở đi, chất lượng test design không chỉ ảnh hưởng đến bài tập tuần hiện tại, mà còn ảnh hưởng trực tiếp đến cách học viên test UI, API, workflow, permission và mini project ở các tuần sau.

​

Đây là tuần tạo ra artifact đầu tiên có thể review thật

Requirement note của tuần 1 cho thấy học viên có biết phân tích hay không. Nhưng sang tuần 2, mentor không chỉ nhìn tư duy, mà còn nhìn khả năng chuyển tư duy thành tài liệu có thể dùng được. Một scenario kém sẽ dẫn tới scope kém. Một test case kém sẽ dẫn tới execution kém. Một checklist kém sẽ khiến người review không biết đã bao phủ gì và chưa bao phủ gì.

​

Chất lượng test case sẽ quyết định chất lượng test execution về sau

Rất nhiều QC mới tưởng rằng viết test case là phần “hành chính” trước khi test. Đó là cách hiểu sai. Test case chính là nơi chất lượng tư duy kiểm thử được bộc lộ rõ nhất:

• Nếu step mơ hồ, execution sẽ lệch.
• Nếu expected result không đo được, Pass/Fail sẽ thành cảm tính.
• Nếu case trùng lặp hoặc hở scope, execution càng nhiều càng lãng phí.
• Nếu scenario và checklist dùng sai chỗ, cả bộ test trở nên khó review và khó bảo trì.

​

Nếu tuần 2 yếu, các tuần sau sẽ lệch từ gốc

• Tuần UI / Bug report: không biết điều gì đáng test trước, điều gì đáng log thành bug.
• Tuần API: biết gọi request nhưng không biết thiết kế case đủ chiều sâu.
• Tuần workflow / permission: khó bao phủ transition, role-state-action vì chưa quen tư duy coverage.
• Mini project cuối khóa: có nhiều file nhưng không có kiến trúc test rõ ràng.

​

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

• Viết scenario giống test case, tức là quá chi tiết và mất vai trò bao quát.
• Viết test case quá ngắn nên không ai execute lại được.
• Viết test case quá dài nhưng vẫn mơ hồ, vì step và expected result không rõ.
• Dùng expected result kiểu Hệ thống hoạt động đúng.
• Không phân biệt case chính với case lặp.
• Bỏ sót negative case, boundary case hoặc alternate flow.
• Dùng checklist cho chỗ cần test case chi tiết, hoặc ngược lại.

Tuần này có ý nghĩa vì nó rèn một kỷ luật quan trọng: thiết kế test phải rõ mục tiêu, rõ phạm vi và rõ khả năng thực thi.

​

Scenario vs Test Case vs Checklist

Scenario, test case và checklist không phải ba tên gọi khác nhau cho cùng một thứ. Chúng là ba công cụ khác nhau để phục vụ ba nhu cầu khác nhau. Dùng lẫn lộn là một trong những nguồn gốc lớn nhất của test design yếu.

​

Một Test Case Tốt Trông Như Thế Nào

Một test case tốt không cần nhiều câu chữ, nhưng bắt buộc phải có các yếu tố sau:

• Rõ mục tiêu: đọc title là hiểu đang kiểm gì.
• Rõ điều kiện trước: biết cần trạng thái, role hay dữ liệu gì trước khi chạy.
• Step đủ cụ thể: người khác có thể thực hiện lại mà không phải đoán.
• Expected result kiểm được: xác nhận bằng UI, message, state, redirect, record hoặc data outcome.
• Không dư chữ: không kể lể điều hiển nhiên, không nhồi nhiều mục tiêu vào một case.
• Không phụ thuộc người viết: người review hoặc tester khác vẫn hiểu và chạy được.

Test case yếu thường có đủ cột nhưng thiếu khả năng sử dụng.

​

Expected Result Tốt vs Expected Result Yếu

Expected result mạnh giúp việc chấm Pass / Fail bớt cảm tính và làm bug report sau này sắc hơn.

​

Bao Phủ Test Như Một QC Mới Nên Nghĩ

Khi bắt đầu thiết kế test, đừng nghĩ theo kiểu “điền cho đủ các cột”. Hãy nghĩ theo các lớp bao phủ:

• Happy path: người dùng làm đúng, dữ liệu đúng, hệ thống chạy đúng.
• Negative path: dữ liệu sai, thiếu dữ liệu, credential sai, role sai, action không hợp lệ.
• Boundary: min/max length, min/max value, ngày đầu/cuối, số lượng sát ngưỡng.
• Alternate flow: user đi một nhánh khác nhưng vẫn hợp lệ.
• Permission implication: role nào thấy được gì, làm được gì, không được làm gì.
• Duplicate / invalid input / empty state: dữ liệu trùng, dữ liệu không hợp lệ, không có kết quả, không có record.

Coverage tốt không phải là thêm case ngẫu nhiên. Coverage tốt là biết vì sao case này tồn tại và nó đang bảo vệ rủi ro gì.

​

Khi Nào Checklist Đủ, Khi Nào Phải Viết Test Case Chi Tiết

Checklist mạnh ở tốc độ. Test case mạnh ở khả năng execute và trace. Dùng sai công cụ sẽ làm bài vừa dài vừa yếu.

​

Kế Hoạch Theo Ngày

​

Ngày 08 - Test Scenario là gì?

Chủ đề: Từ requirement sang phạm vi kiểm thử ở mức nghiệp vụ Mục tiêu của ngày

• Hiểu scenario là lớp bao quát nghiệp vụ, không phải tập steps chi tiết.
• Nhận ra một màn hình có thể có nhiều hướng kiểm thử khác nhau.
• Tránh ngộ nhận “scenario càng chi tiết càng tốt”.

Học gì

• Scenario mô tả cái gì cần kiểm, theo luồng hoặc nhóm hành vi nào.
• Scenario nên chạm tới happy path, negative path, alternate flow và risk chính.
• Mối quan hệ giữa scenario và test case: scenario định hướng coverage, test case triển khai coverage thành artifact có thể execute.

Thực hành gì

• Với màn hình Login, viết tối thiểu 10 scenario.
• Chia scenario theo nhóm:
  • đăng nhập thành công,
  • validation,
  • credential sai,
  • trạng thái account,
  • permission hoặc redirect,
  • session/security cơ bản.
• Chọn 3 scenario và giải thích vì sao đó là ba nhóm rủi ro chính.

Output cần nộp

• day08_login_scenarios.xlsx

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

• Scenario của bạn đọc vào là hiểu phạm vi kiểm thử, không cần nhìn từng click.
• Bạn không viết scenario thành Nhập email -> nhập password -> bấm login.
• Bạn có cả positive và negative scenario, không chỉ một nhóm thành công.

Lỗi thường gặp

• Viết scenario quá chi tiết thành test case trá hình.
• Viết scenario quá rộng kiểu Test login.
• Không tách được nhóm validation, auth và account state.

Mentor review note

• Hỏi: Scenario nào ở đây là nhóm nghiệp vụ, scenario nào đang bị tụt xuống mức step?
• Kiểm tra xem học viên có đang map scope test hay đang liệt kê thao tác.

​

Ngày 09 - Test Case Structure

Chủ đề: Xây khung test case có thể review và execute lại Mục tiêu của ngày

• Hiểu từng cột trong template test case dùng để làm gì.
• Phân biệt đâu là title tốt, precondition đúng, step đủ và expected result có thể assert.
• Xóa ngộ nhận “có template là tự nhiên có test case tốt”.

Học gì

• Cấu trúc cột chuẩn:
  • Test Case ID
  • Module / Feature
  • Title
  • Priority
  • Preconditions
  • Test Data
  • Steps
  • Expected Result
  • Actual Result
  • Status
  • Tester & Date
  • Note / Link Bug
• Vai trò của từng cột trong review, execute, retest và trace lại bug.
• Vì sao Preconditions, Test Data và Expected Result là ba vùng người mới hay viết yếu nhất.

Thực hành gì

• Tạo file template test case bằng Sheets/Excel.
• Điền thử 3 dòng mẫu cho Login:
  • đăng nhập thành công,
  • sai mật khẩu,
  • bỏ trống email.
• Tự review lại từng dòng xem người khác có thể chạy lại không.

Output cần nộp

• test_case_template.xlsx

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

• Bạn giải thích được lý do tồn tại của từng cột, không chỉ chép mẫu.
• Title đủ rõ mục tiêu test.
• Preconditions và Test Data đủ để người khác biết cần chuẩn bị gì.

Lỗi thường gặp

• Template đẹp nhưng cột thiếu logic review hoặc execute.
• Gộp nhiều mục tiêu vào một title.
• Bỏ trống precondition vì nghĩ “ai cũng hiểu”.

Mentor review note

• Hỏi: Nếu đưa file này cho người chưa tham gia buổi học, họ có chạy lại được không?
• Kiểm tra xem học viên hiểu template như công cụ thực thi hay chỉ là form điền thông tin.

​

Ngày 10 - Viết Test Case Cho Login

Chủ đề: Từ scenario sang test case có thể chạy lại Mục tiêu của ngày

• Viết được test case cho một flow quen thuộc nhưng nhiều lớp rủi ro.
• Bao phủ được happy path, validation, auth failure, account state và redirect cơ bản.
• Tránh hai cực: quá ngắn không chạy được, quá dài nhưng vẫn mơ hồ.

Học gì

• Cách chuyển từng scenario thành test case cụ thể.
• Cách viết step vừa đủ chi tiết.
• Cách viết expected result theo logic quan sát được:
  • UI message,
  • redirect,
  • session behavior,
  • trạng thái tài khoản hoặc quyền truy cập.

Thực hành gì

• Viết tối thiểu 20 test case cho màn hình Login.
• Bắt buộc bao phủ:
  • login thành công,
  • required field,
  • email format,
  • sai password,
  • sai email,
  • account locked/inactive,
  • session hết hạn hoặc redirect sau login,
  • remembered state cơ bản nếu có.
• Tự đánh dấu xem case nào là positive, negative, boundary hoặc security-related.

Output cần nộp

• day10_login_test_cases.xlsx

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

• Step của bạn có thể giao cho người khác chạy mà không cần giải thích thêm.
• Expected result không dùng các cụm như đúng, thành công, hợp lệ một cách mơ hồ.
• Bạn không viết 5 case chỉ khác mỗi test data mà không có giá trị phân biệt.

Lỗi thường gặp

• Steps gộp nhiều hành động một dòng.
• Expected result quá mơ hồ, không có điểm quan sát.
• Chỉ viết validation UI, bỏ qua account state hoặc session behavior.

Mentor review note

• Chọn ngẫu nhiên 3 case và thử tưởng tượng giao cho tester khác execute. Chỗ nào phải hỏi lại thì case đó chưa đạt.
• Hỏi: Case này đang bảo vệ rule nào hoặc rủi ro nào?

​

Ngày 11 - Kỹ Thuật Thiết Kế Test Case

Chủ đề: Dùng kỹ thuật test design để giảm cảm tính Mục tiêu của ngày

• Hiểu các kỹ thuật nền không phải để học thuộc, mà để thiết kế case có logic.
• Biết dùng đúng kỹ thuật cho đúng loại bài toán.
• Vượt qua ngộ nhận “cứ nghĩ thêm case là coverage sẽ tốt”.

Học gì

• Equivalence Partitioning: gom dữ liệu thành nhóm tương đương để tránh test dư.
• Boundary Value Analysis: tập trung vào giá trị sát ngưỡng.
• Decision Table: mô tả logic nhiều điều kiện kết hợp.
• State Transition: mô tả hành vi thay đổi theo trạng thái.

Thực hành gì

• Áp dụng 4 kỹ thuật vào form Tạo tài khoản.
• Với mỗi kỹ thuật, ghi rõ:
  • dùng để xử lý loại rủi ro nào,
  • ví dụ case nào được sinh ra,
  • nếu không dùng kỹ thuật này thì dễ miss gì.
• Chuyển ít nhất 2 insight từ mỗi kỹ thuật thành đề xuất case cụ thể.

Output cần nộp

• day11_test_design_techniques.md

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

• Bạn không chỉ định nghĩa kỹ thuật, mà áp nó được vào form thật.
• Bạn giải thích được vì sao boundary quan trọng hơn việc random test nhiều giá trị.
• Bạn biết decision table hoặc state transition dùng khi nào.

Lỗi thường gặp

• Ghi lại định nghĩa lý thuyết nhưng không áp vào màn hình cụ thể.
• Dùng sai kỹ thuật cho sai bài toán.
• Tạo ví dụ quá đơn giản nên không thể hiện được giá trị của kỹ thuật.

Mentor review note

• Hỏi: Nếu em chỉ được chọn 1 kỹ thuật để test form này trong thời gian ngắn, em chọn gì và vì sao?
• Xem học viên có hiểu kỹ thuật như công cụ ra quyết định hay chỉ là mục lý thuyết.

​

Ngày 12 - Checklist Testing

Chủ đề: Dùng checklist đúng chỗ, đủ lực nhưng không lạm dụng Mục tiêu của ngày

• Hiểu checklist không phải test case rút gọn.
• Biết khi nào checklist là đủ, khi nào checklist là quá yếu.
• Viết checklist có khả năng review, không phải bullet list chung chung.

Học gì

• Checklist mạnh trong các bài kiểm tra nhanh, scope đơn giản hoặc lặp lại.
• Checklist yếu khi feature có nhiều rule, nhiều trạng thái hoặc cần trace rõ expected behavior.
• Checklist tốt phải có phạm vi rõ, câu kiểm rõ và tránh các dòng kiểu Kiểm tra hệ thống hoạt động đúng.

Thực hành gì

• Viết checklist test cho màn hình Danh sách nhân viên.
• Bao phủ các nhóm:
  • load list,
  • empty state,
  • search,
  • filter,
  • sort,
  • pagination,
  • action button visibility cơ bản.
• Với mỗi nhóm, tự đánh dấu chỗ nào nếu scope tăng lên thì phải nâng từ checklist sang test case.

Output cần nộp

• day12_employee_list_checklist.md

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

• Checklist của bạn rõ phạm vi và có thể dùng để rà nhanh.
• Bạn không viết checklist thành test case chi tiết.
• Bạn biết nêu giới hạn của checklist trên chính feature đó.

Lỗi thường gặp

• Checklist quá chung chung nên đọc xong không biết phải kiểm gì.
• Checklist dài như test case nhưng vẫn không có expected result rõ.
• Dùng checklist cho chỗ có nhiều business rule.

Mentor review note

• Hỏi: Vì sao chỗ này checklist là đủ? Tại sao không cần full test case?
• Kiểm tra khả năng tự nhận diện giới hạn của checklist.

​

Ngày 13 - Viết Test Case Cho CRUD

Chủ đề: Thiết kế bộ test có phạm vi rộng hơn một form đơn lẻ Mục tiêu của ngày

• Viết bộ test case cho một module CRUD đơn giản theo logic module thật.
• Học cách tránh trùng case khi scope bắt đầu rộng.
• Bao phủ create, read, update, delete và các hành vi đi kèm như search, filter, sort, pagination.

Học gì

• Cách chia module CRUD thành nhóm hành vi:
  • create,
  • read/list,
  • update,
  • delete,
  • search/filter,
  • sort/pagination,
  • permission hoặc visibility cơ bản.
• Cách gom case theo risk và feature slice để dễ review.
• Cách giữ balance giữa coverage và maintainability.

Thực hành gì

• Chọn một module Product hoặc Employee.
• Viết bộ test case cho module đó.
• Bắt buộc có:
  • positive flow,
  • validation quan trọng,
  • duplicate hoặc uniqueness nếu có,
  • empty state,
  • search/filter/sort/pagination,
  • ít nhất 1 nhóm case liên quan permission hoặc visibility nếu feature có role.

Output cần nộp

• day13_crud_test_cases.xlsx

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

• Bộ case của bạn có cấu trúc rõ theo nhóm nghiệp vụ.
• Bạn tránh được tình trạng 10 case gần như lặp nhau chỉ đổi dữ liệu.
• Bạn nhìn được module như một tập hành vi liên kết, không phải từng field rời rạc.

Lỗi thường gặp

• Dồn quá nhiều case vào create, bỏ quên list/search/filter/delete.
• Viết case trùng giữa validation và business rule.
• Không tách case theo nhóm nên mentor rất khó review.

Mentor review note

• Hỏi: Trong bộ CRUD này, nhóm case nào là bắt buộc nếu chỉ có 1 giờ test? Vì sao?
• Xem học viên có đang hiểu ưu tiên kiểm thử hay chỉ viết theo cảm giác.

​

Ngày 14 - Tổng Kết Tuần 2

Chủ đề: Đóng gói test artifact thành một package có thể review thật Mục tiêu của ngày

• Kết nối scenario, test case và checklist thành một bộ test design hoàn chỉnh.
• Tự review xem artifact nào đang thừa, artifact nào đang hở.
• Chuẩn bị nền để sang các tuần thực thi test UI, API và database.

Học gì

• Mối liên hệ:
  • scenario định hướng coverage,
  • test case hướng dẫn execute,
  • checklist hỗ trợ rà nhanh và sanity.
• Cách trình bày package để mentor đọc và review hiệu quả.

Thực hành gì

• Chọn 1 module CRUD đơn giản.
• Tạo đủ:
  • scenario tổng quát,
  • test case chi tiết,
  • checklist rà nhanh,
  • ghi chú ngắn về logic coverage hoặc điểm cần mentor xem kỹ.
• Tự kiểm tra:
  • có case nào trùng,
  • có rule nào chưa chạm,
  • expected result nào còn mơ hồ,
  • có phần nào đang dùng checklist sai chỗ không.

Output cần nộp

• week02_crud_package/

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

• Package của bạn thể hiện được kiến trúc test chứ không chỉ là tập file rời rạc.
• Bạn giải thích được vì sao phần nào dùng scenario, phần nào dùng test case, phần nào chỉ cần checklist.
• Bạn tự chỉ ra được ít nhất 2 điểm còn yếu trước khi mentor comment.

Lỗi thường gặp

• Nộp đủ file nhưng ba artifact không liên kết với nhau.
• Dùng checklist để thay cho test case ở vùng có rule phức tạp.
• Có quá nhiều case trùng nhau nhưng vẫn bỏ sót boundary hoặc permission implication.

Mentor review note

• Hỏi: Nếu giao package này cho một QC khác tiếp quản, họ có hiểu ngay coverage strategy của em không?
• Đánh giá package ở góc độ dùng được trong team, không chỉ ở góc độ “có nộp đủ file hay chưa”.

​

Deliverables Cần Nộp

​

KPI & Focus

​

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

• Hoàn thành 100% deliverable bắt buộc.
• day08_login_scenarios.xlsx có tối thiểu 10 scenario, không viết ở mức steps chi tiết.
• day10_login_test_cases.xlsx có tối thiểu 20 test case, bao phủ:
  • happy path,
  • required field,
  • invalid format,
  • sai credential,
  • account state cơ bản,
  • ít nhất 1 nhóm case liên quan redirect/session/security cơ bản nếu feature có.
• day13_crud_test_cases.xlsx phải bao phủ create, read/list, update, delete, search/filter, sort/pagination.
• week02_crud_package/ phải thể hiện rõ phần nào là scenario, phần nào là test case, phần nào là checklist.
• Không có tiêu chí trọng yếu nào ở mức Need Improvement, đặc biệt là:
  • phân biệt artifact,
  • chất lượng expected result,
  • coverage,
  • step clarity.

​

Focus của tuần

• Design for execution: viết để người khác chạy được, không phải để bản thân người viết tự hiểu.
• Coverage over volume: ít case hơn nhưng rõ risk còn hơn nhiều case trùng nhau.
• Assertable expected result: mọi kết quả kỳ vọng phải quan sát hoặc kiểm chứng được.
• Right artifact for the right scope: scenario, test case và checklist phải được dùng đúng chỗ.

​

Mini Rubric Cho Tuần 2

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 bị rơi xuống Need Improvement.

​

Common Mistakes

​

Mentor Review Guide

​

Mentor cần nhìn gì khi review scenario

• Scenario có đang đứng ở đúng mức nghiệp vụ hay đã rơi xuống step-level.
• Scenario có đủ nhóm rủi ro chính không: happy path, negative path, alternate flow, account state hoặc permission implication cơ bản.
• Tên scenario có đủ rõ để đọc vào là hiểu mục tiêu kiểm thử không.

​

Mentor cần nhìn gì khi review test case

• Title có mô tả đúng mục tiêu test không.
• Preconditions, test data và steps có đủ để người khác execute lại không.
• Expected result có thể assert được không.
• Case có đang trùng nhau không.
• Coverage có bị nặng happy path và nhẹ negative/boundary không.

​

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

• Checklist có được dùng đúng chỗ không.
• Từng item có đủ rõ để rà nhanh không.
• Checklist có bị biến thành danh sách quá chung chung hoặc quá chi tiết không.
• Học viên có nhận ra giới hạn của checklist trên feature đang làm không.

​

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

• Vì sao em chọn viết scenario cho phần này thay vì nhảy thẳng sang test case?
• Nếu phải bỏ bớt 20% số case, em sẽ bỏ những case nào và giữ lại những case nào?
• Expected result nào trong file của em hiện còn yếu nhất?
• Checklist này đủ ở đâu và không đủ ở đâu?
• Case nào ở đây tồn tại vì business rule, không phải vì validation đơn thuần?

​

Dấu hiệu học viên đang “điền template” thay vì thật sự biết test design

​

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

1. Sửa nhầm lẫn giữa scenario, test case và checklist trước.
2. Sửa expected result mơ hồ trước khi chỉnh format.
3. Sửa coverage hole và duplicate trước khi chỉnh câu chữ.
4. Chỉ khi logic test design đã ổn mới tối ưu naming hoặc trình bày.

​

Self-Check Cuối Tuần

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

• Tôi phân biệt được scenario và test case bằng mục đích sử dụng, không chỉ bằng định nghĩa.
• Tôi biết khi nào checklist là đủ và khi nào bắt buộc phải viết test case chi tiết.
• Test case của tôi có thể giao cho người khác chạy lại mà không cần giải thích miệng.
• Expected result của tôi có thể kiểm được bằng quan sát cụ thể.
• Tôi đã có đủ happy path, negative case và ít nhất một số edge/boundary case.
• Tôi đã rà xem case nào đang trùng nhau hoặc quá giống nhau chưa.
• Tôi biết case nào trong bài của mình đang bảo vệ business rule, không chỉ validation.
• Tôi biết artifact nào của mình còn yếu nhất và cần mentor review sâu hơn.
• Tôi hiểu tuần 2 đang chuẩn bị gì cho các tuần test UI, API, DB và workflow về sau.

​

Mapping Review

• Test case và cấu trúc cột chuẩn: /templates/test-case-template
• Rubric chính để review test case: /evaluation/test-case-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 2, học viên không còn đứng ở mức “đã hiểu màn hình cần test gì”, mà đã tiến thêm một bước quan trọng: biết biến hiểu biết đó thành artifact kiểm thử có thể dùng được. Bạn đã bắt đầu xây được scenario để giữ scope, test case để hướng dẫn thực thi và checklist để rà nhanh đúng chỗ. Đây chính là đoạn nối từ phân tích sang thiết kế test. Khi bước sang các tuần tiếp theo, hãy mang theo ba nguyên tắc:

• đừng test theo cảm giác, hãy test theo coverage có chủ đích;
• đừng viết expected result kiểu đoán ý, hãy viết thứ có thể kiểm chứng;
• đừng tạo nhiều artifact cho đẹp, hãy tạo artifact đúng mục tiêu sử dụng.

Giữ được kỷ luật đó, các tuần UI, API, DB, workflow và permission về sau sẽ chắc hơn rất nhiều, vì phần thiết kế test đã đi đúng ngay từ gốc.