Con số 30% đó không phải nhờ viết test giỏi

Con số gọn gàng nhất trên CV của tôi cũng là con số tôi cẩn trọng nhất khi nói ra.

Đâu đó trong những năm tôi ở FPT — giữa 2017 và 2019, trong một dự án workflow cho một khách hàng nước ngoài mà tôi sẽ không nêu tên — chúng tôi giảm được khoảng 30% số production issue. Tôi liệt kê nó vì nó là sự thật. Tôi cẩn trọng với nó vì mỗi lần nói ra, có người trong phòng sẽ nghe thành "anh ta viết test giỏi". Không phải vậy.

Con số 30% không đến từ test suite#

Tôi từng làm manual tester, rồi chuyển sang automation. Câu chuyện dễ kể nhất sẽ là: automation harness bắt được mọi thứ trước khi release. Nhưng không phải. Automation chạy ổn. Nó bắt được regression — đúng như nhiệm vụ của nó. Nhưng tỉ lệ regression thực ra không phải vấn đề. Vấn đề là defect ở feature mới — những bug ship đi vì spec đã sai sẵn trước cả khi có ai kịp viết test cho nó.

Con số 30% đến từ việc kéo cuộc nói chuyện sớm hơn. Không phải nhờ test nhiều hơn, test khó hơn, hay test thông minh hơn. Mà nhờ viết test case ngay trong buổi spec review, trước khi development bắt đầu.

Nghe trên giấy thì nhàm. Làm thì cũng nhàm. Nhưng nó hiệu quả.

Spec review từng là nơi BA nói còn cả nhóm gật đầu#

Quy trình trước khi thay đổi quen thuộc với bất kỳ ai từng làm QA trong một dự án kiểu waterfall. Business analyst trình bày spec. Dev hỏi vài câu làm rõ về data model hay API. Tester thì chủ yếu lắng nghe, vì cái artifact "thật" của bên QA — test plan — là thứ chúng tôi viết sau, sau khi đã nhìn thấy build.

Cuộc họp kết thúc với spec được sign-off, rồi ba tuần sau chúng tôi phát hiện spec mơ hồ ở năm chỗ, mâu thuẫn ở hai chỗ, và im lặng hoàn toàn về những edge case thật sự quan trọng. Đến lúc đó dev đã chọn một cách hiểu, viết code theo cách hiểu đó, và chi phí để đổi cách hiểu là cả một sprint.

Thứ chúng tôi thay đổi rất nhỏ. Tester bắt đầu mang một bản draft test case vào buổi spec review. Không cần đầy đủ — chỉ những luồng hiển nhiên, cộng với những câu hỏi mà một test plan buộc người viết phải đặt ra. Nếu applicant submit hai lần trong năm giây thì sao. Nếu document upload fail giữa chừng thì sao. Hệ thống xử lý thế nào khi cron job và user đụng nhau trên cùng một record ở cuối tháng.

Một nửa những câu hỏi đó không có đáp án trong spec.

Những bug chúng tôi ngăn được là những bug chưa từng được viết ra#

Đây là phần khó truyền đạt cho người chưa ngồi trong những phòng họp đó.

Bạn không thể đếm những bug chưa từng xảy ra. Con số 30% có được từ việc so sánh giữa các release window, chứ không phải từ một thí nghiệm sạch sẽ nào. Điều tôi có thể nói là: những câu hỏi được đặt trong spec review là những câu hỏi mà, trong workflow cũ, sẽ thành defect hai tháng sau. Một field lẽ ra phải từ chối số âm. Một workflow lẽ ra phải cảnh báo trước khi cho hai user cùng edit một record. Một status transition vốn không hợp lệ nhưng chẳng được document là không hợp lệ.

Mỗi cái là một cuộc nói chuyện năm phút trong spec review. Mỗi cái lẽ ra đã thành nửa ngày điều tra defect, một bản hot-fix, một lời xin lỗi gửi đến khách hàng, và một regression test vĩnh viễn trong flow cũ.

Điều tôi muốn nói với chính mình ngày trước

Bug rẻ nhất để fix là bug bạn nói ra trước khi code tồn tại. Bug rẻ thứ hai là bug bạn bắt được trong code review. Mọi thứ sau đó đắt theo cấp số nhân — và chi phí không phải là giờ engineer, mà là niềm tin khách hàng mất đi mỗi lần một defect lọt đến tay họ.

Sự khó chịu chỉ chuyển chỗ, chứ không biến mất#

Điều không ai nhắc tới khi nói về việc kéo testing sớm hơn: nó làm các cuộc họp đầu kỳ tệ đi trước khi làm các cuộc họp cuối kỳ tốt hơn.

Một BA đã quen với việc trình bày spec cho cả phòng gật đầu không thích thú gì khi bị một tester hỏi, ngay trước mặt PM của khách hàng, chuyện gì xảy ra khi file upload bị timeout. Tháng đầu tiên rất khó chịu. Tôi nhớ một buổi review mà BA — senior, sắc sảo, được cả dự án nể trọng — kéo tôi ra ngoài sau cuộc họp và nói, đại ý, rằng tôi đang làm chị ấy trông như không chuẩn bị bài.

Chị ấy đúng. Tôi đã làm vậy. Spec thật sự chưa sẵn sàng, và buổi họp đã hoạt động như một nghi thức lịch sự để giả vờ rằng nó đã sẵn sàng.

Chúng tôi nói chuyện. Team lead ủng hộ thay đổi. Trong vòng một quý, các BA bắt đầu tự viết phần edge case vào spec trước buổi review — một phần để đi trước câu hỏi của tester, một phần vì khi đã rõ là những câu hỏi đó sẽ được đặt ra, nghĩ trước chúng trong một phòng yên tĩnh dễ hơn nhiều so với nghĩ dưới ánh nhìn của khách hàng.

Sự thay đổi không phải là QA giỏi lên. Mà là cả đội đồng ý chịu khó chịu sớm hơn để đổi lấy yên ổn về sau.

Con số 30% thật sự đang đo cái gì#

Tôi nghĩ về con số này mỗi khi có ai đó bảo tôi "improve test coverage" như một mục tiêu tự thân.

Coverage là chỉ số trễ của một thứ đã xảy ra ở thượng nguồn. Nếu spec sắc, nếu dev hiểu edge case trước khi viết code, nếu test case được tranh luận xong trước khi bàn phím được mở ra — coverage tự lo được phần của nó, và những bug còn sót lại là những bug thật sự bất ngờ, chứ không phải những bug mà đọc kỹ spec là đã bắt được.

30% không phải đo việc test của chúng tôi đã giỏi đến mức nào. Nó đo việc những câu hỏi khó chịu đã được đặt ra sớm hơn bao nhiêu. Test suite là artifact nhìn thấy được. Cơ chế thực sự là một thay đổi văn hoá họp hành.

Đó là lý do tôi cẩn trọng với con số. Tôi muốn nó nằm trên CV vì đó là thứ rõ ràng nhất tôi có thể chỉ ra từ những năm đó. Tôi không muốn nó được hiểu thành "cải thiện test automation" hay "dẫn dắt QA initiative", vì không phải nhờ những thứ đó mà chúng tôi có được 30%. Thứ đem lại con số ấy là một tester sẵn sàng hỏi một câu hỏi ngớ ngẩn trước mặt khách hàng, và một đội sẵn sàng để chị ấy hỏi.

Điều tôi giữ lại từ con số đó#

Nhiều năm sau, khi xây dựng các hệ thống autonomous commerce mà "spec" nửa là tiếng Anh nửa là behavior của model, bài học vẫn đúng theo một cách kỳ lạ. Bug rẻ nhất vẫn là bug bạn nói ra trước khi code tồn tại. Định dạng đã thay đổi — test case đã thành behavior trace, spec review đã thành tool-call review — nhưng động tác cốt lõi vẫn vậy. Kéo sự khó chịu sớm hơn. Đổi một cuộc họp thoải mái hôm nay lấy một bản release yên ổn về sau.

Tôi từng viết về một bản năng liên quan trong bài về việc tôi vẫn nghĩ như một tester sau bốn năm làm fullstack — cái thôi thúc hỏi "cái gì sẽ làm hỏng nó" không tự rời đi khi bạn đổi vai. Con số 30% là bằng chứng rõ ràng nhất tôi có rằng cái bản năng đó, được áp dụng đúng lúc, đáng giá hơn bất kỳ công cụ cụ thể nào.

Đó là phiên bản của câu chuyện tôi tin. Phiên bản ngắn hơn — chúng tôi giảm được 30% production issue — là sự thật, nhưng nó thiếu phần thật sự quan trọng.