ขั้นตอนในการรักษาฐานข้อมูลบั๊กที่ดี

การรักษาฐานข้อมูลบั๊กเป็นสิ่งสำคัญสำหรับทุกโครงการ ฉันใช้เพื่อจัดเก็บสิ่งต่อไปนี้ที่ฐานข้อมูลบั๊ก

• เวลาวันที่ออก
• ใครได้รับมอบหมายให้
• ไม่ว่าจะได้รับการแก้ไขหรือไม่
• หากแก้ไขแล้วให้แก้ไขเวลาวันที่

พอที่จะรักษาฐานข้อมูลบั๊กที่ดีอยู่หรือไม่?

ฐานข้อมูลบั๊กที่ดีอาจมีสิ่งต่าง ๆ ดังต่อไปนี้

// วันที่เวลาที่เกี่ยวข้อง

• เวลาวันที่ออกของข้อผิดพลาด
• เวลาแก้ไข / แก้ไขที่คาดหวัง
• หากแก้ไขแล้วให้แก้ไขเวลาวันที่

// มอบหมายโดย + ถึง

• มอบหมายโดย (ตรวจพบโดย)
• ได้รับมอบหมายให้

// พฤติกรรมของแมลง

• สังเกตพฤติกรรม (บั๊กกี้)
• ภาพหน้าจอ (เป็นไปได้)
• ทำตามขั้นตอนเพื่อสร้างข้อผิดพลาด
• พฤติกรรมที่คาดหวัง

// ลำดับความสำคัญ

• ลำดับความสำคัญของข้อบกพร่อง

// ลิงก์สถานะและอื่น ๆ

• ลิงค์ของข้อบกพร่องที่เกี่ยวข้อง
• สถานะของบั๊ก
• ไม่ว่าจะได้รับการแก้ไขหรือไม่
• หากแก้ไขแล้วจะแก้ไขด้วยคำอธิบายอย่างไร

แก้ไข:ฉันยังต้องการที่จะแนะนำ

• ในการแก้ไขข้อบกพร่อง / สาขาใดถูกค้นพบ
• มีการแก้ไขข้อบกพร่อง / สาขาใดบ้าง

แก้ไข:ฉันชอบความคิดเห็น @ jgauffin

• ไม่ต้องแก้ไขไม่ใช่ข้อผิดพลาดทำซ้ำแก้ไขได้

แก้ไข:ระบบฐานข้อมูลบั๊กที่ดียังรักษา

• เมทริกซ์การกำหนดความรับผิดชอบ

อาจมีจำนวนฟิลด์ที่กำหนดเองที่คุณอาจต้องเข้าสู่ระบบขึ้นอยู่กับความต้องการของโครงการ ฉันมาพร้อมกับรายการต่อไปนี้ที่คุณอาจต้องพิจารณาด้วย:

• ปัญหาDateTimeข้อบกพร่อง / ข้อบกพร่อง
• คำอธิบายของ Bug - ขั้นตอนในการสร้างใหม่
• สภาพแวดล้อมที่พบ (Dev, QA, QC, Staging, Prod)
• สกรีนช็อตของปัญหา
• ใครเข้าสู่ระบบ (ตรวจพบโดย)
• ใครเป็นผู้กำหนด (มอบหมายโดย)
• ความรุนแรงของบั๊ก (ต่ำ, ปานกลาง, สูง)
• การแก้ปัญหาที่คาดหวัง DateTime
• State Triage (เสนอ, กำลังดำเนินการ, แก้ไข, ปิด)
• Bug ถูกปิดDateTime- เมื่อแก้ไขข้อบกพร่องและปิด
• มอบหมายให้ทดสอบ (ทดสอบโดย)

แก้ไข:ที่สุดของข้อมูลทั่วไปที่มีค่าที่จะติดตามเป็นอย่างดีที่อธิบายไว้ในโปรแกรมเช่น Bugzilla Bugzilla เป็น bugtracker วัตถุประสงค์ทั่วไป Web-based และการทดสอบเครื่องมือที่สร้างสรรค์พัฒนาและใช้งานโดยโครงการ Mozilla และได้รับใบอนุญาตภายใต้ใบอนุญาต Mozilla สาธารณะและเป็นฟรี ฉันขอแนะนำอย่างยิ่งให้พวกเขาเป็นตัวอย่างหลักและขยายออกไปตามความต้องการของโครงการของคุณ

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

• ในการแก้ไขข้อบกพร่อง / สาขาใดถูกค้นพบ
• มีการแก้ไขในสาขาใดบ้าง

นี่เป็นสิ่งที่เฉพาะเจาะจงมากกว่าวันที่ / เวลาที่พบข้อผิดพลาด / แก้ไข

หากซอฟต์แวร์ของคุณทำงานบนหลายแพลตฟอร์ม (ระบบปฏิบัติการหรือฮาร์ดแวร์) คุณอาจต้องการเขตข้อมูลที่แสดงรายการแพลตฟอร์มที่มีข้อบกพร่องเกิดขึ้น

แต่มีมากกว่าการรักษาฐานข้อมูลข้อผิดพลาดกว่าที่มันควรจะมีเขตข้อมูล คุณต้องพิจารณาว่าคุณใช้ฐานได้อย่างไร

พยายามรักษาจำนวนของ open / unresolved bugs ให้ต่ำที่สุด สิ่งนี้อาจดูเหมือนชัดเจน แต่อาจยากกว่าที่คาดไว้อย่างน้อยสำหรับโครงการขนาดใหญ่ ฉันมักจะเห็นคนกลัวที่จะปิดประเด็นที่ไม่สามารถทำซ้ำได้หรือในกรณีที่ผู้ส่งดั้งเดิมไม่ได้ให้ข้อมูลที่ขาดหายไป นอกจากนี้ยังมีข้อบกพร่องที่ได้รับการวางรอบ ๆ ตลอดไปและเห็นครั้งสุดท้ายในซอฟต์แวร์รุ่นโบราณไม่ควรทิ้งรอบ สิ่งนี้ทำให้ฐานข้อมูลเติบโตขึ้นพร้อมกับปัญหาที่อาจจะใช่หรือไม่ใช่ปัญหาจริงและทำให้การพัฒนาช้าลง

คุณมักจะต้องดูประวัติข้อผิดพลาด _ มันอาจจะได้รับการแก้ไขแล้วเปิดใหม่แล้วแก้ไขอีกครั้ง ฯลฯ ดังนั้นนอกจากสิ่งที่ได้รับการแนะนำแล้วฉันขอแนะนำให้คุณมีตารางแยกต่างหากเพื่อติดตาม ของประวัติข้อผิดพลาดในแต่ละครั้งที่เปิด (ใหม่) ตารางจะมีความสัมพันธ์แบบหนึ่งต่อหนึ่งกับตารางข้อบกพร่องและมีแนวโน้มว่าจะมีฟิลด์ดังนี้:

• วันที่เปิด
• เปิดโดย
• วันที่แก้ไข
• แก้ไขโดย
• ใช้เวลา
• ได้รับการแก้ไขอย่างไร
• เป็นต้น

คุณอาจต้องใช้ตารางที่คล้ายกันเพื่อติดตามว่าใครและเมื่อใดที่มีการมอบหมายข้อบกพร่องอีกครั้งโดยเฉพาะอย่างยิ่งถ้าคุณทำงานในทีมใหญ่

ฉันยังแนะนำให้คุณดูที่ระบบที่มีอยู่ IMHO Jira เป็นหนึ่งในระบบติดตามปัญหาที่ดีที่สุด มันมีคุณสมบัติที่หลากหลายมากและคุณสามารถใช้คุณสมบัติเหล่านี้เป็นแนวทางสำหรับระบบของคุณเอง

กระบวนการในการติดตามบั๊กนั้นสำคัญพอ ๆ กับข้อมูล ลองคิดถึงสิ่งต่อไปนี้ด้วย:

• ผู้ใช้รายงานข้อผิดพลาดได้อย่างไร
• ใครเป็นคนป้อนบั๊กในที่เก็บ?
• ใครสามารถยืนยันข้อผิดพลาดที่มีอยู่
• ใครสามารถยืนยันข้อผิดพลาดได้รับการแก้ไข?
• ใครแจ้งผู้ใช้ว่ามีการแก้ไขข้อบกพร่องหรือไม่

สร้างแผนภูมิ RACIเพื่อให้ทุกคนในทีมของคุณ (รวมถึงผู้ใช้ปลายทางทราบถึงความรับผิดชอบของพวกเขา) รวมกับเทคนิคการป้อนข้อมูลที่เหมาะสมและคุณจะเห็นคุณค่ามากขึ้นด้วยความพยายามพิเศษเล็กน้อย