ทีมพัฒนาของฉันเติบโตขึ้น 100% (จากนักพัฒนา 1 รายถึง 2) กลุ่มใหม่ของฉันต้องการลงทุนในซอฟต์แวร์ติดตามบั๊ก ซอฟต์แวร์นี้มีประโยชน์สำหรับทีมขนาดเล็กเช่นนี้หรือไม่?

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

• คุณต้องการสื่อสารเป็นทีมอย่างไร ด้วย 2 นักพัฒนาคุณเป็นทีมแล้ว คุณต้องการสื่อสารอย่างไร ทีมงานเปรียวจำนวนมากอาศัยอยู่กับการแสดงตัวของบุคคลและภาพร่างกระดานไวท์บอร์ด แต่พวกเขาก็อาจจะเขียนสิ่งต่าง ๆ โดยเฉพาะอย่างยิ่งถ้ามันเป็นข้อผิดพลาดที่จะไม่สูงในรายการลำดับความสำคัญในขณะที่
• คุณต้องการสื่อสารกับลูกค้าของคุณอย่างไร? ฉันไม่ทราบคำตอบสำหรับเรื่องนี้ แต่ถ้าคุณมีเหตุผลที่จะเผยแพร่ข้อบกพร่อง (หรือแก้ไขข้อบกพร่องในเอกสารเผยแพร่รุ่น) คุณจะต้องเขียนมันลงไปในที่สุด อาจเลือกระบบการจัดการบั๊กที่มีความเครียดน้อยและสามารถทำได้ด้วย
• มีคุณค่าต่อการรักษาประวัติศาสตร์หรือไม่? คำตอบอาจเป็น "ไม่ได้ตอนนี้" แต่ถ้าคุณคิดว่าในอนาคตคุณต้องการเห็นแนวโน้มของข้อบกพร่องเพื่อให้คุณสามารถดูสถานที่ที่ผู้ใช้กำลังประสบปัญหามากที่สุดหรือสถานที่ที่คุณสามารถใช้เวลาตรวจสอบ และตรวจสอบก่อนการวางจำหน่ายครั้งสำคัญ - จากนั้นรับระบบติดตามบั๊ก สิ่งที่เกี่ยวกับประวัติศาสตร์คือวันที่คุณต้องการบันทึกไม่ใช่วันที่คุณควรเริ่มเก็บบันทึก

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

1 แต่ถ้ามันไม่เจ็บปวด ตัวอย่างเช่น GitHub มีตัวติดตามปัญหาที่ใช้งานง่ายและมีคุณสมบัติมากเกินพอสำหรับทีมเล็ก ๆ Bugzilla, Trac หรืออื่น ๆ เป็นสิ่งที่ดี แต่พวกเขาทั้งหมดต้องใช้ฮาร์ดแวร์การติดตั้งและการกำหนดค่าก่อนการใช้งานและการบำรุงรักษาเป็นค่าใช้จ่ายที่ไม่เป็นศูนย์แน่นอน

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

ใช่. พันครั้งใช่

อย่าแม้แต่จะคิดในแง่ของการติดตามบั๊ก แต่เป็นการติดตามตั๋ว

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

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

มันช่วยให้คุณจัดการสิ่งต่าง ๆ ได้ดีขึ้นมาก

มันมีค่ากับทีมหนึ่งหรือมากกว่านั้น

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

ควรพิจารณาด้วยเช่นกัน: ตัวติดตามบั๊กจำนวนมากสามารถใช้งานได้ฟรีโดยทีมเล็ก ๆ (1-2) ดังนั้นจึงไม่เหมือนกับที่คุณต้องเสียค่าใช้จ่ายหลักเพื่อผลประโยชน์

คุณไม่ต้องการซอฟต์แวร์ติดตามบั๊กตราบใดที่สมาชิกทุกคนในทีม

• มีหน่วยความจำการถ่ายภาพที่สมบูรณ์แบบและ
• สามารถประสานความคิดของพวกเขากับสมาชิกคนอื่น ๆ ทุกคนในทีม

คำตอบสั้น ๆ คือใช่

สาเหตุบางประการ:

1. ความสามารถในการบันทึกข้อบกพร่องที่พบกับรุ่นที่เฉพาะเจาะจง
2. ความสามารถในการรับรู้ข้อบกพร่อง (ที่รู้จัก) ที่ยังไม่ได้รับการแก้ไข
3. ติดตามผู้แก้ไขข้อผิดพลาดที่ได้รับการค้นพบอีกครั้ง
4. ผลประกอบการของนักพัฒนาซอฟต์แวร์ - อนุญาตให้มีการถ่ายโอนความรู้แม้ว่าคุณจะได้รับความนิยมเป็นบัสสุภาษิต

คุณอาจต้องการดูสิ่งที่ไม่ต้องใช้เวลามากในการตั้งค่า / จัดการ ฉันขอแนะนำให้มองหาสิ่งที่มีความสามารถในการรวมเข้ากับการควบคุมแหล่งที่มาของคุณ

คำตอบนี้คือการเพิ่มน้ำหนักให้กับด้านYESของการโต้แย้ง

ฉันเป็นทีมของคนส่วนใหญ่ ฉันใช้การติดตามปัญหาอย่างกว้างขวาง (redmine) ร่วมกับการรวม SVN

มันยอดเยี่ยมอย่างแท้จริงและฉันจะบ้าโดยไม่ได้ คุณภาพของฉันจะลดลงเพราะฉันจะลืมสิ่งต่าง ๆ และฉันก็จะติดตามสิ่งที่ฉันต้องทำต่อไป

เครื่องมือเพิ่มประสิทธิภาพ:

• IDE ที่มีคุณค่า
• ติดตามปัญหา
• การควบคุมแหล่งที่มา

การติดตามปัญหา อย่าออกจากบ้านหากไม่มี

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

แม้แต่ทีมหนึ่งก็สามารถได้รับประโยชน์จากตัวติดตามบั๊กบางประเภทไม่ว่าจะเป็นไฟล์ข้อความของโน้ตหรือซอฟต์แวร์ที่ถูกเป่าเต็ม สำหรับนักพัฒนา 2 คนผมขอแนะนำให้ใช้เวลาในการตั้งค่าระบบติดตามบั๊กเท่านั้นไม่ใช่เงิน ขึ้นอยู่กับโครงการคุณสามารถทำได้โดยการเขียนบั๊กลงบนกระดาษรักษารายการผ่านเอกสารออนไลน์ที่ใช้ร่วมกันหรือใช้ซอฟต์แวร์การติดตามข้อผิดพลาดฟรีเช่น Trac หรือ Bugzilla Fogbugzมีให้ทดลองใช้ฟรี 45 วัน

ใช่.

คุณต้องติดตามพวกเขาวิธี!

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

มีประโยชน์อย่างแน่นอน - ฉันใช้ซอฟต์แวร์การติดตามข้อผิดพลาดแม้ในโครงการส่วนบุคคล มันมีประโยชน์ไม่เพียง แต่สำหรับการติดตามบั๊ก แต่ยังสำหรับการติดตาม 'สิ่งที่ต้องทำและคำขอคุณสมบัติ

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

เพิ่งเริ่มใช้งาน

หากคุณเพิ่งเริ่มใช้คุณจะเริ่มตระหนักถึงความสะดวกสบายในการฝึกฝนเช่นซอฟต์แวร์ควบคุมเวอร์ชันหรือสำหรับเรื่องนั้นการควบคุมเวอร์ชันแบบกระจาย

กำหนดพัฒนา

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

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

สำหรับฉันมันไม่ได้เป็นเพียงเกี่ยวกับซอฟต์แวร์ แต่กระบวนการที่ดำเนินการไปรอบ ๆ ในงานประจำวันของฉันในฐานะผู้จัดการทดสอบฉันอาศัยอยู่ในที่เดียวและให้ประโยชน์ดังต่อไปนี้:

ฉันพบว่ามันใช้งานได้ดีกับผู้ทดสอบ 2+ และนักพัฒนา 3+ คน

การจัดการความพยายามในการแก้ไขข้อผิดพลาดของนักพัฒนาซอฟต์แวร์

เราจัดการนักพัฒนา "คิวบั๊ก" เพื่อควบคุมจำนวนงานที่มอบหมายให้พวกเขาและให้แน่ใจว่าเรามีการจัดสรรระดับของการแก้ไขข้อบกพร่องในทีม

ตัดสินใจเลือกสิ่งที่ไม่ได้รับการแก้ไข

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

เมื่อคุณต้องการตัวชี้วัด

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

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

ส่วนตัวฉันชอบฟอสซิลสำหรับการควบคุมแหล่งที่มาและการติดตามบั๊ก มันเป็นงานพิธีแจกแจงต่ำที่สมบูรณ์แบบ SCM ที่รวมเข้ากับตัวติดตามบั๊กและวิกิ และมันคือการติดตั้งแบบปฏิบัติการได้ครั้งเดียวพกพาได้กว้างและใช้เว็บแอปพลิเคชันภายในเป็น GUI จริง ๆ แล้วมันเป็นหน้าแรกของหน้าที่ให้บริการเกือบทั้งหมดโดยสำเนาของฟอสซิล

ด้วยตัวติดตามที่ผสานรวมกับการควบคุมการแก้ไขอย่างแน่นหนาคุณสามารถเชื่อมโยงการเปลี่ยนแปลงกับตั๋วได้อย่างง่ายดายและดูการอัปเดตตั๋วในมุมมองบรรทัดเวลาเดียวกับการแก้ไข (และการแก้ไขหน้าวิกิ)

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

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

นี่คือ 2 เซ็นต์ของฉัน

สำหรับการติดตามบั๊กฉันใช้ google-doc สเปรดชีตฉันสามารถเชิญทุกคนที่ฉันต้องการแก้ไขหรือดูได้ มันฟรีไม่มากนัก ฉันติดตามงานทั้งหมดที่นั่นแค่ข้อบกพร่อง

ฉันยังเรียกใช้ SVN บนเว็บโฮสต์ของฉันซึ่งไม่เพิ่มค่าใช้จ่ายเพิ่มเติมใด ๆ ให้กับเว็บโฮสติ้ง

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

หากคุณมีตัวติดตามบั๊กแบบเรียบง่ายฉันจะบอกว่ามันมีประโยชน์แม้กับทีมใดทีมหนึ่ง ที่หนึ่งในไซต์โครงการของเพื่อนของฉันQuokForgeพวกเขาให้อินสแตนซ์ของ Red Mine สำหรับแต่ละโครงการ Red Mine ในความคิดของฉันมีตัวติดตามบั๊กที่ดี (แม้ว่าจะแปลกไปบ้างในบางครั้ง) กล่าวคือเพราะคุณสามารถยื่นข้อบกพร่องโดยป้อนข้อความในช่องเดียวเท่านั้น ฉันเคยใช้FogBugzมาก่อน ฟรีสำหรับ 2 คนหรือน้อยกว่า และมันยังช่วยให้ความเรียบง่ายเหมือนเดิมโดยการป้อนข้อผิดพลาดโดยกรอกข้อมูลในช่องข้อความเดียวเท่านั้น (มันยังให้กราฟและสิ่งอื่น ๆ ที่มีประโยชน์อย่างบ้าคลั่ง)

โดยพื้นฐานแล้วอย่าทำข้อผิดพลาดในการทำกระบวนการที่เข้มงวดและเป็นทางการซึ่งคุณต้องใช้เวลา 30 นาทีในการกรอกรายงานบั๊ก (BugZilla ฉันกำลังมองคุณอยู่) นี่หมายความว่าผู้คนจะไม่ใช้มัน

ในที่สุดการมีรายการข้อผิดพลาด (แม้ว่าข้อผิดพลาดแต่ละข้อจะมีประมาณ 50 ตัวอักษรของข้อความ) มีค่ามาก "อืมการแข่งขันเพื่อปล่อย 1.0 ฉันคิดว่าฉันคงข้อผิดพลาดสุดท้าย" และมันก็ดีสำหรับผู้จัดการที่จะเห็นว่าคุณกำลังทำอะไรอยู่ :) ในทีมมันมีค่ามากกว่าเพราะคุณไม่ได้พยายามเก็บรายการสิ่งที่ต้องทำในหัวไว้ในหัว และมันแก้ไข "คุณแก้ไขข้อผิดพลาดด้านความปลอดภัยที่แย่จริงๆหรือเปล่าอืมใช่ฉันคิดอย่างนั้นโอเคลองปล่อย 1.0 แล้ว

ฉันชอบติดตามฟีเจอร์ด้วยเช่นกัน นี่เป็นตัวเลือกอีกเล็กน้อย แต่ฉันยังคงได้รับประโยชน์จากความสามารถในการถ่ายภาระงานทางจิตใจในการเก็บรายการสิ่งที่ต้องทำในหัว

ดูสิ่งที่โจเอลพูดเกี่ยวกับมันด้วย

คุณเพิ่งจะถึงหมายเลขนั้น ... 2 ! ในขณะที่ฉันสามารถเห็นประโยชน์ของการใช้ซอฟต์แวร์การติดตามบั๊กแม้ว่าคุณจะเป็นนักพัฒนาเพียงคนเดียว ... คุณสามารถทำได้โดยไม่ใช้มันเมื่อจำนวนนักพัฒนาทั้งหมดคือ 1

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

ใช่. และข้อเสนอแนะคือ bitbucket http://www.bitbucket.orgพวกเขาให้การติดตามข้อผิดพลาดฟรีเช่นเดียวกับที่เก็บส่วนตัวฟรีใน Mercurial

หนึ่ง. ในกรณีนี้มันเป็นเหมือนรายการที่ต้องทำ

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

ฉันคิดว่าคำถามของคุณเน้นความเข้าใจผิดของคุณ เนื่องจากไม่ใช่ทีมที่ต้องการการติดตามบั๊กมันเป็นผลิตภัณฑ์

ดังนั้นการติดตามข้อผิดพลาดจำเป็นต้องทำในซอฟต์แวร์หรือไม่? นั่นจะช่วยได้คุณไม่คิดเหรอ?

อาจไม่คุ้มค่าหากมีสองเงื่อนไขต่อไปนี้:

1. ปัญหามีช่วงชีวิตสั้น ในกรณีนี้มันอาจจะเพียงพอกับบอร์ดงานที่เรียบง่าย (เนื่องจากมันฉลาดในการแสดงภาพเวิร์กโฟลว์ด้วยเหตุผลอื่น ๆ มากมาย) อย่างไรก็ตามหากคุณไม่สามารถแก้ไขปัญหาได้อย่างรวดเร็ว f.ex แก้ไขข้อบกพร่องได้อย่างรวดเร็วคุณจะพบว่ามีประโยชน์ในการติดตามปัญหา
2. การเปลี่ยนแปลงรหัสจะถูกบันทึกไว้พร้อมกับการทดสอบอัตโนมัติเป็นเอกสารที่มีชีวิต นั่นคือข้อผิดพลาดและการแก้ไขจะได้รับการบันทึกไว้ด้วยการทดสอบที่ล้มเหลวเมื่อปรากฏขึ้นโดยผ่านการทดสอบกลายเป็นการทดสอบการถดถอยหลังจากการแก้ไข - และการเปลี่ยนแปลงการทำงานนั้นมีการบันทึกไว้ด้วยการทดสอบการยอมรับอัตโนมัติ (f.ex. ใช้เครื่องมือ BDD บางอย่างเช่น FitNesse หรือแตงกวา) เอกสารดังกล่าวควรหาได้ง่ายจากเซิร์ฟเวอร์ CI เช่น Jenkins

หากไม่มี 1 หรือ 2 คุณจะได้รับประโยชน์จากการติดตามปัญหา

ไม่

ไม่ติดตามข้อบกพร่องแก้ไขได้

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

หากคุณใช้ Agile / TDD รายการข้อผิดพลาดของคุณจะสั้นและข้อบกพร่องจะไม่อยู่ในรายการนาน ระบบติดตามใด ๆ จะเพียงพอในกรณีนั้น