Vì sao chủ đề quan trọng
Bài 4 cho bạn các story nhỏ, mỗi cái đạt INVEST. Nhưng chữ T trong INVEST, kiểm thử được, mới chỉ là lời hứa. Lấy story "Là Người chạy lịch, tôi muốn có phần chờ sẵn khi tan lớp". Lập trình viên hỏi: phần được giữ bao lâu? Tester hỏi: giữ 30 phút là tính từ lúc nào? Cô Hạnh, nếu được hỏi, sẽ có câu trả lời mà không ai trong nhóm nghĩ tới. Nếu không ai viết những câu trả lời đó ra, mỗi người sẽ làm theo cách hiểu riêng, và lỗi chỉ lộ ra vào trưa đầu tiên của đợt chạy thử.
Tiêu chí nghiệm thu (acceptance criteria) là các điều kiện mà story phải thỏa thì mới được coi là xong. Cách viết hiệu quả nhất là viết chúng thành ví dụ cụ thể, có người, có giờ, có số, theo khuôn Given/When/Then. Ví dụ cụ thể làm lộ ra chỗ mơ hồ mà câu quy tắc chung che mất.
Đầu vào của bài là story từ bài 4 và các quy tắc R1–R6 từ khóa Hiểu nghiệp vụ trước khi xây. Đầu ra là mỗi story lát 1 có từ ba tới bảy tiêu chí, viết thành ví dụ, đã được một người am hiểu nghiệp vụ xác nhận.
Bức tranh lớn
Khuôn Given/When/Then có ba phần:
Given (cho trước) -> bối cảnh: ai, đơn nào, mấy giờ, trạng thái gì
When (khi) -> một hành động hoặc một sự kiện duy nhất
Then (thì) -> kết quả quan sát được
And (và) -> nối thêm điều kiện hoặc kết quả
Quy tắc và ví dụ khác nhau thế nào. Quy tắc là câu tổng quát: "Phần đặt trước giữ 30 phút sau khung giờ nhận." Ví dụ là một trường hợp cụ thể: "Minh Anh đặt khung 11:30–11:45, tới lúc 12:16 thì phần đã được bán." Quy tắc dễ đồng ý, vì mỗi người đọc nó theo cách của mình. Ví dụ buộc mọi người đồng ý cùng một điều, vì nó có giờ cụ thể.
Kỹ thuật ánh xạ ví dụ (example mapping) của Matt Wynne giúp tổ chức việc này trong một buổi ngắn. Mỗi story có các quy tắc, mỗi quy tắc có vài ví dụ, và mọi câu chưa ai trả lời được thì ghi thành câu hỏi để hỏi người am hiểu nghiệp vụ.
flowchart TD
S[Story giữ phần đã đặt] --> R1[Quy tắc giữ 30 phút]
S --> R2[Quy tắc phần quá hạn bán cho hàng]
R1 --> E1[Ví dụ tới lúc 12 giờ 14]
R1 --> E2[Ví dụ tới đúng 12 giờ 15]
R2 --> E3[Ví dụ tới lúc 12 giờ 16]
R1 --> Q1[Câu hỏi tính từ đầu hay cuối khung]
Q1 --> H[Hỏi Cô Hạnh]Ví dụ chi tiết
Tiêu chí cho R3, giữ 30 phút. Cô Hạnh nói: "Phần đặt mà quá 30 phút không tới lấy thì cô bán cho người đang xếp hàng." Khi viết ví dụ đầu tiên, nhóm lập tức gặp câu hỏi: khung giờ nhận là 11:30–11:45, vậy 30 phút tính từ 11:30 hay từ 11:45? Câu quy tắc không trả lời. Nhóm mang câu hỏi tới Cô Hạnh, và giả sử câu trả lời là tính từ cuối khung. Quyết định này được ghi lại vào bảng quy tắc nghiệp vụ, rồi mới viết ví dụ:
Tình huống 1: Nhận trong thời gian giữ
Given Minh Anh có đơn đã trả, khung nhận 11:30-11:45
When Minh Anh đọc mã đơn ở quầy cơm lúc 12:14
Then nhân viên quầy thấy đơn ở trạng thái Đang giữ
And trao suất và đơn chuyển sang Đã nhận
Tình huống 2: Đúng mốc hết hạn
Given Minh Anh có đơn đã trả, khung nhận 11:30-11:45
When Minh Anh đọc mã đơn lúc 12:15:00
Then đơn vẫn ở trạng thái Đang giữ
Tình huống 3: Quá thời gian giữ
Given Minh Anh có đơn đã trả, khung nhận 11:30-11:45
When đồng hồ hệ thống qua 12:15:00 mà đơn chưa được nhận
Then đơn chuyển sang Quá hạn giữ
And phần đó hiện lại là còn món cho người xếp hàng
And Minh Anh nhận thông báo kèm hướng dẫn liên hệ quản lý
Tình huống 2 là ví dụ biên (boundary): đúng mốc 12:15. Lỗi lập trình hay nằm đúng ở chỗ này, giữa dấu nhỏ hơn và nhỏ hơn hoặc bằng. Tình huống 3 không tự hoàn tiền. Vì R6 nói hoàn tiền chỉ quản lý duyệt, tiêu chí chỉ hướng Minh Anh tới Anh Tuấn. Một câu quy tắc từ khóa trước đã chặn một tính năng sai.
flowchart TD
A[Đã đặt] -->|thanh toán xác nhận| B[Đang giữ]
B -->|đọc mã trước hạn| C[Đã nhận]
B -->|quá 30 phút sau cuối khung| D[Quá hạn giữ]
D -->|sinh viên yêu cầu| E[Chờ duyệt hoàn]
E -->|quản lý duyệt| F[Đã hoàn tiền]Tiêu chí cho R4, suất hỗ trợ. Chị Lan nói: "Suất hỗ trợ mỗi em tối đa một suất một ngày, chỉ ngày thường, không dùng mua nước." Một câu, ba nhánh, mỗi nhánh ít nhất một ví dụ:
Tình huống 1: Dùng suất hỗ trợ ngày thường
Given Thảo Vy thuộc chương trình suất ăn hỗ trợ
And hôm nay là Thứ Ba, Thảo Vy chưa dùng suất nào
When Thảo Vy đặt một suất cơm phần và chọn trả bằng suất hỗ trợ
Then đơn được chấp nhận với số tiền phải trả là 0đ
Tình huống 2: Suất thứ hai trong ngày
Given Thảo Vy đã dùng suất hỗ trợ cho một đơn hôm nay
When Thảo Vy đặt đơn thứ hai trong ngày
Then lựa chọn suất hỗ trợ bị ẩn
And Thảo Vy vẫn đặt được nếu trả bằng chuyển khoản
Tình huống 3: Ngày cuối tuần
Given hôm nay là Thứ Bảy
When Thảo Vy mở màn hình thanh toán
Then không có lựa chọn suất hỗ trợ
Tình huống 4: Đồ uống đi kèm
Given Thảo Vy đặt một suất cơm phần kèm một ly nước
When Thảo Vy chọn trả bằng suất hỗ trợ
Then suất cơm được trả bằng suất hỗ trợ
And ly nước phải trả bằng cách khác
Tình huống 4 lại sinh ra câu hỏi cho Chị Lan: nếu Thảo Vy không muốn trả riêng ly nước thì có bỏ ly nước ra được không? Ghi câu hỏi, đừng tự quyết.
Tiêu chí cho P3, hiển thị chất gây dị ứng. Thảo Vy nói: "Lần nào em cũng phải hỏi món này có đậu phộng không, mà cô bán cũng không chắc." Tiêu chí quan trọng nhất ở đây không phải đường suôn, mà là trường hợp chưa có dữ liệu:
Tình huống 1: Món có khai báo đậu phộng
Given Anh Tuấn đã khai báo món gỏi gà có đậu phộng
When Thảo Vy xem thực đơn quầy cơm
Then cạnh tên món hiện chữ Có đậu phộng
Tình huống 2: Món chưa khai báo thành phần
Given món cá kho chưa được khai báo chất gây dị ứng
When Thảo Vy xem thực đơn quầy cơm
Then cạnh tên món hiện chữ Chưa có thông tin dị ứng
And không hiện chữ Không có chất gây dị ứng
Nếu tiêu chí chỉ có tình huống 1, lập trình viên rất có thể hiển thị trống cho món chưa khai báo, và trống sẽ được Thảo Vy đọc thành "an toàn". Với dữ liệu sức khỏe, thiếu thông tin phải được nói rõ là thiếu.
Bao nhiêu tiêu chí là đủ. Một ví dụ cho đường suôn, một ví dụ cho mỗi nhánh của quy tắc, một ví dụ biên cho mỗi mốc thời gian hoặc giới hạn số. Thường là ba tới bảy. Nếu vượt mười, story đang quá to: quay lại bài 4 và tách theo quy tắc.
Ai viết, viết với ai. Không phải một người viết một mình. Buổi ba người bạn (three amigos) gồm người nắm nghiệp vụ trong nhóm, một lập trình viên và một người kiểm thử, cùng ngồi 25 phút cho mỗi story. Khi chạm quy tắc, mời đúng chủ quy tắc: Cô Hạnh cho R3, Chị Lan cho R4, Anh Tuấn cho R6.
Tiêu chí nghiệm thu khác Định nghĩa Hoàn thành.
| Khía cạnh | Tiêu chí nghiệm thu | Định nghĩa Hoàn thành |
|---|---|---|
| Phạm vi | Riêng một story | Mọi story của đội |
| Nội dung | Hành vi nghiệp vụ, ví dụ cụ thể | Chuẩn chất lượng chung |
| Ví dụ Căng tin số | Đơn quá 12:15 chuyển Quá hạn giữ | Đã review code, có kiểm thử tự động, chạy trên điện thoại thật |
| Ai quyết | Nhóm cùng chủ quy tắc | Cả đội thống nhất một lần |
Lộ trình từng bước
- Lấy một story từ lát 1, liệt kê mọi quy tắc nó chạm.
- Với mỗi quy tắc, viết một ví dụ đường suôn có tên người và giờ cụ thể.
- Thêm một ví dụ cho mỗi nhánh của quy tắc.
- Thêm ví dụ biên cho mỗi mốc giờ và mỗi giới hạn số.
- Thêm ví dụ cho trường hợp thiếu dữ liệu.
- Ghi mọi chỗ mơ hồ thành câu hỏi, mang tới chủ quy tắc.
- Viết lại theo Given/When/Then, mỗi tình huống chỉ một When.
- Đếm: dưới ba thì còn thiếu, trên mười thì tách story.
Thói quen & kỷ luật
| Thói quen | Tần suất | Kết quả mong đợi |
|---|---|---|
| Buổi ba người bạn cho mỗi story | Trước khi story vào vòng lặp | Hiểu chung trước khi viết code |
| Viết ví dụ biên cho mọi mốc giờ | Mỗi story có thời gian | Không lỗi ở 12:15 đúng mốc |
| Ghi câu hỏi thay vì tự đoán | Mỗi buổi viết tiêu chí | Chủ quy tắc quyết, không phải nhóm |
| Cập nhật bảng quy tắc khi có câu trả lời | Ngay sau khi được trả lời | Bảng quy tắc và tiêu chí không lệch nhau |
Cần luyện tập
Drill một: Viết tiêu chí Given/When/Then cho R1 trên story "đặt suất cơm phần". Bao gồm: một món mặn, hai món mặn, món mặn thứ ba cộng 10.000đ, và thử chọn món mặn thứ tư. Ghi câu hỏi nào bạn cần mang tới Cô Hạnh.
Drill hai: Viết tiêu chí cho S3 ở bài 4, từ chối đơn mới sau 10:00. Ví dụ biên là gì? Đơn bắt đầu lúc 9:59 và bấm xác nhận lúc 10:00:30 thì sao?
Drill ba: Lấy một story trong đồ án của bạn có tiêu chí viết kiểu "hệ thống hoạt động đúng". Viết lại thành ba ví dụ Given/When/Then có tên người và số cụ thể.
Checklist hành động tuần này
- [ ] Viết tiêu chí cho bốn story lát 1 của Đặt món trước
- [ ] Có ít nhất một ví dụ biên cho mỗi mốc giờ
- [ ] Viết tiêu chí cho trường hợp thiếu dữ liệu dị ứng
- [ ] Gửi danh sách câu hỏi cho Cô Hạnh và Chị Lan
- [ ] Viết Định nghĩa Hoàn thành chung của nhóm trên một trang
Chỉ số cho cách làm
Các con số dưới đây đo cách nhóm làm bước này, không đo app có thành công hay không. Câu hỏi app có hiệu quả không, và làm gì tiếp, là việc của khóa Đo lường thành công.
| Loại chỉ số | Ví dụ | Vai trò |
|---|---|---|
| North Star | Tỉ lệ story lát 1 được chủ quy tắc xác nhận tiêu chí | Cho biết đội đang làm đúng nghiệp vụ |
| Chỉ số dẫn dắt | Số câu hỏi mở còn chờ trả lời | Báo rủi ro trước khi code |
| Chỉ số chất lượng | Số lỗi trong đợt chạy thử không có tiêu chí tương ứng | Chỉ ra chỗ tiêu chí còn hổng |
| Chỉ số cảnh báo | Story có trên mười tiêu chí | Báo story cần tách |
Dấu hiệu bạn đã thành thạo
Bạn đọc một quy tắc và tự hỏi "mốc này tính từ đâu". Bạn viết ví dụ biên mà không cần nhắc. Bạn nhận ra một tiêu chí thiếu trường hợp chưa có dữ liệu. Và bạn biết câu nào mình quyết được, câu nào phải hỏi Cô Hạnh hay Chị Lan.
Cạm bẫy thường gặp
| Cạm bẫy | Biểu hiện | Cách tránh |
|---|---|---|
| Chép quy tắc thành tiêu chí | Tiêu chí ghi giữ 30 phút và dừng ở đó | Viết ví dụ có giờ cụ thể |
| Bỏ ví dụ biên | Không ai biết 12:15 thì sao | Thêm ví dụ đúng mốc |
| Nhiều When trong một tình huống | Một tình huống đặt, trả và nhận | Mỗi tình huống một hành động |
| Tự đoán thay chủ quy tắc | Nhóm tự quyết cách tính 30 phút | Ghi câu hỏi và hỏi Cô Hạnh |
| Trộn tiêu chí với Định nghĩa Hoàn thành | Mỗi story đều ghi có kiểm thử tự động | Để chuẩn chung ở Định nghĩa Hoàn thành |
Chốt lại
Tiêu chí nghiệm thu là ví dụ cụ thể, không phải câu quy tắc chép lại. Viết theo Given/When/Then, có đường suôn, các nhánh, ví dụ biên và trường hợp thiếu dữ liệu. Trên Căng tin số, R3 lộ ra câu hỏi tính 30 phút từ đâu, R4 cho bốn ví dụ, và hiển thị dị ứng dạy rằng thiếu thông tin phải được nói rõ. Đầu ra là story lát 1 có tiêu chí đã được chủ quy tắc xác nhận. Bài 6 sẽ thêm phần mà story và tiêu chí thường bỏ sót: những yêu cầu người dùng không nói ra.