จะทำให้การทดสอบอัตโนมัติเป็นที่นิยมได้อย่างไร [ปิด]


13

ฐานรหัสของเราเติบโตขึ้นเป็นเวลา 20 ปีแล้ว เราทำงานประมาณ 10 devs + sqa กับ 500kloc เมื่อไม่นานมานี้ทีมเล็ก ๆ ของเรา (2 devs หนึ่งจาก sqa) เริ่มทำงานกับโปรแกรมทดสอบอัตโนมัติ ปัจจุบันการวิ่งหนึ่งครั้งใช้เวลา 11 ชั่วโมงและเป็นการทดสอบการรวมระบบ เรากำลังดำเนินการเพื่อแก้ไขปัญหานี้และลดผลบวกปลอมและกำลังดำเนินการต่อไป แต่รายละเอียดไม่สำคัญ

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

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


11
นี่ไม่ใช่ปัญหาวิศวกรรมซอฟต์แวร์ มันเป็นปัญหาของคน
Robert Harvey

@RobertHarvey ฉันได้ลงคะแนนใน SO เพราะ "ตามความคิดเห็น" และความคิดเห็นที่เว็บไซต์นี้จะเหมาะอย่างสมบูรณ์แบบ (และ upvotes จากความคิดเห็นนั้น) ดังนั้นฉันควรถามที่ไหน ให้ความรู้แก่ฉัน
Peter Schneider

2
ฉันอยู่กับ @RobertHarvey เกี่ยวกับปัญหานี้เป็นปัญหาของคน แต่ตามที่ทำงานคำถามของคุณอาจจะเราพิจารณาว่าเป็นคนหลอกลวง ตัวอย่างเช่นดูคำถามนี้ซึ่งเป็นพื้นฐานสิ่งที่คุณถามสถานที่ทำงานstackexchange.com/questions/44964/…
Peter M

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

1
เป็นที่น่าเสียดายที่คำถามนี้ถูกปิด หากวิศวกรรมซอฟต์แวร์หมายถึงสิ่งใดก็ตามหมายถึงปัญหาในการทำงานกับคนจริงและคำตอบของปัญหาดังกล่าวจะเกี่ยวข้องกับความคิดเห็น ดังที่กล่าวไว้ความคิดสั้น ๆ สองสามข้อ: (1) ถ้าคุณทดสอบให้ผลเชิงลบที่ผิดพลาดนี้จะเพิ่ม pushback แน่นอนเพราะผลลัพธ์จะรู้สึกเสียเวลา (2) ทำให้ runtime ลดลงถ้าเป็นไปได้ 11 ชั่วโมงไม่รู้สึกทันทีแม้ว่าจะดีกว่าสองเดือนก็ตาม (3) sqa จะใช้การทดสอบเหล่านี้เป็นตัวชี้วัดที่พวกเขาดู พวกเขารู้จักองค์กรของคุณในพื้นที่นี้แล้ว
Dale Hagglund

คำตอบ:


4

คำปฏิเสธ

แม้ว่าฉันอาจฟังดูเหมือนผู้จัดการ แต่ฉันเขียนสิ่งนี้ในฐานะนักพัฒนาซอฟต์แวร์ที่ต้องการโน้มน้าวใจว่าการทดสอบอัตโนมัตินั้นดี


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

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

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


11

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

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


5
จากนั้นอีกครั้งมันอาจเป็นอย่างอื่น ชอบความต้านทานต่อการเปลี่ยนแปลง หากการทดสอบล้มเหลวมีบางสิ่งที่ต้องแก้ไขไม่ว่าจะเป็นรหัสหรือการทดสอบดังนั้นทัศนคติที่ผู้คนจะเพิกเฉยต่อการทดสอบเพราะการทดสอบนั้นไม่สม่ำเสมอ
Robert Harvey

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

1
@PeterSchneider การทดสอบสามารถล้มเหลวได้ 100 ครั้งติดต่อกันโดยเฉพาะอย่างยิ่งหากการทดสอบผิด
Pieter B

ในทางกลับกันการทดสอบที่ไม่เคยล้มเหลวน่าจะเป็นประโยชน์อย่างมาก
Vladimir Stokic

1
+1 การทดสอบที่เปราะบางเป็นปัญหาอย่างแน่นอน นักพัฒนาจะต้องเชื่อว่าการทดสอบที่พวกเขาเขียนมีประโยชน์ไม่แนะนำภาวะแทรกซ้อนที่ไม่จำเป็นและไม่ได้ busywork
Andres F.

6

เราทำไม่ได้และไม่ต้องการบังคับอะไรบางอย่าง

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


ฉันเดาว่าขึ้นอยู่กับระบบการทดสอบขนาดและกระบวนการพัฒนา ไม่สามารถแก้ไขข้อบกพร่องทั้งหมดได้ทันทีและไม่ต้องแก้ไขปัญหาทั้งหมดทันที
NickL
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.