Requirement nghe rất rõ trong cuộc họp: user có thể cancel order trước khi hàng được ship. Ai cũng gật đầu vì câu đó dễ hiểu. Rồi QA hỏi nếu payment đã captured thì sao. Product hỏi partial shipment có tính không. Engineering hỏi warehouse status có real time không. Câu đơn giản ấy đã chứa nhiều uncertainty hơn vẻ ngoài ban đầu.
Behavior-Driven Development hữu ích chính trong những khoảnh khắc như vậy. Ở trạng thái tốt nhất, BDD không phải một testing tool. Nó là một thói quen trò chuyện. Nó yêu cầu team mô tả behavior bằng example cụ thể trước khi implementation bắt đầu. Thay vì dựa vào sự đồng ý trừu tượng, team viết scenario cho thấy system nên hành xử ra sao trong tình huống cụ thể.
Format quen thuộc là Given, When, Then. Given một order đã paid nhưng chưa shipped, when customer cancel, then system đánh dấu order là cancelled và bắt đầu refund. Given một order đã shipped, when customer cố cancel, then system giải thích cancellation không còn available. Format đơn giản, nhưng giá trị không nằm ở syntax. Giá trị là mọi người cùng nhìn một example và nhận ra điều còn thiếu.
BDD hoạt động vì example phơi bày assumption ẩn. Product có thể nghĩ về lời hứa với user. QA có thể nghĩ về edge case. Engineering có thể nghĩ về data state và integration timing. Support có thể nghĩ về message customer sẽ đọc. Khi các góc nhìn đó gặp nhau quanh một scenario, ambiguity dễ được bàn hơn. Team có thể disagree sớm hơn, khi đổi chữ vẫn rẻ hơn đổi code.
BDD tốt dùng business language. Scenario không nên nói Given row exists in orders table with status 3, trừ khi business thật sự nói như vậy. Nó nên nói Given the order has been paid and is waiting for shipment. Điều này quan trọng vì BDD là cây cầu giữa nhiều role. Nếu chỉ engineer đọc được scenario, team đã âm thầm biến collaboration thành một artifact kỹ thuật nữa.
Automation có thể hữu ích, nhưng không nên là ám ảnh đầu tiên. Một số team áp dụng BDD và ngay lập tức tạo một bộ end-to-end test lớn, chậm và giòn bằng Gherkin khó đọc. File nhìn có vẻ readable trên lý thuyết, nhưng mỗi step definition giấu setup phức tạp, browser chậm, và selector mong manh. Team rồi dành nhiều thời gian bảo trì ceremony hơn là cải thiện shared understanding.
Cách bình tĩnh hơn là dùng BDD trước cho discovery. Viết example cùng nhau. Giữ chúng gần acceptance criteria. Quyết định scenario nào đáng automation và ở level nào. Một business rule có thể được bảo vệ tốt nhất bằng unit hoặc integration test nhanh. Một user journey critical có thể cần end-to-end test. Một manual operations path hiếm có thể chỉ cần checklist. BDD không yêu cầu mọi câu đều trở thành browser test.
Cuộc trò chuyện cũng nên bao gồm negative path. Chuyện gì xảy ra khi user thiếu permission? Nếu payment provider down thì sao? Nếu hai cancellation attempt đến cùng lúc thì sao? Customer nên thấy gì nếu warehouse status đổi trong lúc checkout? Những example này là nơi behavior trở nên thật. Chúng ngăn team ship chỉ happy path từng nghe có vẻ đầy đủ trong meeting đầu tiên.
BDD cũng cải thiện language theo thời gian. Khi team dùng cùng từ trong scenario, code, test và support documentation, product trở nên dễ suy luận hơn. Cancelled, refunded, shipped, returned, expired và failed không chỉ là label. Chúng là shared concept. Nếu các team dùng cùng một từ với nghĩa khác nhau, BDD sẽ làm tension đó hiện ra nhanh.
Dĩ nhiên có giới hạn. BDD có thể chậm nếu mọi thay đổi nhỏ đều cần workshop trang trọng. Nó có thể thành trình diễn nếu scenario được viết sau implementation chỉ để thỏa process. Nó có thể gây rối nếu team viết quá nhiều example mà không chọn những example thật sự làm rõ decision. Như hầu hết practice khác, nó hữu ích khi ambiguity đắt đỏ và nên được bỏ qua khi behavior đã hiển nhiên.
Những BDD session tốt nhất tôi từng thấy thường rất thực tế và yên lặng. Một PO, QA, developer, và đôi khi designer ngồi quanh một behavior nhỏ rồi hỏi example nào chứng minh chúng ta đã hiểu. Họ viết vài scenario, bỏ từ mơ hồ, gọi tên edge case, và rời đi với ít uncertainty hơn lúc bắt đầu. Output sau này có thể thành automated test, nhưng kết quả đầu tiên là alignment.
Behavior-Driven Development không phải làm requirement trông kỹ thuật hơn. Nó là làm behavior có thể được bàn trước khi code đóng cứng quanh một hiểu lầm. Nếu team bạn thường nói chúng ta đã đồng ý nhưng thật ra mỗi người hiểu một kiểu, vài example Given-When-Then cẩn thận có thể là nơi đơn giản nhất để chậm lại và nghe nhau sớm hơn.