BDD - ข้อมูลจำเพาะตามตัวอย่าง

ตามที่ Gojko Adzic ผู้เขียน 'Specification by Example', Specification by Example คือชุดของรูปแบบกระบวนการที่อำนวยความสะดวกในการเปลี่ยนแปลงผลิตภัณฑ์ซอฟต์แวร์เพื่อให้แน่ใจว่าผลิตภัณฑ์ที่เหมาะสมจะถูกส่งมอบอย่างมีประสิทธิภาพ "

Specification by Example เป็นแนวทางการทำงานร่วมกันในการกำหนดข้อกำหนดและการทดสอบการทำงานเชิงธุรกิจสำหรับผลิตภัณฑ์ซอฟต์แวร์โดยพิจารณาจากข้อกำหนดในการรวบรวมและแสดงภาพประกอบโดยใช้ตัวอย่างที่เป็นจริงแทนข้อความนามธรรม

ข้อมูลจำเพาะตามตัวอย่าง - ภาพรวม

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

สนับสนุนคำศัพท์ที่เฉพาะเจาะจงและกระชับซึ่งเรียกว่าภาษาที่แพร่หลายซึ่ง -

• เปิดใช้งานข้อกำหนดปฏิบัติการ

• ถูกใช้โดยทุกคนในทีม

• ถูกสร้างขึ้นโดยทีมงานข้ามสายงาน

• จับความเข้าใจของทุกคน

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

วัตถุประสงค์ของข้อกำหนดตามตัวอย่าง

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

การใช้ SbE

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

• ทดสอบได้โดยไม่ต้องแปล

• บันทึกในเอกสารถ่ายทอดสด

ต่อไปนี้เป็นเหตุผลที่เราใช้ตัวอย่างเพื่ออธิบายข้อกำหนดเฉพาะ -

• พวกเขาเข้าใจง่ายกว่า

• พวกเขาตีความผิดได้ยากกว่า

ข้อดีของ SbE

ข้อดีของการใช้ Specification by Example คือ -

• คุณภาพที่เพิ่มขึ้น

• ลดของเสีย

• ลดความเสี่ยงของข้อบกพร่องในการผลิต

• มุ่งเน้นความพยายาม

• การเปลี่ยนแปลงสามารถทำได้อย่างปลอดภัยมากขึ้น

• ปรับปรุงการมีส่วนร่วมทางธุรกิจ

การใช้งาน SbE

ข้อมูลจำเพาะตามตัวอย่างค้นหาแอปพลิเคชันใน -

• ทั้งธุรกิจที่ซับซ้อนหรือองค์กรที่ซับซ้อน

• ใช้งานได้ไม่ดีสำหรับปัญหาทางเทคนิคล้วนๆ

• ทำงานได้ไม่ดีสำหรับผลิตภัณฑ์ซอฟต์แวร์ที่เน้น UI

• สามารถนำไปใช้กับระบบเดิมได้เช่นกัน

SbE และการทดสอบการยอมรับ

ข้อดีของ Specification by Example ในแง่ของการทดสอบการยอมรับคือ -

• ภาพประกอบเดียวใช้สำหรับทั้งข้อกำหนดโดยละเอียดและการทดสอบ

• ความคืบหน้าของโครงการอยู่ในแง่ของการทดสอบการยอมรับ -

  • การทดสอบแต่ละครั้งคือการทดสอบพฤติกรรม

  • การทดสอบกำลังผ่านสำหรับพฤติกรรมหรือไม่ได้

  • การทดสอบที่ผ่านแสดงว่าพฤติกรรมเฉพาะเสร็จสมบูรณ์

  • หากโครงการที่ต้องดำเนินการ 100 พฤติกรรมมี 60 พฤติกรรมที่เสร็จสมบูรณ์แสดงว่าเสร็จสิ้น 60%

• ผู้ทดสอบเปลี่ยนจากการแก้ไขข้อบกพร่องเป็นการป้องกันข้อบกพร่องและมีส่วนช่วยในการออกแบบโซลูชัน

• ระบบอัตโนมัติช่วยให้เข้าใจผลกระทบของการเปลี่ยนแปลงความต้องการในโซลูชันได้ทันที

ข้อกำหนดตามตัวอย่าง - ความหมายสำหรับบทบาทต่างๆ

วัตถุประสงค์ของ Specification by Example คือการส่งเสริมการทำงานร่วมกันของทุกคนในทีมรวมถึงลูกค้าตลอดทั้งโครงการเพื่อส่งมอบคุณค่าทางธุรกิจ ทุกคนเพื่อความเข้าใจที่ดีขึ้นใช้คำศัพท์เดียวกัน

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

SbE - ชุดรูปแบบกระบวนการ

ดังที่เราได้เห็นในตอนต้นของบทนี้ Specification by Example ถูกกำหนดเป็นชุดของรูปแบบกระบวนการที่อำนวยความสะดวกในการเปลี่ยนแปลงผลิตภัณฑ์ซอฟต์แวร์เพื่อให้แน่ใจว่าผลิตภัณฑ์ที่เหมาะสมจะถูกส่งมอบอย่างมีประสิทธิภาพ

รูปแบบกระบวนการคือ -

• ข้อกำหนดการทำงานร่วมกัน

• การแสดงข้อมูลจำเพาะโดยใช้ตัวอย่าง

• การปรับแต่งข้อกำหนด

• ตัวอย่างอัตโนมัติ

• ตรวจสอบความถูกต้องบ่อยครั้ง

• เอกสารประกอบการดำรงชีวิต

ข้อกำหนดการทำงานร่วมกัน

วัตถุประสงค์ของข้อกำหนดการทำงานร่วมกันคือ -

• รับบทบาทต่างๆในทีมเพื่อให้มีความเข้าใจร่วมกันและใช้คำศัพท์ร่วมกัน

• ให้ทุกคนมีส่วนร่วมในโครงการเพื่อให้พวกเขามีส่วนร่วมในมุมมองที่แตกต่างกันเกี่ยวกับคุณลักษณะ

• ตรวจสอบให้แน่ใจว่ามีการสื่อสารร่วมกันและความเป็นเจ้าของคุณสมบัติ

วัตถุประสงค์เหล่านี้พบได้ในการประชุมเชิงปฏิบัติการข้อกำหนดหรือที่เรียกว่าการประชุม Three Amigos สาม Amigos คือ BA, QA และผู้พัฒนา แม้ว่าจะมีบทบาทอื่น ๆ ในโครงการ แต่ทั้งสามคนจะต้องรับผิดชอบและรับผิดชอบตั้งแต่คำจำกัดความไปจนถึงการส่งมอบคุณสมบัติ

During the meeting −

• นักวิเคราะห์ธุรกิจ (BA) นำเสนอข้อกำหนดและการทดสอบสำหรับคุณลักษณะใหม่

• Amigos ทั้งสาม (BA, Developer และ QA) พูดคุยเกี่ยวกับคุณลักษณะใหม่และตรวจสอบข้อกำหนด

• QA และผู้พัฒนายังระบุข้อกำหนดที่ขาดหายไป

• อามิโกสทั้งสาม

  • ใช้โมเดลที่ใช้ร่วมกันโดยใช้ภาษาที่แพร่หลาย

  • ใช้คำศัพท์โดเมน (อภิธานศัพท์จะได้รับการดูแลหากจำเป็น)

  • มองหาความแตกต่างและความขัดแย้ง

• อย่าข้ามไปที่รายละเอียดการใช้งานในจุดนี้

• บรรลุฉันทามติว่ามีการระบุคุณลักษณะอย่างเพียงพอหรือไม่

• ความรู้สึกร่วมกันของข้อกำหนดและการทดสอบความเป็นเจ้าของช่วยอำนวยความสะดวกในข้อกำหนดด้านคุณภาพ

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

การแสดงข้อมูลจำเพาะโดยใช้ตัวอย่าง

สถานการณ์ถูกระบุโดยใช้โครงสร้าง Given-When-Then เพื่อสร้างข้อกำหนดที่ทดสอบได้ -

Given <เงื่อนไขเบื้องต้นบางประการ>

And <เงื่อนไขเบื้องต้นเพิ่มเติม> Optional

When <การกระทำ / ทริกเกอร์เกิดขึ้น>

Then <เงื่อนไขการโพสต์บางส่วน>

And <เงื่อนไขการโพสต์เพิ่มเติม> Optional

ข้อกำหนดนี้เป็นตัวอย่างของลักษณะการทำงานของระบบ นอกจากนี้ยังแสดงถึงเกณฑ์การยอมรับของระบบ

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

การปรับแต่งข้อกำหนด

ในการปรับแต่งข้อกำหนด

• มีความแม่นยำในการเขียนตัวอย่าง หากตัวอย่างมีความซับซ้อนให้แบ่งออกเป็นตัวอย่างที่ง่ายกว่า

• มุ่งเน้นไปที่มุมมองทางธุรกิจและหลีกเลี่ยงรายละเอียดทางเทคนิค

• พิจารณาเงื่อนไขทั้งบวกและลบ

• ปฏิบัติตามคำศัพท์เฉพาะโดเมน

• พูดคุยเกี่ยวกับตัวอย่างกับลูกค้า

  • เลือกการสนทนาเพื่อบรรลุเป้าหมายนี้

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

• เพื่อให้แน่ใจว่าสถานการณ์ผ่านไปกรณีทดสอบทั้งหมดสำหรับสถานการณ์นั้นจะต้องผ่าน ดังนั้นปรับปรุงข้อกำหนดเพื่อให้สามารถทดสอบได้ กรณีทดสอบอาจรวมถึงช่วงและค่าข้อมูลต่างๆ (กรณีขอบเขตและมุม) ตลอดจนกฎทางธุรกิจที่แตกต่างกันซึ่งส่งผลให้ข้อมูลมีการเปลี่ยนแปลง

• ระบุกฎเกณฑ์ทางธุรกิจเพิ่มเติมเช่นการคำนวณที่ซับซ้อนการจัดการ / การแปลงข้อมูลเป็นต้น

• รวมสถานการณ์ที่ไม่สามารถใช้งานได้ (เช่นประสิทธิภาพการโหลดความสามารถในการใช้งาน ฯลฯ ) ตามข้อกำหนดตามตัวอย่าง

ตัวอย่างอัตโนมัติ

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

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

ตรวจสอบความถูกต้องบ่อยครั้ง

รวมการตรวจสอบตัวอย่างในขั้นตอนการพัฒนาของคุณด้วยทุกการเปลี่ยนแปลง (เพิ่มเติม / แก้ไข) มีเทคนิคและเครื่องมือมากมายที่สามารถ (และควร) นำมาใช้เพื่อช่วยให้มั่นใจในคุณภาพของผลิตภัณฑ์ พวกเขาหมุนรอบหลักการสำคัญสามประการ -Test Early, Test Well และ Test Often.

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

เอกสารประกอบการดำรงชีวิต

รักษาข้อกำหนดให้เรียบง่ายและสั้นที่สุด จัดระเบียบข้อกำหนดและพัฒนาตามความคืบหน้าของงาน ทำให้เอกสารสามารถเข้าถึงได้สำหรับทุกคนในทีม

ข้อกำหนดตามขั้นตอนกระบวนการตัวอย่าง

ภาพประกอบแสดงขั้นตอนกระบวนการใน Specification by Example

ต่อต้านรูปแบบ

รูปแบบการต่อต้านเป็นรูปแบบบางอย่างในการพัฒนาซอฟต์แวร์ซึ่งถือเป็นการเขียนโปรแกรมที่ไม่ดี ในทางตรงกันข้ามกับรูปแบบการออกแบบซึ่งเป็นแนวทางทั่วไปในการแก้ปัญหาทั่วไปซึ่งได้รับการกำหนดรูปแบบและโดยทั่วไปถือว่าเป็นแนวทางปฏิบัติในการพัฒนาที่ดีรูปแบบการต่อต้านเป็นสิ่งที่ตรงกันข้ามและไม่เป็นที่ต้องการ

รูปแบบการต่อต้านก่อให้เกิดปัญหาต่างๆ

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

แนวทางแก้ไขปัญหา - คุณภาพ

สามารถรับประกันคุณภาพได้ด้วยการเฝ้าดูรูปแบบการต่อต้าน เพื่อลดปัญหาที่เกิดจากรูปแบบการต่อต้านคุณควร -

• รวมกันเพื่อระบุโดยใช้ตัวอย่าง

• ทำความสะอาดและปรับปรุงตัวอย่าง

• เขียนโค้ดซึ่งตรงตามตัวอย่าง

• ทำให้ตัวอย่างเป็นอัตโนมัติและปรับใช้

• ทำซ้ำแนวทางสำหรับเรื่องราวของผู้ใช้ทุกคน

เพื่อแก้ปัญหาเนื่องจากรูปแบบการต่อต้านหมายถึงการยึดมั่น -

• Collaboration.

• มุ่งเน้นไปที่อะไร

• มุ่งเน้นไปที่ธุรกิจ

• เตรียมตัว.

ให้เราเข้าใจว่าแต่ละความหมายข้างต้นหมายถึงอะไร

การทำงานร่วมกัน

ในการทำงานร่วมกัน -

• นักธุรกิจนักพัฒนาและผู้ทดสอบให้ข้อมูลจากมุมมองของตนเอง

• ตัวอย่างอัตโนมัติพิสูจน์ว่าทีมได้สร้างสิ่งที่ถูกต้อง

• กระบวนการนี้มีค่ามากกว่าการทดสอบด้วยตนเอง

มุ่งเน้นไปที่อะไร

คุณต้องมุ่งเน้นไปที่คำถาม - "อะไร" ในขณะที่มุ่งเน้นไปที่ 'อะไร' -

• อย่าพยายามปกปิดทุกกรณีที่เป็นไปได้

• อย่าลืมใช้การทดสอบประเภทต่างๆ

• ยกตัวอย่างให้ง่ายที่สุด

• ตัวอย่างควรเข้าใจได้ง่ายโดยผู้ใช้ระบบ

• เครื่องมือไม่ควรมีส่วนสำคัญในการประชุมเชิงปฏิบัติการ

มุ่งเน้นไปที่ธุรกิจ

เพื่อมุ่งเน้นไปที่ธุรกิจ -

• รักษาข้อกำหนดตามเจตนาทางธุรกิจ

• รวมธุรกิจในการสร้างและตรวจสอบข้อกำหนด

• ซ่อนรายละเอียดทั้งหมดในเลเยอร์การทำงานอัตโนมัติ

เตรียมตัว

เตรียมพร้อมสำหรับสิ่งต่อไปนี้ -

• ผลประโยชน์จะไม่ปรากฏในทันทีแม้ว่าจะมีการเปลี่ยนแปลงแนวทางปฏิบัติของทีมก็ตาม

• การแนะนำ SbE เป็นสิ่งที่ท้าทาย

• ต้องใช้เวลาและเงินลงทุน

• การทดสอบอัตโนมัติไม่ได้ฟรี

เครื่องมือ

การใช้เครื่องมือไม่บังคับสำหรับ Specification by Example แม้ว่าในทางปฏิบัติจะมีเครื่องมือหลายอย่าง มีหลายกรณีที่ทำตาม Specification by Example ได้สำเร็จแม้ว่าจะไม่ใช้เครื่องมือก็ตาม

เครื่องมือต่อไปนี้รองรับข้อมูลจำเพาะตามตัวอย่าง -

• Cucumber

• SpecFlow

• Fitnesse

• Jbehave

• Concordion

• Behat

• Jasmine

• Relish

• Speclog