Tuần 4 - API Testing với Postman

Bắt đầu nhìn thấy lớp dữ liệu và hành vi hệ thống nằm phía sau giao diện. Tuần 4 là thời điểm học viên bước xuống một lớp sâu hơn của hệ thống: từ chỗ quan sát UI sang chỗ đọc được request, response và luồng dữ liệu backend. Ở tuần này, API không còn là thứ “dành cho dev”, mà trở thành công cụ để QC kiểm tra xem dữ liệu được gửi đi đúng chưa, hệ thống phản hồi đúng chưa, và lỗi đang nằm ở lớp giao diện hay lớp xử lý. Khi đã hiểu API, học viên sẽ không còn test UI như một hộp đen nữa, mà bắt đầu nhìn thấy xương sống của hệ thống vận hành như thế nào. Nếu không vững tuần này, học viên rất dễ dùng Postman như công cụ bấm thử, gửi request xong nhìn status code rồi kết luận pass mà không thật sự verify điều gì.

API testing giúp QC nhìn thấy dữ liệu đi như thế nào, hệ thống phản hồi ra sao, và lỗi đang nằm ở lớp nào. Không cần là dev mới test được API, nhưng QC tốt bắt buộc phải hiểu API để kiểm đúng dữ liệu và đúng hành vi hệ thống.

​

Snapshot

​

Mục Tiêu Tuần

​

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

Học viên cần hiểu API không phải một “đầu nối kỹ thuật khó hiểu”, mà là nơi hệ thống nhận dữ liệu, xử lý logic và trả phản hồi lại cho UI. Tuần này giúp học viên nắm được những thành phần cơ bản nhưng rất quan trọng của một API request và response:

• Method: GET, POST, PUT, PATCH, DELETE
• Headers, query params, path params
• Request body, response body
• Status code và ý nghĩa của từng nhóm lỗi/thành công
• Auth, token và permission ở mức API

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

• Status code đúng chưa đồng nghĩa với dữ liệu đúng.
• Response hợp lệ không chỉ là JSON đẹp, mà phải đúng field, đúng value, đúng business meaning.
• UI action luôn có khả năng tương ứng với một hoặc nhiều API call phía dưới.

​

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

Tuần 4 không dừng ở việc “gửi được request”, mà đòi hỏi học viên làm được các tác vụ có thể dùng ngay trong team:

• Gửi request bằng Postman với method, params, headers và body đúng ngữ cảnh.
• Đọc response và xác minh đúng status code, message, schema cơ bản, field chính và business data.
• Test được CRUD API ở mức cơ bản.
• Test được auth và permission ở mức API với các tình huống token thiếu, token sai hoặc đúng token nhưng sai quyền.
• Nối được form input trên UI với payload API và hiểu response đang tác động lại UI như thế nào.

​

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

Tuần 4 xây một tư duy rất quan trọng: đừng chỉ nhìn UI, hãy nhìn cả data flow. QC tốt không chỉ hỏi “bấm Save có thành công không”, mà còn hỏi:

• UI đang gửi request nào?
• Payload có map đúng từ input người dùng không?
• Response có thật sự đúng về mặt dữ liệu hay chỉ đúng về status code?
• Lỗi này là do UI gửi sai, API xử lý sai, hay UI hiển thị sai dữ liệu đúng?

Tư duy này là nền để sang tuần verify database, workflow, permission và integration sâu hơn.

​

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

Tuần 4 là bước ngoặt vì đây là lần đầu tiên học viên nhìn thấy dữ liệu không “tự nhiên xuất hiện” trên UI. Phía sau mỗi form, list page, nút Save hay nút Search đều có request, payload, response và trạng thái backend tương ứng.

​

Đây là tuần học viên bắt đầu hiểu dữ liệu đi như thế nào

Trước tuần 4, học viên đã biết:

• đọc requirement,
• thiết kế test case,
• quan sát UI,
• log bug.

Nhưng nếu vẫn chỉ nhìn ở lớp UI, học viên sẽ luôn bị giới hạn: thấy sai mà không biết sai từ đâu. API testing mở ra khả năng trả lời những câu hỏi đó:

• UI đã gửi request chưa?
• Request body có đủ field chưa?
• API trả về lỗi thật hay UI hiểu sai response?
• Response trả về có sai business data không?

​

API testing giúp tách lỗi frontend và backend

Đây là một trong những giá trị thực chiến nhất của tuần 4. Khi một chức năng hiển thị sai dữ liệu, QC cần đủ bình tĩnh để không kết luận ngay theo cảm tính. API testing giúp bóc tách:

• UI sai vì hiển thị response sai,
• hay API đã trả dữ liệu sai từ đầu,
• hay request payload bị map sai từ input người dùng,
• hay auth/permission đang chặn ở lớp backend nhưng UI không xử lý đúng.

Nếu không có lớp nhìn này, bug report sau này sẽ rất yếu và team mất nhiều vòng hỏi lại.

​

Nếu bỏ qua tuần này, các tuần sau sẽ khó đi sâu

• Tuần DB verification: khó đối chiếu UI, API, DB vì chưa quen nhìn data flow.
• Tuần workflow/permission: khó hiểu vì chưa quen test auth, role và response hành vi ở backend.
• Tuần integration/final package: chỉ biết test bề mặt, không lý giải được lỗi ở tầng sâu hơn.

​

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

• Gửi request nhưng không biết mình đang verify gì.
• Chỉ check status code 200 rồi kết luận pass.
• Không kiểm response body, field hoặc business data.
• Không đối chiếu payload với input UI.
• Không hiểu 401 khác 403 ở đâu.
• Gửi request đúng tool nhưng sai context nghiệp vụ.
• Không quản lý environment/token gọn gàng nên collection khó review.
• Collection lộn xộn, request naming yếu, mentor rất khó đọc.

Tuần này quan trọng vì nó rèn một kỷ luật mới: API testing không phải bấm tool, mà là kiểm chứng dữ liệu và hành vi hệ thống một cách có chủ đích.

​

API Testing Cho QC Để Làm Gì

QC không cần viết backend để test API có giá trị. API testing cho QC giúp:

• nhìn được dữ liệu request gửi đi có đúng không,
• nhìn được hệ thống phản hồi bằng dữ liệu nào,
• xác định nhanh lỗi nằm ở UI hay backend,
• kiểm được auth/permission ở lớp không nhìn thấy hết trên UI,
• tăng độ chắc chắn khi verify bug, retest bug hoặc explain impact cho team.

Đây là một kỹ năng điều tra hệ thống, không phải một kỹ năng “dev-only”.

​

Status Code Đúng Chưa Đủ, Còn Phải Kiểm Gì

Status code là tín hiệu đầu tiên, không phải kết luận cuối cùng.

​

401 vs 403 Khác Nhau Thế Nào

Ví dụ:

• Không gửi token khi gọi API GET /employees và nhận 401: hợp lý.
• Gửi token của role Viewer vào API POST /employees và nhận 403: hợp lý.

Người mới rất hay gộp cả hai thành “không có quyền”. Điều đó làm yếu phần verify auth/permission và dẫn tới bug log sai bản chất.

​

Payload UI vs Payload API

Một trong những kỹ năng quan trọng nhất của tuần 4 là nhìn thấy mối nối giữa UI và backend:

• Người dùng nhập Tên nhân viên, Email, Phòng ban trên form.
• UI map các input đó thành request payload.
• API nhận payload, xử lý và trả về response.
• UI dùng response đó để hiển thị toast, update list, chuyển trang hoặc báo lỗi.

Một bug có thể nằm ở bất kỳ đoạn nào trong chuỗi đó.

​

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

API note tốt không phải là ảnh chụp màn hình Postman rồi kết thúc. Nó phải giúp mentor hiểu học viên đang test gì và verify gì:

• API này dùng để làm gì.
• Request gồm method, endpoint, params, headers, body nào.
• Response mong đợi gồm status code, field chính, message hoặc business data nào.
• Điều gì được xem là pass, điều gì đáng ngờ.
• API này liên quan tới thao tác UI nào hoặc dữ liệu nghiệp vụ nào.

Nếu đọc note mà mentor vẫn không biết học viên đang kiểm chứng điều gì, note đó chưa đạt.

​

Kế Hoạch Theo Ngày

​

Ngày 22 - API Basics

Chủ đề: Hiểu request/response như ngôn ngữ cơ bản của hệ thống Mục tiêu của ngày

• Hiểu API là gì và vì sao QC cần test API.
• Nắm được method, headers, params, body, status code theo cách dùng được ngay.
• Vượt qua ngộ nhận “API là việc của dev, QC chỉ cần nhìn UI”.

Học gì

• GET, POST, PUT, PATCH, DELETE
• Headers, query params, path params
• Request body, response JSON
• Status code thường gặp: 200, 201, 400, 401, 403, 404, 500
• API call đứng ở đâu trong luồng UI -> backend -> UI

Thực hành gì

• Viết note ngắn cho từng method với ví dụ nghiệp vụ thực tế.
• Chọn 1 tính năng như Tạo nhân viên hoặc Login và chỉ ra:
  • UI action nào gọi API nào,
  • API đó nhận gì,
  • API đó trả gì.
• Tạo bảng phân biệt request hợp lệ với request gửi được nhưng verify sai.

Output cần nộp

• day22_api_basics.md

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

• Bạn giải thích được API bằng logic hệ thống, không chỉ bằng định nghĩa sách vở.
• Bạn biết method khác nhau kéo theo mục đích kiểm khác nhau.
• Bạn không còn nhìn API như một “hộp đen kỹ thuật”.

Lỗi thường gặp

• Học tên method nhưng không hiểu nên dùng để verify điều gì.
• Chỉ mô tả request và response ở mức lý thuyết.
• Không nói được API liên quan gì tới hành vi trên UI.

Mentor review note

• Hỏi: Nếu UI báo lưu thành công nhưng em chưa nhìn API, em còn thiếu lớp thông tin gì?
• Kiểm tra xem học viên đã thật sự hiểu API như một phần của data flow hay chưa.

​

Ngày 23 - Làm Quen Postman

Chủ đề: Dùng Postman như công cụ kiểm chứng, không phải công cụ bấm thử Mục tiêu của ngày

• Biết tạo request, collection, folder và environment theo cách dễ review.
• Hiểu variable giúp test API có tổ chức hơn như thế nào.
• Vượt qua ngộ nhận “save request là đủ”.

Học gì

• Tạo request, send request, save request
• Collections và folder grouping
• Environment variables, token variable, base URL
• Naming request rõ ràng theo module và hành vi
• Cách tổ chức collection để mentor đọc là hiểu phạm vi test

Thực hành gì

• Tạo collection QC Learning API.
• Chia folder cơ bản:
  • Auth
  • Employee
  • Product hoặc một module demo tương tự
• Tạo environment với base_url, token, invalid_token nếu phù hợp.
• Viết 1 note ngắn giải thích vì sao cách tổ chức collection này giúp review dễ hơn.

Output cần nộp

• day23_postman_collection.json

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

• Collection của bạn có naming và grouping rõ.
• Bạn không hardcode mọi giá trị nếu có thể dùng variable.
• Mentor mở collection là hiểu được learner đang test nhóm API nào.

Lỗi thường gặp

• Request đặt tên mơ hồ như test1, api1, new request.
• Không tách folder nên collection rất khó đọc.
• Không dùng environment/token variable, làm bài khó review và khó chạy lại.

Mentor review note

• Hỏi: Nếu đưa collection này cho một bạn khác, họ có biết request nào phục vụ auth và request nào phục vụ CRUD không?
• Ưu tiên review tính rõ ràng và tái sử dụng của collection trước số lượng request.

​

Ngày 24 - Test GET API

Chủ đề: Đọc dữ liệu trả về, không dừng ở 200 OK Mục tiêu của ngày

• Test được list API và detail API ở mức QC thực dụng.
• Biết verify response data, pagination, empty response và field quan trọng.
• Vượt qua ngộ nhận “GET chỉ cần check code 200”.

Học gì

• GET list vs GET detail
• Query params: page, limit, keyword, filter
• Empty response, no data, pagination metadata
• Field presence, data type cơ bản, count/total logic

Thực hành gì

• Test tối thiểu 5 GET API từ hệ thống demo hoặc public API phù hợp.
• Với mỗi API, ghi rõ:
  • mục tiêu API,
  • params dùng để test,
  • status code,
  • field chính cần verify,
  • điều gì đáng ngờ nếu code đúng nhưng data sai.
• Tạo ít nhất 1 ví dụ kiểu:
  • GET trả 200 nhưng total sai,
  • GET trả 200 nhưng thiếu field quan trọng,
  • GET trả 200 nhưng danh sách không khớp filter.

Output cần nộp

• day24_get_api_notes.md

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

• Bạn biết kiểm không chỉ code mà còn cả body response.
• Bạn biết GET list có thêm logic pagination/filter chứ không chỉ “lấy dữ liệu”.
• Bạn chỉ ra được ít nhất 1 tình huống 200 nhưng vẫn fail về mặt dữ liệu.

Lỗi thường gặp

• Chỉ ghi code 200/404 mà không nói data có đúng không.
• Không đối chiếu params với dữ liệu trả về.
• Không kiểm empty response hoặc total count.

Mentor review note

• Hỏi: Nếu GET trả 200 nhưng danh sách sai total count, em coi là pass hay fail? Vì sao?
• Kiểm tra xem học viên có thật sự biết verify response data hay chưa.

​

Ngày 25 - Test POST / PUT / PATCH / DELETE

Chủ đề: Verify CRUD API theo góc nhìn dữ liệu và side effect Mục tiêu của ngày

• Test được create, update, patch và delete ở mức cơ bản.
• Biết verify validation error và side effect dữ liệu.
• Vượt qua ngộ nhận “gửi request thành công là đủ”.

Học gì

• POST để tạo dữ liệu
• PUT / PATCH để cập nhật dữ liệu
• DELETE để xóa hoặc soft delete tùy context
• Validation error ở mức API
• Side effect sau create/update/delete

Thực hành gì

• Gửi request tạo, sửa, xóa dữ liệu bằng Postman.
• Với mỗi nhóm CRUD, ghi rõ:
  • payload gửi đi,
  • status code mong đợi,
  • field nào cần verify trong response,
  • side effect nào cần kiểm thêm.
• Tạo ít nhất 2 ví dụ:
  • POST trả 201 nhưng record tạo sai dữ liệu,
  • DELETE trả 200 nhưng record vẫn còn hiển thị hoặc trạng thái xóa không đúng.

Output cần nộp

• day25_crud_api_notes.md

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

• Bạn verify được create/update/delete không chỉ bằng status code.
• Bạn nhìn thấy validation error như một phần bắt buộc của test API.
• Bạn biết side effect dữ liệu sau hành động CRUD là thứ cần kiểm.

Lỗi thường gặp

• Không đối chiếu response với payload gửi đi.
• Không kiểm record sau update hoặc delete.
• Gửi request đúng tool nhưng sai context nghiệp vụ, ví dụ patch sai field hoặc bỏ quên uniqueness rule.

Mentor review note

• Hỏi: POST trả 201 nhưng một field business quan trọng bị lưu sai, em xử lý thế nào?
• Xem học viên có hiểu CRUD API theo góc nhìn dữ liệu hay chỉ theo thao tác tool.

​

Ngày 26 - Auth Và Permission Trong API

Chủ đề: Xác minh user nào được làm gì ở lớp backend Mục tiêu của ngày

• Hiểu auth và permission ở mức API cơ bản.
• Phân biệt đúng 401 và 403.
• Vượt qua ngộ nhận “UI đã ẩn nút thì API chắc cũng an toàn”.

Học gì

• Bearer token
• Token thiếu, token sai, token hết hạn
• Unauthorized vs Forbidden
• Role-based access ở mức API
• Tại sao permission phải được kiểm ở backend, không chỉ ở UI

Thực hành gì

• Chọn 1 API cần quyền như POST /employees hoặc tương tự.
• Test 3 tình huống:
  • không có token,
  • token sai hoặc hết hạn,
  • đúng token nhưng role không đủ quyền.
• Ghi rõ:
  • status code nhận được,
  • message/error body,
  • vì sao đây là 401 hay 403,
  • nếu UI chỉ ẩn nút nhưng API không chặn thì rủi ro gì.

Output cần nộp

• day26_auth_permission_api.md

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

• Bạn phân biệt được xác thực với phân quyền.
• Bạn không gọi chung mọi lỗi quyền là “không có quyền”.
• Bạn thấy được rủi ro nếu permission chỉ nằm ở UI.

Lỗi thường gặp

• Nhầm 401 và 403.
• Chỉ test “đúng token” mà không test token thiếu/sai.
• Không mô tả impact của lỗi permission ở backend.

Mentor review note

• Hỏi: Nếu Viewer không thấy nút Create trên UI nhưng vẫn gọi được API tạo record, đây là lỗi gì và nghiêm trọng ở đâu?
• Kiểm tra xem learner có hiểu permission ở lớp API như một control thật hay không.

​

Ngày 27 - Mapping UI Với API

Chủ đề: Nối thao tác người dùng với payload và response backend Mục tiêu của ngày

• Nối được input UI với request payload.
• Nối được response API với hành vi hiển thị của UI.
• Vượt qua ngộ nhận “UI và API là hai bài riêng”.

Học gì

• Một form Create hoặc Update map field UI sang payload như thế nào.
• Response ảnh hưởng toast, redirect, list refresh hoặc error state ra sao.
• Dấu hiệu payload map sai, field bị thiếu, value bị chuyển sai type hoặc sai key.

Thực hành gì

• Chọn 1 form Create thực tế hoặc demo.
• Ghi lại:
  • input trên UI,
  • payload request,
  • response body,
  • UI update sau response.
• Tạo ít nhất 2 ví dụ:
  • UI submit thành công nhưng payload thiếu field quan trọng,
  • UI hiển thị success nhưng response trả về data chưa đúng.

Output cần nộp

• day27_ui_api_mapping.md

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

• Bạn nối được input UI với key trong payload.
• Bạn nhìn ra response ảnh hưởng tới UI như thế nào.
• Bạn có thể mô tả bug nằm ở UI mapping hay API response.

Lỗi thường gặp

• Chỉ chụp payload mà không đối chiếu với input trên UI.
• Không xem response tác động lại UI ra sao.
• Kết luận dữ liệu sai nhưng không chỉ ra sai ở đoạn nào của flow.

Mentor review note

• Hỏi: Trong flow này, nếu dữ liệu hiển thị sai trên UI, em sẽ kiểm ở những điểm nào trước để xác định lỗi nằm ở đâu?
• Xem học viên có thật sự hiểu data flow hay chỉ chụp lại request/response.

​

Ngày 28 - Tổng Kết Tuần 4

Chủ đề: Gói API testing thành một package có thể review và dùng tiếp Mục tiêu của ngày

• Kết nối collection, API notes, auth tests và UI/API mapping thành một package thống nhất.
• Tự đánh giá learner đã hiểu API ở mức nào.
• Chuẩn bị nền để sang giai đoạn verify database và integration sâu hơn.

Học gì

• API testing package tốt phải thể hiện được:
  • learner đang test API nào,
  • đang verify điều gì,
  • auth/permission được kiểm thế nào,
  • UI được nối với backend ra sao.
• Collection chỉ là một phần; giá trị thật nằm ở logic verify đi kèm.

Thực hành gì

• Tạo 1 mini package API test gồm:
  • collection,
  • tối thiểu 10 request mẫu,
  • notes verify cho GET/CRUD/auth,
  • UI/API mapping cho ít nhất 1 form.
• Tự rà lại package trước khi nộp:
  • request naming có rõ không,
  • environment có gọn không,
  • note có nói rõ đang verify gì không,
  • auth/permission đã có chưa,
  • data flow đã nhìn thấy chưa.

Output cần nộp

• week04_api_testing/

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

• Package của bạn không chỉ là tập request được lưu lại, mà là một bộ API testing có logic.
• Bạn chứng minh được mình biết API nào đang phục vụ action UI nào.
• Bạn phân biệt được “gửi request được” với “đã verify đúng”.

Lỗi thường gặp

• Nộp collection nhiều request nhưng không có giải thích verify.
• Collection lộn xộn, naming kém, khó review.
• Có request auth nhưng không giải thích được vì sao là 401 hay 403.

Mentor review note

• Hỏi: Nếu bỏ hết note verify và chỉ giữ collection, mentor còn đánh giá được bao nhiêu năng lực thật của em?
• Đánh giá package ở góc độ team có thể dùng lại và hiểu được data flow hay không.

​

Deliverables Cần Nộp

​

KPI & Focus

​

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

• Hoàn thành 100% deliverable bắt buộc.
• week04_api_testing/ có tối thiểu 10 API request được tổ chức trong collection.
• Bắt buộc có đủ các nhóm:
  • GET
  • CRUD mutation (POST/PUT/PATCH/DELETE tùy ngữ cảnh)
  • auth/permission
  • UI/API mapping
• day24_get_api_notes.md phải có ít nhất 1 ví dụ status code đúng nhưng data fail.
• day26_auth_permission_api.md phải thể hiện rõ:
  • không token,
  • token sai hoặc hết hạn,
  • đúng token nhưng sai quyền.
• day27_ui_api_mapping.md phải map được ít nhất 1 form với chuỗi:
  • input UI
  • payload
  • response
  • UI update

​

Focus của tuần

• Verify meaning, not just mechanics: đừng dừng ở việc request gửi được.
• Data over code-only: status code đúng chưa đủ, cần kiểm dữ liệu và business meaning.
• Trace the flow: luôn cố nối UI action với backend behavior.
• Readable package: collection và note phải đủ rõ để mentor đọc là review được ngay.

​

Mini Rubric Cho Tuần 4

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à Đọc đúng status code, Verify response data, Auth/permission và UI/API mapping.

​

Common Mistakes

​

Mentor Review Guide

​

Mentor review collection như thế nào

• Xem naming request có nói rõ module và mục tiêu kiểm không.
• Xem folder structure có logic review không.
• Xem learner có dùng environment/variable hợp lý không.
• Xem collection có thật sự phản ánh nhóm test GET/CRUD/auth hay chỉ là tập request lưu tạm.

​

Mentor review API note như thế nào

• Learner có giải thích API này dùng để làm gì không.
• Có ghi rõ đang verify request nào, response nào, business data nào không.
• Có ví dụ code đúng nhưng data sai không.
• Có nối API note với UI action hoặc business context không.

​

Nên hỏi gì để biết learner hiểu API hay chỉ bấm tool

• Request này đang verify điều gì ngoài status code?
• Nếu response trả 200 nhưng field business chính sai, em coi là bug ở đâu?
• Ở flow này, UI input nào map vào payload nào?
• Vì sao case này là 401 chứ không phải 403?
• Nếu bỏ Postman đi, em còn giải thích được data flow của action này không?

​

Dấu hiệu learner hiểu data flow vs chỉ thao tác máy móc

​

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

1. Sửa tư duy “check code là đủ” trước.
2. Sửa nhầm 401 / 403 trước khi tối ưu format note.
3. Sửa collection lộn xộn và naming yếu trước khi tăng số lượng request.
4. Nếu learner chưa nối được UI với API, kéo lại phần 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 hiểu GET, POST, PUT, PATCH, DELETE khác nhau ở mục tiêu sử dụng và cách verify.
• Tôi đọc được request body và response body chứ không chỉ bấm send.
• Tôi biết status code nào đang phản ánh điều gì ở mức cơ bản.
• Tôi phân biệt được 401 và 403.
• Tôi test được auth/permission cơ bản với token thiếu, token sai hoặc sai quyền.
• Tôi nối được ít nhất một thao tác UI với API tương ứng.
• Tôi biết response đúng về code chưa đủ, còn phải đúng về dữ liệu.
• Collection của tôi đủ rõ để mentor hoặc người khác mở ra là hiểu phạm vi test.
• 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

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

​

Kết Thúc Tuần

Sau tuần 4, học viên đã đi thêm một bước rất quan trọng: từ chỗ test giao diện và ghi nhận lỗi bề mặt, sang chỗ đọc được request, response và data flow của hệ thống. Đây là lúc learner bắt đầu kiểm chất lượng không chỉ ở lớp hiển thị, mà ở lớp dữ liệu và hành vi backend đằng sau UI. Khi bước sang giai đoạn verify database và các lớp sâu hơn, hãy mang theo ba mindset này:

• đừng chỉ hỏi “UI có đúng không”, hãy hỏi “data đi đúng chưa”;
• đừng chỉ nhìn status code, hãy nhìn cả response meaning;
• đừng coi Postman là công cụ bấm thử, hãy dùng nó như công cụ kiểm chứng hệ thống.

Giữ được ba điều đó, tuần DB verification và các phần integration/workflow sau này sẽ chắc hơn rất nhiều, vì bạn đã bắt đầu nhìn hệ thống như một chuỗi dữ liệu có thể truy vết và xác minh.