Kiểm soát chất lượng
PM cần gì để quyết định automation test
Ba artifact hay được liệt kê chỉ trả lời nửa câu hỏi. Nửa còn lại — số lần kiểm lại, trọng số nghiệp vụ, dữ liệu test — chỉ chủ sản phẩm có, và đó mới là nửa quyết định được.
Nội dung bài
- Câu hỏi thật sự đang được quyết
- Hồ sơ quyết định có hai nửa
- Ba artifact quen thuộc — và chỗ hụt của từng cái
- Sáu câu chỉ chủ sản phẩm trả lời được
- Bảng kịch bản — artifact duy nhất phải ép có
- Thêm hai mục vào Definition of Ready
- Quy trình quyết định bốn bước
- Ba lằn ranh nên nói thẳng "chưa quyết được"
- Hỏi sai và hỏi đúng
- Sáu việc phải chốt trước khi coi là quyết xong
Thuật ngữ trong bài (11)
2 nửa
hồ sơ quyết định — khả thi và đáng giá
6 câu
chỉ chủ sản phẩm trả lời được
+2 mục
thêm vào Definition of Ready đã có
1 bảng
thứ duy nhất phải ép có cho mỗi kịch bản
Câu hỏi thật sự đang được quyết
Không phải "có làm automation không". Câu đó ai cũng trả lời có, rồi không đổi được gì.
Ba câu dưới mới là câu phải quyết, và cả ba đều cần dữ liệu khác nhau:
- Luồng nào trước
cần trọng số nghiệp vụ và lượt dùng
- Automation ở tầng nào
cần bản đồ hành động sang API
- Đổi lại cắt việc tay nào
cần cam kết, không cần dữ liệu
Câu thứ ba hay bị bỏ. Thêm automation mà không bớt regression tay thì chi phí chỉ tăng — nguyên tắc thêm vào thì phải lấy ra ở ưu tiên công việc áp dụng nguyên vẹn cho automation.
Hồ sơ quyết định có hai nửa
Hồ sơ quyết định automation
Nửa KHẢ THI
trả lời "làm được tới đâu, giá bao nhiêu" — đội kỹ thuật tự làm ra được
Acceptance criteria kiểm chứng được bằng số
Chuỗi hành động người dùng, mỗi bước gọi API nào
Danh sách API kèm contract — mã lỗi, quyền, idempotency, phân trang
Nửa ĐÁNG GIÁ
trả lời "có đáng bỏ tiền không" — chỉ chủ sản phẩm có dữ liệu
Luồng này bị kiểm lại bao nhiêu lần mỗi năm
Trọng số nghiệp vụ — tiền, quyền, mất dữ liệu, lượt dùng
Độ biến động ba sprint qua, và kế hoạch đổi sắp tới
Dữ liệu test tạo và dọn được không
Ai sửa khi test đỏ
Việc tay nào được cắt khi automation xong
Ba gạch đầu dòng ở nhánh trên là ba thứ hay được liệt kê khi bàn automation. Chúng cần, nhưng chúng là phần đội kỹ thuật tự lo được. Đóng góp không thay thế được của chủ sản phẩm nằm ở nhánh dưới — vì nó ở roadmap, ở số người dùng, ở tiền.
Đi đòi mỗi nhánh trên là đang làm hộ việc của chủ kỹ thuật, mà vẫn không quyết được gì.
Ba artifact quen thuộc — và chỗ hụt của từng cái
Happy path gần như không bắt được bug nào. Bug nằm ở nhánh lỗi, nhánh thiếu quyền, nhánh gửi lại — đúng những nhánh mà tài liệu sơ sài không mô tả.
Sáu câu chỉ chủ sản phẩm trả lời được
Câu thứ tư và câu thứ sáu là hai câu bị bỏ qua nhiều nhất, và cũng là hai câu rẻ nhất để hỏi.
Bảng kịch bản — artifact duy nhất phải ép có
Ba artifact ở trên hội tụ thành đúng một bảng, làm một lần cho mỗi kịch bản trọng yếu:
Kịch bản: Tạo đơn -> thanh toán -> xem lịch sử
Trọng số : chạm tiền CÓ | ~40k lượt/ngày | kiểm lại ~24 lần/năm
Biến động: đổi lần cuối 4 tháng trước | sắp đổi giao diện: không
# | Hành động người dùng | API được gọi | Quy tắc phải đúng | Tầng
----+-----------------------+----------------------+-----------------------------+------
1 | Chọn sản phẩm | GET /products | Giá hiện = giá server | API
2 | Bấm đặt hàng | POST /orders + key | Gửi lại 5 lần vẫn 1 đơn | API
3 | Chọn thanh toán | POST /payments | Tổng khớp bảng ca biên | API
4 | Xem lịch sử | GET /orders | Đúng 1 đơn, đúng thứ tự | API
- | Rút mạng ở bước 3 | (không gọi được) | Không mất, không nhân đôi | E2E
Dữ liệu test: seed bằng script, dọn được Chủ sở hữu khi đỏ: <tên người>
Có bảng này rồi thì quyết định tự rơi ra, không cần họp:
Đếm số dòng ghi API
Đó là phần rẻ — vài giây một case. Làm hết, không cần bàn.
Đếm số dòng ghi E2E
Đó là toàn bộ ngân sách đắt — vài phút một case. Chỗ duy nhất phải cân nhắc cắt.
Dòng dữ liệu test còn trống
Chưa quyết được. Đây là việc hạ tầng phải làm trước, không phải việc của người viết test.
Dòng "sắp đổi giao diện: có"
Cấm automation tầng giao diện cho kịch bản này. Dồn xuống API, đợi thiết kế chốt.
Cột Tầng do chủ kỹ thuật điền, không phải chủ sản phẩm. Việc của chủ sản phẩm là ép cho bảng tồn tại và ép ba dòng đầu có số.
Thêm hai mục vào Definition of Ready
Yêu cầu và acceptance criteria đã có Definition of Ready bảy mục. Bảy mục đó đủ để dev làm được hạng mục. Chưa đủ để quyết được automation. Thiếu đúng hai:
Có bảng kịch bản cho luồng bị chạm
Hành động, API, quy tắc phải đúng. Cột tầng để trống cũng được — chủ kỹ thuật điền trong buổi chuẩn bị.
Nêu được cách tạo và dọn dữ liệu test
Kể cả khi câu trả lời là "chưa có cách". Biết sớm thì mở phiếu hạ tầng, không phải phát hiện lúc sắp release.
Thêm hai dòng vào checklist có sẵn, không dựng checklist mới. Và giữ nguyên luật cũ: dev được quyền từ chối nhận việc chưa đạt Định nghĩa Sẵn sàng.
Quy trình quyết định bốn bước
Kiểm đủ hồ sơ chưa
Thiếu acceptance criteria dạng số, thiếu bảng kịch bản, thiếu contract — thì kết luận là "chưa quyết được", trả về chặng làm rõ. Đây không phải từ chối automation.
Xếp hạng
Chạm tiền hay quyền hay dữ liệu, nhân lượt dùng, nhân số lần kiểm lại mỗi năm, chia cho độ biến động. Xếp xong mới bàn tới tầng.
Chọn tầng
Mặc định là API. Chỉ leo lên E2E khi API không chứng minh nổi — mất mạng, hệ điều hành kill app, nâng cấp mang dữ liệu cũ, deep link. Danh sách đầy đủ ở phạm vi automation.
Chốt đánh đổi
Ghi thẳng vào quyết định: được bao nhiêu giờ viết automation, đổi lại cắt bỏ việc regression tay nào. Không có vế sau thì không duyệt.
Ba lằn ranh nên nói thẳng "chưa quyết được"
Hỏi sai và hỏi đúng
Hỏi ở cấp từng feature
- "Feature này có automation không?" — hỏi lại từ đầu mỗi sprint
- Automation luôn thua feature khi deadline gần
- Quyết định không tích luỹ, không thành bộ test
- Mỗi lần quyết lại tốn một buổi họp
- Ai giọng to hơn thì thắng, không ai có số để cãi
Hỏi ở cấp quy trình
- Biến ba artifact thành Definition of Ready, quyết một lần
- Hạng mục thiếu bảng kịch bản thì chưa được vào sprint
- Ở từng feature chỉ còn đúng một câu: tầng nào?
- Câu đó chủ kỹ thuật trả lời trong năm phút bằng chính cái bảng
- Tranh luận chuyển từ ý kiến sang số liệu
Sáu việc phải chốt trước khi coi là quyết xong
Ai chốt
Chủ sản phẩm chốt trọng số và thứ tự ưu tiên. Chủ kỹ thuật chốt tầng và ước lượng. Hai người không đổi vai cho nhau.
Chặn ở chặng nào
Buổi chuẩn bị hạng mục, trước khi vào sprint. Chặn ở đây rẻ hơn chặn lúc sắp release vài chục lần — xem shift left.
Người quyết cái gì
Chủ sản phẩm không chọn tầng automation. Chủ sản phẩm chỉ ép cho đủ dữ liệu để người khác chọn được.
Đo bằng số nào
Tỷ lệ kịch bản trọng yếu đã có bảng đầy đủ. Dưới 100% thì phần thiếu chính là phần đang quyết định mù.
Bằng chứng ở đâu
Bảng kịch bản nằm ngay trong hạng mục, cùng chỗ với acceptance criteria. Không nằm ở file riêng, không nằm trong trí nhớ ai.
Hết giờ cắt gì
Cắt dòng E2E trước, cắt từ luồng ít lượt dùng nhất. Không bao giờ cắt cái bảng — bảng rẻ, và không có nó thì lần sau lại quyết mù.