Tuần 7 - End-to-End, Retest, Regression, Summary

Bắt đầu quản lý chất lượng theo luồng, không chỉ theo từng điểm kiểm riêng lẻ. Tuần 7 là lúc học viên ghép tất cả những gì đã học ở các tuần trước thành một hành trình kiểm thử hoàn chỉnh: luồng end-to-end, dữ liệu test, retest bug đã fix, regression scope, smoke checklist và báo cáo summary cuối vòng test. Đây là tuần học viên chuyển từ “test từng phần” sang “nhìn hệ thống như một chuỗi tác động liên kết”, nơi một thay đổi nhỏ có thể kéo theo ảnh hưởng dây chuyền ở nhiều lớp. Nếu không vững tuần này, học viên rất dễ retest theo cảm tính, regression quá hẹp hoặc quá rộng, và viết summary report chỉ có số liệu nhưng không nói được rủi ro thật. Tuần 7 chính là nơi QC bắt đầu học cách đứng ở vị trí gần hơn với sprint thực tế và quyết định chất lượng release.

End-to-end là logic hành trình. Retest là xác minh bug đã được sửa đúng. Regression là bảo vệ hệ thống khỏi hiệu ứng domino. Summary report là tiếng nói của QC ở cuối vòng test.

​

Snapshot

​

Mục Tiêu Tuần

​

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

Học viên cần hiểu end-to-end testing không phải là việc nối nhiều màn hình cho có, mà là kiểm cả một hành trình nghiệp vụ từ đầu vào đến kết quả cuối cùng. Tuần này cũng giúp learner phân biệt rõ ba khái niệm thường bị dùng lẫn:

• Retest: kiểm lại bug đã fix để xác nhận lỗi cũ đã hết.
• Regression: kiểm các vùng có khả năng bị ảnh hưởng dây chuyền sau thay đổi.
• Smoke: kiểm nhanh các điểm sống còn để biết build có đủ ổn định để đi tiếp hay không.

Hết tuần, học viên cần hiểu rõ:

• thế nào là critical path,
• test data tốt ảnh hưởng trực tiếp tới khả năng chạy E2E,
• risk statement khác defect count,
• test summary report là output quản trị chất lượng, không phải bản thống kê cho đẹp.

​

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 sprint thật:

• Xác định và mô tả một end-to-end flow có giá trị nghiệp vụ rõ ràng.
• Chuẩn bị test data đủ sạch để chạy một luồng hoàn chỉnh.
• Retest bug bằng cách tái lập đúng precondition cũ.
• Xác định regression scope dựa trên impact analysis, không chọn theo cảm giác.
• Tạo smoke checklist đủ gọn để dùng trước release hoặc sau deploy.
• Viết test summary report có scope, coverage, bug picture, residual risk và recommendation.

​

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

Tuần 7 xây một tư duy rất quan trọng: QC không chỉ test từng phần đúng, mà phải nhìn hệ thống như một chuỗi liên động. QC tốt không dừng ở câu hỏi “case này pass chưa”, mà hỏi sâu hơn:

• flow nào là luồng sống còn của hệ thống,
• fix bug này có thể ảnh hưởng vùng nào khác,
• smoke nên giữ những điểm chạm nào để đủ nhanh nhưng vẫn đủ ý nghĩa,
• summary report nên nói điều gì để lead hiểu rủi ro thật, không chỉ hiểu số lượng bug.

Đây là tư duy cần thiết trước khi bước vào tuần final project và readiness gần giống dự án thật.

​

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

Tuần 7 là cây cầu nối từ kỹ năng kiểm thử từng lớp riêng lẻ sang năng lực vận hành kiểm thử trong một vòng test thật. Đây là nơi learner phải chứng minh rằng mình không chỉ biết test case, API, SQL hay permission riêng lẻ, mà biết ghép chúng thành một bức tranh chất lượng có thể dùng để hỗ trợ quyết định release.

​

Đây là tuần trước final readiness

Ở những tuần trước, learner đã học cách:

• đọc requirement,
• thiết kế test,
• test UI,
• log bug,
• test API,
• verify DB,
• test workflow và permission.

Tuần 7 buộc learner ghép chúng lại thành một hành trình kiểm thử từ đầu đến cuối. Nếu không làm được việc này, learner rất khó bước vào mini project hoặc sprint mô phỏng với tư duy có tổ chức.

​

Năng lực E2E và regression quyết định learner có thể làm việc trong sprint thật hay chưa

Trong sprint thực tế, QC không chỉ được giao “test màn hình A” hay “check API B”. QC phải biết:

• flow nào là quan trọng nhất để bảo vệ,
• bug fix này cần retest như thế nào,
• vùng nào cần regression,
• build mới có đủ ổn để cho team dùng tiếp hay không,
• và cuối vòng test cần báo cáo ra sao để PM/Lead ra quyết định.

Đây là phần biến QC từ người “thực hiện test” thành người “quản lý chất lượng theo phạm vi và rủi ro”.

​

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

• Chỉ test chức năng riêng lẻ, không nhìn flow xuyên luồng.
• Retest bug nhưng quên precondition hoặc test data cũ.
• Regression quá hẹp nên miss impact, hoặc quá rộng nên lãng phí effort.
• Smoke checklist quá dài, biến thành full regression.
• Summary report chỉ có số liệu pass/fail và bug count, không có risk statement.

Tuần này quan trọng vì nó rèn kỷ luật: mọi hoạt động test cuối vòng đều phải phục vụ quyết định chất lượng, không phải chỉ phục vụ “đã test xong”.

​

Retest vs Regression vs Smoke

Ba khái niệm này có liên quan nhưng không thay thế cho nhau.

​

E2E Flow Không Phải Chỉ Là Ghép Màn Hình

Một E2E flow tốt phải có:

• mục tiêu nghiệp vụ rõ,
• điểm bắt đầu và điểm kết thúc rõ,
• vai trò tham gia rõ,
• dữ liệu đi qua các bước có ý nghĩa,
• và outcome cuối cùng kiểm được.

Ví dụ, flow Login -> Tạo Leave Request -> Submit -> Approve -> Xem lịch sử là E2E vì nó kiểm được:

• create request,
• state change,
• permission,
• audit/history,
• và kết quả hiển thị sau cùng.

Chỉ nối Màn hình A -> Màn hình B -> Màn hình C mà không có logic nghiệp vụ đi xuyên suốt thì chưa phải E2E đúng nghĩa.

​

Regression Scope Nên Nghĩ Theo Impact

Regression scope không nên chọn theo kiểu “cái gì gần gần thì test lại”. QC cần nghĩ theo impact:

• thay đổi này chạm module nào,
• chạm field nào,
• chạm action nào,
• chạm role nào,
• chạm state nào,
• chạm integration hoặc report nào.

Regression tốt không phải là regression nhiều nhất, mà là regression đúng nhất theo vùng rủi ro.

​

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

Test summary report tốt không chỉ nói:

• đã chạy bao nhiêu case,
• có bao nhiêu bug,
• pass hay fail bao nhiêu.

Nó phải giúp người đọc hiểu:

• phạm vi nào đã được kiểm,
• phạm vi nào chưa được kiểm,
• bug nào còn tồn đọng quan trọng,
• rủi ro nào còn lại nếu release,
• và recommendation của QC là gì.

Nếu PM hoặc Lead đọc xong mà vẫn không biết nên release hay nên chặn, summary đó chưa đạt.

​

Risk Statement Khác Gì Defect Count

Defect count trả lời câu hỏi: có bao nhiêu lỗi. Risk statement trả lời câu hỏi: nếu release bây giờ, chuyện gì có thể xảy ra với user, dữ liệu hoặc nghiệp vụ. Ví dụ:

• Có 3 bug High là defect count.
• Flow approve leave request chưa được regression đủ trên role Manager; có rủi ro đơn vẫn đổi state nhưng không ghi history đúng khi release là risk statement.

QC mới rất hay báo số lượng mà không nói rủi ro thật. Tuần 7 phải sửa điểm này.

​

Kế Hoạch Theo Ngày

​

Ngày 43 - End-to-End Thinking

Chủ đề: Nhìn hệ thống như một hành trình nghiệp vụ, không như nhiều màn hình rời nhau Mục tiêu của ngày

• Hiểu E2E flow là gì và tại sao QC hệ thống cần nó.
• Xác định được đâu là critical path.
• Bỏ ngộ nhận “E2E chỉ là ghép nhiều màn hình”.

Học gì

• Critical flow
• Trigger point
• State/data change xuyên bước
• Actor xuyên flow
• Outcome cuối cùng cần verify

Thực hành gì

• Chọn 1 flow mẫu như:
  • Login -> Tạo Leave Request -> Submit -> Approve -> Xem lịch sử
• Viết note mô tả:
  • mục tiêu nghiệp vụ của flow,
  • vai trò tham gia,
  • bước chính,
  • điểm kiểm quan trọng ở mỗi chặng,
  • kết quả cuối cùng nào cần xuất hiện.
• Chỉ ra ít nhất 2 điểm trong flow mà bug có thể gây hiệu ứng dây chuyền.

Output cần nộp

• day43_e2e_flow.md

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

• Bạn mô tả flow bằng logic nghiệp vụ, không chỉ bằng list màn hình.
• Bạn biết flow bắt đầu ở đâu, kết thúc ở đâu và outcome nào là critical.
• Bạn chỉ ra được data/state thay đổi ở từng chặng.

Lỗi thường gặp

• Flow chỉ là danh sách màn hình nối nhau.
• Không nêu actor hoặc mục tiêu nghiệp vụ.
• Không nói được điểm kiểm quan trọng nhất của flow.

Mentor review note

• Hỏi: Nếu flow này fail ở bước Approve, hậu quả dây chuyền sẽ xuất hiện ở đâu nữa?
• Kiểm tra learner có nhìn flow như chuỗi liên động hay chỉ là sơ đồ thao tác.

​

Ngày 44 - Test Data Strategy

Chủ đề: Chuẩn bị dữ liệu đúng để flow chạy được và kết quả đáng tin Mục tiêu của ngày

• Hiểu test data không phải phần phụ.
• Biết chọn test data sạch, biên, reusable và đủ điều kiện cho flow.
• Bỏ ngộ nhận “test data nào cũng được, miễn chạy được”.

Học gì

• Clean test data
• Edge test data
• Reusable data
• Dirty environment risk
• Precondition data cho E2E flow

Thực hành gì

• Tạo test data sheet cho flow Leave Request.
• Sheet phải có:
  • employee account,
  • manager account,
  • leave balance,
  • trạng thái ban đầu của request,
  • field dữ liệu chính,
  • expected output sau mỗi bước.
• Chỉ ra ít nhất 2 rủi ro nếu dùng data bẩn hoặc data cũ.

Output cần nộp

• day44_test_data_sheet.xlsx

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

• Test data của bạn phục vụ trực tiếp cho flow, không phải list ngẫu nhiên.
• Bạn biết data nào là prerequisite, data nào là data biên.
• Bạn nhìn thấy mối liên hệ giữa data sạch và kết luận test đáng tin.

Lỗi thường gặp

• Data thiếu điều kiện để chạy full flow.
• Dùng account hoặc record cũ làm flow khó lặp lại.
• Không ghi rõ state/data ban đầu.

Mentor review note

• Hỏi: Nếu account Manager này đã approve xong một request trước đó, flow của em còn đáng tin để chạy lại không?
• Xem learner có hiểu data strategy là một phần của test design chứ không chỉ là chuẩn bị đầu vào.

​

Ngày 45 - Retest

Chủ đề: Xác minh bug đã fix đúng, không test theo trí nhớ mơ hồ Mục tiêu của ngày

• Phân biệt retest với regression.
• Biết tái lập đúng bug cũ bằng đúng precondition và dữ liệu cần thiết.
• Bỏ ngộ nhận “dev báo fixed thì chạy lại đại khái là đủ”.

Học gì

• Bug context
• Preconditions cũ
• Reproduce path cũ
• Verify fix
• Check for adjacent side effect

Thực hành gì

• Lấy 5 bug mẫu và viết retest note.
• Với mỗi bug, ghi:
  • bug cũ là gì,
  • precondition cũ là gì,
  • steps cần lặp lại,
  • expected behavior sau fix,
  • điểm nào cần nhìn thêm để tránh false pass.
• Chọn 1 bug và chỉ ra lỗi nếu retest mà quên một precondition quan trọng.

Output cần nộp

• day45_retest_notes.md

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

• Bạn tái lập lại đúng điều kiện bug cũ trước khi kiểm fix.
• Bạn phân biệt retest với regression.
• Bạn hiểu pass retest không có nghĩa là toàn bộ hệ thống xung quanh đã an toàn.

Lỗi thường gặp

• Retest không đúng môi trường hoặc đúng data.
• Quên precondition bug ban đầu.
• Thấy symptom cũ hết là kết luận fix hoàn toàn.

Mentor review note

• Hỏi: Nếu bug cũ xảy ra chỉ với role Manager và state Submitted, mà em retest bằng role khác hoặc state khác, kết quả pass có còn giá trị không?
• Kiểm tra learner có thật sự hiểu retest là tái kiểm đúng bug cũ hay không.

​

Ngày 46 - Regression

Chủ đề: Xác định vùng ảnh hưởng sau fix bằng impact analysis Mục tiêu của ngày

• Phân biệt regression với retest và smoke.
• Xác định regression scope theo impact thay vì theo cảm giác.
• Bỏ ngộ nhận “càng test nhiều càng là regression tốt”.

Học gì

• Change impact
• Adjacent modules
• Shared component / shared API / shared data
• Critical path regression
• Regression prioritization

Thực hành gì

• Với bug sửa create employee hoặc fix submit leave request, liệt kê các phần cần regression.
• Chia scope thành:
  • must regression,
  • should regression,
  • optional if time allows.
• Giải thích vì sao mỗi vùng được đưa vào scope.
• Chỉ ra một ví dụ regression quá hẹp và một ví dụ regression quá rộng.

Output cần nộp

• day46_regression_scope.md

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

• Scope của bạn dựa trên impact thật, không dựa vào cảm giác.
• Bạn biết ưu tiên critical path trước.
• Bạn không biến regression thành “test lại tất cả”.

Lỗi thường gặp

• Chọn scope quá hẹp, bỏ sót vùng bị ảnh hưởng.
• Chọn scope quá rộng, lãng phí effort và không có trọng tâm.
• Không giải thích được vì sao vùng đó cần regression.

Mentor review note

• Hỏi: Nếu fix ở API create leave request, vùng regression tối thiểu của em là gì và vì sao?
• Xem learner có thật sự làm impact analysis hay chỉ liệt kê module gần đó.

​

Ngày 47 - Smoke Test

Chủ đề: Kiểm nhanh các điểm sống còn, không biến smoke thành regression đầy đủ Mục tiêu của ngày

• Hiểu smoke test khác regression ở mục tiêu và độ sâu.
• Biết chọn checklist đủ gọn nhưng vẫn đủ ý nghĩa.
• Bỏ ngộ nhận “smoke = test sơ sơ toàn hệ thống”.

Học gì

• Smoke entry criteria
• Critical touch points
• Build health
• Minimal viable confidence

Thực hành gì

• Tạo smoke checklist cho web admin hoặc flow Leave Request.
• Checklist phải bao phủ:
  • login,
  • open list,
  • create basic record,
  • submit action,
  • approve basic action nếu flow có,
  • logout hoặc session stability cơ bản.
• Chỉ ra 2 ví dụ:
  • smoke quá dài nên biến thành regression,
  • smoke quá hời hợt nên không đủ giá trị.

Output cần nộp

• day47_smoke_checklist.md

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

• Checklist của bạn đủ ngắn để chạy nhanh.
• Nhưng vẫn giữ được các điểm sống còn của build.
• Bạn không nhầm smoke với regression.

Lỗi thường gặp

• Smoke checklist quá dài.
• Smoke checklist quá ngắn và không chạm critical path.
• Không nói được mục tiêu của smoke là gì.

Mentor review note

• Hỏi: Nếu chỉ có 15 phút sau deploy, checklist này có còn là smoke usable không?
• Kiểm tra learner có hiểu smoke là bài kiểm ổn định build chứ không phải full test rút gọn.

​

Ngày 48 - Test Summary Report

Chủ đề: Biến kết quả test thành báo cáo để lead ra quyết định Mục tiêu của ngày

• Viết được test summary report usable cho PM/Lead.
• Biết tách defect count khỏi risk statement.
• Bỏ ngộ nhận “summary report chỉ cần số pass/fail”.

Học gì

• Scope
• Coverage metrics
• Defect summary
• Residual risks
• Decision recommendation
• Release readiness tone

Thực hành gì

• Viết report mẫu sau 1 vòng test cho flow Leave Request.
• Report phải có:
  • scope test,
  • executed/passed/failed/blocked,
  • bug summary theo severity,
  • key risks,
  • decision recommendation.
• Viết ít nhất 2 risk statement có ý nghĩa thực tế, không chỉ lặp bug count.

Output cần nộp

• day48_test_summary_report.md

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

• Report của bạn cho người đọc biết nên tin build ở mức nào.
• Bạn nói được risk còn lại, không chỉ số lượng bug.
• Recommendation của bạn bám coverage và residual risk, không bám cảm tính.

Lỗi thường gặp

• Chỉ liệt kê số liệu.
• Không có risk statement thật.
• Recommendation mơ hồ kiểu “có thể release tùy team”.

Mentor review note

• Hỏi: Nếu PM chỉ đọc 60 giây đầu tiên của report này, họ có hiểu được rủi ro chính còn lại không?
• Xem learner có viết report như công cụ ra quyết định hay chỉ như bản tổng hợp số liệu.

​

Ngày 49 - Tổng Kết Tuần 7

Chủ đề: Mô phỏng một vòng sprint test hoàn chỉnh ở mức QC junior có định hướng Mục tiêu của ngày

• Ghép E2E flow, test data, retest, regression, smoke và summary thành một package hoàn chỉnh.
• Tự đánh giá learner đã nhìn hệ thống như một chuỗi liên động hay chưa.
• Chuẩn bị nền cho tuần final project.

Học gì

• Mock sprint testing không yêu cầu mọi thứ hoàn hảo, nhưng bắt buộc phải thể hiện logic:
  • chọn flow đúng,
  • chuẩn bị data đúng,
  • retest đúng,
  • regression có lý,
  • smoke đủ gọn,
  • summary usable.

Thực hành gì

• Mô phỏng một sprint test với flow Leave Request.
• Đóng gói:
  • E2E flow note,
  • test data sheet,
  • retest note,
  • regression scope,
  • smoke checklist,
  • test summary report.
• Tự rà package trước khi nộp:
  • critical flow đã rõ chưa,
  • data có đủ sạch để chạy lại chưa,
  • retest có bám bug cũ chưa,
  • regression có đủ impact không,
  • report có risk statement usable không.

Output cần nộp

• week07_mock_sprint_testing/

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

• Package của bạn có logic xuyên suốt chứ không chỉ là tập file rời rạc.
• Bạn cho thấy được tư duy quản lý chất lượng theo flow.
• Bạn tự chỉ ra được ít nhất 2 chỗ package còn yếu trước khi mentor comment.

Lỗi thường gặp

• Nộp đủ file nhưng không nối được giữa flow, data, retest và report.
• Retest/regression/smoke chồng lẫn lên nhau.
• Report thiếu góc nhìn quyết định release.

Mentor review note

• Hỏi: Nếu giao package này cho một QC khác để tiếp quản sprint test, họ có hiểu ngay flow nào là critical, bug nào đã retest, vùng nào còn risk và vì sao không?
• Đánh giá package ở góc độ gần với sprint thật, không chỉ ở góc độ “đủ deliverable”.

​

Deliverables Cần Nộp

​

KPI & Focus

​

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

• Hoàn thành 100% deliverable bắt buộc.
• Có ít nhất 1 E2E flow xuyên nhiều bước với critical path rõ.
• day44_test_data_sheet.xlsx phải có đủ account/role/data/state phục vụ flow.
• day45_retest_notes.md phải có ít nhất 5 bug mẫu được retest với precondition rõ.
• day46_regression_scope.md phải chia được must, should, optional hoặc logic ưu tiên tương đương.
• day47_smoke_checklist.md phải đủ ngắn để dùng trước release hoặc sau deploy.
• day48_test_summary_report.md phải có:
  • scope,
  • coverage metrics,
  • defect summary,
  • key risks,
  • decision recommendation.
• Package cuối tuần phải chứng minh được learner phân biệt rõ retest, regression và smoke.

​

Focus của tuần

• Think in flows: đừng test rời rạc từng điểm chạm.
• Rebuild the bug context: retest phải bám điều kiện cũ.
• Regress by impact: regression scope phải có lý do rõ.
• Speak in risk: summary report phải nói được rủi ro thật, không chỉ số lượng lỗi.

​

Mini Rubric Cho Tuần 7

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à Xác định đúng E2E flow, Phân biệt retest/regression/smoke, Regression scope và Summary report usable.

​

Common Mistakes

​

Mentor Review Guide

​

Review E2E flow thế nào

• Flow có mục tiêu nghiệp vụ rõ không.
• Có actor, data/state change và outcome rõ không.
• Có chỉ ra điểm critical nhất của luồng không.
• Có nhìn thấy tác động dây chuyền nếu một bước fail không.

​

Review regression scope thế nào

• Scope có dựa trên impact hay chỉ liệt kê module gần đó.
• Có ưu tiên critical path trước không.
• Có bỏ sót shared component, API dùng chung hoặc dữ liệu downstream không.
• Có phân biệt được retest phần bug cũ với regression vùng bị ảnh hưởng không.

​

Review summary report thế nào

• Scope có rõ phần đã test và chưa test không.
• Coverage metrics có đáng tin không.
• Risk statement có nói được residual risk thật không.
• Recommendation có usable cho PM/Lead không.

​

Hỏi gì để kiểm tra learner thật sự hiểu impact analysis

• Bug này được fix ở bước Submit, vậy vùng impact tối thiểu của em là những đâu?
• Vì sao flow này là critical path chứ không phải flow kia?
• Nếu smoke chỉ được chạy trong 10 phút, em giữ lại những điểm nào và cắt điểm nào?
• Risk lớn nhất còn lại sau vòng test này là gì, và vì sao nó quan trọng hơn bug count?

​

Nên ưu tiên sửa lỗi gì trước

1. Sửa nhầm lẫn giữa retest, regression và smoke trước.
2. Sửa E2E flow rời rạc trước khi tối ưu format report.
3. Sửa regression scope cảm tính trước khi tăng số lượng case.
4. Nếu summary report không usable, sửa phần risk statement và recommendation trước mọi thứ khác.

​

Self-Check Cuối Tuần

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

• Tôi xác định được critical flow thay vì chỉ nối các màn hình.
• Tôi phân biệt được retest và regression.
• Tôi biết bug này có thể ảnh hưởng vùng nào khác.
• Tôi tạo được test data đủ sạch để chạy flow.
• Tôi phân biệt được smoke checklist và regression scope.
• Tôi viết được summary report để lead đọc hiểu nhanh.
• Tôi nêu được risk thay vì chỉ nêu số lượng bug.
• Tôi biết output nào của mình còn yếu nhất và cần mentor review sâu hơn.

​

Mapping Review

• Summary report: /templates/test-summary-template
• Weekly score: /templates/weekly-assessment-template
• Tự đánh giá cuối tuần: /templates/self-assessment-template
• Review checklist: /mentor-guide/review-checklist
• Quy tắc feedback: /mentor-guide/feedback-rules
• Scoring framework chung: /evaluation/scoring-framework

​

Kết Thúc Tuần

Sau tuần 7, học viên đã đi từ việc test từng lớp riêng lẻ sang việc quản lý chất lượng theo luồng, theo rủi ro và theo quyết định release. Đây là bước rất quan trọng trước tuần final project, vì từ thời điểm này learner không chỉ là người “chạy test”, mà bắt đầu có tư duy của một QC biết bảo vệ hệ thống ở mức hành trình và ảnh hưởng dây chuyền. Khi bước sang tuần 8, hãy mang theo ba mindset này:

• đừng test từng mảnh rời nhau, hãy nhìn flow và impact chain;
• đừng retest theo cảm giác, hãy retest bằng đúng bug context;
• đừng báo cáo số lượng trước, hãy báo cáo rủi ro và khuyến nghị trước.

Giữ được ba điều đó, bài mô phỏng gần với dự án thật ở tuần cuối sẽ chắc hơn rất nhiều, vì bạn đã biết nhìn hệ thống như một vòng test hoàn chỉnh chứ không chỉ là tập hợp các case riêng lẻ.