​

Cách Tự Review Trước Khi Nộp

​

Tự Soi Bài Trước Khi Người Khác Phải Soi Giúp Bạn

Mục tiêu của tự review là biến output từ “có file” thành “usable cho review”.

​

Vì Sao Phải Tự Review Trước Khi Nộp

​

1. Nó giúp bạn phát hiện lỗi dễ sửa trước khi mentor thấy

• naming sai;
• title mơ hồ;
• expected result không đo được;
• bug report thiếu precondition;
• checklist toàn câu chung chung.

​

2. Nó giúp mentor tập trung vào lỗi chất lượng cao hơn

• logic test;
• coverage;
• risk;
• cách chọn assumption;
• độ trưởng thành của output.

​

3. Nó giúp bạn hiểu bài sâu hơn

• mình chưa thật sự hiểu mục tiêu bài;
• mình đang viết theo thói quen chứ không theo logic;
• mình tưởng là rõ nhưng thực ra người khác phải đoán.

​

4. Nó giúp giảm vòng feedback lặp lại

• expected result mơ hồ;
• case trùng nhau;
• summary chỉ có số liệu;
• note dài nhưng không phân tích,

​

5. Nó giúp phân biệt giữa “mình nghĩ là rõ” và “người khác đọc có hiểu không”

Nếu đây không phải bài của mình, mình có hiểu và dùng lại được không?

​

Quy Trình Tự Review Đề Xuất

​

Bước 1. Đọc lại mục tiêu bài

• bài này đang rèn năng lực gì;
• output này dùng để làm gì;
• mentor sẽ review trọng tâm nào.

​

Bước 2. Đối chiếu output với mục tiêu

• file này có đang phục vụ đúng mục tiêu bài không;
• mình đang tạo artifact để review được, hay chỉ đang “viết cho có”.

• note phân tích phải giúp hiểu bài toán;
• test case phải giúp người khác chạy lại;
• bug report phải giúp người khác tái hiện;
• summary phải giúp người đọc hiểu risk.

​

Bước 3. Kiểm logic trước

• flow có đúng không;
• case có bám scope không;
• bug có phản ánh đúng vấn đề không;
• summary có dựa trên evidence không.

​

Bước 4. Kiểm độ rõ

• title có rõ không;
• wording có mơ hồ không;
• câu nào khiến người đọc phải đoán;
• steps hoặc note có bị nhảy ý không.

​

Bước 5. Kiểm độ đầy đủ

• thiếu negative case;
• thiếu state quan trọng;
• thiếu precondition;
• thiếu evidence;
• thiếu risk statement.

​

Bước 6. Kiểm format và tính nhất quán

• naming;
• cột bắt buộc;
• format file;
• cách trình bày;
• term dùng có nhất quán không.

​

Bước 7. Tự hỏi: nếu mentor hỏi “vì sao?”, mình trả lời được không?

• vì sao em test chỗ này;
• vì sao em bỏ chỗ kia;
• vì sao expected result viết như vậy;
• vì sao bug này để severity này,

​

Một vòng tự review 10 phút nên làm gì

1. Đọc lại mục tiêu bài trong 1 phút.
2. Kiểm logic chính trong 3 phút.
3. Kiểm chỗ mơ hồ nhất trong 3 phút.
4. Kiểm thiếu sót quan trọng trong 2 phút.
5. Kiểm naming và format trong 1 phút.

​

5 Câu Hỏi Tự Review Quan Trọng Nhất

1. Output này có đúng mục tiêu bài không?
2. Người khác có thể đọc và dùng lại output này không?
3. Chỗ nào trong bài đang mơ hồ hoặc viết cho có?
4. Tôi có đang thiếu phần quan trọng nào không?
5. Nếu mentor hỏi “vì sao làm vậy?”, tôi có trả lời được không?

​

Cách Tự Review Theo Từng Loại Output

​

A. Với note / analysis note

• note có đi đúng trọng tâm bài không;
• có đang lặp lại lý thuyết vô ích không;
• có dùng lời của chính mình để thể hiện hiểu bài không;
• có ví dụ, nhận định hoặc phân tích cụ thể không;
• có chỗ nào chỉ đang kể lại mà không kết luận gì không.

​

B. Với test scenario

• đã bao phủ được nghiệp vụ chính chưa;
• có đang rơi vào step-level quá sớm không;
• scenario nào đang trùng logic nhau;
• có thiếu happy path, negative path hoặc alternate flow quan trọng không;
• scenario đã map theo flow/module chưa hay vẫn là list ý tưởng rời.

​

C. Với test case

• title có nói rõ đang test gì không;
• precondition có đủ để người khác setup không;
• steps có thể chạy lại không;
• expected result có kiểm được không;
• case nào đang trùng nhau;
• case nào đang hở scope;
• có đủ happy, negative và edge cases chưa.

​

D. Với checklist

• checklist có quá chung chung không;
• từng điểm check có review được không;
• có bỏ sót state hoặc condition quan trọng không;
• checklist có đúng mức khái quát không;
• checklist có bị biến thành test case trá hình hoặc ngược lại quá sơ sài không.

​

E. Với bug report

• title có nói rõ vấn đề không;
• steps có tái hiện được không;
• actual result và expected result có rõ không;
• có precondition không;
• có evidence tối thiểu không;
• severity có lý do không;
• bug này đang mô tả hiện tượng hay đang nhảy sang kết luận nguyên nhân.

​

F. Với matrix / workflow / permission table

• có thiếu role, state hoặc action nào không;
• logic giữa các hàng/cột có khớp không;
• đã có trường hợp bị cấm hoặc invalid chưa;
• matrix này có dễ dùng để review/test không;
• người khác nhìn vào có thấy được luật nghiệp vụ không.

​

G. Với summary report

• có nói rõ scope không;
• số liệu có rõ và có nghĩa không;
• có risk statement không;
• có recommendation không;
• report này có usable cho mentor/lead không;
• có nói được phần nào đã test thật, phần nào chưa chạm hoặc còn giới hạn không.

​

Dấu Hiệu Bài “Đủ File” Nhưng Chưa “Đủ Dùng”

• test case có đủ cột nhưng expected result mơ hồ;
• checklist dài nhưng toàn câu kiểu “kiểm tra hiển thị đúng”;
• bug report có đủ trường nhưng không tái hiện được;
• summary report có pass/fail và defect count nhưng không có risk statement;
• note rất nhiều chữ nhưng không có phân tích nào cụ thể;
• matrix có nhiều ô nhưng thiếu role hoặc thiếu trạng thái cấm quan trọng.

• Đủ file là hình thức.
• Đủ dùng mới là chất lượng thật.

​

“Nếu người khác dùng file này, họ có bị mắc kẹt không?” là câu hỏi vàng vì sao

• không bắt người đọc đoán thêm;
• không bắt mentor phải dịch lại ý của bạn;
• không bắt người execute tự bù chỗ thiếu;
• không làm dev bị chặn khi đọc bug.

​

Cách Phát Hiện Lỗi Mơ Hồ Trong Chính Bài Của Mình

• dùng từ như đúng, ổn, hợp lý, chuẩn nhưng không mô tả cụ thể;
• expected result kiểu hệ thống hoạt động đúng;
• note kiểu kể lại mà không phân tích;
• steps bị nhảy bước;
• câu quá chung khiến người đọc phải đoán ý.

​

Khi nào nên đọc bài của mình như người lạ

1. Sau khi vừa làm xong bản nháp đầu tiên.
2. Trước khi nộp 10-15 phút.
3. Sau khi sửa một vòng lớn theo logic.

​

Cách Tự Review Mà Không Sa Vào Perfectionism

1. sửa logic trước;
2. sửa độ rõ sau;
3. sửa format cuối.

• sửa wording mãi nhưng chưa chốt logic;
• đổi format liên tục nhưng chưa kiểm coverage;
• cố làm file đẹp hơn trong khi expected result vẫn mơ hồ;
• ngại nộp vì cảm giác “chưa hoàn hảo” dù bài đã đủ để review.

• bài phải usable;
• lỗi cơ bản phải được loại bớt;
• chỗ chưa chắc phải được chỉ rõ để mentor review tiếp.

​

Tự review theo logic trước, format sau

• sửa format không cứu được;
• thêm màu, thêm icon, thêm bảng cũng không giúp bài tốt hơn;
• mentor vẫn sẽ phải quay lại chỉ những điểm gốc.

​

Khi Nào Nên Dừng Tự Review Và Gửi Mentor

• logic chính đã được kiểm;
• lỗi cơ bản đã được sửa;
• bạn biết chỗ nào mình chưa chắc;
• bạn có thể nói rõ muốn mentor tập trung review phần nào.

• bạn chỉ đang sửa wording mãi;
• càng sửa càng rối hơn;
• bạn bị kẹt quá lâu ở một assumption chưa thể tự chốt;
• bạn không còn nhìn ra lỗi của chính mình nữa;
• bạn đã tới ngưỡng cần một góc nhìn bên ngoài.

​

Mini Checklist Tự Review Trước Khi Nộp

Tôi đã đọc lại mục tiêu bài chưa?
Output của tôi có đúng mục tiêu không?
Tôi đã kiểm logic chưa?
Tôi đã kiểm độ rõ chưa?
Có phần nào đang mơ hồ không?
Có phần nào chỉ viết cho đủ không?
Nếu mentor hỏi “vì sao”, tôi có trả lời được không?
Tôi có biết mình muốn mentor review kỹ phần nào không?

​

Dấu Hiệu Bạn Đang Tự Review Tốt Vs Chưa Tốt

​

Dấu Hiệu Tự Review Tốt

• Bài nộp ngày càng ít lỗi cơ bản.
• Câu hỏi gửi mentor cụ thể hơn.
• Output rõ hơn qua từng tuần.
• Bạn tự phát hiện được lỗi trước khi bị góp ý.
• Bạn biết rõ chỗ nào mình chưa chắc.

​

Dấu Hiệu Tự Review Chưa Tốt

• Nộp xong mới phát hiện lỗi rất cơ bản.
• Tuần nào cũng lặp lại lỗi cũ.
• Chỉ check format, không check logic.
• Luôn phụ thuộc mentor để chỉ lỗi sơ đẳng.
• Không biết file của mình yếu ở đâu.

​

Kết Thúc Trang