Behaviour Driven Development. Có thực sự tốt hơn cho Agile? (Phần II)

Các đặc tính, kịch bản và Living Documentation

Kể từ khi bắt đầu với sự phát triển Agile vài năm trước đây, chúng tôi đã theo dõi và giúp đỡ những người khác làm như vậy. Hơn một lần, cùng một ý tưởng sai lầm đã xuất hiện: "Điều gì sẽ xảy ra nếu bạn có thể tạo ra đặc tả kỹ thuật từ những User story"? Đây là 1 giải pháp hấp dấn để mở ra các vấn đề của tài liệu. Lý tưởng hơn, bạn cần phải ghi lại các tính năng của phần mềm nhưng điều này không thể thực hiện trước được và nó đòi hỏi hướng dẫn sử dụng liên tục. Đó là tài liệu phát triển mà không ai muốn viết nó. Vấn đề với tìm kiếm User story cho câu trả lời về User story thường là:

1. Chưa hoàn thành, thường có tiêu chuẩn chấp nhận kém.

2. Một mục công việc tạm thời hoặc giả tạo nó sẽ nhanh chóng bị thay thế hoặc bổ sung bởi các user story khác.

BDD, hay nói cách khác, là tất cả về các tính năng. Bạn sẽ thấy chính mình viết rất nhiều các file đặc tả, cả trước, trong, và sau khi bạn viết các User story. Các đặc tả định nghĩa những gì phần mềm làm. Ví dụ các kịch bản giải thích làm thế nào 1 tính năng hoạt động. Các User story là đã được tạo như ‘developer tasks’ để đảm bảo 1 phần của tính năng được thực thi.

User story nên tham chiếu kịch bản mà nó đang cố gắng bao phủ hết và trong thực tế, các tình huống thường được khám phá khi thảo luận các chi tiết của 1 User story tại 1 cuộc họp planning meeting. Trong trường hợp này, kịch bản được thêm vào tính năng và tính năng này trở nên hoàn chỉnh hơn và được mọi người hiểu rõ hơn. Đó là sự hiểu biết lặp đi lặp lại và phát triển các tính năng sản phẩm mà BDD làm tốt.

1 đầu ra tự nhiên của quá trình là một tập các tính năng, hoàn chỉnh với các ví dụ có thể biến thành một đặc tả kỹ thuật. Thậm chí tốt hơn, việc tạo ra tài liệu này có thể được tự động. Đây được gọi là Tài Liệu Sống-Living Documentation. Và chúng tôi nghĩ nó rất tuyệt.

Automated testing

Tự động hóa gần như... tốt, chúng ta nói rằng có rất nhiều người nói về nó, nhưng họ không phải lúc nào cũng làm được nhiều. Có những lý do tốt cho điều này, đặc biệt là đối với các dự án ngắn hạn, nơi mà chi phí thường vượt quá lợi nhuận. Tuy nhiên, không có nghi ngờ gì để có được lợi nhuận tối đa từ BDD, automation test là một cái gì đó cần phải được thực hiện nghiêm túc.

Có rất nhiều công cụ BDD khuyến khích và tạo điều kiện thử nghiệm tự động cho phép bạn tạo ra các bài test trực tiếp từ các kịch bản theo mô hình BDD được viết sử dụng Gherkin. Điều này là rất tốt vì hai lý do chính:

1. Các bài test của bạn dựa trên cùng một ví dụ mà cả team đã làm quen.

2. Các bài test của bạn được viết từ trên xuống dưới, chứ không phải từ dưới lên. Lưu ý: Điều này không ngăn được việc finer grained testing bằng bất kỳ ý nghĩa nào, nhưng bài test của bạn có thể thực tế hơn ở cấp độ nuts và bolts nếu cần.

Tiết lộ đầy đủ: Chúng tôi đã chạy một số dự án mô hình BDD mà không sử dụng automationg testing (gasp!) Và chúng tôi thấy rằng nó đã vượt ra những gì chúng tôi muốn. Các ví dụ cụ thể và kịch bản mà bạn viết cho mỗi tính năng có thể khá cao cấp. Đây là một điểm xuất phát tuyệt vời để thử nghiệm nhưng nhiều chi tiết và các bài test quy định sẽ phải được viết và duy trì. Điều này làm cho bạn có hai lựa chọn: 1) viết và duy trì các script test thủ công chi tiết hơn 2) viết một bộ các bài test tự động xuất ra từ một kịch bản cụ thể.

Dù bằng cách nào, kết quả cuối cùng cần phải là một phần của tài liệu sản phẩm và bộ kiểm thử hồi quy. Tự động hóa rõ ràng là một cách tiếp cận đẹp và tốt hơn để mô hình BDD phát triển lặp đi lặp lại.

Chú ý những thiếu sót

Có phải tất cả mọi thứ đều tốt? Chúng tôi đã đi nhanh chóng một loạt các User story mà có thể là mơ hồ và lỗi truyền đạt đến một tập hợp các tính năng và các ví dụ chính có thể được sử dụng để tạo ra tài liệu, kiểm thử và cuối cùng là một đặc tả kỹ thuật sống. Vâng, chúng tôi nghĩ rằng BDD có rất nhiều thứ để cung cấp nhưng bạn vẫn cần phải nhận thức được một số thiếu sót tiềm ẩn.

1. BDD không có gì để nói về tầm nhìn. Trong thực tế, nó cố gắng để tránh chúng. Như vậy tính năng dựa trên đặc tả kỹ thuật không nên tồn tại độc lập. Nó có thể chi tiết những gì hệ thống dự kiến sẽ làm, nhưng không nhất thiết làm thế nào mà nó được dự kiến sẽ làm điều đó. Để giải quyết vấn đề này, chúng tôi tạo ra cả wireframes và tầm nhìn nguyên mẫu tương tác cho tất cả các sản phẩm chúng tôi làm. Điều này đảm bảo rằng UX được khám phá và thiết kế đúng và tiếp tục tạo thành đặc tả tầm nhìn của sản phẩm.

2. Có khá nhiều công cụ cho phép bạn tạo các bài test từ các ví dụ được viết và báo cáo về phạm vi kết quả test. Tuy nhiên, thường bạn vẫn cần phải ghi lại những bài test gì đã được thực hiện, bởi ai, vào ngày nào. Thông thường bạn sẽ sử dụng một công cụ quản lý test dành riêng cho việc này nhưng nhiều người trong số họ vẫn không nói cùng một ngôn ngữ với BDD, vì vậy nếu điều đó có ý nghĩa đối với bạn, bạn sẽ phải lựa chọn cẩn thận.

3. Mặc dù có nhiều lợi ích rõ ràng với automated testing, nhưng trong thực tế nó khó có thể đạt được tất cả những lợi ích đó. Bạn cần các tester người mà có thể code và người mà là 1 phần của team scrum của bạn (hoặc tương tự). Đây là vấn đề đặc biệt khó đối với các công ty của outsource QA. Tuy nhiên, Automated testing là tốn kém hơn đối với những dự án ngắn hạn.

4. Vẫn là những ngày đầu tiên của BDD. Agile đã được khoảng hơn 20 năm nhưng chúng tôi vẫn thấy ngày nay mình giúp các công ty để hiểu được nó. Với BDD, các quyển sách, các công cụ và phần mềm không có gì gần gũi bởi vì họ đã quen với sự phát triển của Agile truyền thống.

Tổng hợp

Chúng tôi đã bắt đầu cuộc hành trình của Agile cách đây 5 năm. Thời gian sau đó chúng tôi đã quản lý để tạo ra các nhóm Agile thành thạo và hiệu suất cao. Tin hay không, chúng tôi vẫn được coi là những người chấp nhận sớm mặc dù chúng tôi đã nắm lấy một ý tưởng đã được 15 tuổi.

BDD dường như ở cùng một vị trí Agile 5 năm trước đây. Có thể chúng thậm chí còn có ý tưởng sớm hơn thời gian này một chút. Nó không phải là một thay thế cho Agile. Nó không rắc rối để chuyển sang Agile và có thể chuyển được. Nó không phải là một ý tưởng cơ bản của bất kỳ ai mà phải chuyển từ mô hình phát triển waterfall.

BDD là gì, chúng tôi nghĩ, là một bước thắng lợi đúng hướng. Nó giải quyết một số thiếu sót và thừa nhận rằng phát triển phần mềm là nền tảng cho nghiệp vụ ngày nay mà các nhà phát triển phần mềm cần cách giao tiếp tốt hơn với các bên nghiệp vụ liên quan và các bên nghiệp vụ liên quan cần những cách tốt hơn để giao tiếp với các nhà phát triển phần mềm.

Nhắc lại những lời khôn ngoan của Dan North, một giọng nói có thẩm quyền và cha đẻ của BDD. "Trên tất cả BDD là một cơ chế để thúc đẩy hợp tác và khám phá thông qua các ví dụ". Điều quan trọng cần nhớ là khi bạn gỡ bỏ nó, sự phát triển Agile, và BDD bây giờ, thực sự tất cả là cách giao tiếp tốt hơn.

Tham khảo: https://medium.com/the-reading-room/behaviour-driven-development-a-better-agile-778d2d2a7ab5