คำถามติดแท็ก defect

17
มันมีเหตุผลที่จะยืนยันในการทำซ้ำทุกข้อบกพร่องก่อนที่จะวินิจฉัยและแก้ไขหรือไม่
ฉันทำงานให้กับ บริษัท ผลิตภัณฑ์ซอฟต์แวร์ เรามีลูกค้าองค์กรขนาดใหญ่ที่ใช้ผลิตภัณฑ์ของเราและเราให้การสนับสนุนพวกเขา ตัวอย่างเช่นหากมีข้อบกพร่องเราให้บริการแพตช์และอื่น ๆ กล่าวคือเป็นการตั้งค่าที่ค่อนข้างทั่วไป เมื่อเร็ว ๆ นี้มีการออกตั๋วและมอบหมายให้ฉันเกี่ยวกับข้อยกเว้นที่พบโดยลูกค้าในล็อกไฟล์ซึ่งเกี่ยวข้องกับการเข้าถึงฐานข้อมูลพร้อมกันในการใช้งานกลุ่มผลิตภัณฑ์ของเรา ดังนั้นการกำหนดค่าเฉพาะของลูกค้ารายนี้อาจมีความสำคัญในการเกิดข้อผิดพลาดนี้ สิ่งที่เราได้รับจากลูกค้าคือไฟล์บันทึกของพวกเขา วิธีที่ฉันเสนอให้กับทีมของฉันคือพยายามทำซ้ำข้อผิดพลาดในการตั้งค่าการกำหนดค่าที่คล้ายกับของลูกค้าและรับบันทึกที่เปรียบเทียบกันได้ อย่างไรก็ตามพวกเขาไม่เห็นด้วยกับวิธีการของฉันบอกว่าฉันไม่จำเป็นต้องทำซ้ำข้อผิดพลาดเพราะมันใช้เวลานานเกินไปและจะต้องจำลองเซิร์ฟเวอร์คลัสเตอร์บน VMs ทีมของฉันแนะนำให้ฉันเพียง "ติดตามรหัส" เพื่อดูว่ารหัสเธรดและ / หรือธุรกรรมที่ไม่ปลอดภัยอยู่ที่ใดและเปลี่ยนการทำงานนอกการพัฒนาท้องถิ่นอย่างง่ายซึ่งไม่ใช่การใช้คลัสเตอร์เช่นสภาพแวดล้อมที่เกิดขึ้น ของข้อผิดพลาดมา สำหรับฉันแล้วการทำงานจากพิมพ์เขียวที่เป็นนามธรรม (รหัสโปรแกรม) แทนที่จะเป็นรูปธรรมที่ชัดเจนและชัดเจน (การทำสำเนารันไทม์) ดูเหมือนยากดังนั้นฉันต้องการถามคำถามทั่วไป: มันมีเหตุผลที่จะยืนยันในการทำซ้ำทุกข้อบกพร่องและแก้ปัญหาก่อนที่จะวินิจฉัยและแก้ไขหรือไม่ หรือ: ถ้าฉันเป็นนักพัฒนาอาวุโสฉันควรจะสามารถอ่านรหัสแบบมัลติเธรดและสร้างภาพจิตของสิ่งที่มันทำในทุกกรณีสถานการณ์การใช้งานมากกว่าที่จะต้องเรียกใช้แอปพลิเคชันทดสอบสถานการณ์การใช้กรณีและสถานการณ์ที่แตกต่างกัน บรรทัดรหัสโดยบรรทัด? หรือฉันเป็นผู้พัฒนาที่ไม่ดีสำหรับความต้องการสภาพแวดล้อมการทำงานแบบนั้น? การดีบักสำหรับน้องสาวหรือไม่? ในความเห็นของฉันการแก้ไขใด ๆ ที่ส่งมาเพื่อตอบสนองต่อตั๋วเหตุการณ์ควรทดสอบในสภาพแวดล้อมที่จำลองขึ้นให้ใกล้เคียงกับสภาพแวดล้อมเดิมมากที่สุด คุณจะรู้ได้อย่างไรว่ามันจะแก้ไขปัญหาได้จริง ๆ ? มันเหมือนกับการปล่อยรถรุ่นใหม่โดยไม่มีการทดสอบการชนด้วยหุ่นจำลองเพื่อแสดงให้เห็นว่าถุงลมนิรภัยใช้งานได้จริง สุดท้าย แต่ไม่ท้ายสุดถ้าคุณเห็นด้วยกับฉัน: ฉันจะพูดคุยกับทีมของฉันเพื่อโน้มน้าวพวกเขาได้อย่างไรว่าแนวทางของฉันนั้นมีความสมเหตุสมผล

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

7
ทำไมเราต้องการทั้งลำดับความสำคัญและความรุนแรง
ฉันเข้าใจสิ่งที่พวกเขาพิจารณา แต่มีประโยชน์จริง ๆ หรือไม่ที่จะมอบหมายสิ่งเหล่านั้นให้กับปัญหาที่พบ? ฉันหมายถึงมันจำเป็นต้องแก้ไขอย่างรวดเร็วหรือไม่ ฉันรู้วิธีการตั้งค่าจัดหมวดหมู่ ฯลฯ ฉันรู้ว่า IEEE / ISO จำเป็นต้องทำเช่นนั้น ฉันไม่เห็นว่าทำไม
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.