วิธีจัดการกับข้อบกพร่องที่ฉันคิดว่าฉันแก้ไข แต่ฉันไม่แน่ใจทั้งหมด


13

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

ถ้าฉันตั้งค่าให้เป็นค่าstatusคงที่และค่าsolutionคงที่มันจะหมายถึงบางสิ่งที่แก้ไขอย่างสมบูรณ์ใช่ไหม

เป็นเรื่องธรรมดาหรือไม่ที่จะตั้งค่าเป็นstatusคงที่และsolutionเปิดเพื่อระบุถึงผู้ทดสอบว่า "อาจคงที่ แต่ต้องการความสนใจมากขึ้นเพื่อให้แน่ใจ"

แก้ไข:บั๊กส่วนใหญ่ (ถ้าไม่ใช่ทั้งหมด) มีคุณสมบัติสองอย่างสำหรับสถานะของบั๊กชื่ออาจจะไม่เหมือนกัน โดยstatusฉันหมายถึงใหม่กำหนดคงปิด ฯลฯและโดยsolutionฉันหมายถึงเปิด (ใหม่) คงไม่สามารถแก้ไขไม่ได้ทำซ้ำทำซ้ำไม่ใช่ข้อบกพร่องฯลฯ


3
นี่เป็นลักษณะเฉพาะของตัวติดตามบั๊กของคุณ สิ่งที่มีค่าอื่น ๆ ที่คุณสามารถกำหนดให้กับสถานะและการแก้ปัญหา ?
Scarfridge

ในตัวติดตามบั๊กบางตัวจะมีสถานะการแก้ไขและสถานะอื่นของการปิด มีเพียงคน QA เท่านั้นที่ได้รับอนุญาตให้ตั้งสถานะเป็นปิด แต่นักพัฒนาสามารถตั้งค่าสถานะให้แก้ไขได้
Brian

คำตอบ:


8

เป็นเรื่องธรรมดาหรือไม่ที่จะกำหนดสถานะให้คงที่และวิธีแก้ปัญหาเพื่อเปิดเพื่อระบุผู้ทดสอบว่า "อาจคงที่ แต่ต้องการความสนใจมากกว่าเพื่อให้แน่ใจ"

ธรรมดาหรือไม่นี่เป็นสิ่งที่ถูกต้องที่จะทำอยู่แล้วและคุณกำหนดว่าทำไมตัวเอง: ไม่ว่ามันจะเป็นวิธีการที่ดี

บ่งบอกผู้ทดสอบว่า "อาจแก้ไขได้ แต่ต้องการความสนใจมากขึ้นเพื่อให้แน่ใจ"


หมายเหตุด้านข้างแม้ว่าตัวติดตามบั๊กเฉพาะไม่มีฟิลด์เหมือนที่คุณอธิบายไว้solutionอย่างน้อยนักพัฒนาสามารถเพิ่มความคิดเห็นแบบฟรีฟอร์มที่อธิบายข้างต้น

... และหากตัวติดตามบั๊กไม่อนุญาตให้เพิ่มความคิดเห็นในปัญหาคุณจะต้องแทนที่ด้วยสิ่งที่ทำ ความสามารถในการเพิ่มการแจกแจงแบบฟรีฟอร์มเป็นคุณลักษณะที่สำคัญอย่างยิ่งเนื่องจากปัญหาแตกต่างกันมากเกินไปเพื่อให้พอดีกับบางรูปแบบที่กำหนดไว้ล่วงหน้า


6

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


+1 - นี่คือคำตอบที่ง่ายที่สุด หากคุณพยายามอย่างหนักและชุดทดสอบของทีมนั้นแข็งแกร่งพอคุณจะทำอะไรได้อีก
ozz

3

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

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

ตัวอย่างเช่นสมมติว่าคุณเปลี่ยนโปรแกรมและผู้ทดสอบใช้เวลา 1 ชั่วโมงในการพยายามสร้างข้อผิดพลาดและข้อผิดพลาดไม่ปรากฏขึ้น - หนึ่งชั่วโมงเพียงพอหรือไม่ หรือทดสอบเพิ่มเติมเสียเวลาเพราะข้อผิดพลาดได้รับการแก้ไขแล้ว?

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

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


4
สำหรับข้อผิดพลาดบางประเภทสถานการณ์จำลองการทดสอบก็ไม่มีอยู่จริง ตัวอย่างเช่นข้อผิดพลาดเกี่ยวกับเวลาอาจเกิดขึ้นได้ 1 ครั้งโดยเฉลี่ยนับล้าน- แต่มันเป็นไปไม่ได้ที่จะทำนายว่ามันจะเป็นการวิ่งครั้งที่ 3 หรือ 532454 อย่างไรก็ตามข้อผิดพลาดดังกล่าวเป็นข้อบกพร่องและจะต้องแก้ไข
Joonas Pulakka

3
@Joonas Pulakka: ฉันเห็นด้วย และข้อบกพร่องดังกล่าวสามารถขึ้นอยู่กับสถานการณ์ภายนอก ในกรณีของการฝังตัวพวกเขาสามารถพึ่งพาพลังงานที่เกิดจากสิ่งที่อยู่นอกเหนือการควบคุมของคุณ การไม่พยายามแก้ไขมันไม่ใช่วิธีที่ดีที่สุดเสมอไปโดยเฉพาะถ้าฉันพบว่ามีกลิ่นรหัสที่ฉันสงสัยว่าอาจเป็นสาเหตุของข้อผิดพลาดนั้น ในกรณีนี้ทำไมฉันไม่ควรแก้ไข
vsz

2
@ JoonasPulakka: จากประสบการณ์ของฉันเกี่ยวกับสถานการณ์จำลองในกรณีส่วนใหญ่ที่ผู้คนพูดว่า "มันเป็นไปไม่ได้" พวกเขาเพิ่งพลาดแนวคิดที่ถูกต้องเพื่อให้เป็นไปได้ ในตัวอย่างของคุณคุณสามารถตั้งค่าสถานการณ์ด้วยลูป "10 ล้านรอบ" ทำให้อย่างน้อยน่าจะเป็นมากที่จะแสดงข้อผิดพลาดในระยะเวลาที่เหมาะสม
Doc Brown

2
@ vsz: คุณควรแก้ไขแน่นอน แต่สิ่งที่ฉันแนะนำคือสิ่งแรกที่ควรสร้างการทดสอบ (หรือให้คำแนะนำแก่ผู้ทดสอบว่าจะทดสอบอะไร) และจากนั้นแก้ไขไม่ใช่ในทางกลับกัน
Doc Brown

2
@DocBrown ถูกต้องวิธีคิดอีกอย่างคือว่าบางครั้งข้อบกพร่องต้องใช้วิธีการทางสถิติเพื่อ "ทำซ้ำ" อาจเป็นไปได้ว่ามีชุดของอินพุต / สถานการณ์ที่เฉพาะเจาะจงมากที่ทำซ้ำข้อบกพร่อง แต่คุณอาจไม่มีความคิดใด ๆ ว่าอินพุตเหล่านี้คืออะไรและชุดของอินพุตที่เป็นไปได้อาจมีขนาดใหญ่เกินกว่าที่จะทำซ้ำได้ ในกรณีเหล่านี้วิธีหนึ่งคือการรวบรวมสถิติเกี่ยวกับการเกิดข้อผิดพลาดทุกครั้งที่คุณพยายามแก้ไข อาจใช้เวลานานและผลลัพธ์อาจไม่ทำให้คุณ "มั่นใจ" 100% ในแง่สถิติ แต่บางครั้งสิ่งที่คุณมี
แองเจโล

0

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

คำแนะนำสองข้อที่ฉันมีคือ (1) สมมติว่ามีหลายสาเหตุอาจมีผลจนกว่าคุณจะทราบเป็นอย่างอื่นและ (2) ตั้งสมมติฐานว่าอาการอาจเกิดขึ้นได้อย่างไรจากนั้นจึงแยกตรรกะทุกบรรทัดที่มีส่วนเกี่ยวข้องจากระยะไกล คำแนะนำแบบลึกบางครั้งก็หมายถึงการสิ้นสุดที่น่าพอใจเท่านั้น

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.