โปรแกรมเมอร์เป็นผู้ทดสอบที่ไม่ดีหรือไม่?

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

โจเอลซอฟแวร์ - Top Five (ผิด) เหตุผลที่คุณไม่ได้มีการทดสอบ (เหมืองเน้น)

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

และในคำถามนี้หนึ่งในคำตอบที่ได้รับความนิยมมากที่สุดบอกว่า (อีกครั้งฉันขอเน้น):

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

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

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

คำถามดูเหมือนจะถามโดยเฉพาะเกี่ยวกับการทดสอบระบบดังนั้นนั่นคือสิ่งที่ฉันหมายถึงตลอดคำตอบนี้

ฉันคิดว่ามีความแตกต่างที่สำคัญระหว่างการเป็นคนไม่ดีที่จะเลือกทำการทดสอบและจริง ๆ แล้วการทดสอบที่ไม่ดี

ทำไมโปรแกรมเมอร์ไม่ดีในการทดสอบ:

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

ทำไมโปรแกรมเมอร์ทดสอบเก่ง:

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

ทำไมโปรแกรมเมอร์จึงเป็นผู้ทดสอบที่ไม่ดี:

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

ผมคิดว่าการเขียนโปรแกรมที่ไม่ดีในการทดสอบรหัสของตัวเอง

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

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

โปรแกรมเมอร์รายหนึ่งที่มีแนวโน้มจะแย่มากในการทดสอบคือบิตทั้งหมด "ใช้ UI เหมือนผู้ใช้ปกติ" ซึ่งไม่ใช่ผู้ใช้ปกติและไม่ประพฤติเหมือนพวกเขา ตัวอย่างเช่น:

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

ดังนั้นผู้ใช้ปกติทำสิ่งต่าง ๆ โปรแกรมเมอร์ไม่ คุณไม่สามารถไว้วางใจทีม dev สำหรับ UAT ได้อย่างสมบูรณ์

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

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

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

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

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

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

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

ในคำถามการทดสอบไม่ได้หมายความว่าอะไรอัตโนมัติ แต่จริง ๆ แล้วการทดสอบโดยใช้โปรแกรม

การทดสอบมีหลายระดับ การทดสอบ "ระดับต่ำ" สามารถทำได้โดยนักพัฒนาซอฟต์แวร์ ฉันคิดว่าที่หน่วย testig

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

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

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

ฉันสามารถรับทราบว่านักพัฒนาซอฟต์แวร์ที่ออกแบบอาจมีการมองเห็นช่องทางเมื่อมันมาถึงสิ่งที่รหัสคือการจัดการและละเว้นกรณีขอบเขตที่เป็นไปได้บางอย่างที่อาจไม่ได้รับการพิจารณา ตัวอย่างเช่นถ้าฉันสร้างเว็บฟอร์มที่ใช้ตัวเลข n แล้วพิมพ์จาก 1 ถึง n บนหน้าจอฉันอาจพลาดบางกรณีพิเศษเช่นหากไม่มีการป้อนอะไรหรือสิ่งที่ไม่ใช่จำนวนธรรมชาติเช่น e หรือ pi . โปรแกรมที่ควรทำในกรณีเหล่านี้อาจเป็นสิ่งที่น่าสงสัย

Test Driven Developmentจะเป็นตัวอย่างของวิธีการพัฒนาที่ทำให้การทดสอบเป็นแสงที่แตกต่างที่อาจให้มุมมองอื่นที่นี่

โปรแกรมเมอร์คือการกำหนดการทดสอบที่ดีเมื่อพวกเขากำหนดการทดสอบก่อนที่จะเขียนรหัส ด้วยการฝึกฝนพวกเขาจะดีขึ้นกว่าเดิม

อย่างไรก็ตามเมื่อกำหนดการทดสอบสำหรับรหัสที่พวกเขาเขียนพวกเขาไม่ได้ดีนัก พวกเขาจะมีจุดบอดเดียวกันในการทดสอบว่าพวกเขามีการเขียนรหัส

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

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

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

ดังนั้นผู้พัฒนารายอื่นที่ทำแบบทดสอบก็มักจะทำข้อสันนิษฐานเดียวกันหลายข้อเพราะพวกเขาก็จะทำการตั้งสมมติฐานบางอย่างเช่น "พวกเขาจะมีรายละเอียดมากขึ้นถ้าพวกเขาหมายถึง X Vice Y เพราะมีรายละเอียดมากมายที่จะตอบก่อน แต่ผู้เขียนข้อกำหนดไม่ได้คิดอย่างนั้นดังนั้นคนที่คิดเหมือนนักเขียนข้อกำหนดจะต้องทดสอบสมมติฐานของนักพัฒนาและคนที่ไม่ใช่นักพัฒนาเป็นคนที่ดีกว่าที่จะเห็นว่ามีปัญหา