-
ที่อยู่เดิม: เหตุใดข้อบกพร่องจึงไม่ได้รับการแก้ไข
ผู้แต่ง: Alan Page ผู้อำนวยการฝ่ายความเป็นเลิศด้านวิศวกรรมการทดสอบที่ Microsoft ผู้ร่วมเขียนหนังสือ How We Test Software ที่ Microsoft (ภาษาจีนแปลว่า "วิธีทดสอบซอฟต์แวร์ของ Microsoft")
การแปล: Lu Yueli, Lu Mengyan, Wang Hong
ช่วงนี้ฉันพบผู้คนจำนวนมากขึ้นเรื่อยๆ ที่แปลกใจว่าเราจะออกผลิตภัณฑ์รถบักกี้ สิ่งที่ทำให้ฉันประหลาดใจก็คือคนเหล่านี้หลายคนเป็นผู้ทดสอบซอฟต์แวร์ และฉันคิดว่าพวกเขาจะรู้เรื่องนี้อยู่แล้ว ฉันขอแนะนำให้คุณอ่านบทความก่อนหน้า (แต่ยอดเยี่ยม) ของ Eric Sink ก่อน ไม่แน่ใจว่าฉันสามารถมีส่วนร่วมในหัวข้อนี้ได้มากแค่ไหน แต่ฉันอยากลอง
ข้อบกพร่องหลายอย่างไม่คุ้มค่าที่จะแก้ไข "คุณเป็นผู้ทดสอบหรือไม่" คุณจะตะโกนใส่ฉันว่า "ผู้ทดสอบคือผู้พิทักษ์คุณภาพของผลิตภัณฑ์" ฉันสามารถทำซ้ำได้อีกครั้ง (หากจำเป็น) ข้อบกพร่องหลายอย่างไม่คุ้มค่าที่จะแก้ไข “ให้ฉันบอกคุณว่าทำไม ในกรณีส่วนใหญ่การแก้ไขจุดบกพร่องจำเป็นต้องเปลี่ยนรหัส และการเปลี่ยนแปลงรหัสต้องใช้การลงทุนทรัพยากร (เวลา) และทำให้เกิดความเสี่ยง นั่นแย่มาก แต่ก็จริง บางครั้งหากความเสี่ยงและการลงทุนไกล มีค่ามากกว่าการแก้ไขข้อบกพร่อง ดังนั้นเราจึงไม่แก้ไขข้อบกพร่องเหล่านั้น
การตัดสินใจของเราว่าจะแก้ไขข้อบกพร่องหรือไม่นั้นไม่ได้ขึ้นอยู่กับ "ความรู้สึก" และไม่ควรเป็นเช่นนั้น ฉันชอบใช้แนวคิดเรื่อง “ความเจ็บปวดของผู้ใช้” เพื่อช่วยฉันในการตัดสินใจ ฉันใช้ปัจจัยสำคัญสามประการในการพิจารณาและระบุ "ความเจ็บปวดของผู้ใช้":
1. ระดับความรุนแรง - จุดบกพร่องนี้จะมีผลกระทบอย่างไร - มันจะขัดข้องกับโปรแกรมทั้งหมดหรือไม่? จะทำให้ข้อมูลของผู้ใช้สูญหายหรือไม่? หรือมันไม่ร้ายแรงขนาดนั้น? มีวิธีแก้ไขที่ง่ายกว่านี้ไหม? หรือเป็นเพียงปัญหาที่ไม่เกี่ยวข้อง?
2. ความถี่ - ผู้ใช้ประสบปัญหานี้บ่อยหรือไม่? มันเป็นส่วนหนึ่งของขั้นตอนการทำงานหลักของโปรแกรมหรือไม่? หรือมันถูกซ่อนอยู่ในฟีเจอร์ที่ไม่ได้ใช้กันทั่วไป? ปัญหาเล็กๆ น้อยๆ ที่มีอยู่ในส่วนที่ถูกใช้บ่อยที่สุดของโปรแกรมอาจจะต้องได้รับการแก้ไข ในขณะที่ปัญหาใหญ่ๆ บางอย่างที่มีอยู่ในส่วนที่ไม่ค่อยได้ใช้กันของโปรแกรมก็อาจถูกมองข้ามไป
3. ผลกระทบต่อลูกค้า – หากคุณทำการบ้านมาอย่างดี คุณควรรู้อยู่แล้วว่าลูกค้าของคุณคือใคร และจะมีผู้ใช้กี่คน (หรือคุณหวังว่าจะมี) กี่คนในกลุ่มลูกค้าแต่ละกลุ่มของคุณ จากนั้นคุณต้องตัดสินใจว่าปัญหานี้จะส่งผลกระทบต่อผู้ใช้ทุกคนหรือเฉพาะบางคนเท่านั้น หากคุณสามารถติดตามวิธีที่ลูกค้าใช้ผลิตภัณฑ์ของคุณ คุณจะได้รับข้อมูลที่แม่นยำยิ่งขึ้น
ปัจจัยทั้งสามข้างต้นประกอบขึ้นเป็นสูตร กำหนดช่วงของค่าให้กับแต่ละปัจจัยข้างต้นและทำการคำนวณ - คุณสามารถเพิ่ม คูณ หรือเพิ่มน้ำหนักได้โดยตรงตามการใช้งานและปัจจัยทางการตลาดของคุณ ตัวอย่างเช่น เราเพียงแต่ต้องดำเนินการเพิ่มเติมและกำหนดช่วงตัวเลข 10 คะแนนให้กับแต่ละจุดบกพร่อง
ข้อผิดพลาด #1: ตัวอย่างเช่น มันเป็นข้อบกพร่องที่ทำให้โปรแกรมขัดข้อง (10 คะแนน) มีอยู่ในส่วนหลักของโปรแกรม (10 คะแนน) และส่งผลกระทบต่อลูกค้า 80% (8 คะแนน) ดังนั้นข้อผิดพลาดนี้จึงเป็นสาเหตุ "ความเจ็บปวดของผู้ใช้" "ปริมาณอยู่ที่ 28 จุด และเราพนันได้เลยว่าเราจะแก้ไขมันได้
ข้อผิดพลาด #2: มันเป็นเพียงข้อผิดพลาดในการจัดเรียง (2 คะแนน) โดยปรากฏในหน้าต่างรอง (2 คะแนน) และส่วนของโปรแกรมที่มีข้อบกพร่องนั้นจะถูกใช้ในเวอร์ชันเก่าเท่านั้น (2 คะแนน) ดังนั้นค่า "ความเจ็บปวดของผู้ใช้" ของจุดบกพร่องนี้คือ 6 คะแนน และเราอาจจะไม่สามารถแก้ไขได้
น่าเสียดายที่หลายสถานการณ์ไม่ง่ายเหมือนที่กล่าวมาข้างต้น Bug #3 คือปัญหาข้อมูลสูญหาย (10 คะแนน) ที่มีอยู่ในส่วนสำคัญของแอปพลิเคชัน แต่จะล้มเหลวในบางกรณีเท่านั้น (5 คะแนน) (ข้อมูลเป็นส่วนตัว) การวิจัยจากลูกค้าพิสูจน์ว่าไม่ค่อยได้ใช้ (2 คะแนน) ดังนั้นค่า "ความเจ็บปวดของผู้ใช้" จึงเป็น 17 คะแนน ซึ่งเป็นข้อมูลที่คลุมเครือซึ่งสามารถแก้ไขได้หรือไม่ ในด้านหนึ่ง การลงทุนที่จำเป็นในการแก้ไขอาจไม่คุ้มค่า แต่ตราบใดที่ปัญหาได้รับการเข้าใจและไม่มีจุดบอด การเพิกเฉยต่อจุดบกพร่องอาจเป็นแนวทางที่ถูกต้อง
ในทางกลับกัน คุณต้องชั่งน้ำหนักเทียบกับจุดบกพร่องอื่นๆ ในระบบ เราใช้เอฟเฟกต์ "หน้าต่างที่เสียหาย" ที่นี่ - หากมีจุดบกพร่องระดับกลางดังกล่าวมากเกินไปในแอปพลิเคชัน คุณภาพของผลิตภัณฑ์ (หรืออย่างน้อยก็การรับรู้ถึงคุณภาพ) จะได้รับผลกระทบอย่างมาก เมื่อคุณพิจารณาจุดบกพร่องแต่ละจุดในระบบ คุณควรพิจารณาจุดบกพร่องอื่นๆ (ที่ทราบ) ในระบบด้วย และใช้สิ่งนี้เพื่อวิเคราะห์และตัดสินใจว่าจุดบกพร่องใดที่ต้องแก้ไข และจุดบกพร่องใดที่ไม่คุ้มค่าที่จะแก้ไข
การมีข้อบกพร่องในซอฟต์แวร์ที่เปิดตัวอย่างเป็นทางการถือเป็นสิ่งที่แย่มาก แต่จากเครื่องมือการพัฒนาและภาษาการพัฒนาที่มีอยู่ของเรา เรายังไม่พบวิธีแก้ปัญหาที่สมเหตุสมผลกว่านี้
เติมเงิน:
ขณะที่ฉันเขียนสิ่งนี้ ฉันคิดว่าฉันขาดปัจจัยที่สี่ในสูตร: วันที่วางจำหน่าย ปัจจัยนี้ยังมีบทบาทสำคัญในการตัดสินใจแก้ไข/ไม่แก้ไขจุดบกพร่องเมื่อใกล้ถึงวันวางจำหน่าย อย่างไรก็ตาม ฉันไม่แน่ใจว่ามันเป็นปัจจัยที่สี่หรือไม่ หรือเกณฑ์สำหรับจำนวน "ความเจ็บปวดของผู้ใช้" ที่จำเป็นในการแก้ไขข้อบกพร่องที่ใกล้จะเผยแพร่เป็นอย่างไร