การทดสอบซอฟต์แวร์ทำจริงในโครงการมืออาชีพหรือไม่?

ฉันมีส่วนเกี่ยวข้องกับหลายโครงการในหลาย บริษัท เพราะฉันเป็นนักพัฒนามานานและฉันเป็นผู้รับเหมา

ฉันประเมินว่าโครงการน้อยกว่า 20%ได้รับการทดสอบอย่างมีระบบ ด้วยการทดสอบอย่างมีระบบฉันหมายถึงการทดสอบใด ๆ ที่เหนือกว่าแบบเฉพาะกิจไม่มีการทดสอบแผน

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

คำถามสองข้อ

1. คุณมีค่าประมาณเปอร์เซ็นต์เกี่ยวกับปัญหานี้หรือไม่?
2. ประสบการณ์วิชาชีพของคุณเกี่ยวกับการทดสอบซอฟต์แวร์คืออะไร

หมายเหตุเพิ่มเติม

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

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

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

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

บริษัท สามแห่งที่ฉันทำงานมาในช่วง 15 ปีที่ผ่านมาทุกคนมีการทดสอบหน่วยซึ่งทำงานโดยอัตโนมัติ

ที่สอง บริษัท เหล่านั้นฉันผลักดันเพื่อแนะนำพวกเขา

ในช่วง 9 ปีที่ผ่านมาฉันพบกับการทดสอบการยอมรับและการถดถอยเท่านั้น มีเพียงไม่กี่บททดสอบ

ใช่.

จำนวนของการทดสอบนั้นขึ้นอยู่กับความน่าเชื่อถือของแอพและสัดส่วนของวัฒนธรรมโปรแกรมเมอร์

เว็บไซต์มักจะเดินบั๊กรูท (ลิงก์ที่ใช้งานไม่ได้มีข้อบกพร่อง)

วิดีโอเกมมักจะบั๊กกี้

Windows (ในที่สุด) มีความน่าเชื่อถือพอสมควร

เราเตอร์มีความน่าเชื่อถือมาก

โรงพยาบาลตรวจสอบ "ไม่ทำลาย"

โปรดทราบว่าต้นทุนทางการเงินของความล้มเหลวนั้นสัมพันธ์กับความน่าเชื่อถือ

ใน 10 ปีฉันไม่เคยทำงานในโครงการที่มีการทดสอบรหัสอย่างเป็นทางการ

ในงานปัจจุบันของฉันเรามีการทดสอบการทำงานเท่านั้น

ปัญหาคือไม่มีใครในการจัดการได้รู้เกี่ยวกับการทดสอบรหัส แผนกทดสอบไม่รู้ด้วยซ้ำเกี่ยวกับการทดสอบโค้ดพวกเขาเพียงทำตามข้อกำหนดระดับสูงและตรวจสอบว่าเราปฏิบัติตามมุมมองพฤติกรรม / การทำงานหรือไม่

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

เราเป็น บริษัท นอกชายฝั่งขนาดกลางในเอเชียใต้ อย่างไรก็ตามเรามักจะทำโครงการในสหรัฐอเมริกาและทำงานโดยตรงกับข้อกำหนดที่ส่งมาจาก บริษัท ในสหรัฐอเมริกา

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

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

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

ตัวอย่างของฉันเล็กมากที่จะอนุมานเปอร์เซ็นต์จากที่นี่ แต่ไปเลย

หนึ่งคือ บริษัท fabless chip + เฟิร์มแวร์ซึ่งทำการทดสอบแบบคลั่ง การทดสอบแบบ 24/7 โดยอัตโนมัติในการติดตั้งหลายสิบการทดสอบแต่ละสิบหน่วยในแบบคู่ขนาน ทีมซอฟต์แวร์ที่อุทิศตนเพื่อการพัฒนาซอฟต์แวร์ทดสอบ ทีมฮาร์ดแวร์ที่ทุ่มเทให้กับการสร้างแท่นทดสอบ การทดสอบความเข้ากันได้กับคู่แข่งนับสิบ Heck พวกเขาซื้อการติดตั้งเครื่องทดสอบชิปมูลค่าหลายล้านดอลลาร์เพื่อพัฒนาและตรวจแก้จุดบกพร่องการทดสอบบางอย่างที่ fabs ทำงานเมื่อชิปออกจากโรงหล่อ

อีกคนหนึ่งเป็นธนาคาร อันนี้เป็นสภาพแวดล้อมที่แตกต่างอย่างสิ้นเชิง: ไม่มีการเปิดตัวผลิตภัณฑ์ แต่มีซอฟท์แวร์มากมายที่จะทำงานต่อเนื่องได้ พวกเหล่านี้ทดสอบ cr * p จากการเปลี่ยนแปลงทุกครั้งที่ทำ พวกเขามีการแยกอย่างเข้มงวดของสภาพแวดล้อม DEV / QA / PROD การทดสอบการถดถอยอัตโนมัติการทดสอบ QA บังคับลงนามโดยผู้ใช้ปลายทางก่อนที่จะออกสู่การผลิต ฯลฯ

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

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

ผลการทดสอบของเราถูกส่งไปยัง FDA (จนถึงตอนนี้เราได้รับการรับรองจาก FDA สองครั้ง - แต่ละการส่งมีความยาวประมาณ 500 หน้า) ทั้งวิธีการพัฒนาและทดสอบของเรานั้นขึ้นอยู่กับการตรวจสอบเป็นระยะ

ดังนั้นจึงไม่ใช่แค่ บริษัท ใหญ่ที่ทำการทดสอบอย่างเป็นทางการจำนวนมาก

หมายเหตุ - ในการเขียนโปรแกรมสัญญา / ให้คำปรึกษามากกว่า 25 ปีของฉันฉันได้ทำงานกับ บริษัท หลายแห่งที่ไม่ได้ทำการทดสอบอย่างเป็นทางการ ส่วนใหญ่ไม่ได้อยู่ใกล้ ๆ อีกต่อไป

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

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

บริษัท บางแห่งไม่มีการทดสอบอัตโนมัติมากบาง บริษัท ไม่มีการทดสอบด้วยตนเอง แต่มีอย่างน้อยหนึ่งรายการ

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

คำตอบสั้น ๆ : ใช่

คำตอบยาว:

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

2. ฉันได้ผ่านโครงการที่หลากหลายด้วยการผสมผสานของปัจจัยต่าง ๆ ข้างต้น:

   • ไม่มีการทดสอบหน่วยอย่างเป็นทางการเพียงการทดสอบการรวมและการทดสอบ Adhoc ส่วนใหญ่

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

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