นักพัฒนาควรมีส่วนร่วมในการทดสอบขั้นตอนหรือไม่

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

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

ขอบคุณสำหรับการแบ่งปันความคิดของคุณ

(*) สำหรับเหตุผลที่คลุมเครือการเพิ่มจำนวนผู้ทดสอบไม่ใช่ตัวเลือก ณ วันนี้

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

มองคำถามของคุณอย่างแท้จริง ("เกี่ยวข้องกับ") คำตอบเดียวของฉันคือชัดเจนแน่นอน

ใช่

ผู้พัฒนาไม่ควรพูดขั้นสุดท้ายด้วยรหัสของตนเอง

แต่ Devs ควรมีส่วนร่วมในการทดสอบการทำงานของ devs อื่น ๆ มันทำสองสิ่ง:

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

ในที่สุดทำไมคุณไม่ใช้ดวงตาให้มากที่สุด? คุณแทบจะไม่สามารถผ่านขั้นตอนการจ้างงานและการขึ้นเครื่องบินเพื่อนำคน QA เพิ่มเติมมาบนเครื่องบินในเวลาวิกฤติ ดังนั้นคุณจะพบดวงตาที่ต้องการได้ที่ไหน หรือคุณพยายามที่จะผ่านช่วงเวลาวิกฤติด้วยหมายเลข QA ที่คุณมีมาตลอด? แม้ว่า devs ใช้เวลา 20% ในการทดสอบเวลาของพวกเขาและ 80% แก้ไขข้อผิดพลาดใด ๆ ที่เกิดขึ้น การทดสอบอัตโนมัติจะให้ความมั่นใจในระดับหนึ่งเท่านั้นและจะไม่เป็น 100%

http://haacked.com/archive/2010/12/20/not-really-interested-in-lean.aspx?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+haacked+%28you%27ve+been+HAACKED%29

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

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

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

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

ในแง่ของการทดสอบมี 3 ประเภท

กล่องดำกล่องสีเทาและกล่องสีขาว

กล่องดำหมายถึงผู้ใช้ที่ทำการทดสอบผลิตภัณฑ์โดยไม่มีความรู้ว่าผลิตภัณฑ์ทำงานอย่างไรภายใน

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

นี่คือส่วนหลัก: กล่องสีขาวหมายถึงนักพัฒนาทดสอบผลิตภัณฑ์ที่ระดับรหัส นี่หมายความว่าพวกเขาทำการทดสอบหน่วยการดีบัก ... ฯลฯ

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

การทดสอบหน่วยเป็นสิ่งที่จำเป็นสำหรับนักพัฒนาทั้งหมด

สำหรับข้อมูลเกี่ยวกับวิธีการใช้สิ่งนี้เพื่อประโยชน์ของคุณอ่านลิงค์ต่อไปนี้หากคุณเข้าสู่การพัฒนา C ++:

• คำแนะนำเบื้องต้นเกี่ยวกับกรอบการทดสอบของ Google C ++
• เครื่องมือทดสอบหน่วย C / C ++ แบบโอเพ่นซอร์สตอนที่ 1: ทำความรู้จักกับกรอบการทดสอบเพิ่มหน่วย
• เครื่องมือทดสอบหน่วย C / C ++ แบบโอเพ่นซอร์สตอนที่ 3: ทำความรู้จักกับ CppTest

ไม่มีทางที่คน QA สามารถทำแบบทดสอบเหล่านี้ได้ ไม่มีทาง.

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

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

ที่คุณเขียน:

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

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