Không tranh luận bằng lý tưởng "code sạch". Nói bằng thời gian và rủi ro, là thứ quản lý phải chịu trách nhiệm.
Các lập luận dùng được:
- Đưa số của chính dự án. Sprint vừa rồi mất bao nhiêu giờ cho hotfix và test tay? Bao nhiêu bug là lỗi hồi quy — thứ lẽ ra một test bắt được? Một con số nội bộ thuyết phục hơn mọi bài blog.
- Đóng khung là tốc độ, không phải chất lượng. Chất lượng nội tại không đánh đổi lấy tốc độ được lâu: sau vài tháng, thời gian bỏ ra để sửa hồi quy và kiểm tra tay lớn hơn thời gian tiết kiệm được lúc bỏ qua test.
- Nêu chi phí kiểm tra tay. Mỗi lần release phải bấm tay 2 giờ, một tháng 8 lần là 16 giờ lặp lại mãi mãi. Test tự động là chi phí một lần.
- Xin phạm vi nhỏ, không xin cả chiến dịch. "Cho tôi phủ test luồng thanh toán trong sprint này" khả thi hơn "dừng feature để viết test". Đo lại số bug ở luồng đó sau 1-2 tháng để lấy bằng chứng cho lần xin tiếp theo.
- Gắn vào định nghĩa hoàn thành. Từ nay bug fix nào cũng kèm test hồi quy — chi phí gần như bằng không, tích luỹ dần.
Điều nên tránh: hứa "có test là hết bug", hoặc đòi coverage 80% ngay. Cam kết quá tay một lần rồi không giữ được sẽ khiến lần sau không ai nghe nữa.