ฉันควรขอการทดสอบหน่วยจากโปรแกรมเมอร์หรือไม่ [ปิด]

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

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

ฉันอยู่ที่นี่ทั้งหมดหรือไม่

กรุณาให้ข้อโต้แย้งสำหรับความคิดเห็นใด ๆ ของฉัน

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

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

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

โดยส่วนตัวฉันคิดว่าในกรณีของคุณคุณควรคิดในแง่ของการทดสอบการยอมรับแทน

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

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

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

มันทำให้ฉันประหลาดใจว่าความคิดนี้เป็นเรื่องธรรมดา อัตโนมัติใช่ การทดสอบหน่วย (คนเดียว) หมายเลข มีวิธีการทดสอบซอฟต์แวร์อัตโนมัติมากกว่าการทดสอบหน่วยเพียงอย่างเดียว สิ่งที่เกี่ยวกับการรวมระบบการทำงาน QA? ด้วยเหตุผลบางอย่างที่คนมักจะคิดว่า"โอเคเรามีการทดสอบหน่วยที่เหมาะสมทำการทดสอบเสร็จแล้วเรียกมันว่าเย็นวันศุกร์!" . การทดสอบหน่วยเป็นเพียงจุดเริ่มต้น

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

ในงานแรกของฉันฉันเคยทำงานในสถานที่ที่เรามีการทดสอบหน่วย 0 (เราหลายคนรุ่นน้องโยนสิ่งที่ร้ายแรงมากขึ้นหรือน้อยลง) เชื่อหรือไม่ว่ามันใช้ได้ แน่นอนไม่มีใครมั่นใจว่าทำไมข้อผิดพลาดนี้ถึงได้รับการแก้ไขหรือสิ่งที่การแก้ไขนี้แตก แต่ทำงานได้ มีหลายครั้งที่บั๊กแบบสุ่มบางอันจะโผล่ออกมาไม้เบสบอลและความเสี่ยงในการเผาอพาร์ทเม้นท์บางชั่วโมงพิเศษสามารถทำงานได้อย่างมหัศจรรย์ ซัพพลายเออร์ของคุณอาจใช้เทคนิคที่คล้ายกัน?

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

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

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

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

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

คุณจ่ายเงินคุณสามารถเรียกร้องสิ่งที่คุณต้องการรวมถึงสำเนา / รายงานการทดสอบหน่วยของพวกเขาทั้งหมด

คุณสามารถเขียนการทดสอบหรืออย่างน้อยก็คุณสมบัติการทดสอบเอง

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

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

อย่างไรก็ตามสิ่งที่เรียกร้องจะไม่บรรลุผลตามที่คุณต้องการตามที่ผู้อื่นมีรายละเอียด

ความท้าทายของคุณคือการอธิบายและชักชวนผู้คน - ทักษะที่ยากยิ่งขึ้น!

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

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

การบังคับให้ทดสอบอัตโนมัติกับใครบางคนจะไม่บรรลุผลตามที่คุณต้องการตามที่ @Joachim Sauer และ @Telastyn ชี้ให้เห็นในความคิดเห็นของพวกเขา สำหรับคนจำนวนมากการทดสอบหน่วยอัตโนมัติเป็นการเปลี่ยนแปลงครั้งใหญ่ในความคิดของพวกเขา เพราะผู้คนจำนวนมากเขียนโค้ดที่ใช้งานได้ แต่ไม่สามารถทดสอบได้มากนัก ฉันสามารถเขียนเว็บเพจ ASP.NET ที่มีตรรกะทั้งหมด, การสืบค้นฐานข้อมูล, กฎเกณฑ์ทางธุรกิจ, วัตถุ, ฯลฯ อยู่ในโค้ดด้านหลัง หน้านี้จะใช้งานได้? ใช่. มันสามารถทดสอบได้โดยใช้การทดสอบหน่วยอัตโนมัติ? ไม่ได้อย่างแน่นอน. หากซัพพลายเออร์ไม่มีการทดสอบหน่วยอัตโนมัติมันจะใช้ความพยายามอย่างมากในการเรียนรู้วิธีการเขียนการทดสอบหน่วยอย่างถูกต้องและจากการเรียนรู้สิ่งนี้ให้เขียนใหม่หรือใส่รหัสของพวกเขาอีกครั้งเพื่อให้สามารถทดสอบได้ง่ายขึ้น โอกาสที่พวกเขาจะผ่านค่าใช้จ่ายที่คุณ

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

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

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

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

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

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

ฉันพบบทความนี้เกี่ยวกับการซื้อซอฟต์แวร์ที่กำหนดเองมีประโยชน์มาก: http://blog.8thlight.com/paul-pagel/2012/06/20/ent Entrepreneurs-guide-to- buying-software.html

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

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

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

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

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

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

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

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

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

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

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

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

ให้ลำดับความสำคัญตรงก่อน ...

ในบทบาทของคุณในฐานะลูกค้าข้อกังวลหลักของคุณไม่ใช่การทดสอบหน่วย

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

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

• จำนวนหน่วยทดสอบที่ยอมรับได้คือเท่าใด

ควรมีการทดสอบ 10 ข้อ? วิธีการประมาณ 100 การทดสอบ? มีการทดสอบประมาณ 1,000 ครั้ง ที่จริงแล้วมันค่อนข้างยากที่จะกำหนดในการเริ่มต้นจำนวนการทดสอบที่คุณจะต้อง จำนวนจริงไม่สามารถกำหนดได้จริง ๆ ... เช่นปัญหาการหยุด ... แต่เราไม่ได้แก้ปัญหานั้น

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

• ระดับการครอบคลุมโค้ดที่ยอมรับได้คืออะไร

"100% แน่นอน!" คุณคิด น่าเสียดายที่เมตริกนั้นทำให้เข้าใจผิด แม้ว่าคุณจะมีรหัสครอบคลุม 100% คุณแน่ใจหรือไม่ว่าสิ่งต่าง ๆ ได้ผลตามที่คาดหวัง เป็นไปได้ที่จะได้รับความคุ้มครอง 100% แต่ไม่สามารถทำได้

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

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

คุณต้องการให้ซอฟต์แวร์ที่ส่งมอบทำงานและเอกสารข้อกำหนดการรับประกันของคุณเป็นเพียงการรับประกันเท่านั้น

คุณจะต้องทดสอบในระดับที่สูงขึ้น

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

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

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

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

เป็นเรื่องน่าเศร้าที่ซอฟต์แวร์โอเพ่นซอร์สระดับสูงมาพร้อมกับการทดสอบหน่วย แต่ผู้พัฒนาซอฟต์แวร์มืออาชีพทำไม่ได้ใช่ไหม

ดังนั้นเมื่อฉันในฐานะลูกค้าจะได้รับการดูแลเกี่ยวกับการทดสอบหน่วย?

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

คุณจะรู้ได้อย่างไรว่าผู้ขายไม่ได้เขียนการทดสอบหน่วย

อาจมีการจัดการและผู้จัดจำหน่ายที่มีการประชุมและผู้ขายกล่าวว่ารหัสค่าใช้จ่าย $ X และการทดสอบหน่วยค่าใช้จ่าย $ Y การจัดการการจับเศษสตางค์บอกว่าเราแค่ต้องการรหัส

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

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

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

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