Tác giả
Đọc và hiểu yêu cầu là nhóm việc đầu tiên trong bốn nhóm việc của một tester — và là nhóm ngốn nhiều thời gian nhất. Ba nhóm còn lại ở Manual testing là gì.
Nhận một chức năng cần test. Hỏi tài liệu yêu cầu. Nhận về một đoạn chat, một ảnh chụp màn hình, và câu "làm giống app kia".
Tình huống này phổ biến đến mức nó gần như là mặc định ở nhiều dự án. Nhưng hầu như không có bài nào viết về nó, vì nó không phải quy trình chuẩn — nó là chuyện thật.
Việc đầu tiên không phải là test
Không có tài liệu yêu cầu thì bạn không thể biết chắc "đúng" là gì. Nên việc đầu tiên là dựng ra một bản mô tả cái đúng, rồi đi xin xác nhận.
Nói cách khác: bạn tạm thời làm luôn phần việc của người phân tích yêu cầu. Không phải vì đó là việc của bạn, mà vì không có nó thì phần việc của bạn không làm được.
Điều tuyệt đối không nên làm: cứ test theo cảm nhận riêng rồi báo lỗi. Sẽ có một phần lớn số lỗi bị trả về với câu "cái đó thiết kế như vậy", và mỗi lần như thế uy tín của bạn giảm một chút. Sau vài vòng, những lỗi thật của bạn cũng bị đọc với thái độ nghi ngờ.
Năm nguồn thay thế tài liệu
Không có tài liệu chính thức không có nghĩa là không có thông tin. Thông tin đang nằm rải rác.
1. Chính phần mềm đang chạy.
Nếu đã có bản cũ đang chạy, hành vi hiện tại là điểm mốc. Nó không chắc đúng — nhưng nó là thứ người dùng đang quen, và thay đổi nó mà không thông báo trước cũng là một loại lỗi.
2. Lịch sử trao đổi.
Đoạn chat, email, bình luận trong công cụ quản lý công việc. Ở nhiều dự án, đây là chỗ các quyết định thật sự được đưa ra. Rất rời rạc và khó tìm, nhưng có thật và có thẩm quyền.
3. Lỗi cũ đã sửa.
Danh sách lỗi cũ nói rất nhiều về ý định. Một lỗi từng được sửa nghĩa là ai đó đã xác nhận hành vi nào là đúng — và xác nhận đó vẫn còn giá trị.
Đây là nguồn bị bỏ qua nhiều nhất, dù nó là nguồn dễ tra nhất.
4. Người dùng thật, hoặc người gần họ nhất.
Người bán hàng, người hỗ trợ khách, người vận hành. Họ biết luồng nghiệp vụ thật, và thường rõ hơn tài liệu — vì tài liệu viết một lần rồi để đó, còn họ dùng hàng ngày.
5. Dữ liệu và giao diện lập trình.
Tên các ô dữ liệu, ô nào bắt buộc, giới hạn độ dài, kiểu dữ liệu, ràng buộc giữa các bảng. Đấy đã là quy tắc nghiệp vụ được viết ra, chỉ là dưới dạng kỹ thuật.
Một ô ghi độ dài tối đa 50 ký tự là một quy tắc. Một ô bắt buộc không được rỗng là một quy tắc. Một ràng buộc chỉ cho phép một trong ba giá trị là một quy tắc — và nó nói cho bạn biết có đúng ba trạng thái, không phải bốn.
Cách làm: viết giả định ra, rồi đi xin xác nhận
Bước 1 — viết ra những gì bạn cho là đúng, dưới dạng câu khẳng định.
Không viết câu hỏi. Viết câu khẳng định.
❌ Số lượng tối đa cho một sản phẩm là bao nhiêu?
✅ Tôi hiểu là số lượng tối đa cho một sản phẩm là 99. Nhập 100
sẽ bị chặn và có thông báo nói rõ giới hạn. Đúng không?
Câu thứ hai gần như luôn nhận được trả lời, vì phản đối một khẳng định sai chỉ tốn một chữ "không". Câu thứ nhất đẩy toàn bộ việc suy nghĩ sang người đọc, nên nó bị để đó.
Đây là mẹo nhỏ nhưng tác dụng lớn, và nó dùng được ở mọi tình huống cần thông tin từ người đang bận.
Bước 2 — gửi cho người quyết được, và ghi lại câu trả lời ở nơi tìm lại được.
Được trả lời miệng lúc họp thì ba tuần sau không ai nhớ, kể cả người đã trả lời. Ghi lại thành chữ, ở chỗ cả đội thấy — bình luận trong công cụ quản lý công việc là chỗ tốt, vì nó gắn với đúng việc đó.
Bước 3 — chỗ nào không ai xác nhận thì ghi rõ là chưa xác nhận.
Đừng để trống, và cũng đừng tự quyết.
Ghi rõ "chưa có xác nhận" là một hành động có ích thật, không phải thủ tục: nó chuyển rủi ro từ chỗ vô hình sang chỗ nhìn thấy được. Khi có sự cố, sự khác nhau giữa "không ai biết" và "đã nêu ra mà chưa ai trả lời" là rất lớn.
Một lợi ích không ai nói
Việc viết giả định ra rồi đi xác nhận thường tự tìm ra lỗi trước khi test.
Vì khi ép mọi thứ thành câu khẳng định rõ ràng, các chỗ mâu thuẫn lộ ra. Hai người trả lời hai kiểu khác nhau cho cùng một câu. Một quy tắc không thể đúng đồng thời với quy tắc ở mục trước. Một trạng thái không có đường nào đi tới.
Những mâu thuẫn đó là lỗi — lỗi ở tầng yêu cầu. Và sửa ở tầng đó rẻ hơn nhiều so với sửa sau khi đã lập trình xong, vì chưa có mã nào phải viết lại.
Đây cũng là lý do việc này không phải làm thay việc của người khác một cách vô ích. Nó là phần công việc có giá trị cao nhất trong cả chu trình, chỉ là nó không trông giống test.
Khi vẫn phải test dù chưa có xác nhận
Có lúc không kịp. Ngày ra bản đến rồi, và câu hỏi vẫn chưa ai trả lời.
Lúc đó vẫn còn nhiều thứ test được mà không cần biết quy tắc nghiệp vụ, vì chúng đúng ở mọi phần mềm:
- Không được sập, không được trắng trang
- Dữ liệu đã lưu phải hiện lại đúng như đã lưu
- Thông báo lỗi phải nói được điều gì đã sai
- Chạy được trên trình duyệt và thiết bị mà người dùng thật đang dùng
- Không có đường nào để người dùng bị kẹt — không đi tiếp và không lùi lại được
- Người dùng không xem hoặc sửa được dữ liệu của người khác
Gạch đầu dòng cuối đáng chú ý: nó không cần tài liệu yêu cầu để biết là sai. Không có tài liệu nào cho phép người này đọc dữ liệu của người kia.
Và trong báo cáo, nói rõ phạm vi: đã test được những gì, chưa test được những gì, vì sao. Câu đó bảo vệ cả bạn và cả bản phát hành.
Nói lại một câu
Không có tài liệu thì đừng đi test bằng cảm nhận. Hãy viết cảm nhận đó ra thành câu khẳng định, gửi cho người quyết được, và ghi lại câu trả lời.
Việc đó chậm hơn lúc đầu và nhanh hơn ở tổng thể — vì nó cắt bỏ vòng lặp báo lỗi rồi bị trả về.
