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