Tự động hóa kiểm thử hướng đặc tả: Khi bộ test 'xanh' chưa chắc đã đáng tin

Trong phát triển phần mềm, rất ít thứ mang lại cảm giác yên tâm hơn một bộ kiểm thử tự động chạy xong với toàn dấu tích xanh. Đội ngũ nhìn vào đó, thở phào, rồi tự tin đẩy mã nguồn lên môi trường sản xuất. Nhưng cảm giác yên tâm ấy có thể là một cái bẫy.

Câu hỏi trung tâm mà bài viết này đặt ra rất đơn giản nhưng khó chịu: liệu một bộ test xanh có thực sự chứng minh phần mềm của bạn hoạt động đúng?

Vấn đề: màu xanh không phải là bằng chứng

Hầu hết các bài kiểm thử hiện nay được viết theo kiểu "kiểm tra những gì lập trình viên đã nghĩ đến". Điều đó có nghĩa là chúng ta đang kiểm tra chính giả định của mình, chứ không kiểm tra yêu cầu thực tế của sản phẩm.

• Nếu một hàm xử lý sai một trường hợp biên hiếm gặp mà không ai nghĩ tới, sẽ không có bài test nào bắt được lỗi đó.
• Nếu hai thành phần hiểu sai nhau về định dạng dữ liệu, các test đơn lẻ vẫn có thể đều xanh.
• Nếu yêu cầu nghiệp vụ thay đổi nhưng test cũ không cập nhật, bộ test vẫn "đúng" theo nghĩa kỹ thuật nhưng đã lạc hậu so với thực tế.

Kết quả là một nghịch lý quen thuộc: tỷ lệ bao phủ (coverage) cao, test xanh đều đặn, nhưng lỗi vẫn lọt ra sản xuất.

Vì sao điều này xảy ra?

Có vài nguyên nhân gốc rễ thường gặp.

Thứ nhất, test được viết sau khi suy nghĩ về code, không phải về đặc tả. Lập trình viên nhìn vào hàm vừa viết rồi nghĩ xem nên kiểm tra gì. Cách này dễ, nhưng nó khóa bài test vào cách hiện thực, chứ không phải vào hành vi mà người dùng mong đợi.

Thứ hai, các bài test dễ bị "phản xạ sai". Khi có lỗi, thay vì sửa sản phẩm, người ta sửa kỳ vọng trong test cho khớp với hành vi thực tế. Dần dần, bộ test trở thành một tấm gương phản chiếu lỗi thay vì phát hiện lỗi.

Thứ ba, thiếu một nguồn sự thật duy nhất. Yêu cầu nằm rải rác trong tài liệu, trong đầu các thành viên, trong ticket, trong tin nhắn chat. Test chỉ là một mảnh ghép nữa, và không ai đảm bảo mảnh ghép đó khớp với bức tranh tổng thể.

Một bộ test xanh chỉ chứng minh rằng hệ thống hoạt động đúng như cách bạn nghĩ nó hoạt động — chứ không chứng minh nó hoạt động đúng như nó nên hoạt động.

Hướng tiếp cận: kiểm thử hướng đặc tả

Ý tưởng cốt lõi của kiểm thử hướng đặc tả (spec-driven testing) là đảo ngược quy trình. Thay vì bắt đầu từ code để viết test, ta bắt đầu từ đặc tả hành vi — một mô tả rõ ràng, có thể kiểm chứng được về việc hệ thống phải làm gì trong từng tình huống cụ thể.

Đặc tả này trở thành nguồn sự thật duy nhất:

• Nó độc lập với cách hiện thực, nên không bị "đóng băng" theo code.
• Nó mô tả hành vi quan sát được từ bên ngoài, gần với góc nhìn của người dùng.
• Nó có thể được dùng để sinh ra test tự động, thay vì viết thủ công.

Cách tiếp cận này nối liền các truyền thống như Specification by Example, kiểm thử dựa trên thuộc tính (property-based testing) và phát triển hướng hành vi (BDD), nhưng đặt trọng tâm vào việc biến đặc tả thành thứ có thể thực thi và kiểm chứng một cách hệ thống.

Điều này có nghĩa gì với đội ngũ tại Việt Nam?

Với các đội phát triển phần mềm ở Việt Nam — đặc biệt là các đội làm sản phẩm outsource hoặc product có tốc độ thay đổi nhanh — vấn đề này càng cấp thiết.

Khi khách hàng hoặc thị trường liên tục thay đổi yêu cầu, một bộ test gắn chặt vào cách hiện thực sẽ nhanh chóng trở thành gánh nặng bảo trì. Ngược lại, nếu đặc tả hành vi được viết rõ ràng và tách biệt, việc thay đổi yêu cầu chỉ cần cập nhật đặc tả, còn phần sinh test và kiểm tra có thể tự động hóa.

Đây cũng là điểm giao thoa đáng chú ý với làn sóng AI hỗ trợ lập trình: khi các mô hình ngôn ngữ có thể sinh mã, việc có một đặc tả rõ ràng càng trở nên quan trọng, bởi đặc tả chính là thứ giúp kiểm chứng xem mã do AI sinh ra có thực sự đúng hay không.

Kết luận

Một bộ test xanh là điều kiện cần, nhưng chưa bao giờ là điều kiện đủ. Bài viết này là phần đầu trong chuỗi nội dung về tự động hóa kiểm thử hướng đặc tả. Ở các phần tiếp theo, chúng ta sẽ đi sâu vào cách xây dựng đặc tả có thể kiểm chứng, cách sinh test tự động từ đặc tả, và cách biến chúng thành một phần tự nhiên trong quy trình phát triển hằng ngày.

Điểm mấu chốt cần nhớ: đừng để màu xanh của bộ test ru ngủ bạn. Hãy hỏi xem bộ test đó đang kiểm chứng điều gì — và liệu điều đó có thực sự quan trọng với người dùng hay không.