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