ออกจากข้อบกพร่องโดยเจตนาในรหัสสำหรับทดสอบเพื่อค้นหา

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

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

นี่คือวิธีที่มันจะไป พวกเขาบอกว่าวิธีนี้มีข้อดีดังต่อไปนี้

1. ผู้ทดสอบจะอยู่บนนิ้วเท้าของพวกเขาเสมอและพวกเขาจะทดสอบอย่างบ้าคลั่ง ที่ช่วยให้พวกเขาพบข้อบกพร่องที่ซ่อนอยู่ (โดยไม่ได้ตั้งใจ) เพื่อให้นักพัฒนาสามารถแก้ไขได้
2. ผู้ทดสอบกินแมลง การไม่พบข้อบกพร่องใด ๆ จะส่งผลกระทบต่อขวัญและกำลังใจของพวกเขา ดังนั้นการหาคนง่าย ๆ จะช่วยให้กำลังใจพวกเขา

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

คำอธิบายบางอย่าง:

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

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

• QA นั้นจะไม่ทำงานหนักจนกว่าพวกเขาจะรู้ว่าพวกเขากำลังถูกทดสอบทุกวัน (ซึ่งไม่ดีสำหรับขวัญกำลังใจ)

• มีข้อบกพร่องในซอฟต์แวร์ที่นำมาใช้เพื่อค้นหา QA ไม่เพียงพอ

• งานของ QA นั้นคือการหาข้อบกพร่อง - ไม่ใช่; เพื่อให้มั่นใจว่าซอฟต์แวร์มีคุณภาพการผลิต

• ว่าการต่อสู้แบบฉลาดระหว่างการพัฒนากับ QA นั้นดีต่อ บริษัท - ไม่ใช่; พนักงานทุกคนควรทำงานร่วมกันกับคู่แข่งของ บริษัท แทนกัน

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

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

ดีขึ้นอยู่กับสิ่งที่ฉันได้เรียนรู้:

1. มันไม่ใช่โรงเรียนหรือการสัมภาษณ์งาน
2. ผู้ทดสอบไม่ใช่เด็ก
3. มันไม่ใช่เกม
4. มันเสียเงินของ บริษัท

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

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

TL; DR

ไม่เพียง แต่เป็นข้อบกพร่องผู้ทดสอบควรเติบโตจากมุมมองที่แคบนี้

ความคิดที่ไม่ดี

จากมุมมองของผู้ทดสอบ: "ดังนั้นพวกเขาจะทดสอบอย่างหนักเพราะพวกเขารู้ว่ามีข้อบกพร่องอยู่และไม่พบว่าพวกเขาอาจถูกมองว่าไร้ความสามารถ" โดยพื้นฐานแล้ว devs นั้นเป็นโค้ดที่ดักจับไม่ได้ มีคนไม่กี่คนที่ชอบทำงานที่ไร้จุดหมายในที่สุด (เพราะเป็นที่รู้จักกันในชื่อแมลงล่วงหน้า) แต่ยังคงส่งผลกระทบต่อวิธีการรับรู้ของพวกเขา หากมีการลงโทษที่จับต้องไม่ได้ในการค้นหากับดักบูบี และคุณรู้หรือไม่ว่าผู้ทดสอบประสบความสำเร็จในการค้นหาข้อบกพร่อง? นั่นฟังดูเป็นพิษต่อสิ่งแวดล้อม การประกันคุณภาพควรมีความสุขถ้ารหัสที่พวกเขาตรวจสอบมีคุณภาพสูง แม้ว่าพวกเขาจะได้รับเงินจากข้อผิดพลาด ... http://thedailywtf.com/articles/The-Defect-Black-Market

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

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

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

1. จากคำสั่งแรกคุณไม่เคยทดสอบรหัสการผลิตจริงของคุณในการส่งผ่านสองครั้งนี้

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

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

แก้ไข

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

สิ้นสุดการแก้ไข

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

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

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

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

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

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

สุจริตฉันจะเรียกพฤติกรรมนี้อย่างผิดจรรยาบรรณและโจ่งแจ้ง PM กำลังต้องการการฝึกอบรมที่จริงจังบางอย่างหากไม่มีการยกเลิก

• มันแสดงให้เห็นการขาดพื้นฐานของความเข้าใจในแนวคิดของการประกันคุณภาพ ผู้ทดสอบไม่ควรคิดเหมือนนักพัฒนา: พวกเขาควรคิดเหมือนผู้ใช้ เหตุผลทั้งหมดในการมีทีมงาน QA คือนักพัฒนาซอฟต์แวร์นั้นใกล้เคียงกับรหัสมากเกินไป QA ควรรักษาระยะห่างจากโค้ดให้เพียงพอเพื่อให้สามารถติดตามสิ่งที่ devs พลาด
• มันเสียความพยายามควบคุมคุณภาพ สมมติว่าข้อบกพร่องเหล่านี้ไม่สำคัญ - ดูด้านล่างเมื่อพวกเขา - หมายถึงว่า QA ใช้เวลาและทรัพยากรในการตรวจสอบสิ่งที่เป็นที่รู้จักแล้วเมื่อพวกเขาสามารถใช้ความพยายามเพื่อค้นหาสิ่งที่ไม่เป็นที่รู้จัก
• มันเสียความพยายามของนักพัฒนา เพื่อให้ผู้ควบคุมคุณภาพสามารถดักจับข้อบกพร่องที่ไม่สำคัญเหล่านี้ได้ผู้พัฒนาจะต้องเขียนมันก่อน สิ่งนี้ต้องใช้ความพยายามเพิ่มเติมใช้เวลาไม่เพียง แต่การเข้ารหัสข้อบกพร่อง แต่ยังพิจารณาถึงข้อกำหนดและการออกแบบซอฟต์แวร์
• มันทำให้การผลิตที่มีความเสี่ยงที่ไม่มีความจำเป็น มันเป็นเพียงเรื่องของเวลาก่อนที่การเปลี่ยนแปลงจะไม่ถูกรวมเข้าด้วยกันอย่างถูกต้อง
• ถ้ามันไม่ได้ทำข้างต้นแล้วมันจะไม่มีจุดหมาย หากข้อบกพร่องที่รู้จักทั้งหมดเป็นเรื่องเล็กน้อยพวกเขาจะไม่จับคนงานที่ต่ำกว่ามาตรฐานพวกเขาจะจับคนที่ไม่ได้ทำงานเลย มีวิธีที่ดีกว่าในการทำเช่นนั้น
• มันยาพิษสภาพแวดล้อมการทำงาน ผู้ทดสอบ QA ของคุณเป็นมืออาชีพ พวกเขาควรได้รับความไว้วางใจให้เป็นมืออาชีพจนกว่าจะมีเหตุผลจริงที่ต้องสงสัยอย่างอื่น เมื่อมีเป็นเหตุผลที่จะสงสัยมิฉะนั้นควรจะมีการตรวจสอบที่เหมาะสมแทนเหล่านี้เกมใจ อะไรก็ตามที่ฆ่าขวัญกำลังใจ

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

โดยส่วนตัวแล้วฉันรู้สึกไม่สบายใจกับวิธีนี้

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

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

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

ดังนั้นโดยรวมแล้วไม่มั่นใจ

ในทางกลับกันเรามักจะให้ลูกค้าตรวจสอบการทำงานของทีมงาน QA ซึ่งอาจไม่เหมาะ มันเป็นห่วงข้อเสนอแนะที่มีประสิทธิภาพมากแม้ว่า

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

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

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

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

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

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

ความคิดที่ไม่ดี

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

การคิดแบบนี้รวมกับ QEs เป็นผู้ทดสอบด้วยตนเองเท่านั้นและไม่ได้รับแรงจูงใจให้เข้าใจรหัสจริงภายใต้การทดสอบ

ฉันเป็น QE อาวุโสและนี่เป็นปัญหาที่คุ้นเคยในองค์กรส่วนใหญ่ที่ฉันเคยทำงานมา

ฉันจะพูดความคิดที่ไม่ดี

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

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

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

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

ฉันไม่คิดว่านี่เป็นความคิดที่เลว มีหลายสิ่งหลายอย่างที่ฉันจะคาดเดาการทำงานที่ดีขึ้น:

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

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

เป็นการยากที่จะบอกว่า QA นั้น "ดีพอ" มันง่ายกว่าและดีกว่าในระยะยาวเพื่อหาวิธีที่ QA จะ "ดีขึ้นเรื่อย ๆ "

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

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

มันเรียกว่าการทดสอบการกลายพันธุ์ แนวคิดคือการใช้ซอฟต์แวร์เพื่อสร้างการเปลี่ยนแปลงเล็กน้อยในซอร์สโค้ดโดยอัตโนมัติ (เรียกว่าการกลายพันธุ์) การเปลี่ยนแปลงถูกออกแบบมาเพื่อสร้างพฤติกรรมที่แตกต่างเช่นเราสามารถเปลี่ยนแปลงได้

if x < 10:
    print "X is small!"

เข้าไป

# we flipped the inequality operator
if x > 10:
    print "X is small!"

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

ฉันชอบความคิด นายพลแพตตันพูดว่า "ยิ่งเหงื่อออกมากในความสงบคุณก็ยิ่งตกอยู่ในภาวะสงคราม"

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

การค้นหาข้อผิดพลาดที่ไม่ได้ตั้งใจจะช่วยให้คุณเศร้าโศกมากขึ้นในระยะยาวซึ่งค่าใช้จ่ายในการจัดการกับข้อผิดพลาดโดยเจตนา

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

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

ผลบวก - ทีม QA ทำงานหนักเพื่อค้นหาข้อบกพร่อง ใครจะรู้บางทีพวกเขาอาจเห็นว่านี่เป็นความท้าทาย มันเป็นเกมกระชับมิตร หรือพวกเขากำลังทำเพราะพวกเขากำลังดู (Hawthorne Effect?)

ผลลัพธ์เชิงลบ - พวกเขาอาจไม่ทำงานหนักขึ้นและพบข้อบกพร่องอยู่ดี QA เห็นว่าสิ่งนี้เป็นเรื่องเล็กน้อยและเป็นปรปักษ์ ดังนั้นตอนนี้พวกเขาไปสู่การค้นหาไฮเปอร์บั๊กและส่งคืนปัญหาเล็ก ๆ น้อย ๆ ที่จู้จี้จุกจิกทุกประเภท แบบอักษรนั้นแสดงผลไม่ถูกต้องเมื่อฉันถ่ายภาพหน้าจอและแปลงเป็น PDF แล้วดูที่ 500%

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

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

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

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

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

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

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

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

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

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

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

ยัง - ความรู้คือพลังและไม่มีเทคนิคนี้คุณมีความคิดน้อยของคุณภาพของฐานรหัสของคุณ หากคุณสามารถใช้มันด้วยความเคารพและด้วยเหตุผลที่ถูกต้องฉันจะพูดว่า "ทำไมไม่"

สิ่งหนึ่งที่ไม่มีใครได้กล่าวถึงเลย: การทดสอบการกลายพันธุ์

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

หากการทดสอบทั้งหมดผ่านไปมีความเป็นไปได้สองอย่าง:

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

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

ฉันขอแนะนำว่าการทดสอบการกลายพันธุ์อัตโนมัติเป็นวิธีที่ไกลกว่าดีกว่าสถานการณ์แบบแมนนวลที่คุณกำลังพูดถึง

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

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

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

คุณสามารถทำลายรหัสการผลิตโดยเจตนาเพื่อตรวจสอบว่าการทดสอบยังคงทำงานอยู่หรือไม่

มีหลายระดับที่เป็นไปได้:

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

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

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

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

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

แนวคิดของการจงใจฉีดผิดพลาดในรหัสการผลิตที่เรียกว่าการก่อวินาศกรรม , ความผิดฉีดเรียกว่าก่อวินาศกรรม

ผู้ทดสอบที่ไม่ใช้โค้ดเพื่อทดสอบโดยตรงจากแหล่งเก็บข้อมูลกำลังทำสิ่งที่ผิด (1)

นักพัฒนาที่กำลังตรวจสอบรหัสที่รู้จักผิดในที่เก็บข้อมูลกำลังทำผิดพลาด (2)

ดังนั้นในขั้นตอนนี้จึงไม่มีวิธีใดที่โครงการนี้จะทำงานได้หากไม่มีฝ่ายใดฝ่ายหนึ่งหรือทั้งสองฝ่ายละเมิดสถานที่ขั้นพื้นฐานมากว่าการพัฒนาและทดสอบควรทำอย่างไร

(1) เนื่องจากคุณต้องจัดทำเอกสารเวอร์ชันที่คุณทดสอบ เวอร์ชันที่ติดแท็กโดยแฮช Git หรือหมายเลขการแก้ไข SVN เป็นสิ่งที่คุณสามารถทดสอบได้ "รหัสโจให้ฉัน" ไม่ใช่

(2) เพราะคุณทำไม่ได้นอกไดรเวอร์ทดสอบที่ต้องการความล้มเหลว

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

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

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

หากพวกเขาพบข้อบกพร่องกรณีขอบไม่ทำงานมากกว่าที่คุณเขียนลงแน่นอนว่าไม่ใช่ QA ของคุณที่ต้องมีการควบคุมดูแล ... ;-)