มาตรฐานคุณภาพซอฟต์แวร์

1 การทำความเข้าใจเป้าหมายทางธุรกิจ

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

2 การกำหนดและอธิบายคุณลักษณะต่างๆ

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

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

1 การคิดย้อนกลับและความเข้าใจในผลลัพธ์ (Working Backward and Understanding the Outputs)

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

* แบบฟอร์มการลาจะถูกส่งไปยังแผนกทรัพยากรบุคคล (HR)
* จำนวนวันลาและประเภทการลาจะถูกส่งไปยังแผนก HR หรือหัวหน้าทีมผ่านทางอีเมล
* จำนวนวันลาจะถูกหักออกจากโควตาวันลาในประเภทนั้นๆ โดยอัตโนมัติ

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

4 การสำรวจและวางผังกระบวนการทางธุรกิจและลำดับขั้นตอน

เมื่อเข้าใจผลลัพธ์ที่ต้องการแล้ว ทีมงานมักจะใช้การเขียนแผนภาพเรื่องราว (Story Mapping) การวางผังกระบวนการ (Process Mapping) หรือเทคนิคอื่นๆ ที่ใกล้เคียงกัน เพื่อทำความเข้าใจลำดับการทำงานภายในระบบ วิธีนี้จะช่วยระบุแนวทางที่รวดเร็วที่สุดในการส่งมอบฟีเจอร์ที่ใช้งานได้จริง และยังช่วยให้มั่นใจว่าจะไม่มีขั้นตอนใดตกหล่นไป

ตัวอย่างลำดับขั้นตอนง่ายๆ สำหรับฟีเจอร์การส่งใบลาออนไลน์อาจเป็นดังนี้:

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

5 การกำหนดรายละเอียดฟีเจอร์ด้วยภาษา Gherkin

สมาชิกในทีมที่จะรับผิดชอบฟีเจอร์หรือ Story นั้นๆ จะมารวมตัวกันเพื่อหารือเกี่ยวกับรายละเอียดของข้อกำหนด ซึ่งโดยปกติอย่างน้อยที่สุดจะประกอบด้วย ตัวแทนฝ่ายธุรกิจ (BA), นักพัฒนา (Developer) และผู้ทดสอบระบบ (Tester) เป้าหมายของการประชุมนี้เพื่อให้สมาชิกในทีมมีความเข้าใจอย่างลึกซึ้งในกฎทางธุรกิจ (Business Rules) และเกณฑ์การยอมรับ (Acceptance Criteria) ของฟีเจอร์นั้นๆ ตลอดจนช่วยกันค้นหาความซับซ้อนหรือความเสี่ยงที่อาจถูกมองข้ามไป ซึ่งอาจกลายเป็นอุปสรรคต่อการพัฒนาในขั้นตอนต่อๆ ไป

หลายทีมมักจะระบุเกณฑ์การยอมรับโดยใช้รูปแบบ “Given-When-Then” ที่เป็นที่รู้จักกันดี ดังตัวอย่างต่อไปนี้:

6 การทดสอบแบบอัตโนมัติ (Automated Testing)

ข้อกำหนดที่สามารถนำไปรันได้ (Executable Specifications) พร้อมสำหรับการทดสอบแล้วในขั้นตอนนี้ โดยการทดสอบแบบอัตโนมัติสามารถดำเนินการโดยวิศวกรซอฟต์แวร์ นักพัฒนา หรือเป็นการทำงานร่วมกันของทั้งสองฝ่าย ซึ่งไม่ว่าจะในกรณีใดก็ตาม งานด้านระบบอัตโนมัติมักจะเริ่มต้นให้เร็วที่สุดเท่าที่จะเป็นไปได้ในระยะการพัฒนา และโดยปกติจะทำไปพร้อมๆ กันหรือตามหลังการพัฒนาเพียงเล็กน้อยเท่านั้น

7 การส่งมอบงาน (Deliver)

เป้าหมายสำคัญของแนวทาง **Behaviour-Driven Development (BDD)** คือการส่งมอบฟีเจอร์ที่มีมูลค่าสูงให้แก่ธุรกิจได้รวดเร็วและสม่ำเสมอมากยิ่งขึ้น การผสาน BDD เข้ากับเกณฑ์การตอบรับแบบอัตโนมัติ (**Automated Acceptance Criteria**) ช่วยให้ทีมสามารถแสดงความเชื่อมโยงที่ชัดเจน (**Traceability**) ระหว่างผลลัพธ์ที่ส่งมอบ (ซึ่งผ่านการทดสอบแล้วว่าใช้งานได้จริง) กับความต้องการของธุรกิจที่ได้หารือกันไว้ตั้งแต่ตอนเริ่มต้น

8 การดำเนินการตามเกณฑ์การตอบรับให้ครบถ้วน

การทดสอบแบบอัตโนมัติ (Automated testing) ถือเป็นข้อบังคับที่ต้องทำเพื่อแสดงให้เห็นว่าซอฟต์แวร์สามารถตอบสนองความต้องการในเกณฑ์การตอบรับ (Acceptance criteria) ได้ครบถ้วน กล่าวอีกนัยหนึ่งคือ การพัฒนายังไม่ถือว่าเสร็จสมบูรณ์จนกว่าซอฟต์แวร์จะผ่านการทดสอบและตรงตามเกณฑ์การตอบรับทั้งหมด การวางแผนและการทดสอบที่ยึดตามวัตถุประสงค์ที่ชัดเจนเช่นนี้ ช่วยลดจำนวนข้อผิดพลาด (Defects) ที่ต้องตามแก้หลังจบสปรินต์ (Sprint) ทำให้เหล่านักพัฒนาสามารถทุ่มเทแรงกายแรงใจไปกับการพัฒนาฟีเจอร์ใหม่ๆ ได้อย่างเต็มที่

9 การทดสอบซ้ำเพื่อป้องกันข้อผิดพลาด (Regression Tests)

ชุดการทดสอบซ้ำ (Regression test suite) คือกลุ่มของการทดสอบที่ออกแบบมาเพื่อสร้างความมั่นใจว่าซอฟต์แวร์ยังคงมีความแม่นยำและทำงานได้อย่างถูกต้อง หลังจากที่ได้มีการแก้ไขหรือปรับเปลี่ยนโค้ดไปแล้ว ชุดการทดสอบซ้ำนี้จะถูกจัดหมวดหมู่ตามฟีเจอร์และความสามารถของระบบ ซึ่งสามารถทำหน้าที่เป็นเอกสารอธิบายการทำงาน (Functional documentation) ไปในตัว โดยไม่เพียงแต่ระบุว่าระบบทำงานอย่างไร แต่ยังอธิบายถึงเป้าหมายทางธุรกิจที่ระบบนั้นต้องการตอบโจทย์อีกด้วย