Tuần 5 - SQL Cơ Bản Cho QC

Bắt đầu nhìn tận dữ liệu gốc, không chỉ nhìn điều hệ thống đang hiển thị. Tuần 5 là thời điểm học viên bước thêm một lớp nữa vào bên trong hệ thống: từ API response sang dữ liệu đang thật sự được lưu trong database. Ở tuần này, SQL không được dạy như một kỹ năng lập trình, mà như một công cụ kiểm chứng: record có được tạo đúng không, field có được cập nhật đúng không, trạng thái xóa có đúng loại không, dữ liệu hiển thị có khớp dữ liệu lưu trữ không. Đây là tuần giúp học viên bỏ nỗi sợ “SQL là việc của dev hoặc DBA” và thay bằng một cách nhìn thực dụng hơn: query đúng mục tiêu quan trọng hơn query khó. Nếu không vững tuần này, học viên rất dễ test đúng bề mặt nhưng không chắc dữ liệu đã lưu đúng, hoặc nhìn thấy dữ liệu hiển thị sai mà không phân biệt được bug ở UI, API hay DB.

Với QC hệ thống, SQL là kính lúp dữ liệu. Mục tiêu không phải viết query phức tạp, mà là xác minh đúng record, đúng field, đúng trạng thái và đúng dấu vết của thao tác vừa xảy ra.

​

Snapshot

​

Mục Tiêu Tuần

​

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

Học viên cần hiểu SQL cho QC không phải để xây hệ thống, mà để đọc dữ liệu và xác minh sự thật đang nằm trong database. Tuần này giúp học viên nắm được các mảnh kiến thức đủ dùng để verify:

• SELECT, WHERE, ORDER BY
• LIKE, IN, BETWEEN
• JOIN
• COUNT
• audit fields và trạng thái record
• soft delete và hard delete

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

• Query đúng cú pháp chưa chắc đã đúng mục tiêu verify.
• Cùng một record có thể xuất hiện khác nhau trên UI, API và DB vì transform, mapping hoặc format.
• Kiểm dữ liệu phải luôn gắn với một thao tác hoặc một hành vi hệ thống cụ thể.

​

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 team:

• Query được đúng record theo điều kiện đủ hẹp.
• Kiểm được dữ liệu sau thao tác create, update, delete.
• Kiểm được các field quan trọng như status, updated_at, deleted_at, foreign key cơ bản hoặc field mapping chính.
• Dùng JOIN và COUNT ở mức đủ để verify record, relation và số liệu.
• Compare được cùng một flow qua ba lớp: UI, API và DB.

​

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

Tuần 5 xây tư duy: query không phải để chứng minh mình biết SQL, mà để chứng minh hệ thống đang lưu dữ liệu đúng hay sai. QC tốt không viết query vì “hay”, mà vì cần trả lời một câu hỏi rất cụ thể:

• record nào vừa được tạo,
• field nào vừa đổi,
• xóa này là xóa thật hay chỉ đánh dấu xóa,
• dữ liệu API trả về có đang phản ánh đúng DB hay không,
• UI đang hiển thị bản raw data hay data đã transform.

Khi tư duy này chắc, learner sẽ sang tuần workflow/permission với khả năng verify sâu hơn rất nhiều.

​

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

Tuần 5 là tuần học viên bắt đầu kiểm chứng dữ liệu tận gốc. Sau khi đã nhìn UI, viết bug report và test API, learner giờ cần đủ năng lực để nhìn vào nơi hệ thống đang lưu sự thật: database.

​

Nhiều bug không thể kết luận nếu không check DB

Có những tình huống nhìn ở UI hoặc API vẫn chưa đủ để kết luận:

• UI báo lưu thành công, nhưng record trong DB thiếu field quan trọng.
• API trả về dữ liệu đúng format, nhưng dữ liệu gốc lưu sai value.
• Nút Delete biến mất khỏi UI, nhưng record không hề bị xóa hoặc chưa được đánh dấu xóa đúng.
• UI list không thấy record mới, nhưng DB đã có record nên lỗi nằm ở lớp hiển thị hoặc filter.

Đây là lý do SQL verification là một năng lực cốt lõi của QC hệ thống, không phải một kỹ năng “có thì tốt”.

​

DB verification là cầu nối từ API sang workflow và integration

Tuần 4 giúp learner nhìn được request/response. Tuần 5 đi tiếp một bước: đối chiếu API với DB để hiểu dữ liệu thực sự có thay đổi không. Khi đã làm được điều này, learner sẽ dễ hơn rất nhiều khi sang:

• verify workflow theo state,
• verify permission theo impact dữ liệu,
• verify integration theo chuỗi UI -> API -> DB.

​

Nếu không biết verify data, QC rất dễ pass sai hoặc log bug sai gốc

Những lỗi người mới hay gặp:

• Query đúng cú pháp nhưng sai mục tiêu verify.
• Kiểm nhầm record vì điều kiện quá rộng.
• Không kiểm audit fields như updated_at, deleted_at, status.
• Không phân biệt soft delete và hard delete.
• Chỉ đối chiếu UI mà không kiểm DB.
• JOIN sai bảng hoặc sai khóa nên kết luận sai.

Tuần này rất quan trọng vì nó rèn một kỷ luật mới: trước khi kết luận dữ liệu đúng hoặc sai, QC phải chắc rằng mình đang nhìn đúng record, đúng field và đúng ngữ cảnh thao tác.

​

SQL Cho QC Khác Gì SQL Cho Dev

QC không cần viết query phức tạp để có giá trị. Query ngắn nhưng đúng record và đúng mục tiêu verify luôn đáng tin hơn query dài mà không trả lời đúng câu hỏi.

​

Query Đúng Cú Pháp Nhưng Vẫn Sai Kiểm Chứng

QC phải luôn tự hỏi: query này đang chứng minh điều gì, và điều kiện đã đủ hẹp để chỉ ra đúng record chưa?

​

Soft Delete vs Hard Delete

Người mới rất hay thấy record không còn trên UI rồi kết luận “xóa thành công”, trong khi DB chỉ đang soft delete hoặc thậm chí không đổi gì cả.

​

UI Data vs API Data vs DB Data

Một record có thể không giống hệt nhau ở ba lớp:

• UI thường hiển thị dữ liệu đã format, rút gọn hoặc transform.
• API có thể trả raw data hoặc structured data ở mức backend contract.
• DB lưu dữ liệu gốc, foreign key, code value hoặc trạng thái hệ thống.

So sánh ba lớp này mà không cùng ngữ cảnh là một nguồn sai phổ biến của QC mới.

​

Một DB Verification Note Tốt Trông Như Thế Nào

DB verification note tốt không phải chỉ chép query. Nó phải giúp mentor hiểu learner đang verify gì:

• thao tác nào vừa được thực hiện,
• query nào được dùng để kiểm,
• record nào hoặc field nào là trọng tâm,
• kết quả query nói lên điều gì,
• giới hạn của việc kiểm đó là gì.

Nếu đọc note mà mentor không biết query đang chứng minh điều gì, note đó chưa đạt.

​

Kế Hoạch Theo Ngày

​

Ngày 29 - SQL Select Cơ Bản

Chủ đề: Đọc đúng record trước khi nghĩ tới verify sâu hơn Mục tiêu của ngày

• Hiểu SELECT như điểm bắt đầu để nhìn vào dữ liệu gốc.
• Biết query đọc dữ liệu theo hướng QC, không theo hướng học cú pháp đơn thuần.
• Bỏ ngộ nhận “SQL là phải viết query khó mới có giá trị”.

Học gì

• SELECT, FROM, WHERE, ORDER BY, LIMIT
• Khi nào cần chọn ít cột thay vì SELECT *
• Cách dùng WHERE để thu hẹp record theo context test

Thực hành gì

• Viết tối thiểu 10 câu query cơ bản để đọc dữ liệu từ 1-2 bảng demo.
• Với mỗi query, thêm comment SQL ngắn mô tả:
  • mục tiêu verify,
  • bảng đang đọc,
  • vì sao điều kiện hiện tại đủ hoặc chưa đủ hẹp.
• Tạo 1 ví dụ query chạy được nhưng dễ chọn nhầm record.

Output cần nộp

• day29_sql_select.sql

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

• Bạn biết query để tìm đúng record thay vì query cho “ra dữ liệu là được”.
• Bạn không lạm dụng SELECT * khi chỉ cần vài field để verify.
• Bạn bắt đầu gắn query với một câu hỏi verify cụ thể.

Lỗi thường gặp

• Chỉ học cú pháp mà không nói đang muốn kiểm gì.
• Điều kiện query quá rộng.
• Kết luận từ query đầu tiên mà chưa chắc đó là đúng record.

Mentor review note

• Hỏi: Query này đang chứng minh điều gì, và tại sao em tin record em đang nhìn là đúng record cần verify?
• Ưu tiên review mục tiêu verify trước độ dài hay độ “đẹp” của query.

​

Ngày 30 - Filter Dữ Liệu

Chủ đề: Thu hẹp dữ liệu đủ chính xác để tránh verify nhầm Mục tiêu của ngày

• Biết dùng filter để tìm đúng record theo trạng thái, keyword, khoảng ngày hoặc giá trị null.
• Hiểu query đủ hẹp quan trọng hơn query chạy nhanh.
• Bỏ ngộ nhận “có kết quả trả về là đủ”.

Học gì

• LIKE, IN, BETWEEN, IS NULL, DISTINCT
• Kết hợp nhiều điều kiện WHERE
• Lọc theo thời gian, trạng thái, tên hoặc id

Thực hành gì

• Viết query cho các tình huống:
  • tìm theo tên,
  • lọc theo trạng thái,
  • lọc theo khoảng ngày,
  • tìm record chưa được cập nhật,
  • tìm record có giá trị null ở field quan trọng.
• Với mỗi query, thêm comment SQL mô tả vì sao điều kiện đó giúp tránh chọn nhầm record.
• Tạo 1 ví dụ:
  • query đúng cú pháp nhưng điều kiện quá rộng nên match sai record.

Output cần nộp

• day30_sql_filter.sql

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

• Bạn biết thu hẹp dữ liệu theo đúng ngữ cảnh test.
• Bạn không dùng filter mơ hồ nếu có thể dùng điều kiện cụ thể hơn.
• Bạn biết khi nào cần combine nhiều điều kiện để tránh false conclusion.

Lỗi thường gặp

• LIKE '%text%' quá rộng khi đã có id hoặc field định danh.
• Quên lọc theo thời gian hoặc trạng thái nên lẫn record cũ.
• Dùng điều kiện đúng cú pháp nhưng không phục vụ verify.

Mentor review note

• Hỏi: Nếu trong DB có 100 record giống nhau về tên, query của em còn đủ tin cậy để verify không?
• Kiểm tra learner có hiểu “độ hẹp của điều kiện” là yếu tố sống còn của DB verification hay không.

​

Ngày 31 - JOIN Cơ Bản

Chủ đề: Hiểu quan hệ bảng đủ để verify dữ liệu liên kết Mục tiêu của ngày

• Hiểu JOIN ở mức đủ để nối record chính với dữ liệu liên quan.
• Bỏ ngộ nhận “JOIN là kiến thức SQL nâng cao không cần cho QC”.
• Biết join đúng khóa để không kết luận sai.

Học gì

• INNER JOIN, LEFT JOIN
• Quan hệ cơ bản giữa bảng chính và bảng tham chiếu
• Foreign key ở mức phục vụ verify

Thực hành gì

• Join 2-3 bảng demo như:
  • employees + departments
  • orders + customers
• Với mỗi query, thêm comment SQL mô tả:
  • đang verify relation gì,
  • khóa nào được dùng để join,
  • nếu join sai thì hậu quả verify là gì.
• Tạo 1 ví dụ JOIN đúng cú pháp nhưng sai khóa dẫn tới kết quả sai.

Output cần nộp

• day31_sql_join.sql

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

• Bạn biết join để chứng minh relation, không chỉ để “lấy thêm cột”.
• Bạn giải thích được tại sao khóa join hiện tại là đúng.
• Bạn hiểu join sai khóa có thể làm toàn bộ kết luận không còn đáng tin.

Lỗi thường gặp

• Join theo cột trùng tên nhưng sai ý nghĩa.
• Không phân biệt record chính và record tham chiếu.
• Query ra nhiều dòng bất thường nhưng không nghi ngờ khóa join.

Mentor review note

• Hỏi: Nếu query này ra dữ liệu hợp lý bề ngoài nhưng em join sai khóa, em đang gặp rủi ro verify gì?
• Xem learner có hiểu bản chất relation hay chỉ ghép bảng theo mẫu.

​

Ngày 32 - COUNT Và Verify Record

Chủ đề: Dùng số lượng và aggregation để xác minh trạng thái dữ liệu Mục tiêu của ngày

• Dùng COUNT và GROUP BY để verify duplicate, active count và record mới tạo.
• Biết số lượng cũng là một tín hiệu bug quan trọng.
• Bỏ ngộ nhận “đã thấy 1 record là đủ, không cần nhìn tổng thể”.

Học gì

• COUNT(*)
• GROUP BY
• Verify duplicate
• Verify active/inactive count
• Verify record existence sau thao tác

Thực hành gì

• Viết query kiểm:
  • số record active,
  • duplicate theo mã hoặc email,
  • record mới tạo trong khoảng thời gian gần nhất,
  • số record bị soft delete.
• Với mỗi query, thêm comment SQL mô tả:
  • mục tiêu verify,
  • metric nào đang được kiểm,
  • kết quả nào sẽ bị xem là bất thường.
• Tạo ít nhất 1 ví dụ:
  • record có tồn tại nhưng count logic vẫn fail.

Output cần nộp

• day32_sql_verify.sql

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

• Bạn dùng được COUNT để verify logic chứ không chỉ đếm cho có.
• Bạn biết duplicate hoặc count lệch là tín hiệu bug quan trọng.
• Bạn nói được query đang chứng minh điều gì.

Lỗi thường gặp

• Chỉ đếm tổng số record mà không gắn với trạng thái hoặc điều kiện nghiệp vụ.
• Không group đúng field nên bỏ sót duplicate.
• Thấy count “có vẻ hợp lý” rồi kết luận quá nhanh.

Mentor review note

• Hỏi: Vì sao query count này đủ để nói có duplicate hoặc không duplicate?
• Kiểm tra learner có dùng COUNT như một công cụ verify chứ không chỉ như bài cú pháp.

​

Ngày 33 - QC Verify DB Sau Thao Tác

Chủ đề: Sau create, update, delete cần nhìn gì trong DB Mục tiêu của ngày

• Hiểu create/update/delete không chỉ là có record hay không.
• Biết check field chính, audit fields và trạng thái xóa.
• Bỏ ngộ nhận “UI báo thành công là xong”.

Học gì

• Sau Create: check record mới, field mặc định, foreign key chính, status ban đầu
• Sau Update: check field thay đổi, updated_at, updated_by nếu có
• Sau Delete: check deleted_at, is_deleted, status hoặc sự biến mất của record
• Audit fields và ý nghĩa verify của chúng

Thực hành gì

• Tạo checklist verify DB cho 3 thao tác:
  • create,
  • update,
  • delete.
• Với mỗi thao tác, ghi rõ:
  • field bắt buộc phải kiểm,
  • field audit nên kiểm,
  • dấu hiệu của soft delete,
  • khi nào cần đối chiếu thêm API hoặc UI.
• Tạo ít nhất 2 ví dụ:
  • create thành công nhưng status mặc định sai,
  • delete trên UI nhưng DB chỉ set deleted_at hoặc ngược lại không set gì.

Output cần nộp

• day33_db_verification_checklist.md

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

• Bạn biết verify create/update/delete ở mức field và trạng thái.
• Bạn nhắc được audit fields thay vì chỉ check “có record hay không”.
• Bạn phân biệt được soft delete và hard delete trong context verify.

Lỗi thường gặp

• Chỉ check record tồn tại mà không check field quan trọng.
• Bỏ sót updated_at, deleted_at, status.
• Nhìn record biến mất khỏi UI rồi kết luận delete thành công.

Mentor review note

• Hỏi: Sau thao tác update, ngoài field nghiệp vụ chính, em còn cần check dấu vết nào để biết update thực sự xảy ra?
• Xem learner có hiểu DB verification như kiểm hành vi hệ thống chứ không chỉ kiểm snapshot dữ liệu.

​

Ngày 34 - Compare UI / API / DB

Chủ đề: Nối ba lớp dữ liệu để xác định lỗi nằm ở đâu Mục tiêu của ngày

• Compare được cùng một record qua UI, API và DB.
• Hiểu sự khác nhau giữa raw data và data đã transform.
• Bỏ ngộ nhận “dữ liệu giống nhau ở ba lớp là chuyện hiển nhiên”.

Học gì

• UI có thể format dữ liệu khác DB thế nào
• API có thể map hoặc transform dữ liệu ra sao
• Khi nào mismatch là bug hiển thị, bug mapping hay bug dữ liệu gốc

Thực hành gì

• Chọn 1 màn hình list hoặc detail.
• So sánh 1 record ở 3 lớp:
  • UI
  • API response
  • DB row
• Ghi rõ:
  • field nào giống nhau,
  • field nào khác nhau vì format hợp lệ,
  • field nào khác nhau đáng nghi.
• Tạo ít nhất 2 ví dụ:
  • UI hiển thị tên phòng ban nhưng DB chỉ lưu department_id,
  • UI hiển thị value đã format còn DB lưu raw code/value.

Output cần nộp

• day34_ui_api_db_compare.md

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

• Bạn compare theo cùng một record và cùng một ngữ cảnh thao tác.
• Bạn không kết luận bug chỉ vì UI và DB không giống từng ký tự.
• Bạn mô tả được đoạn nào trong flow đang transform dữ liệu.

Lỗi thường gặp

• So sánh UI và DB mà quên lớp API ở giữa.
• So record không cùng id hoặc không cùng thời điểm.
• Kết luận sai vì không hiểu data đã được format hoặc mapping.

Mentor review note

• Hỏi: Field này khác nhau giữa UI và DB là hợp lý hay là bug? Em dựa vào đâu để kết luận?
• Kiểm tra learner có thật sự hiểu ba lớp dữ liệu hay chỉ chụp lại ba màn hình khác nhau.

​

Ngày 35 - Tổng Kết Tuần 5

Chủ đề: Gói tư duy verify dữ liệu thành một package end-to-end Mục tiêu của ngày

• Kết nối SQL select/filter/join/verify với checklist DB verification và compare UI/API/DB.
• Tự đánh giá learner đã dùng SQL đúng như công cụ verify hay chưa.
• Chuẩn bị nền để sang tuần workflow/permission với khả năng nhìn state và data impact tốt hơn.

Học gì

• Một package verify dữ liệu tốt phải cho thấy:
  • learner đang kiểm thao tác nào,
  • query nào được dùng để verify,
  • record nào là record trọng tâm,
  • kết luận cuối cùng về UI/API/DB là gì.
• SQL note, checklist và comparison note phải nối thành một logic xuyên suốt.

Thực hành gì

• Chọn 1 module CRUD đơn giản.
• Verify end-to-end:
  • thao tác trên UI,
  • API response liên quan,
  • dữ liệu trong DB.
• Đóng gói:
  • query runnable,
  • checklist verify,
  • note compare 3 lớp,
  • kết luận ngắn learner đang chứng minh điều gì.
• Tự rà lại package:
  • có query nào quá rộng không,
  • có chỗ nào đang chọn nhầm record không,
  • có field audit nào bị bỏ sót không,
  • compare có cùng ngữ cảnh chưa.

Output cần nộp

• week05_ui_api_db_e2e/

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

• Package của bạn không chỉ có query, mà có logic verify xuyên suốt.
• Bạn chứng minh được SQL đang phục vụ câu hỏi kiểm thử nào.
• Bạn chỉ ra được ít nhất 1 điểm dễ sai nếu compare không đúng ngữ cảnh.

Lỗi thường gặp

• Nộp nhiều query nhưng không giải thích query đang chứng minh gì.
• Query được nhưng không nối với UI/API.
• Kết luận quá nhanh từ một truy vấn đơn lẻ.

Mentor review note

• Hỏi: Nếu bỏ đi phần giải thích mục tiêu verify, chỉ nhìn query, mentor còn hiểu được bao nhiêu phần trong logic kiểm của em?
• Đánh giá package ở góc độ dùng được trong team, không chỉ ở góc độ “query chạy được”.

​

Deliverables Cần Nộp

​

KPI & Focus

​

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

• Hoàn thành 100% deliverable bắt buộc.
• Viết tối thiểu 15 query cơ bản phục vụ verify trong các output .sql.
• Phải verify được ít nhất:
  • 1 record mới tạo,
  • 1 record được cập nhật,
  • 1 trường hợp xóa mềm hoặc logic xóa tương đương.
• day33_db_verification_checklist.md phải có audit fields và phân biệt soft delete.
• day34_ui_api_db_compare.md phải compare ít nhất 1 record ở cùng ngữ cảnh qua UI, API, DB.
• Các file .sql ngày 29-32 phải có comment thể hiện:
  • mục tiêu verify,
  • query chính,
  • kết luận ngắn hoặc dấu hiệu pass/fail mong đợi.

​

Focus của tuần

• Query for verification: query phải trả lời một câu hỏi kiểm thử cụ thể.
• Correct record first: chọn sai record thì mọi kết luận sau đó đều yếu.
• Audit fields matter: đừng chỉ nhìn data business, hãy nhìn cả dấu vết thao tác.
• Compare with context: UI/API/DB chỉ có giá trị khi được so theo cùng record và cùng thời điểm.

​

Mini Rubric Cho Tuần 5

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à Query đúng mục tiêu, Verify đúng record, Check đúng field và Compare UI/API/DB.

​

Common Mistakes

​

Mentor Review Guide

​

Review SQL notes như thế nào

• Nhìn trước vào comment/mục tiêu verify rồi mới nhìn câu query.
• Kiểm tra query có thực sự bám thao tác learner đang test không.
• Kiểm tra learner có đang giải thích được vì sao chọn bảng, field và điều kiện đó không.

​

Review query có đúng mục tiêu verify không

• Query này đang cố chứng minh record tồn tại, field thay đổi, hay trạng thái xóa?
• Điều kiện đã đủ hẹp chưa?
• Nếu query trả về nhiều dòng, learner có nhận ra rủi ro chọn nhầm record không?
• Nếu query có JOIN, learner có nói được khóa join đúng là gì không?

​

Hỏi gì để kiểm tra learner hiểu data flow

• Query này đang verify thao tác nào từ UI hoặc API?
• Nếu UI nói tạo thành công nhưng query này không ra record, em sẽ nghĩ tới khả năng gì?
• Field nào ở đây là raw data, field nào là dữ liệu đã transform ở UI?
• Delete này là soft delete hay hard delete? Em dựa vào đâu để kết luận?
• Nếu có 2 record cùng tên, query của em còn đáng tin không?

​

Dấu hiệu learner hiểu bản chất vs chỉ học cú pháp

​

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

1. Sửa query sai mục tiêu verify trước.
2. Sửa lỗi chọn nhầm record trước khi tối ưu cú pháp.
3. Sửa thiếu audit fields và nhầm soft delete/hard delete trước.
4. Nếu learner chưa nối được UI/API/DB, kéo lại data flow trước khi đi tiếp tuần sau.

​

Self-Check Cuối Tuần

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

• Tôi query được record theo điều kiện cụ thể, không quá rộng.
• Tôi biết create/update/delete nên check những field nào.
• Tôi hiểu soft delete biểu hiện như thế nào trong DB.
• Tôi compare được cùng một record qua UI, API và DB.
• Tôi biết query của mình đang chứng minh điều gì, không chỉ chạy cho ra kết quả.
• Tôi có kiểm audit fields hoặc status khi cần.
• Tôi biết khi nào UI và DB khác nhau là hợp lý vì transform.
• 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

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

​

Kết Thúc Tuần

Sau tuần 5, học viên đã đi từ việc “thấy dữ liệu hiển thị trên UI” sang việc nhìn được dữ liệu gốc, kiểm được record thật và đối chiếu được ba lớp UI/API/DB. Đây là bước trưởng thành rất quan trọng của QC hệ thống, vì từ thời điểm này learner không chỉ nhìn hành vi bề mặt, mà bắt đầu kiểm được tính đúng đắn của dữ liệu phía sau. Khi bước sang tuần workflow/permission và các phần hệ thống phức tạp hơn, hãy giữ ba mindset này:

• đừng chỉ tin điều UI đang hiển thị, hãy kiểm điều hệ thống thật sự lưu;
• đừng query cho có kết quả, hãy query để trả lời đúng câu hỏi verify;
• đừng kết luận từ một lớp dữ liệu duy nhất, hãy nối UI, API và DB thành một chuỗi kiểm chứng.

Giữ được ba điều đó, những tuần sau sẽ chắc hơn rất nhiều, vì bạn đã có nền verify dữ liệu đủ sâu để theo được state, permission và logic hệ thống phức tạp hơn.