จุดประกาย : ทำไม Softwareต้องมี bug (ตอนที่ 2)

- การพัฒนาระบบอย่างต่อเนื่องเพื่อไล่ตาม requirement

จุดประสงค์ของ software ที่ใช้ในธุรกิจส่วนใหญ่ ทำออกมาเพื่อตอบรับความต้องการของธุรกิจหลักขององค์กรที่ใช้ระบบนั้นๆ เพื่อให้ธุรกิจเป็นไปอย่างแข่งขัน (low cost + high efficiency) กลยุทธ์ของธุรกิจจึงมีการเปลี่ยนแปลงตลอดเวลา ส่งผลให้ระบบ software requirement ต่างๆจำเป็นจะต้องมีการปรับเปลี่ยนอยู่บ่อยๆ หากแต่การปรับเปลี่ยนโครงสร้างของระบบให้สอดคล้องกับความเปลี่ยนแปลงที่เกิดขึ้นเรื่อยๆนั้น นับมีความท้าทายอยู่อย่างมาก โดยเฉพาะอย่างยิ่ง เมื่อเวลาผ่านไปจนบุคคลกรที่พัฒนา software เกิดการหมุนเวียน บางคนถูกย้ายไปทำงาน project อื่น บางคนลาออกจากบริษัท หรือบริษัท/ตัว product ถูกซื้อไป การรับช่วงต่อเปลี่ยนมือคนทำ software ที่ไม่ได้มีการดำเนินการที่ดี โดยเฉพาะเอกสารที่ไม่ครบถ้วนหรือ update ก็เป็นการเปิดโอกาสที่ทำให้เกิดbug ได้เช่นเดียวกัน

- การ test ทุกอย่างที่เป็นไปไม่ได้
ลองนึกถึง web application ตัวนึงที่มี 5 use case แต่ละ use case มี 20 test cases เท่ากับว่าเรามีทั้งหมด 100 test cases หากในตลาดมี browser เป็น ie, firefox, safari ก็คูณไปอีก 3 = 300 แต่ว่าแต่ละ browser ก็ยังมีการ settings/addon (javascript, flash, security options) ต่างๆกัน และมี major/minor version ก็ทวีคูณกันขึ้นไปอีก (นี่ยังไม่รวม version ของ OS, screen resolution และลำัดับการกรอกข้อมุลและอื่นๆ) การ test ทุกอย่างในทุก environment จึงเป็นไปไม่ได้ที่จะทำให้เกิดขึ้นใน timelineของprojectและคุ้มค่ากับต้นทุนการ testได้ ดังนั้นการออกแบบกลยุทธ์ในการ test (test strategy)ที่ทำให้เกิด Smart Testing โดยไม่testทุกอย่างแต่ยังได้ testสิ่งที่ควรจะถูกtest และให้ได้coverage ที่ดีที่สุดจึงเป็นหัวใจสำคัญและเป็นความท้าทายที่ถูกถกเถียงกันในวงการ testing มานาน อย่างไรก็ตาม แม้ว่า test strategy จะถูกคัดสรรค์มาดีแค่ไหน การที่ไม่ได้ test ทุกอย่างและเว้นไปในแค่รายละเอียดย่อยเล็กน้อยล้วนก็เป็นการเปิดช่องให้มีโอกาสให้มี software bug เกิดขึ้นได้ หากแต่ว่าผลกระทบของการมี bug เหล่านั้นน่าจะส่งผลที่น้อยที่สุดต่อผู้ใช้และธุรกิจของผู้ใช้ระบบนั่นเอง พบกับการบรรยายหลากหลายมุม เรื่อง Smart Testing ได้ในงาน SPIN Day เดือน พ.ค นี้ครับ

- การเมือง และ การตัดสินใจ release software บนพื้นฐานของ cost of quality

โดยปกติแล้ว software ส่วนใหญ่จะมี schedule ในการพัฒนา/ทดสอบที่ค่อนข้างกระชั้น (ไว้มีโอกาสผมจะมาเล่าเบื้องหลังให้ฟังว่าทำไม) และในหลายกรณีmanagementอาจมีการตกลงกันไว้ล่วงหน้าแล้วว่าวัน release software เป็น hard deadline คือเลื่อนไม่ได้ อาจจะเนื่องมาจากสาเหตุที่เป็นไปได้ดังต่อไปนี้
-ได้มีการบอกกับสื่อไปแล้วว่า version ต่อไปจะออกมาเมื่อไหร่ ซึ่งจะส่งผลกระทบต่อความน่าเชื่อถือขององคกรณ์
-ได้มีการระบุเป็นเงื่อนไขข้อตกลงกับทางลูกค้าว่าจะต้องเสียค่าปรับหากส่งมอบ software ล่าช้า
-วัน goliveเป็น KPI ของฝ่ายพัฒนา software หรือแม้กระทั่งของฝ่าย IT/IS ของลูกค้าเอง
-ตัวลูกค้าเองก็มีความจำเป็นที่จะต้องใช้ระบบใหม่ในวันที่กำหนดไว้ล่วงหน้า อย่างเช่นตลาดหลักทรัพย์จะมีการเปิดให้ซื้อขาย ETF ซึ่งเป็นทางเลือกการลงทุนใหม่ ในวันที่ที่ได้มีการประกาศไปล่วงหน้าให้ผู้ลงทุนรับทราบไปแล้ว

ซึ่งหากเป็นกรณีใดกรณีหนึ่งที่กล่าวมา ความกดดันในกาำรพัฒนาและทดสอบรวมถึงการแก้software ก็จะเพิ่มขึ้นเป็นทวีคูณ สุดท้ายแล้วการตัดสินใจที่จะ release software ก็อยู่ที่ key management ที่จะมาชั่งใจดูว่า เมื่อมาเทียบน้ำหนักว่า cost of finding more bugs + cost of fixing the bugs เมื่อเปรียบเทียบกับ cost of releasing software with known + unknown bugs แล้วจะเป็นอย่างไร และส่วนใหญ่ก็จะตัดสินใจ release ออกมาก่อนและส่ง patch version เพื่อจะแก้ bug ที่มีอยู่ตามมาและรวมถึง bug สำคัญที่มีการเจอหลังจากการ go live ไปเป็นรายตัว ในกรณีพิเศษอาจมี bug บางตัวที่มี impact กับ userระดับกลาง แต่มีการแก้ใน code ส่วนนั้นๆมีความเสี่ยงที่การแก้ bug นั้นอาจทำนำไปสู่ bug อื่นๆสูง การอาจมีการตัดสินใจที่จะประกาศว่าอันนี้เป็น limitation หรือ known issue และจะยังไม่มี plan ที่จะแก้ในส่วนนี้ในระยะอันใกล้ก็เป็นได้

- Lastly, we are human after all

สิ่งที่มองข้ามไม่ได้คือ ไม่ว่าจะพยายามแค่ไหน เราก็เป็นแค่มนุษย์ซึ่งสามารถทำผิดพลาดได้ BA/SA อาจจะ design ได้ไม่ครอบคลุมทุกรายละเอียด อาจมองข้ามผลกระทบระหว่าง module, Programmer เองก็อาจเขียน program ไม่ได้ดักexceptionครบทุกcase, Tester เองก็ผิดพลาดได้เช่นเขียน test case ไม่คลุมรายละเอียดที่ user อาจจะทำได้ หรืออาจจะด้วย time pressure เลยไม่ได้ทำให้ execute ตาม test case ที่เขียนเอาไว้แล้ว หรืออาจ assume ไปเองว่าผล actual test result ที่ได้ออกมาหมายความว่าระบบทำงานถูกต้องแล้วเป็นความเข้าใจผิดของตัวเองตอนเขียน test case เป็นต้น

…Combination ของปัจจัยที่ได้กล่าวมาทำให้การdevelopและtest software ต้องผ่านกระบวนการที่ซับซ้อน สื่อสารและประสานงานที่ลำบาก มีผู้ร่วมในแต่ละกระบวนการจากหลายฝ่ายหลาย function ซึ่งเป็นสาเหตุที่ทำให้เกิดช่องโหว่ได้ในหลายๆจุดระหว่างการทำงานและช่องโหว่เหล่านี้ก็นำไปสู่การเกิด bug นั่นเอง

สุดท้ายนี้หลังจากเขียนเสร็จผมก็ได้ไป search google ออกมาว่าคนอื่นเค้าคิดกันอย่างไรบ้างในหัวข้อที่เกี่ยวกับว่า “ทำไม software ถึงมี bug” จึงเอามาแบ่งกันตรงนี้ด้วยครับ

http://www.softwaretestinghelp.com/why-does-software-have-bugs/

http://www.guardian.co.uk/technology/2006/may/25/insideit.guardianweeklytechnologysection

 .. แล้วเพื่อนๆล่ะครับคิดว่ายังไงกันบ้างครับสำหรับหัวข้อนี้ ถ้ามีมุมมองอะไรที่เด็ดๆเอามาแบ่งกันตรงนี้ได้เลยนะครับ …