Tuần 6 - Workflow & Permission Testing

Bắt đầu test “luật vận hành” của hệ thống, không chỉ test từng màn hình riêng lẻ. Tuần 6 là lúc học viên đi vào phần cốt lõi nhất của các hệ thống doanh nghiệp: workflow, trạng thái, bước duyệt, vai trò và quyền hạn. Từ tuần này trở đi, QC không còn chỉ kiểm “form có lưu được không” hay “API có trả đúng không”, mà phải kiểm hệ thống có cho đúng người làm đúng hành động ở đúng trạng thái hay không. Đây là nơi nhiều bug nghiêm trọng nhất của ERP, HRM, approval system thường xuất hiện: skip state, approve sai vai trò, UI ẩn nút nhưng API vẫn mở, history sai, audit không ghi đủ. Nếu không vững tuần này, học viên rất dễ chỉ test “có thấy nút hay không” mà bỏ sót logic chuyển trạng thái và quyền thật của hệ thống.

Workflow là logic sống của hệ thống. Permission là hàng rào kiểm soát hành động. QC hệ thống phải nhìn state + role + action như một tam giác kiểm thử không thể tách rời.

​

Snapshot

​

Mục Tiêu Tuần

​

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

Học viên cần hiểu workflow không phải là một sơ đồ trang trí, mà là tập luật mô tả hệ thống đi từ trạng thái nào sang trạng thái nào, ai được làm gì và điều kiện nào mới cho phép hành động đó xảy ra. Permission cũng không chỉ là chuyện “thấy nút hay không”, mà là lớp kiểm soát hành động theo role, scope và ngữ cảnh. Hết tuần, học viên cần hiểu rõ:

• state, transition, action, approver, history log nghĩa là gì trong một module nghiệp vụ.
• role, permission, scope, UI permission, API permission khác nhau ở đâu.
• State transition matrix dùng để kiểm đường đi hợp lệ, invalid action, state bị skip và điều kiện chuyển trạng thái.
• Role-State-Action matrix dùng để kiểm ai được làm gì ở state nào.

​

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

Tuần 6 yêu cầu học viên làm được các việc có thể dùng ngay trong công ty:

• Vẽ được workflow đủ state và transition chính cho một module như Leave Request.
• Viết được state transition matrix có cả đường đi hợp lệ và hành động bị cấm.
• Lập được permission matrix đủ role, action và scope cơ bản.
• Test được UI permission và API permission như hai lớp khác nhau.
• Kết hợp workflow với permission thành logic role x state x action, thay vì test rời rạc từng phần.

​

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

Tư duy cốt lõi của tuần này là: đừng test hành động đơn lẻ, hãy test hành động trong đúng trạng thái và đúng vai trò. QC tốt không chỉ hỏi “nút Approve có bấm được không”, mà sẽ hỏi sâu hơn:

• Nút này chỉ được phép xuất hiện ở state nào?
• Role nào được bấm?
• Nếu UI ẩn nút nhưng gọi API trực tiếp thì sao?
• Sau transition, state đổi ra sao, audit/history có ghi đúng không, notify có phát ra không?

Đây là lớp tư duy quyết định việc learner có thể theo kịp các module nghiệp vụ phức tạp hay không.

​

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

Tuần 6 là nơi QC chuyển từ test chức năng đơn lẻ sang test luật nghiệp vụ có điều kiện. Đây là một bước trưởng thành lớn vì hệ thống doanh nghiệp hiếm khi sai ở mức “textfield không lưu được”; chúng thường sai ở chỗ cho sai người làm sai việc ở sai trạng thái.

​

Workflow và permission bug thường có severity cao

Một số bug ở tuần này nhìn bề ngoài không ồn ào như crash, nhưng mức độ rủi ro lại rất cao:

• Nhân viên tự approve đơn của chính mình.
• Manager approve khi đơn vẫn còn ở Draft.
• Record chuyển sang Approved nhưng không ghi history.
• UI ẩn nút Delete nhưng API vẫn cho role không đủ quyền xóa dữ liệu.

Những lỗi này thường tác động trực tiếp tới quy trình nghiệp vụ, kiểm soát nội bộ và audit.

​

Đây là tuần learner bắt đầu test “luật chơi” của hệ thống

Trước tuần 6, learner đã có nền về:

• requirement,
• test case,
• UI,
• bug report,
• API,
• DB verification.

Tuần 6 buộc learner ghép tất cả lại để trả lời câu hỏi lớn hơn: hệ thống có đang vận hành đúng luật hay không. Đây là nơi learner phải nhìn cùng lúc:

• state hiện tại,
• role hiện tại,
• action đang muốn thực hiện,
• transition được phép,
• và dấu vết hệ thống để lại sau transition.

​

Nếu không chắc tuần này, learner sẽ rất khó theo module ERP/HRM/Approval thực tế

Các lỗi người mới rất hay mắc:

• Chỉ test happy path của workflow.
• Không test hành động bị cấm.
• Kiểm quyền trên UI nhưng quên API permission.
• Thiếu role hoặc thiếu state trong matrix.
• Không kiểm history, audit, notification sau transition.
• Nhầm workflow issue với permission issue.

Tuần này rất quan trọng vì nó tạo nền cho E2E, regression và mọi module có quy trình duyệt thực tế sau này.

​

Workflow Bug vs Permission Bug

QC phải biết tách bản chất lỗi, nếu không bug report và test design tuần này sẽ rất yếu.

​

UI Chặn Chưa Đủ, API Phải Chặn Thật

Một trong những sai lầm phổ biến nhất là chỉ test permission ở UI:

• Nút Approve bị ẩn với Employee role.
• Learner kết luận permission đã ổn.

Nhưng nếu API POST /leave-requests/{id}/approve vẫn cho Employee gọi trực tiếp thì hệ thống vẫn đang hở quyền nghiêm trọng. Permission phải được kiểm ở cả UI và API, đặc biệt với các hành động tác động trạng thái hoặc dữ liệu.

​

State Transition Matrix Dùng Để Làm Gì

State transition matrix giúp learner và mentor nhìn rõ:

• state hiện tại là gì,
• action nào được phép,
• action nào bị cấm,
• transition nào hợp lệ,
• next state là gì,
• điều kiện, notify và audit cần đi kèm là gì.

Đây là công cụ để biến workflow từ một sơ đồ “đẹp” thành một artifact kiểm thử dùng được.

​

Role-State-Action Matrix Dùng Để Làm Gì

Role-State-Action matrix là nơi workflow và permission gặp nhau. Nó trả lời một câu hỏi rất thực dụng:

Ở state này, role này có được làm action này hay không?

Nếu không có matrix này, learner rất dễ test rời rạc theo kiểu:

• role có thấy nút không,
• state có đổi được không,

nhưng không ghép được hai lớp lại với nhau.

​

Một Workflow/Permission Package Tốt Trông Như Thế Nào

Package tốt không chỉ có sơ đồ workflow và vài checklist rời rạc. Nó phải cho mentor nhìn ra:

• workflow đủ state và transition chính,
• state transition matrix đủ hành động hợp lệ và hành động bị cấm,
• permission matrix đủ role/action/scope,
• role-state-action matrix đủ để map quyền theo state,
• note hoặc scenario cho UI permission và API permission,
• history/audit/notification có được xem là một phần của verify hay không.

Nếu package chỉ có ma trận mà không cho thấy logic luật nghiệp vụ, package đó chưa đạt.

​

Kế Hoạch Theo Ngày

​

Ngày 36 - Workflow Basics

Chủ đề: Hiểu workflow như vòng đời thật của một nghiệp vụ Mục tiêu của ngày

• Hiểu workflow, state, transition, approver và history log theo ngữ cảnh doanh nghiệp.
• Bỏ ngộ nhận “workflow chỉ là sơ đồ để BA dùng”.
• Dùng Leave Request làm ví dụ xuyên suốt cho toàn tuần.

Học gì

• Draft -> Submitted -> Approved / Rejected
• Actor/approver liên quan trong từng bước
• History log và notify sau từng transition
• Vì sao không phải action nào cũng được phép ở mọi state

Thực hành gì

• Vẽ workflow cho Leave Request.
• Ghi chú với từng state:
  • ai tạo,
  • ai duyệt,
  • action nào xuất hiện,
  • transition nào được phép.
• Thêm 1 ví dụ tình huống sai:
  • nhân viên skip từ Draft sang Approved.

Output cần nộp

• day36_workflow_basics.md
• day36_workflow.png

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

• Bạn vẽ được đủ state chính chứ không chỉ một đường happy path.
• Bạn chỉ ra được actor/role quan trọng trong từng bước.
• Bạn nhìn workflow như logic nghiệp vụ, không như sơ đồ trang trí.

Lỗi thường gặp

• Vẽ thiếu state Rejected hoặc thiếu đường quay lại Draft/Resubmit nếu nghiệp vụ có.
• Không gắn state với actor và action.
• Không nhắc tới history, notify hoặc audit log.

Mentor review note

• Hỏi: Ở workflow này, bước nào là nơi bug nghiêm trọng nhất dễ xảy ra? Vì sao?
• Xem learner có vẽ workflow bằng tư duy kiểm thử hay chỉ mô tả flow đẹp mắt.

​

Ngày 37 - State Transition Test

Chủ đề: Kiểm các transition hợp lệ và không hợp lệ Mục tiêu của ngày

• Biết test workflow theo state, không chỉ theo đường đi đúng.
• Bao phủ được invalid transition, skip state và action bị cấm.
• Bỏ ngộ nhận “test workflow chỉ cần kiểm từ đầu tới cuối”.

Học gì

• Current State
• Allowed Action
• Next State
• Validation Condition
• Invalid transition
• Skip state
• Resubmit flow nếu có

Thực hành gì

• Tạo state transition matrix cho Leave Request.
• Matrix phải có:
  • transition hợp lệ,
  • action bị cấm,
  • state không được skip,
  • note về audit/notify sau transition.
• Thêm ít nhất 2 ví dụ:
  • manager approve khi đơn còn Draft,
  • request bị Rejected có cho resubmit hay không.

Output cần nộp

• day37_state_transition_matrix.xlsx

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

• Matrix của bạn có cả valid và invalid action.
• Bạn chỉ ra được state nào không được skip.
• Bạn nhìn transition như một rule set, không phải chỉ là thứ tự màn hình.

Lỗi thường gặp

• Chỉ ghi transition hợp lệ, bỏ qua action bị cấm.
• Thiếu điều kiện hoặc precondition của transition.
• Không gắn audit/notify sau khi state đổi.

Mentor review note

• Hỏi: Trong matrix này, transition nào bị cấm nhưng hệ thống rất dễ lỡ cho đi qua nếu dev xử lý ẩu?
• Kiểm tra learner có thật sự dùng matrix để test luật chuyển trạng thái hay không.

​

Ngày 38 - Permission Basics

Chủ đề: Hiểu role, permission và scope như lớp kiểm soát hành động Mục tiêu của ngày

• Phân biệt role, permission, scope và quyền theo ngữ cảnh.
• Bỏ ngộ nhận “permission chỉ là có thấy nút hay không”.
• Chuẩn bị nền để tách UI permission với API permission.

Học gì

• Role
• Permission
• Scope
• UI permission vs API permission
• Hành động phổ biến:
  • View
  • Create
  • Edit
  • Delete
  • Approve
  • Reject
  • Export

Thực hành gì

• Dùng module Leave Request để liệt kê các role:
  • Employee
  • Line Manager
  • HR Admin
  • Super Admin
• Tạo permission matrix cho các action chính.
• Ghi chú rõ scope nếu có, ví dụ:
  • chỉ xem đơn của bản thân,
  • xem toàn bộ đơn,
  • chỉ approve đơn của team mình.

Output cần nộp

• day38_permission_matrix.xlsx

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

• Bạn không gộp role và permission làm một.
• Matrix có cả action và scope, không chỉ có dấu X.
• Bạn nhìn permission như lớp kiểm soát hành động, không chỉ là lớp hiển thị UI.

Lỗi thường gặp

• Thiếu role quan trọng.
• Không ghi scope đặc biệt.
• Gộp permission UI và permission API thành một dòng mơ hồ.

Mentor review note

• Hỏi: Role này được View nhưng view cái gì, scope đến đâu, và điều đó có ảnh hưởng gì tới test?
• Xem learner có hiểu permission như một rule có ngữ cảnh hay chỉ như bảng yes/no.

​

Ngày 39 - Test Permission Trên UI

Chủ đề: Kiểm thứ hệ thống cho người dùng thấy và cho người dùng bấm Mục tiêu của ngày

• Test được UI permission ở mức thực dụng.
• Biết kiểm hide button, disable action, route access, detail access.
• Bỏ ngộ nhận “ẩn nút là xong”.

Học gì

• Hide action
• Disable action
• Chặn route hoặc detail page
• Chặn action theo state và role
• UI message khi người dùng không có quyền

Thực hành gì

• Viết checklist test UI permission cho Leave Request.
• Bao phủ:
  • Employee
  • Manager
  • HR Admin
• Kiểm:
  • ai thấy nút gì,
  • state nào hiện nút gì,
  • route/detail page có truy cập được không,
  • action bị disable hay bị ẩn trong state nào.

Output cần nộp

• day39_ui_permission_checklist.md

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

• Bạn không chỉ test thấy/không thấy nút.
• Checklist có gắn role với state và action.
• Bạn biết UI permission chỉ là lớp đầu, chưa phải kết luận cuối.

Lỗi thường gặp

• Chỉ test role mà quên state.
• Không test route hoặc detail access.
• Thấy nút bị ẩn là kết luận permission đúng.

Mentor review note

• Hỏi: Nếu Employee không thấy nút Approve nhưng vẫn vào được route detail và thao tác qua devtools, em còn phải kiểm gì nữa?
• Kiểm tra learner có thật sự hiểu giới hạn của UI permission hay không.

​

Ngày 40 - Test Permission Trên API

Chủ đề: Kiểm hàng rào quyền thật ở lớp backend Mục tiêu của ngày

• Test được permission ở API theo nhiều role.
• Nhấn mạnh nguyên tắc: UI chặn chưa đủ, API phải chặn thật.
• Bỏ ngộ nhận “không thấy nút thì không cần test API permission nữa”.

Học gì

• API permission scenarios
• Role-based access ở backend
• 401 vs 403 trong context action bị cấm
• Tại sao permission bug ở API thường nghiêm trọng hơn UI bug

Thực hành gì

• Viết test scenarios permission cho API của Leave Request.
• Bao phủ ít nhất:
  • Employee gọi API approve,
  • Manager gọi API approve ở state sai,
  • HR Admin gọi API action ngoài scope,
  • token đúng nhưng role sai quyền.
• Ghi rõ:
  • API nào,
  • role nào,
  • state nào,
  • action nào,
  • expected code và expected business behavior.

Output cần nộp

• day40_api_permission_scenarios.md

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

• Bạn test permission bằng ngữ cảnh state + role + action.
• Bạn biết API permission mới là hàng rào thật của hệ thống.
• Bạn phân biệt được lỗi auth với lỗi permission và lỗi workflow.

Lỗi thường gặp

• Chỉ test một role.
• Không gắn state hiện tại vào permission scenario.
• Quên những hành động bị cấm nhưng vẫn gọi API được.

Mentor review note

• Hỏi: Nếu Manager có quyền approve nhưng request đang ở state Rejected, lỗi phát sinh khi approve thành công là workflow issue hay permission issue hay cả hai?
• Xem learner có hiểu permission API như kiểm soát hành động theo state hay không.

​

Ngày 41 - Workflow + Permission Combined

Chủ đề: Ghép state, role và action thành ma trận kiểm thử thực sự Mục tiêu của ngày

• Kết hợp workflow với permission thay vì test riêng lẻ từng lớp.
• Tạo được Role x State x Allowed Actions matrix dùng được cho review và test execution.
• Bỏ ngộ nhận “có workflow rồi thì permission tự hiểu”.

Học gì

• Role-State-Action matrix
• Allowed actions theo từng state
• Invalid actions theo từng role
• Scope theo state nếu có
• History/audit/notification như phần hậu quả của transition

Thực hành gì

• Tạo ma trận Role x State x Allowed Actions cho Leave Request.
• Phải thể hiện:
  • state hiện tại,
  • role,
  • action được phép,
  • action bị cấm,
  • next state hoặc note hậu quả nếu action hợp lệ.
• Thêm ví dụ:
  • Employee không thấy nút Approve nhưng vẫn gọi API approve được.
  • Transition thành công nhưng không có history hoặc notify đúng.

Output cần nộp

• day41_role_state_action_matrix.xlsx

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

• Bạn không còn test workflow và permission tách rời nhau.
• Matrix của bạn giúp nhìn ra ngay hành động nào hợp lệ hoặc bị cấm ở từng state.
• Bạn gắn được transition với role và hậu quả hệ thống.

Lỗi thường gặp

• Matrix thiếu state hoặc thiếu role.
• Chỉ ghi allowed action mà không ghi invalid action quan trọng.
• Không nhắc tới audit/history/notify sau transition.

Mentor review note

• Hỏi: Ở state Submitted, role nào được phép làm gì, role nào tuyệt đối không được làm gì, và hậu quả hệ thống sau action hợp lệ là gì?
• Xem learner có thật sự hiểu tam giác state + role + action hay chỉ đang điền matrix.

​

Ngày 42 - Tổng Kết Tuần 6

Chủ đề: Gói luật vận hành của hệ thống thành một package có thể review thật Mục tiêu của ngày

• Đóng gói workflow, transition matrix, permission matrix, UI permission checklist, API permission scenarios và role-state-action matrix thành một package dùng được.
• Tự đánh giá learner đã hiểu luật nghiệp vụ ở mức nào.
• Chuẩn bị nền cho tuần E2E và regression.

Học gì

• Một workflow/permission package tốt phải cho mentor thấy:
  • flow có đủ state,
  • transition có đủ valid/invalid path,
  • role có đủ scope,
  • permission được test cả UI và API,
  • history/audit/notify có được xem là part of verification hay không.

Thực hành gì

• Chọn Leave Request làm module tổng hợp.
• Đóng gói:
  • workflow note,
  • workflow image,
  • state transition matrix,
  • permission matrix,
  • UI permission checklist,
  • API permission scenarios,
  • role-state-action matrix.
• Tự rà package trước khi nộp:
  • còn thiếu state nào không,
  • còn role nào chưa đưa vào matrix không,
  • đã có action bị cấm chưa,
  • đã kiểm history/audit/notify chưa,
  • có nhầm workflow issue với permission issue không.

Output cần nộp

• week06_workflow_permission_package/

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

• Package của bạn thể hiện rõ luật vận hành của module.
• Bạn giải thích được vì sao một action hợp lệ ở state này nhưng bị cấm ở state khác.
• Bạn cho thấy permission phải được nhìn ở cả UI và API.

Lỗi thường gặp

• Nộp đủ file nhưng logic giữa các matrix không nối với nhau.
• Chỉ có happy path, thiếu invalid path.
• Không có phần audit/history/notify sau transition.

Mentor review note

• Hỏi: Nếu giao package này cho một QC khác, họ có đủ thông tin để test đúng state, đúng role và đúng action mà không cần hỏi lại em không?
• Đánh giá package ở góc độ tài sản kiểm thử dùng được trong team, không chỉ ở góc độ “nộp đủ”.

​

Deliverables Cần Nộp

​

KPI & Focus

​

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

• Hoàn thành 100% deliverable bắt buộc.
• Có ít nhất 1 workflow hoàn chỉnh cho Leave Request.
• day37_state_transition_matrix.xlsx phải có:
  • state chính,
  • transition hợp lệ,
  • ít nhất 3 action bị cấm hoặc invalid transition quan trọng.
• day38_permission_matrix.xlsx phải có đủ role cơ bản:
  • Employee
  • Line Manager
  • HR Admin
  • Super Admin
• day39_ui_permission_checklist.md phải bao phủ:
  • button visibility
  • disabled action
  • route/detail access
• day40_api_permission_scenarios.md phải có ít nhất 1 scenario chứng minh UI chặn chưa đủ, API phải chặn thật.
• day41_role_state_action_matrix.xlsx phải thể hiện được action hợp lệ và action bị cấm theo từng state.
• Package cuối tuần phải có kiểm history/audit hoặc notification sau ít nhất 1 transition quan trọng.

​

Focus của tuần

• Test the rule, not the screen: đừng dừng ở việc “có nút hay không”.
• State + Role + Action together: thiếu một đỉnh của tam giác này thì test sẽ hở.
• UI permission is not enough: backend phải chặn thật.
• Invalid path matters: action bị cấm thường là nơi bug nghiêm trọng nằm.

​

Mini Rubric Cho Tuần 6

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à Bao phủ transition hợp lệ/không hợp lệ, Phân biệt UI permission và API permission, và Kết hợp workflow với permission.

​

Common Mistakes

​

Mentor Review Guide

​

Review matrix như thế nào

• Đọc workflow để hiểu vòng đời trước.
• So state transition matrix với workflow xem có thiếu state hoặc transition nào không.
• So permission matrix với role-state-action matrix xem có role nào bị rơi hoặc action nào không được map.
• Tìm trước các invalid action và action bị cấm, vì đó là vùng dễ hở nhất.

​

Nhìn gì để biết learner hiểu luật nghiệp vụ

• Learner có giải thích được vì sao action này chỉ hợp lệ ở state này không.
• Learner có gắn role với state thay vì chỉ gắn role với action không.
• Learner có coi history/audit/notify là một phần của verify hay bỏ qua.
• Learner có phân biệt được UI chặn và backend chặn không.

​

Hỏi gì để kiểm tra logic state-role-action

• Ở state Submitted, Employee còn được làm gì? Manager được làm gì?
• Action nào nhìn hợp lý trên UI nhưng thực ra bị cấm theo workflow?
• Nếu role không thấy nút trên UI nhưng API vẫn mở, em classify bug này thế nào?
• Transition này thành công thì hệ thống phải để lại dấu vết gì?
• Nếu request bị Reject, có cho Edit hay Resubmit không, và ai được làm?

​

Dấu hiệu học viên làm máy móc vs hiểu thật

​

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

1. Sửa thiếu state và thiếu invalid action trước.
2. Sửa nhầm lẫn giữa workflow bug và permission bug trước khi tối ưu format matrix.
3. Sửa bỏ sót API permission trước khi tối ưu UI checklist.
4. Nếu learner chưa nhìn ra history/audit/notify, kéo lại phần “hậu quả của transition” trước khi đi tiếp.

​

Self-Check Cuối Tuần

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

• Tôi đã vẽ được workflow đủ state chính cho Leave Request.
• Tôi biết state nào cho phép action nào và state nào cấm action nào.
• Tôi phân biệt được UI permission và API permission.
• Tôi biết role nào được làm gì ở state nào.
• Tôi đã test cả hành động bị cấm, không chỉ happy path.
• Tôi có nhớ kiểm history, audit log hoặc notification sau transition quan trọng.
• Tôi có phân biệt được bug workflow với bug permission.
• 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

• Workflow matrix: /templates/workflow-matrix-template
• Permission matrix: /templates/permission-matrix-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 6, học viên đã đi thêm một bước rất quan trọng: từ chỗ test chức năng đơn lẻ sang chỗ test được luật vận hành của hệ thống theo trạng thái, vai trò và hành động. Đây là lớp năng lực phân biệt rõ QC hệ thống với kiểu test bề mặt theo form hoặc list page. Khi bước sang tuần E2E và regression, hãy giữ ba mindset này:

• đừng chỉ hỏi “tính năng có chạy không”, hãy hỏi “đúng người có được làm đúng việc ở đúng state không”;
• đừng chỉ test action hợp lệ, hãy test cả action bị cấm;
• đừng coi permission là chuyện UI, hãy luôn nhớ backend phải chặn thật và hệ thống phải để lại dấu vết đúng sau transition.

Giữ được ba điều đó, learner sẽ theo được các module nghiệp vụ phức tạp hơn rất nhiều, vì lúc này bạn đã bắt đầu test được luật chơi thật của hệ thống.