Hãy hình dung hai đội cùng làm một chức năng "xuất báo cáo doanh thu".
Đội A đợi đến khi code xong mới đưa cho tester. Tester chạy thử, phát hiện báo cáo đang tính sai múi giờ — đơn hàng lúc nửa đêm bị nhảy sang ngày hôm sau. Lần ngược lại, hóa ra ngay từ đầu tài liệu yêu cầu đã không nói rõ "doanh thu theo ngày" là theo múi giờ nào. Để sửa, dev phải viết lại logic xử lý ngày, tester phải làm lại bộ test, tài liệu phải cập nhật. Mất vài ngày công của cả nhóm.
Đội B thì khác. Ngay buổi refinement (buổi cả nhóm cùng đọc và làm rõ yêu cầu trước khi bắt tay vào làm), một bạn tester hỏi: "Doanh thu theo ngày là tính theo múi giờ server hay múi giờ người dùng?" Câu hỏi đó khiến cả nhóm khựng lại — vì chưa ai nghĩ tới. Họ làm rõ ngay trong tài liệu, trước khi viết một dòng code. Chi phí: vài phút trao đổi.
Cùng một lỗi tiềm ẩn. Một đội trả giá bằng một tuần, đội kia bằng vài phút. Khác biệt nằm ở đúng một thứ: thời điểm. Và đó chính là nội dung của nguyên tắc Early Testing.
Early Testing là gì?
Early Testing là một trong bảy nguyên tắc kiểm thử nền tảng của ISTQB. Nội dung của nó rất ngắn gọn: hoạt động kiểm thử nên bắt đầu càng sớm càng tốt trong vòng đời phát triển phần mềm.
"Sớm" ở đây là sớm đến mức nào? Sớm hơn nhiều so với suy nghĩ thông thường. Không phải đợi có sản phẩm chạy được mới test. Ngay khi có tài liệu yêu cầu, có bản thiết kế, có một user story (mô tả ngắn một yêu cầu từ góc nhìn người dùng) trên bảng — đã có thứ để kiểm thử rồi. Bạn rà soát, đặt câu hỏi, tìm chỗ mơ hồ hay thiếu sót. Đó đã là kiểm thử, dù chưa có gì để "chạy".
Nói cách khác, Early Testing đẩy việc kiểm thử về phía trái của vòng đời — về gần với khâu phân tích yêu cầu và thiết kế. Đây cũng là tinh thần mà ngày nay nhiều người gọi là "shift-left testing".
Vì sao càng sớm càng rẻ?
Có một quy luật khắc nghiệt: chi phí sửa một lỗi tăng dần theo thời gian nó sống sót.
Lý do không khó hiểu. Một lỗi trong tài liệu yêu cầu, nếu bị bắt ngay lúc review, chỉ tốn vài phút sửa một dòng chữ. Nhưng nếu nó lọt qua, nó không nằm yên — nó lan ra:
- Dev đọc yêu cầu sai và code theo cách hiểu sai.
- Tester viết test case dựa trên cùng yêu cầu sai đó, nên test dù có pass thì kết quả cũng vô nghĩa.
- Lỗi đi qua tích hợp, lên môi trường staging (môi trường gần giống thật để chạy thử trước khi phát hành), đôi khi ra tới production.
Càng đi xa, càng nhiều thứ được xây dựa trên cái sai ban đầu. Đến lúc phát hiện, bạn không chỉ sửa một dòng nữa — bạn phải gỡ cả một chuỗi: code, test, tài liệu, đôi khi cả dữ liệu đã sinh ra. Lỗi không đắt hơn vì bản thân nó phức tạp hơn, mà vì cái giá của việc tháo dỡ những gì đã xây chồng lên nó.
Early Testing trông như thế nào trong thực tế?
Nguyên tắc thì gọn, nhưng áp dụng ra sao mới là phần quan trọng. Dưới đây là những việc cụ thể.
Review yêu cầu và thiết kế. Đây là hình thức Early Testing rõ nhất. Khi đọc một user story, hãy chủ động đặt câu hỏi: trường hợp ngoại lệ thì sao? Dữ liệu rỗng thì sao? Điều kiện biên ở đâu? Có hành vi nào khác nhau giữa các môi trường không? Mỗi câu hỏi tìm ra một lỗ hổng trên giấy là một lỗi bạn không phải sửa trong code.
Tester tham gia từ đầu, không phải cuối. Nếu tester chỉ xuất hiện ở khâu cuối để "nghiệm thu", thì mọi hiểu lầm về yêu cầu đã kịp đông cứng lại từ lâu. Đưa tester vào ngay từ buổi refinement, buổi planning — nơi yêu cầu còn đang được định hình — là cách rẻ nhất để chặn hiểu lầm.
Định nghĩa "kết quả mong đợi" trước. Trước khi code, hãy thống nhất rõ thế nào là đúng. Việc này vừa làm lộ ra những yêu cầu chưa rõ ràng (nếu không định nghĩa nổi kết quả đúng, tức là yêu cầu còn mơ hồ), vừa cho dev một cái đích cụ thể để nhắm tới.
Test sớm ở từng tầng. Dev viết unit test (test kiểm tra riêng từng đơn vị code nhỏ) ngay khi code thay vì để dành. Tích hợp được kiểm tra sớm thay vì dồn đến cuối. Mỗi tầng bắt lỗi của riêng nó, không đẩy gánh nặng xuống tầng sau.
Một hiểu lầm phổ biến
Ở đây mình muốn nói thẳng một quan niệm cần gỡ bỏ: "Testing là việc làm sau khi code xong."
Quan niệm này vẽ ra một quy trình tuyến tính — phân tích, rồi code, rồi cuối cùng mới test — và vô tình biến kiểm thử thành một cánh cổng kiểm tra ở phút chót. Nhưng nếu bạn chỉ test ở cuối, bạn đang để lỗi tích lũy qua suốt cả chặng đường trước đó, rồi cố bắt hết chúng trong khoảng thời gian ngắn nhất và áp lực nhất của dự án.
Early Testing đảo ngược tư duy đó. Kiểm thử không phải một giai đoạn nằm cuối hàng. Nó là một hoạt động trải dài suốt vòng đời — bắt đầu từ dòng yêu cầu đầu tiên. Chất lượng không phải thứ được "kiểm" vào lúc cuối; nó được xây vào từ đầu.
Mối liên hệ với kiểm thử tĩnh
Nếu bạn từng đọc về Static Testing (Kiểm thử tĩnh) — việc rà soát tài liệu, đặc tả, mã nguồn mà không cần chạy chương trình — thì bạn sẽ thấy nó và Early Testing là hai mặt của cùng một đồng xu.
Static Testing trả lời câu hỏi "làm thế nào để test khi chưa có code?". Early Testing trả lời câu hỏi "khi nào nên bắt đầu?". Và câu trả lời gặp nhau ở cùng một điểm: ngay từ khâu phân tích yêu cầu. Review một đặc tả vừa là Static Testing, vừa là Early Testing trong hành động. Bắt được một yêu cầu mơ hồ ở đó, bạn đồng thời thực hiện cả hai nguyên tắc — và tiết kiệm được nhiều nhất.
Lời kết
Quay lại hai đội ở đầu bài. Đội B không giỏi hơn đội A về kỹ thuật. Họ chỉ làm một việc đơn giản: đặt câu hỏi sớm hơn. Một câu hỏi đúng lúc, ở đúng thời điểm yêu cầu còn trên giấy, đã thay thế cho vài ngày sửa lỗi sau này.
Đó là toàn bộ tinh thần của Early Testing. Không cần công cụ đắt tiền, không cần kỹ thuật cao siêu — chỉ cần dời sự chú ý của bạn về phía trước một chút. Đọc kỹ yêu cầu trước khi code. Đặt câu hỏi trước khi giả định. Định nghĩa "đúng" trước khi bắt đầu làm.
Lần tới khi nhận một user story, thử dừng lại và hỏi một câu mà bạn nghĩ "chắc ai cũng đã rõ rồi". Rất có thể, đó chính là câu hỏi cứu cả team vài ngày công.
Cảm ơn bạn đã đọc đến đây. Chúc bạn test vui!
Tài liệu tham khảo
- ISTQB Certified Tester Foundation Level Syllabus.