ทำไมจึงไม่แนะนำให้โพสต์ข้อบกพร่องหลายอย่างในปัญหา / ตั๋วเดียวกัน

ฉันไม่แน่ใจว่านี่เป็นสถานที่สำหรับถามคำถามเชิงแนวคิดต่อไปนี้ (Stackoverflow ไม่แน่นอน)

ฉันเห็นคำถามนี้ในการสอบแบบปรนัย (คำตอบเดียว) คล้ายกับการสอบISTQB :

เหตุใดจึงไม่แนะนำให้รายงานข้อบกพร่องต่าง ๆ ในปัญหา / ตั๋วเดียวกัน

เพื่อให้รายงานมีความกระชับและชัดเจน

ข เนื่องจากผู้พัฒนาอาจแก้ไขข้อบกพร่องเพียงข้อเดียว

ค เนื่องจากผู้ทดสอบกลุ่มทดสอบได้รับการจัดอันดับตามจำนวนข้อบกพร่องที่พบ

d ระบบการจัดการข้อบกพร่องไม่สนับสนุนคุณสมบัตินี้ของข้อบกพร่องหลายรายการ

ความเห็นของฉันaคือคำตอบที่ถูกต้อง

b- ไม่สามารถทำได้เนื่องจากการแก้ไขข้อเสนอแนะที่แก้ไขแล้วปิดควรหลีกเลี่ยงกรณีดังกล่าว c- ผิดอย่างชัดเจน

d - ปลั๊กอิน Redmine / Trac รองรับหลายฟิลด์

bคำตอบตามแผ่นคำตอบคือ

มีคนอธิบายได้ไหม ความคิดเห็นที่มีความคิดเห็นเกี่ยวกับคำตอบยินดีต้อนรับ

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

ระบบติดตามบั๊กทำเพื่อ ... ติดตามบั๊ก การติดตามข้อบกพร่องหมายถึง:

1. การสร้างเร็กคอร์ดโดยบอกว่าอาจมีข้อบกพร่องพร้อมข้อมูลเกี่ยวกับวิธีการทำให้เกิดซ้ำ

2. การยืนยันว่าข้อผิดพลาดมีอยู่จริงและเป็นข้อผิดพลาดไม่ใช่บางอย่างจากการออกแบบ

3. ยืนยันว่าข้อผิดพลาดได้รับการแก้ไขแล้ว

4. ยืนยันว่าข้อผิดพลาดได้รับการแก้ไข

ในรูปแบบที่ง่ายมากลูกค้า 1 และ 4 จะทำโดยลูกค้าและ 2 และ 3 - โดยนักพัฒนา

ลองนึกภาพบันทึกต่อไปนี้:

• วันที่ 1 [ลูกค้า] เมื่อกดปุ่ม "นำออก" ในหน้าต่าง "รายละเอียดผลิตภัณฑ์" แอปพลิเคชันจะหยุดทำงาน การรีสตาร์ทแอปพลิเคชันแสดงว่าผลิตภัณฑ์ไม่ได้ถูกลบออก พฤติกรรมที่คาดหวังคือการลบผลิตภัณฑ์

• วันที่ 4 [นักพัฒนาซอฟต์แวร์] <ออกฉบับใหม่>

• วันที่ 5 [ผู้พัฒนา] <ปัญหาได้รับการแก้ไขในรุ่น 5031>

• วันที่ 12 [ลูกค้า] <ตั๋วปิด: แก้ไขปัญหา>

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

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

เป็นเรื่องง่ายที่จะกำหนดตั๋วใหม่หรือกำหนดเดิมว่าเป็นบุคคลที่ควรรับผิดชอบข้อบกพร่อง

ตอนนี้จินตนาการถึงบันทึกต่อไปนี้:

• วันที่ 1 [ลูกค้า] แอพหยุดทำงานเมื่อฉันกดปุ่ม "ลบ" ในหน้าต่าง "รายละเอียดผลิตภัณฑ์" นอกจากนี้สีพื้นหลังของแผงด้านซ้ายเป็นสีน้ำเงินเข้มในขณะที่ควรเป็นสีม่วง ฉันยังตั้งข้อสังเกตว่าข้อความของหน้าต่าง“ รายละเอียดผลิตภัณฑ์” นั้นไม่ได้แปลเป็นภาษาเยอรมันได้ดี คาดหวังไหม จะมีการแปลขั้นสุดท้ายเมื่อใด BTW คุณได้รับไอคอนใหม่ที่ฉันส่งสำหรับการดำเนินการ“ เผยแพร่ผลิตภัณฑ์” หรือไม่ ฉันไม่เห็นมันในหน้าต่าง“ ซิงค์ข้อมูล”

• วันที่ 6 [ผู้พัฒนา] ฉันเปลี่ยนสีเป็นสีม่วง

• วันที่ 7 [ผู้พัฒนา] ใช่มันเป็นเรื่องปกติที่การแปลภาษาเยอรมันไม่สมบูรณ์

• วันที่ 8 [ลูกค้า] ตกลงสำหรับภาษาเยอรมัน แล้วอิตาลีล่ะ Lucia ส่งไฟล์ XML ให้คุณเมื่อสองวันก่อน

• วันที่ 9 [ผู้พัฒนา] ไม่เป็นไรตอนนี้

• วันที่ 10 [ลูกค้า] ตกลงสำหรับปุ่ม "ลบ" หรือไม่ แปลกที่คอมพิวเตอร์ของฉันมันยังคงแขวนอยู่

• วันที่ 11 [ผู้พัฒนา] ไม่ฉันอยากจะบอกว่ามันใช้ได้สำหรับการแปลภาษาอิตาลี

• วันที่ 12 [ลูกค้า] ฉันเห็น ขอขอบคุณ. แต่มีปัญหากับสี คุณเปลี่ยนเป็นสีม่วงเข้ม แต่ควรเป็นสีม่วงอ่อนเช่นแผงด้านบนของหน้าต่างหลัก

• วันที่ 13 [นักพัฒนาซอฟต์แวร์] ฉันอัปเดตไอคอน

• วันที่ 14 [ลูกค้า] ไอคอน? ไอคอนอะไร

• วันที่ 15 [นักพัฒนาซอฟต์แวร์] ไอคอนที่คุณขอให้ฉันอัปเดต

• วันที่ 16 [ลูกค้า] ฉันไม่เคยขอให้คุณอัปเดตไอคอนใด ๆ

• วันที่ 17 [ผู้พัฒนา] แน่นอนคุณถาม ดูตั๋วนี้ คุณเขียนว่าควรเผยแพร่อัปเดตไอคอนผลิตภัณฑ์ ฉันได้ทำมัน.

  ⁞

• วันที่ 100 [ลูกค้า] แล้วรายการในบันทึกล่ะ

• วันที่ 101 [ผู้พัฒนา] ฉันไม่รู้ว่าคุณกำลังพูดถึงอะไร มันไม่ใช่แม้กระทั่งในตั๋วนี้ แต่ใน 6199 ฉันปิดรายการนี้ตามที่แก้ไขแล้ว <ปิดตั๋วแล้ว: แก้ไขปัญหา>

• วันที่ 102 [ลูกค้า] ขออภัยที่จะเปิดใหม่ แต่ปัญหาไม่ได้รับการแก้ไข ฉันกำลังพูดถึงรายการในบันทึก: ฉันบอกคุณเมื่อสัปดาห์ที่แล้วว่าบางครั้งข้อความไม่ถูกต้องเมื่อมันมีอักขระ Unicode คุณจำได้ไหม? <เปิดตั๋วอีกครั้ง>

• วันที่ 103 [นักพัฒนาซอฟต์แวร์] ฉันจำอะไรทำนองนั้นได้ แต่หลังจากค้นหาสามหน้าสุดท้ายของตั๋วนี้ฉันไม่พบร่องรอยใด ๆ คุณช่วยเขียนปัญหาอีกครั้งได้ไหม

  ⁞

• วันที่ 460 [นักพัฒนาซอฟต์แวร์] ฉันใช้เวลาสองชั่วโมงในการค้นหาสิ่งที่คุณพูดเกี่ยวกับไฟล์ที่ส่งเข้ารหัสผ่านเครือข่าย ฉันไม่แน่ใจว่าฉันสามารถค้นหาคำขอที่แน่นอนได้หรือไม่

• วันที่ 460 [ลูกค้า] พวกคุณควรมีระเบียบมากขึ้น ฉันแจ้งให้คุณทราบเกี่ยวกับปัญหานี้สี่ครั้งในสองสัปดาห์ที่ผ่าน ทำไมคุณลืมทุกอย่าง

  ⁞

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

หมายเหตุ: คุณอาจเชื่อว่าไม่มีการบันทึกดังกล่าว เชื่อฉันฉันเห็นคนมากกว่าหนึ่งครั้ง

เพียงแสดงความคิดเห็นในคำสั่งของคุณ:

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

นี่ถือว่าข้อบกพร่องทั้งหมดที่เกิดขึ้นจะได้รับการแก้ไขในเวลาเดียวกัน ลองนึกภาพสถานการณ์ที่มีการยกระดับตั๋วกับผลิตภัณฑ์หนึ่งใน v1 ที่มีสองประเด็น:

1. ปุ่มรีเซ็ตฟอร์มส่งฟอร์มจริงแทนที่จะล้างค่า
2. ขนาดตัวอักษรของปุ่มคือ 110% เมื่อควรเป็น 115%

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

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

ขอบเขต:

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

ในทางตรงกันข้ามมันเป็นเรื่องธรรมดาสำหรับ GUI ตั๋วบกพร่องที่มีข้อกำหนดหลายอย่างเพราะตั๋ว GUI แต่ละใบนั้นมีประสิทธิภาพ "การออกแบบใหม่" (ข้อบกพร่องการออกแบบ), "ข้อกำหนดที่แก้ไขแล้ว" หรือ "คำขอคุณลักษณะ" (ฟังก์ชั่นขาดหายไป)

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

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

จุดประสงค์ของระบบติดตามข้อบกพร่องของรหัสคือ:

• เพื่อเปิดใช้งานการติดตามข้อบกพร่องที่ทำซ้ำได้อย่างอิสระและไม่คลุมเครือและ
• เพื่อให้การประมาณที่ดีที่สุด (การติดต่อแบบหนึ่งต่อหนึ่ง) กับสาเหตุของข้อบกพร่องแต่ละอย่าง

ในขณะที่ทำเช่นนั้นควรเพิ่มคุณสมบัติที่พึงประสงค์ต่อไปนี้:

• ปรับขนาดอย่างมีประสิทธิภาพเมื่อจำนวนข้อบกพร่องเพิ่มขึ้นเมื่อเวลาผ่านไป
• ป้องกันกลุ่มอาการของการเคลื่อนไหวเป้าหมาย

คำเตือน: การใช้ถ้อยคำใหม่นี้มาจากประสบการณ์ส่วนตัวของฉัน อาจไม่เพียงพอหรือไม่ถูกต้องสำหรับการสอบเพื่อขอใบรับรอง

การติดตามอย่างอิสระและไม่คลุมเครือหมายความว่า:

1. ข้อบกพร่องที่ถูกต้องแต่ละข้อสามารถแก้ไขได้หรือไม่สามารถแก้ไขได้โดยไม่มีความกำกวม

   • เหตุผลที่ 1: เพื่อให้การจัดการง่ายขึ้น
     • ตัวอย่าง: ช่วยให้การใช้ "จำนวนตั๋วที่ไม่ได้แก้ไข" เป็นตัวชี้วัด
   • เหตุผลที่ 2: แปลเป็นรายการที่ดำเนินการได้
     • ตัวอย่าง: หากยังไม่ได้รับการแก้ไขความรับผิดชอบจะอยู่ที่โปรแกรมเมอร์ที่ได้รับมอบหมาย หากได้รับการแก้ไข แต่ไม่ปิดความรับผิดชอบจะอยู่ที่ผู้ทดสอบที่ได้รับมอบหมาย (ตัวตรวจสอบ)
   • ผลที่ตามมา: ในวิธีการนี้ข้อบกพร่องที่ได้รับการแก้ไขบางส่วนสมควรที่จะได้รับการแบ่งย่อยออกเป็นข้อบกพร่องหลายประการ

2. ควรติดตามข้อบกพร่องที่ทำซ้ำได้อย่างอิสระ

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

ดูจากมุมมองของคนอื่นที่ใช้ระบบปรากฏขึ้นไม่กี่เดือนต่อมา พวกเขาพบข้อบกพร่องในโปรแกรม พวกเขาอยู่ที่ Google และเห็นว่ามีตั๋วสนับสนุนที่ตรงกับปัญหาที่พวกเขามี และเฮ้มันปิดแล้ว! ! น่ากลัว มันได้รับการแก้ไขในเวอร์ชั่นล่าสุด! ดังนั้นพวกเขาอัปเดต ... และข้อผิดพลาดยังคงอยู่หรือไม่ เกิดอะไรขึ้นกับนักพัฒนาที่โง่เหล่านี้?!?

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

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