Là BDD thực sự có thể ghi bởi những người không lập trình?

Phát triển dựa trên hành vi với cú pháp kịch bản biểu tượng của Cho-Khi-Sau đó, gần đây đã bị thổi phồng vì những ứng dụng có thể của nó như là một đối tượng ranh giới để đánh giá chức năng phần mềm.

Tôi chắc chắn đồng ý rằng Gherkin , hoặc bất kỳ tập lệnh định nghĩa tính năng nào bạn thích, là DSL có thể đọc được cho doanh nghiệp và đã cung cấp giá trị như vậy.

Tuy nhiên, tôi không đồng ý rằng nó không thể ghi được bởi những người không lập trình (cũng như Martin Fowler ).

Có ai có tài khoản của các kịch bản được viết bởi những người không lập trình, sau đó được các nhà phát triển thiết bị không?

Nếu thực sự có sự đồng thuận về việc thiếu khả năng ghi, thì bạn có thấy vấn đề với một công cụ, thay vì bắt đầu với các kịch bản và sử dụng chúng, sẽ tạo ra các kịch bản có thể đọc được từ các thử nghiệm thực tế không?

Cập nhật: liên quan đến công cụ máy phát kịch bản của chương trình, tất nhiên nó sẽ không đoán được ngôn ngữ kinh doanh một cách kỳ diệu;) Nhưng, giống như chúng ta hiện đang sử dụng các công cụ đối sánh regrec để tạo các thử nghiệm theo cách tiếp cận từ trên xuống (trên kích thước trừu tượng), chúng ta có thể sử dụng các nhà xây dựng chuỗi để tạo các kịch bản theo cách tiếp cận từ dưới lên.

Một người đưa ra một ý tưởng chỉ ví dụ về:

Given I am on page ${test.currentPage.name}
And I click on element ${test.currentAction.element}
…

Tôi đã nhìn thấy nó. Không kết thúc tốt đẹp.

Tôi nghĩ rằng dưa chuột là cồng kềnh (<- lol: D) vì lý do chính xác này. Quá khó cho những người không có kỹ thuật tự viết; quá dài dòng cho người kỹ thuật.

Những người không có kỹ thuật chỉ không học cách suy nghĩ như lập trình viên. Đó là đặc quyền của chúng tôi để hiểu kiến ​​thức trừu tượng, phá vỡ nó, xây dựng lại và vẫn có thể chạy trốn khỏi sự mơ hồ thành công. Đó là những gì chúng ta được trả tiền cho.

Nếu thực sự có sự đồng thuận về việc thiếu khả năng ghi, thì bạn có thấy vấn đề với một công cụ, thay vì bắt đầu với các kịch bản và sử dụng chúng, sẽ tạo ra các kịch bản có thể đọc được từ các thử nghiệm thực tế không?

Công cụ sẽ không thể tạo ra chúng. Máy tính không biết gì về lĩnh vực kinh doanh. Cuối cùng - lập trình viên sẽ chịu trách nhiệm vẽ những gì cần được tạo ra và thậm chí sau đó - có thể những kịch bản đó sẽ quá dài dòng / khó hiểu đối với người dùng cuối của họ.

Một phần khó khăn trong việc khách hàng viết tài liệu thông số kỹ thuật là khách hàng thường không biết cách dịch những thứ khách hàng muốn sang ngôn ngữ mô tả thực sự những gì khách hàng cần. Mặc dù khách hàng có thể nói rằng họ muốn có một hành vi nhất định tồn tại trong một hệ thống, nhưng họ thường không quá quan tâm đến những chi tiết vụn vặt cho đến khi họ thấy và sử dụng và trải nghiệm phần mềm hoạt động theo cách mà khách hàng cảm thấy không phù hợp với họ nhu cầu.

Khi khách hàng mô tả một quy trình kinh doanh, họ thường để lại rất nhiều thông tin liên quan. Thông thường thông tin này liên quan đến những điều về một quy trình thường được hiểu trong miền cụ thể của khách hàng và do đó được coi là hiển nhiên và thường không được chuyển tiếp đến người lập trình. Vào những lúc khác, khách hàng không thực sự biết cách xử lý tất cả các điều kiện biên trong một hệ thống và đang tìm kiếm người lập trình để được hướng dẫn. Đôi khi tất cả chỉ là một trường hợp đơn giản về khả năng sử dụng, với khách hàng nghĩ rằng họ muốn một cái gì đó hoạt động theo một cách, nhưng sau đó thay đổi suy nghĩ khi mọi thứ trở nên rõ ràng hơn.

Ok, vậy là đủ "quan hệ khách hàng 101 cho lập trình viên". Câu hỏi đặt ra là liệu vẫn còn giá trị khi khách hàng sử dụng DSL có thể đọc được cho doanh nghiệp để xác định cách xác định thông số kỹ thuật. Tôi tin rằng với sự hướng dẫn, câu trả lời là 'có', và tôi nói dự kiến ​​bởi vì câu hỏi tiếp theo xuất hiện là, tại sao bạn lại có một khách hàng tạo ra DSL khi bạn có thể lập trình viên dễ dàng xác định một lập trình viên hơn cung cấp cho khách hàng một ngôn ngữ đơn giản nhưng phong phú để xác định hệ thống cần hoạt động như thế nào?

Khi bạn đã cung cấp cho khách hàng một ngôn ngữ để mô tả họ muốn hệ thống hoạt động như thế nào, bạn sẽ kết thúc với những tuyên bố nói lên điều gì đó:

"for a given 'subsystem', as a 'business entity' I want 'some feature' so that I might achieve 'some result'".

Đây là loại tuyên bố kết thúc mô tả một yêu cầu trong một cách rất rõ ràng, cung cấp các hình dạng tổng thể mà khách hàng về cơ bản muốn hệ thống để giả định, hoặc một cách khác để nhìn vào nó là các khách hàng đang diễn tả những gì hệ thống được. Nếu bạn muốn khách hàng nghĩ về những điều xa hơn một chút, thì bạn có thể yêu cầu họ mô tả các quy tắc mà tính năng phải tuân theo bằng cách sử dụng một số câu lệnh tương tự như:

"Given 'some system state', When 'some action occurs', Then expect 'some result'

Một lần nữa mô tả rất rõ ràng, lần này là về cáchhệ thống nên hành xử. Vấn đề là, điều này sẽ không thay thế nhu cầu của một nhà phát triển phần mềm để điền vào tất cả các khoảng trống và để trêu chọc thêm chi tiết mà khách hàng có thể chỉ biết ngoại vi. Mặc dù khách hàng có thể được lập trình viên 'đào tạo' để mô tả các tính năng và hành vi theo định dạng thân thiện với lập trình viên, khách hàng sẽ không thực sự có kỹ năng hoặc kiến ​​thức để tạo ra các trường hợp thử nghiệm có ý nghĩa, cũng như không cung cấp việc triển khai mã. Đây là ý kiến ​​của bài báo Martin Fowler mà OP đã đề cập. Vì vậy, có, bản thân phần mềm không thể ghi được bởi khách hàng, nhưng phần mô tả về phần mềm chắc chắn có thể - và IMHO nên - được viết bởi khách hàng. Để biết giá trị của nó, tôi đã không đọc bài viết của Fowler khi nói rằng khách hàng không nên '

Tôi cảm thấy rằng các lập trình viên của chúng tôi đôi khi có thể quên rằng khách hàng của chúng tôi thường rất thông minh về sự hiểu biết của họ về doanh nghiệp và quy trình kinh doanh của họ, chắc chắn tốt hơn nhiều so với chúng tôi. Khi họ không có một lập trình viên để nói với họ cách xây dựng một hệ thống phần mềm, khách hàng thường dùng đến phương pháp khác - có lẽ kém hiệu quả hơn - để giải quyết các vấn đề quản lý kinh doanh cụ thể của họ. Bằng cách này, tôi có nghĩa là cơ sở dữ liệu đơn giản (nghĩ là Access) hoặc bảng tính, hoặc thậm chí trong sổ cái viết tay, và với các quy tắc và quy trình được xác định rõ để quản lý các quy trình đó. Điều mà nhiều khách hàng thiếu không phải là một phương tiện để xác định thế nào là một hệ thống nhu cầu làm việc, mà là làm thế nào nó nên được xây dựng , và quan trọng hơn như thế nào có hiệu quả mô tả các quy tắc hành vi của một hệ thống với những ngườilàm gì có kỹ năng thực sự xây dựng hệ thống.

Nếu thực sự có sự đồng thuận về việc thiếu khả năng ghi, thì bạn có thấy vấn đề với một công cụ, thay vì bắt đầu với các kịch bản và sử dụng chúng, sẽ tạo ra các kịch bản có thể đọc được từ các thử nghiệm thực tế không?

Tôi nghĩ rằng điều này đang nhìn vấn đề sai cách xung quanh. Tôi sẽ thấy một vấn đề lớn với một công cụ tạo tài liệu từ các bài kiểm tra nếu tài liệu đó được dự định đại diện cho một đặc tả theo bất kỳ cách nào. Để kiểm tra một kịch bản, bạn cần hiểu nó, do đó kịch bản cần phải tồn tại để bạn xác định cả hai thử nghiệm cho kịch bản đó. Nếu bạn mô tả kịch bản theo cú pháp BDD, thì bạn đã chỉ định nó và do đó bạn chỉ có thể ghi lại các tình huống sau thực tế. Mặt khác, nếu bạn có một công cụ cho phép khách hàng mô tả một hệ thống trong DSL thân thiện với lập trình và nếu công cụ đó có thể được sử dụng để tạo các mẫu mã sẽ được sử dụng như một bộ kiểm tra, thì tôi sẽ d nói rằng sẽ có giá trị lớn trong một công cụ như vậy. Nó sẽ không thấy khách hàng đưa các lập trình viên ra khỏi phương trình, và nó sẽ giúp giảm bớt nỗ lực cần thiết để thực hiện mong muốn của khách hàng và tạo ra các yêu cầu được mã hóa thử nghiệm theo kiểu BDD, và có lẽ sẽ khiến cho mong muốn của khách hàng dễ hiểu hơn. Tuy nhiên, nó sẽ không thay thế cho việc có một nhà phát triển phần mềm có kinh nghiệm trong tay để giúp khách hàng tách biệt nhu cầu của khách hàng khỏi mong muốn của khách hàng.

Tôi đã thấy các nhà phát triển viết kịch bản; người kiểm tra viết kịch bản và thậm chí một chủ sở hữu sản phẩm viết kịch bản. Tôi cũng đã có các cuộc hội thoại được thiết kế rõ ràng để đưa ra các kịch bản - "Đưa ra <bối cảnh khác này>, khi nào thì chuyện gì sẽ xảy ra?" - và viết ra những từ mà doanh nghiệp sử dụng.

Kết quả tốt nhất mà tôi có được là từ cuộc trò chuyện với chủ sở hữu sản phẩm khi anh ta ở trong văn phòng, ghi lại chúng trên wiki sau đó gửi chúng cho anh ta để anh ta có thể sửa và bổ sung thêm. Anh ấy tìm thấy một cặp vợ chồng chúng tôi đã bỏ lỡ trong các cuộc trò chuyện của chúng tôi. Điều đó làm rung chuyển.

Các kịch bản tồi tệ nhất tôi từng thấy là những nhà phát triển đã tự viết mà không có bất kỳ cuộc trò chuyện nào với doanh nghiệp. Tôi có thể biết vì họ sử dụng các cụm từ như "Khi tôi thực hiện tìm kiếm" hoặc "Khi tôi gửi biểu mẫu có ngày hôm nay + 3". Chúng thường không phải là những tình huống rất thú vị, quá nhiều trong số chúng, mức độ chi tiết quá thấp và do đó hoàn toàn không thể hiểu được. Các doanh nghiệp cũng không đọc những điều này.

Tốt hơn nhiều để tập trung vào các cuộc hội thoại IMO. Tôi đã thấy một vài đội làm điều này bây giờ trong một vài tháng với những cải tiến lớn về chất lượng, bất kể tự động hóa. Một nhóm quản lý để có được tự động hóa làm việc trong một môi trường rất khó khăn vài tuần sau đó, rất nhiều cho niềm vui của người thử nghiệm! Nhưng thực sự, miễn là nhóm đang có các cuộc trò chuyện và sử dụng các kịch bản để rút ra các kịch bản khác, tôi không nghĩ vấn đề là ai viết chúng ra.

Kinh nghiệm của tôi là tốt nhất nên để BA (Chuyên viên phân tích nghiệp vụ) viết các GWT ( Cho trước khi đó ) (kinh nghiệm sử dụng SpecFlow). BA có thể dịch các yêu cầu của Khách hàng sang GWT và doanh nghiệp có thể đọc nó. Khách hàng hiểu các hệ thống nhưng họ không có công nghệ nghĩ để viết các yêu cầu theo cách mà chúng ta có thể sử dụng.

Lý tưởng nhất là BA sẽ viết một số GWT, tôi sẽ thực hiện một số sửa đổi, BA sẽ xem xét / sửa đổi lặp lại cho đến khi BA và doanh nghiệp tự tin trong phạm vi bảo hiểm. Thực tế BA sẽ cho tôi một bản thảo sơ bộ rằng tôi sẽ dọn dẹp và làm việc. Doanh nghiệp từ chối nói rằng sau đó tự hỏi tại sao nó không bao gồm một số lĩnh vực mà không ai nghĩ tới.