BDD เขียนได้จริง ๆ โดยผู้ที่ไม่ใช่โปรแกรมเมอร์หรือไม่?


24

การพัฒนาพฤติกรรมที่ขับเคลื่อนด้วยสัญลักษณ์ของสถานการณ์“ ที่ได้รับเมื่อนั้น” ได้รับการเน้นย้ำอย่างมากสำหรับการใช้ที่เป็นไปได้ในฐานะวัตถุขอบเขตสำหรับการประเมินการทำงานของซอฟต์แวร์

ฉันยอมรับอย่างแน่นอนว่าGherkinหรือสคริปต์การกำหนดคุณสมบัติที่คุณต้องการเป็นDSL ที่สามารถอ่านได้ทางธุรกิจและมอบคุณค่าเช่นนี้แล้ว

อย่างไรก็ตามฉันไม่เห็นด้วยที่จะไม่สามารถเขียนโปรแกรมได้ (เช่นMartin Fowler )

ใครบ้างมีบัญชีของสถานการณ์ที่เขียนโดยไม่ใช่โปรแกรมเมอร์แล้ว instrumented โดยนักพัฒนา

หากมีความเห็นพ้องต้องกันเกี่ยวกับการขาดความสามารถในการเขียนคุณจะเห็นปัญหากับเครื่องมือที่แทนที่จะเริ่มต้นด้วยสถานการณ์และการใช้เครื่องมือพวกเขาจะสร้างสถานการณ์ที่สามารถอ่านได้ทางธุรกิจจากการทดสอบจริงหรือไม่

อัปเดต:เกี่ยวกับเครื่องมือ“ ตัวสร้างสถานการณ์จำลอง” แน่นอนว่ามันจะไม่เดาภาษาธุรกิจอย่างน่าอัศจรรย์;) แต่เหมือนกับที่เราใช้ regexp matchers ในการสร้างแบบทดสอบจากบนลงล่าง (ในมิติที่เป็นนามธรรม) เราสามารถใช้ ผู้สร้างสตริงเพื่อสร้างสถานการณ์ในแนวทางจากล่างขึ้นบน

ตัวอย่าง“ เพื่อให้ความคิดเท่านั้น”:

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

จะใช้เวลานานกว่าที่มนุษย์จะสามารถใช้ภาษากลางที่มนุษย์ทั่วไปสามารถอ่านได้ในลักษณะที่แน่นอนแม้กระทั่งหลังจากที่คอมพิวเตอร์สามารถเขียนโค้ดสำหรับคอมพิวเตอร์ได้

กระแทกแดกดัน JBehave 1 (เครื่องมือ BDD แรก) เริ่มต้นด้วยการสร้างสถานการณ์จำลองที่ธุรกิจอ่านได้ เราไม่ได้แยกวิเคราะห์ภาษาอังกฤษจนกระทั่งแตงกวา ฉันคิดว่า JBehave 1 มีประโยชน์สำหรับการเตือนผู้คนว่าพวกเขาต้องพูดถึงพวกเขาก่อน ...
Lunivore

คำตอบ:


20

ฉันได้เห็นมัน. ไม่ได้จบลงด้วยดี

ฉันคิดว่าแตงกวานั้นค่อนข้างยุ่งยาก (<- lol: D) ยากเกินไปสำหรับคนที่ไม่ใช้เทคนิคในการเขียน verbose เกินไปสำหรับคนด้านเทคนิค

คนที่ไม่ใช่ด้านเทคนิคก็ไม่ได้เรียนรู้ที่จะคิดเหมือนโปรแกรมเมอร์ มันเป็นสิทธิพิเศษของเราที่จะเข้าใจความรู้ที่เป็นนามธรรมทำลายมันสร้างขึ้นใหม่และยังสามารถหนีจากความคลุมเครือได้สำเร็จ นั่นคือสิ่งที่เราจ่ายไป

หากมีความเห็นพ้องต้องกันเกี่ยวกับการขาดความสามารถในการเขียนคุณจะเห็นปัญหากับเครื่องมือที่แทนที่จะเริ่มต้นด้วยสถานการณ์และการใช้เครื่องมือพวกเขาจะสร้างสถานการณ์ที่สามารถอ่านได้ทางธุรกิจจากการทดสอบจริงหรือไม่

เครื่องมือจะไม่สามารถสร้างได้ คอมพิวเตอร์ไม่รู้อะไรเลยเกี่ยวกับโดเมนธุรกิจ ในท้ายที่สุด - โปรแกรมเมอร์จะต้องรับผิดชอบในการวาดสิ่งที่ต้องสร้างต่อไปและแม้กระทั่ง - สถานการณ์เหล่านั้นน่าจะเป็น verbose / cryptic มากเกินไปสำหรับผู้ใช้ปลายทาง


20
Non technical people just haven't learned to think like programmers. ความจริง. แนวคิดเดียวกันนี้ถูกสะกดจิตและคิดค้นซ้ำหลายครั้งในรอบ 20 ปีที่ผ่านมาและมันก็มักจะจบลงด้วยผลลัพธ์ที่ไม่ดี ธุรกิจเช่นแนวคิดของการรับซอฟต์แวร์โดยไม่ต้องจ่ายนักพัฒนาซอฟต์แวร์ดูดเลือดที่โลภ แต่พวกเขาลืมว่าส่วนที่ยากที่สุดของการพัฒนาซอฟต์แวร์นั้นส่วนใหญ่เข้าใจถึงกฎเกณฑ์ทางธุรกิจที่ลึกซึ้งและซับซ้อนกว่าพวกนักธุรกิจเอง
maple_shaft

2
“ คนที่ไม่ใช่ด้านเทคนิคเพิ่งไม่ได้เรียนรู้ที่จะคิดอย่างโปรแกรมเมอร์”อ๋อความสามารถในการย่อยสลายปัญหาและแสดงให้พวกเขาทราบภายใต้เงื่อนไขเชิงอะตอมมิกที่กำหนดน่าจะเป็นสิ่งที่ทำให้นักเขียนโปรแกรม / นักวิเคราะห์ ความคิดที่ดูเหมือนภาษาอังกฤษทำให้ Gherkin ใช้งานได้โดยทุกคนดูเหมือนว่าฉันจะไร้เดียงสาอย่างเหลือเชื่อ ขอบคุณสำหรับการยืนยัน :) Computer knows nothing about business domain.แน่นอน ฉันไม่ได้ทำให้ความคิดของฉันชัดเจนมากขอโทษเกี่ยวกับเรื่องนั้น ฉันจะเพิ่มข้อมูลให้กับคำถาม
MattiSG

8
@maple_shaft: 20 ปีที่ผ่านมา? ลองตลอด 60 ปีที่ผ่านมา ต้นปีหน้าของ COBOL บางอย่างก็คือนักธุรกิจสามารถเขียนได้โดยไม่จำเป็นต้องมีโปรแกรมเมอร์ เมื่อสิ่งนั้นล้มเหลวผู้คนก็มาด้วยภาษาที่เรียกว่าภาษายุคที่สี่ซึ่งควรจะทำในสิ่งเดียวกัน
David Thornley

11

ส่วนหนึ่งของความยากลำบากในแง่ของลูกค้าที่เขียนเอกสารข้อมูลจำเพาะคือลูกค้ามักไม่รู้วิธีแปลสิ่งที่ลูกค้าต้องการเป็นภาษาซึ่งอธิบายสิ่งที่ลูกค้าต้องการได้อย่างแท้จริง ในขณะที่ลูกค้าอาจบอกว่าพวกเขาต้องการพฤติกรรมบางอย่างที่มีอยู่ในระบบพวกเขามักจะไม่เกี่ยวข้องกับ minutiae จนกว่าพวกเขาจะได้เห็นและใช้และประสบการณ์ซอฟต์แวร์ที่ทำงานในลักษณะที่ลูกค้ารู้สึกไม่ตรงกับของพวกเขา จำเป็น

เมื่อลูกค้าอธิบายกระบวนการทางธุรกิจพวกเขามักจะทิ้งข้อมูลที่เกี่ยวข้องไว้มากมาย บ่อยครั้งที่ข้อมูลนี้เกี่ยวข้องกับสิ่งต่าง ๆ เกี่ยวกับกระบวนการที่เป็นที่เข้าใจกันโดยทั่วไปในโดเมนเฉพาะของลูกค้าดังนั้นจึงได้รับอนุญาตและมักจะไม่ถูกส่งต่อไปยังโปรแกรมเมอร์ ในบางครั้งลูกค้าไม่ทราบวิธีการจัดการกับเงื่อนไขขอบเขตทั้งหมดภายในระบบและกำลังมองหาโปรแกรมเมอร์เพื่อขอคำแนะนำ บางครั้งมันก็เป็นกรณีของการใช้งานง่าย ๆ โดยที่ลูกค้าคิดว่าพวกเขาต้องการบางสิ่งบางอย่างในวิธีเดียว แต่ต่อมาเปลี่ยนใจเมื่อเห็นชัดเจนว่าสิ่งต่าง ๆ ควรทำงานต่างกัน

ตกลงดังนั้นเพียงพอของ "ลูกค้าสัมพันธ์ 101 สำหรับโปรแกรมเมอร์" คำถามคือว่ายังคงมีค่าในการให้ลูกค้าใช้ DSL ที่อ่านได้ทางธุรกิจเพื่อกำหนดวิธีการกำหนดสเปค ฉันเชื่อว่าด้วยคำแนะนำคำตอบคือไม่แน่นอน 'ใช่' และฉันพูดอย่างแน่นอนเพราะคำถามต่อไปที่มาถึงใจคือทำไมคุณต้องให้ลูกค้าสร้าง DSL เมื่อคุณสามารถให้โปรแกรมเมอร์กำหนดคำตอบที่ง่ายกว่า ให้ลูกค้าที่มีความเรียบง่าย แต่ภาษาที่อุดมไปด้วยเพื่อกำหนดวิธีการที่ระบบต้องทำงานหรือไม่

เมื่อคุณให้ภาษาแก่ลูกค้าเพื่ออธิบายว่าพวกเขาต้องการให้ระบบทำงานอย่างไรคุณจะต้องจบลงด้วยข้อความที่พูดอะไรบางอย่างตามบรรทัดของ:

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

คำแถลงประเภทนี้ลงท้ายด้วยการอธิบายข้อกำหนดอย่างชัดเจนโดยให้รูปร่างโดยรวมที่ลูกค้าต้องการให้ระบบสันนิษฐานหรือโดยทั่วไปอีกวิธีหนึ่งคือการที่ลูกค้าอธิบายว่าระบบคืออะไร หากคุณต้องการที่จะมีลูกค้าของคุณคิดเกี่ยวกับสิ่งเล็ก ๆ น้อย ๆ อีกแล้วคุณสามารถขอให้อธิบายกฎซึ่งคุณลักษณะต้องปฏิบัติตามโดยใช้หมายเลขของคำสั่งที่คล้ายกันอาจจะไปที่:

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

คำอธิบายที่ชัดเจนมากอีกครั้งคราวนี้เกี่ยวกับวิธีการระบบควรทำงาน สิ่งนี้คือสิ่งนี้จะไม่แทนที่ความต้องการสำหรับนักพัฒนาซอฟต์แวร์ในการเติมช่องว่างทั้งหมดและเพื่อหยอกล้อรายละเอียดเพิ่มเติมที่ลูกค้าอาจได้รับรู้เพียงอุปกรณ์ต่อพ่วง ในขณะที่ลูกค้าสามารถ 'ฝึกอบรม' โดยโปรแกรมเมอร์เพื่ออธิบายคุณสมบัติและพฤติกรรมในรูปแบบที่เป็นมิตรกับโปรแกรมเมอร์ แต่ลูกค้าจะไม่มีทักษะหรือความรู้ในการสร้างกรณีทดสอบที่มีความหมาย รหัส. นี่คือฉันคิดว่าจุดของบทความ Martin Fowler ที่ OP ได้อ้างถึง ใช่แล้วตัวซอฟต์แวร์เองนั้นไม่สามารถเขียนได้โดยลูกค้า แต่คำอธิบายของซอฟต์แวร์ที่แน่นอนที่สุดที่สามารถ - และ IMHO ควร - เขียนโดยลูกค้า สำหรับสิ่งที่คุ้มค่าฉันไม่ได้อ่านบทความของ Fowler ว่าลูกค้าไม่ควร '

ฉันรู้สึกว่าโปรแกรมเมอร์ของเราบางครั้งสามารถลืมว่าลูกค้าของเราโดยทั่วไปฉลาดมากในแง่ของความเข้าใจในธุรกิจและกระบวนการทางธุรกิจของพวกเขาดีกว่าที่เราทำอย่างแน่นอน เมื่อพวกเขาไม่มีโปรแกรมเมอร์ที่จะบอกพวกเขาถึงวิธีการสร้างระบบซอฟต์แวร์ลูกค้าส่วนใหญ่มักหันไปใช้วิธีอื่นเพื่อแก้ไขปัญหาการจัดการธุรกิจของพวกเขา ด้วยวิธีนี้ฉันหมายถึงฐานข้อมูลอย่างง่าย (คิดว่า Access) หรือสเปรดชีตหรือแม้กระทั่งในบัญชีแยกประเภทที่เขียนด้วยมือ สิ่งที่ลูกค้าจำนวนมากขาดไม่ได้หมายถึงการกำหนดว่าระบบจำเป็นต้องทำงานอย่างไร แต่ควรสร้างอย่างไรและที่สำคัญกว่านั้นจะอธิบายกฎพฤติกรรมของระบบให้กับคนที่จะมีทักษะในการสร้างจริงระบบ

หากมีความเห็นพ้องต้องกันเกี่ยวกับการขาดความสามารถในการเขียนคุณจะเห็นปัญหากับเครื่องมือที่แทนที่จะเริ่มต้นด้วยสถานการณ์และการใช้เครื่องมือพวกเขาจะสร้างสถานการณ์ที่สามารถอ่านได้ทางธุรกิจจากการทดสอบจริงหรือไม่

ผมคิดว่านี้คือการมองที่ปัญหาทางที่ผิดไปรอบ ๆ ฉันจะดูเป็นปัญหาใหญ่ที่มีเครื่องมือที่สร้างเอกสารจากการทดสอบถ้าเอกสารที่ตั้งใจจะเป็นตัวแทนของสเปคในทางใดทางหนึ่ง ในการทดสอบสถานการณ์คุณต้องเข้าใจดังนั้นสถานการณ์จึงจำเป็นต้องมีอยู่แล้วเพื่อให้คุณกำหนดการทดสอบได้ หากคุณอธิบายสถานการณ์ในรูปแบบ BDD- จากนั้นคุณระบุไว้แล้วและทำให้คุณสามารถใช้ภาพจำลองได้หลังจากข้อเท็จจริง หากในอีกทางหนึ่งคุณมีเครื่องมือที่จะช่วยให้ลูกค้าอธิบายระบบใน DSL ที่เป็นมิตรกับการเขียนโปรแกรมที่ดีและหากเครื่องมือนั้นสามารถใช้ในการสร้างแม่แบบรหัสที่จะใช้เป็นชุดทดสอบได้ d บอกว่าจะมีความคุ้มค่าสูงสุดในเครื่องมือเช่น มันจะไม่เห็นลูกค้าที่เอาโปรแกรมเมอร์ออกจากสมการและมันจะช่วยลดความพยายามในการทำตามความต้องการของลูกค้าและสร้างข้อกำหนดการเข้ารหัสทดสอบในรูปแบบ BDD และอาจทำให้ความต้องการของลูกค้าเข้าใจได้ง่ายขึ้น อย่างไรก็ตามมันจะไม่ใช่สิ่งทดแทนการมีนักพัฒนาซอฟต์แวร์ที่มีประสบการณ์ในมือเพื่อช่วยลูกค้าในการแยกความต้องการของลูกค้าออกจากความต้องการของลูกค้า


“ ในการทดสอบสถานการณ์คุณต้องเข้าใจดังนั้นสถานการณ์จึงจำเป็นต้องมีอยู่แล้วเพื่อให้คุณกำหนดการทดสอบได้”ฉันเห็นด้วย สิ่งที่ฉันถามคือการบังคับใช้ข้อ จำกัด ด้านภาษานั้นมีค่าหรือไม่ ฉันไม่ได้อ้างว่าเราควรเขียนการทดสอบเท่านั้น แต่ผมสงสัยว่าเราไม่ควรจะยอมรับความจริงที่ว่ารายละเอียดธุรกิจจะ (และอาจจะ) เสมอธรรมดาแบบฟรีฟอร์มรายละเอียด ดังนั้นเราจึงมีกลุ่มธุรกิจที่บริสุทธิ์และสร้างสถานการณ์สมมติที่อ่านได้ทำให้มนุษย์ตัดสินใจได้ว่าตรงกันหรือไม่ แทนที่จะทำเป็นว่าเราใช้descs จริงเพื่อทดสอบ
MattiSG

...whether enforcing language constraints is worth anything@MattiSG นี่เป็นคำถามที่ดี คำอธิบายแบบฟรีฟอร์มมีความชัดเจนและเป็นธรรมชาติมากขึ้นสำหรับนักเขียน แต่ส่งผลให้คำวิจารณ์ที่ต้องใช้การผ่า โดยการกำหนด 'กฎ' อย่างเป็นทางการ (aka DSL) สำหรับการเขียนข้อกำหนดและข้อกำหนดคุณมีภาษากลางที่ทั้งลูกค้าและโปรแกรมเมอร์สามารถเข้าใจและจำกัดความเข้าใจผิด หากคุณได้คำอธิบายที่ถูกต้องพวกเขาสามารถใช้คำต่อคำเป็นเทมเพลตสำหรับการทดสอบของคุณ ดังนั้นไม่จำเป็นต้องใช้เครื่องมือที่ซับซ้อนในการ "สร้าง" อะไรเลย
S.Robins

@MattiSG FWIW โดยใช้ DSL และ BDD เป็นระบบที่ฉันใช้เอง ข้อกำหนดถูกกำหนดเป็นคำสั่ง Entity-Feature-Benefit และตามด้วยสเป็คที่ขยายข้อความสั่งความต้องการเริ่มต้นโดยใช้คำสั่ง AAA (Ie: Given-When-Then) ... โดยพื้นฐานแล้วคำแถลงสถานการณ์ ปัญหาในการพยายามถอดรหัสข้อความฟรีก็คือหากไม่มี DSL คุณจะไม่มีวิธีง่าย ๆ ในการกำหนดอัลกอริทึมที่สามารถสร้างสถานการณ์การรวบรวมที่มีความหมายได้ ประเด็นของฉันคือการใช้การทดสอบเป็นจุดเริ่มต้นในการสร้างสถานการณ์เป็นแบบย้อนหลัง
S.Robins

5

ฉันเห็นนักพัฒนาเขียนสถานการณ์ ทดสอบการเขียนสถานการณ์และแม้กระทั่งเจ้าของผลิตภัณฑ์เขียนสถานการณ์ ฉันยังมีการสนทนาที่ออกแบบมาอย่างชัดเจนเพื่อนำเสนอสถานการณ์ - "ให้ <บริบทอื่น>> เมื่อไรจะเกิดอะไรขึ้น" - และเขียนคำที่ใช้ในธุรกิจ

ผลลัพธ์ที่ดีที่สุดที่ฉันได้รับจากการสนทนากับเจ้าของผลิตภัณฑ์ในขณะที่เขาอยู่ในสำนักงานจับภาพพวกเขาบนวิกิแล้วส่งพวกเขามาให้เขาเพื่อที่เขาจะได้แก้ไขและเพิ่มได้มากขึ้น เขาพบคู่ที่เราไม่ได้รับในการสนทนาของเรา นั่นสั่นสะเทือน

สถานการณ์ที่เลวร้ายที่สุดที่ฉันเคยเห็นคือนักพัฒนาที่เขียนตัวเองโดยไม่ต้องพูดคุยกับธุรกิจ ฉันสามารถบอกได้เพราะพวกเขาใช้คำเช่น "เมื่อฉันทำการค้นหา" หรือ "เมื่อฉันส่งแบบฟอร์มพร้อมวันที่วันนี้ +3" โดยทั่วไปแล้วพวกเขาจะไม่ได้เป็นสถานการณ์ที่น่าสนใจมากเกินไปพวกเขามีรายละเอียดต่ำเกินไปจนทำให้ไม่สามารถเข้าใจได้อย่างสมบูรณ์ ธุรกิจยังไม่ได้อ่านสิ่งเหล่านี้

ดีกว่ามากที่จะมุ่งเน้นการสนทนา IMO ฉันได้เห็นสองสามทีมทำสิ่งนี้ในตอนนี้สองสามเดือนด้วยการปรับปรุงคุณภาพอย่างมากโดยไม่คำนึงถึงระบบอัตโนมัติ ทีมหนึ่งจัดการเพื่อให้ระบบอัตโนมัติทำงานได้ในสภาพแวดล้อมที่ยากลำบากหลายสัปดาห์ต่อมาเพื่อความสนุกของผู้ทดสอบ! แต่จริงๆแล้วตราบใดที่ทีมกำลังสนทนาและใช้สถานการณ์เพื่ออธิบายสถานการณ์อื่น ๆ ฉันไม่คิดว่ามันสำคัญที่จะเขียนลงไป


+1 การสื่อสารเป็นกุญแจสำคัญและสถานการณ์จำเป็นต้องเป็นจริงในแง่ที่นักธุรกิจของเราดังนั้นในการตอบคำถาม OPs หากเราสร้าง DSL มันจะต้องมีความใกล้เคียงกันมากขึ้น กับสิ่งที่ลูกค้ากำลังจะพูดและไม่ใช่สิ่งที่โปรแกรมเมอร์คิดว่าลูกค้าควรจะพูด
S.Robins

0

ประสบการณ์ของฉันคือมันเป็นสิ่งที่ดีที่สุดที่เหลือ BA (นักวิเคราะห์ธุรกิจ) เพื่อเขียน GWT ( ให้ - เมื่อ - แล้ว ) s (ประสบการณ์การใช้ SpecFlow) BA สามารถแปลความต้องการของลูกค้าเป็น GWT และธุรกิจสามารถอ่านได้ ลูกค้าเข้าใจระบบ แต่พวกเขาไม่มีเทคโนโลยีคิดที่จะเขียนข้อกำหนดในวิธีที่เราสามารถใช้ได้

ในอุดมคติแล้วบริติชแอร์เวย์จะเขียน GWT บางอย่างฉันจะทำการแก้ไขบางอย่าง BA จะทบทวน / แก้ไขซ้ำจนกระทั่งบริติชแอร์เวย์และธุรกิจมีความมั่นใจในการรายงานข่าว บริติชแอร์เวย์จะให้ร่างคร่าวๆที่ฉันจะทำความสะอาดและทำงาน ธุรกิจยักไหล่ออกไปโดยบอกว่าแล้วสงสัยว่าทำไมมันไม่ครอบคลุมบางพื้นที่ที่ไม่มีใครคิด


คุณช่วยกรุณาบอกด้วยว่าGWT มีความหมายต่อคุณอย่างไร? :)
MattiSG

@MattiSG: เดาว่าเป็นเพราะเมื่อ - เมื่อ - จากนั้น (ดู OP)
sleske

@MattiSG - อัปเดตโพสต์ที่ดี
SoylentGray
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.