1. Tóm tắt nhanh & yêu cầu bạn sẽ đọc
Chào bạn mới! Nhiều bạn khi mới học test có phản xạ: đọc lướt yêu cầu một lượt rồi bắt tay viết test case ngay cho nhanh. Cách làm này rất dễ khiến bạn bỏ sót ca quan trọng hoặc hiểu sai ý người viết yêu cầu. Kỹ năng phân tích yêu cầu chính là bước dừng lại, đọc kỹ, tách từng câu trong yêu cầu thành các điểm cần kiểm tra — trước khi đặt bút viết bất kỳ test case nào. Chúng ta sẽ học kỹ năng này qua yêu cầu thật của tính năng mã giảm giá trên ShopEasy, có hình minh họa và phần tự làm thử.
2. User Story và Acceptance Criteria là gì
User story mô tả nhu cầu ở mức tổng quát theo mẫu 'Là [ai], tôi muốn [làm gì], để [đạt được gì]'. Với tính năng mã giảm giá ShopEasy: 'Là khách hàng, tôi muốn nhập mã giảm giá khi thanh toán, để được giảm tiền đơn hàng'. Câu này cho bạn biết TẠI SAO tính năng tồn tại, nhưng chưa đủ chi tiết để viết test case — đó là lý do cần Acceptance Criteria (AC) đi kèm.
Acceptance Criteria (AC) là các điều kiện CỤ THỂ, kiểm tra được, xác định khi nào user story được xem là hoàn thành đúng. Ví dụ AC1 của tính năng này: 'Mã hợp lệ, còn hạn -> áp dụng giảm giá, hiển thị đúng số tiền được giảm'. Câu này rõ ràng hơn nhiều so với user story: nó nêu rõ ĐIỀU KIỆN (mã hợp lệ, còn hạn) và KẾT QUẢ MONG ĐỢI (áp dụng giảm giá, hiển thị đúng số tiền) — chính là nguyên liệu để bạn viết test case.
3. Vì sao người mới cần đọc kỹ yêu cầu trước khi viết test case
Viết test case trước khi hiểu rõ yêu cầu giống như xây nhà mà không xem bản vẽ: bạn có thể xây rất nhanh, nhưng dễ xây sai chỗ. Nếu bạn chỉ đọc lướt yêu cầu rồi viết ca kiểm thử ngay, bạn thường bỏ sót các điều kiện phụ (như AC3 'giảm tối đa 100.000đ') hoặc hiểu sai ý người viết — dẫn tới test case không phản ánh đúng điều cần kiểm tra.
Với riêng bạn — người mới — kỹ năng phân tích yêu cầu là nền tảng của MỌI kỹ thuật thiết kế test case khác (phân vùng tương đương, giá trị biên, kiểm thử âm...). Dù bạn dùng kỹ thuật nào, bạn vẫn phải bắt đầu từ việc hiểu đúng yêu cầu. Đây cũng là câu hỏi phỏng vấn phổ biến: 'Cho một đoạn yêu cầu, hãy chỉ ra những điểm chưa rõ ràng và các điểm kiểm bạn sẽ viết test case'.
Và quan trọng nhất: đọc kỹ yêu cầu giúp bạn tìm ra vấn đề SỚM NHẤT có thể — ngay ở giai đoạn thiết kế test case, trước khi tính năng được lập trình. Phát hiện một yêu cầu mơ hồ ở bước này rẻ hơn rất nhiều so với phát hiện lỗi sau khi tính năng đã lên production.
4. Chuẩn bị: kỹ thuật tách yêu cầu thành điểm kiểm
Bạn không cần công cụ đặc biệt — chỉ cần một quy trình đọc có kỷ luật để không bỏ sót góc nào khi đọc một yêu cầu bất kỳ.
▶ Bước 1: Đọc user story trước để nắm bối cảnh chung: ai dùng, dùng để làm gì.
▶ Bước 2: Đọc từng Acceptance Criteria (AC) một, tách riêng ĐIỀU KIỆN và KẾT QUẢ MONG ĐỢI trong từng câu.
💬 Bình luận (0)
Chưa có bình luận nào. Hãy là người đầu tiên!