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

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

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

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

OBS: การแข่งขันครั้งนี้ไม่ใช่การฝึกฝนของ บริษัท ! เป็นการแข่งขันระหว่างผู้ทดสอบเท่านั้นที่จัดโดยพวกเขาและไม่มีรางวัลใด ๆ

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

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

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

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

บรรทัดล่างสุด: อย่าสร้างเกมโดยหาข้อบกพร่อง ค้นหาวิธีในองค์กรของคุณเพื่อให้รางวัลกับงานที่ดีและทิ้งไว้ Gamification ให้รางวัลแก่ผู้คนในการบรรลุเป้าหมาย คุณไม่ต้องการให้นักวิเคราะห์ QA มีเป้าหมาย "ค้นหาข้อบกพร่องมากที่สุด" คุณต้องการให้เป้าหมายของพวกเขาคือ "ปรับปรุงคุณภาพของซอฟต์แวร์" เป้าหมายทั้งสองนั้นไม่เหมือนกัน

ฉันจะไม่เห็นด้วยเล็กน้อยกับคำตอบอื่น ๆ "การค้นหาข้อบกพร่อง" สำหรับผู้ทดสอบนั้นค่อนข้างเหมือนกับ "การเขียนโค้ด" สำหรับนักพัฒนา ปริมาณดิบไม่มีความหมาย หน้าที่ของผู้ทดสอบคือการหาข้อบกพร่องที่มีอยู่ให้มากที่สุดเท่าที่จะทำได้เพื่อไม่ให้พบข้อบกพร่องมากที่สุด หากผู้ทดสอบ A พบข้อผิดพลาด 5 จาก 10 ข้อในส่วนประกอบที่มีคุณภาพสูงและตัวทดสอบ B พบข้อผิดพลาด 58 จาก 263 ข้อในส่วนประกอบที่มีคุณภาพต่ำจากนั้นผู้ทดสอบ A จะเป็นผู้ทดสอบที่ดีกว่า

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

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

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

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

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

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

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

ไม่กี่เกมจริงมีระบบการให้คะแนนที่เรียบง่าย ทำไมข้อผิดพลาดควรล่า?

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

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

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

นี้คือการขยายตัวในของ @ CandiedOrange คำตอบ

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

ในแต่ละวันที่มีการรายงานข้อผิดพลาดที่สำคัญอย่างน้อยหนึ่งรายการให้ทิ้งโทเค็น "Bug of the Day" ไว้บนโต๊ะของผู้ทดสอบ สัปดาห์ละครั้งจัดพิธีพร้อมขบวนของนักพัฒนาที่มอบโทเค็นหรือถ้วยรางวัล "Bug of the Week" ที่ใหญ่กว่าและดีกว่า ทำให้การจัดส่งของรางวัล "Bug of the Month" น่าทึ่งยิ่งกว่าเดิมด้วยเค้ก โทเค็นหรือถ้วยรางวัลแต่ละอันควรมีการอ้างว่าทำไมนักพัฒนาจึงคิดว่าเป็นสิ่งที่ดีที่พบข้อบกพร่องในการทดสอบ ควรใส่สำเนาการอ้างอิงไว้ที่ที่ผู้ทดสอบสามารถอ่านได้ทั้งหมด

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

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

เป็นสิ่งที่ดีสำหรับโครงการหรือไม่

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

ถ้าไม่ฉันจะ (ในฐานะนักพัฒนาซอฟต์แวร์) ได้อย่างไรลองเปลี่ยนความคิดและทัศนคติของทีมทดสอบ

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

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

การรายงานข้อบกพร่องเกี่ยวกับการปรับปรุงหน้าจอการใช้งานหรือข้อบกพร่องที่โง่

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

เหตุผลที่พวกเขามีการแข่งขันน่าจะสนุกในขณะทำงานดังนั้นพวกเขาอาจไม่ตั้งใจทำงานที่ไม่ดี (ถ้านี่ถือว่าแย่)