Kiểm tra: Đường không vui, lỗi, huỷ, hết hàng, mất mạng

Vì sao chủ đề quan trọng

Câu nói đáng nhớ nhất trong toàn bộ ghi chép của Căng tin số có lẽ là của Minh Anh: "Em không muốn trả tiền trước, lỡ ra tới nơi hết món thì sao." Đó không phải một lời phàn nàn. Đó là một ca kiểm thử mà người dùng đã viết sẵn cho bạn. Minh Anh đang hỏi đúng câu mà một phần mềm tốt phải trả lời: khi đường đi không suôn sẻ, chuyện gì xảy ra với tôi và với tiền của tôi?

Đường vui (happy path) là kịch bản mọi bước thành công. Đường không vui (unhappy path) là mọi kịch bản còn lại: thất bại, trễ, huỷ, hết hàng, mất mạng, làm hai lần, người sai làm. Trong phần mềm thật, phần lớn công sức lập trình và phần lớn lỗi nằm ở đường không vui. Nếu backlog chỉ mô tả đường vui, lập trình viên sẽ tự đoán phần còn lại, và mỗi người đoán một kiểu.

Bài này nhận vào story map và tiêu chí chấp nhận từ khóa Từ journey tới user story, vòng đời đối tượng và quy tắc từ khóa Hiểu nghiệp vụ trước khi xây, cùng hai ma trận ở bài 2 và bài 3. Đầu ra là trang Đường không vui trong tệp kiểm tra: mỗi bước của story map có các tình huống hỏng, cách hệ thống phản ứng, người quyết định và story tương ứng.

Bức tranh lớn

Kỹ thuật cốt lõi là đặt bảy câu hỏi cho mỗi bước trên xương sống (backbone) của story map:

• Nếu bước này thất bại thì sao?
• Nếu nó trễ thì sao?
• Nếu người dùng huỷ giữa chừng thì sao?
• Nếu hết hàng thì sao?
• Nếu mất mạng thì sao?
• Nếu nó bị làm hai lần thì sao?
• Nếu người sai làm nó thì sao?

Không phải câu nào cũng áp dụng cho mọi bước. Nhưng bạn phải hỏi đủ bảy rồi mới được gạch đi câu không áp dụng, và ghi lý do gạch.

flowchart TD
    A[Đặt món] --> B{Còn món và còn trước giờ chốt?}
    B -->|Không| B1[Báo hết hoặc gợi ý quầy khác]
    B -->|Có| C[Thanh toán]
    C --> D{Tiền đã về?}
    D -->|Treo| D1[Giữ đơn chờ, báo trạng thái]
    D -->|Thất bại| D2[Huỷ đơn, không trừ tiền]
    D -->|Có| E[Bếp chuẩn bị]
    E --> F{Hết món sau khi đã trả?}
    F -->|Có| F1[Đổi món hoặc hoàn tiền theo R6]
    F -->|Không| G[Nhận món]
    G --> H{Tới trong 30 phút?}
    H -->|Không| H1[Bán cho hàng theo R3]
    H -->|Có| I[Đã nhận]

Sơ đồ trên chỉ có ba bước chính nhưng đã sinh ra năm nhánh không vui. Mỗi nhánh cần ít nhất một tiêu chí chấp nhận, và nhiều nhánh cần cả một story riêng.

Ví dụ chi tiết

Áp bảy câu hỏi lên ba bước Đặt món, Thanh toán, Nhận món của Căng tin số. Bảng dưới chỉ giữ những tình huống có bằng chứng hoặc quy tắc trong ghi chép.

Đi sâu vào bốn tình huống khó nhất.

Hết món sau khi đã trả tiền. Đây chính là nỗi sợ của Minh Anh, và nó chạm thẳng vào mâu thuẫn C1: Anh Tuấn muốn trả trước vì "Đặt rồi không tới, tôi lỗ", Minh Anh muốn trả khi nhận. Nếu nhóm chọn trả trước, lời hứa với Minh Anh phải nằm trong sản phẩm: đơn đã trả thì được giữ suất, và nếu vẫn hết thì có đường lui rõ ràng. Nhưng hoàn tiền theo R6 chỉ quản lý duyệt. Vậy lúc 12:10, khi Anh Tuấn đang bận, Minh Anh đứng ở quầy với một đơn đã trả mà không có cơm. Cần một quyết định: đổi món cùng giá ngay tại quầy có cần Anh Tuấn duyệt không? Câu hỏi này phải được hỏi trước khi code, vì nó quyết định trạng thái nào tồn tại trong vòng đời đơn.

Chuyển khoản treo. Hôm nay, nhân viên xem thông báo trên điện thoại để xác nhận chuyển khoản (P5), và chính việc đó làm chậm hàng. Nếu app chỉ thiết kế hai kết quả "thành công" và "thất bại", lập trình viên sẽ phải tự quyết trạng thái thứ ba. Thực tế ngân hàng có lúc báo chậm vài phút. Đơn treo có được đưa vào danh sách nấu không? Nếu đưa vào và tiền không về, ai chịu? Nếu không đưa vào, mẻ nấu của Cô Hạnh có thể thiếu suất.

stateDiagram-v2
    Cho : Chờ thanh toán
    Treo : Đã chuyển, chưa xác nhận
    ThanhCong : Đã thanh toán
    ThatBai : Thất bại
    HoanTien : Chờ quản lý duyệt hoàn tiền
    DaHoan : Đã hoàn tiền
    Cho --> ThanhCong
    Cho --> Treo
    Cho --> ThatBai
    Treo --> ThanhCong
    Treo --> ThatBai
    ThanhCong --> HoanTien
    HoanTien --> DaHoan

Không tới lấy sau 30 phút. R3 nói phần đặt giữ 30 phút sau khung giờ nhận, sau đó bán cho hàng. Phần bếp đã rõ. Phần tiền thì chưa: suất bán lại cho người khác, vậy tiền của người đặt xử lý thế nào? Anh Tuấn nói "Đặt rồi không tới, tôi lỗ", nghe như mất tiền là hợp lý. Nhưng nếu suất đó đã được bán lại, căng tin thu tiền hai lần cho một suất. Đây là câu hỏi chính sách phải đưa lên Anh Tuấn và Chị Lan, và câu trả lời phải hiện ra trên màn hình đặt món trước khi sinh viên bấm trả.

Mất mạng ở quầy. Giờ cao điểm 11:35 tới 12:15, quầy cơm phục vụ phần lớn trong khoảng 600 suất. Nếu wifi của căng tin rớt mười phút đúng lúc đó, quầy có giao được món không? Câu hỏi này kéo theo yêu cầu phi chức năng: quầy cần đối chiếu được mã đơn khi không có mạng, hoặc có phương án giấy. Ghi nó vào trang Phi chức năng của tệp kiểm tra, cạnh các hạng mục như tốc độ tải thực đơn lúc cao điểm và bảo mật thông tin phiếu hỗ trợ.

Lộ trình từng bước

• Chép xương sống story map vào cột "Bước" của trang Đường không vui.
• Với mỗi bước, đặt đủ bảy câu hỏi. Ghi mọi tình huống, kể cả những cái bạn nghĩ hiếm.
• Gạch tình huống không áp dụng, và ghi một dòng lý do.
• Với mỗi tình huống còn lại, viết "hệ thống nên làm gì" bằng ngôn ngữ người dùng, không phải mã lỗi.
• Ghi ai có quyền quyết định cách xử lý. Nếu là chính sách tiền, gần như luôn là Anh Tuấn; nếu chạm suất hỗ trợ, là Chị Lan.
• Đối chiếu với vòng đời đối tượng: tình huống có cần trạng thái mới không? Nếu có, báo lại cho người giữ sơ đồ vòng đời.
• Biến mỗi tình huống thành tiêu chí chấp nhận dạng "Cho trước… Khi… Thì…" của story liên quan, hoặc thành story mới nếu đủ lớn.

Thói quen & kỷ luật

Cần luyện tập

Drill một: Áp bảy câu hỏi cho bước "Dùng phiếu suất hỗ trợ" của Thảo Vy. Gợi ý: hôm nay là thứ Bảy, hoặc Thảo Vy đã dùng một suất sáng nay, hoặc nhân viên quầy mới không biết R4. Đừng quên P12: cách từ chối cũng phải kín đáo.

Drill hai: Viết ba tiêu chí chấp nhận dạng "Cho trước… Khi… Thì…" cho tình huống chuyển khoản treo, mỗi tiêu chí cho một kết quả: tiền về, tiền không về, tiền về sau khi suất đã bán.

Drill ba: Mở một ứng dụng đặt xe hoặc đặt đồ ăn. Thử cố ý huỷ ở ba thời điểm khác nhau. Ghi lại ứng dụng phản ứng thế nào. Nó đã trả lời câu hỏi nào trong bảy câu?

Checklist hành động tuần này

• [ ] Chép xương sống story map vào trang Đường không vui
• [ ] Hỏi đủ bảy câu cho ba bước Đặt món, Thanh toán, Nhận món
• [ ] Ghi người quyết định cho mọi tình huống liên quan tới tiền
• [ ] Thêm trạng thái chuyển khoản treo vào vòng đời Thanh toán
• [ ] Ghi yêu cầu mất mạng ở quầy vào trang Phi chức năng

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.

Dấu hiệu bạn đã thành thạo

• Nghe một câu "lỡ… thì sao" trong phỏng vấn, bạn ghi ngay nó thành một dòng đường không vui.
• Bạn phân biệt được câu hỏi kỹ thuật như bấm hai lần với câu hỏi chính sách như tiền của đơn quá hạn.
• Bạn không để lập trình viên tự quyết chuyện tiền.
• Mỗi story liên quan tới thanh toán của bạn có nhiều tiêu chí cho nhánh không vui hơn nhánh vui.

Cạm bẫy thường gặp

Chốt lại

Đường không vui là nơi phần mềm thật sự được kiểm nghiệm. Bảy câu hỏi cho mỗi bước biến những nỗi lo trong phỏng vấn thành tiêu chí chấp nhận. Với Căng tin số, ba bước đã lộ ra hết món sau khi trả tiền, chuyển khoản treo, đơn quá hạn theo R3 và mất mạng ở quầy, và hầu hết cần một quyết định của Anh Tuấn trước khi ai đó viết code. Bài 5 kiểm tra từ phía ngược lại: mỗi story có trỏ về một bằng chứng không.