การทดสอบซอฟต์แวร์คือการตรวจสอบว่าซอฟต์แวร์นั้นบรรลุวัตถุประสงค์ที่ตั้งไว้และตรงตามความคาดหวังหรือไม่

การทดสอบซอฟต์แวร์สามารถให้ข้อมูลที่เป็นกลางและเป็นอิสระเกี่ยวกับคุณภาพของซอฟต์แวร์และความเสี่ยงของความล้มเหลวต่อผู้ใช้ผู้สนับสนุน หรือผู้มีส่วนได้ส่วนเสียอื่น ๆ^{[ 1 ]}

การทดสอบซอฟต์แวร์สามารถระบุความถูกต้องของซอฟต์แวร์สำหรับสถานการณ์ เฉพาะได้ แต่ไม่สามารถระบุความถูกต้องสำหรับทุกสถานการณ์ได้^{[ 2 ] [ 3 ]}ไม่สามารถค้นหาข้อบกพร่อง ทั้งหมด ได้

โดยอิงตามเกณฑ์การวัดความถูกต้องจากออราเคิลการทดสอบซอฟต์แวร์ใช้หลักการและกลไกที่อาจระบุปัญหาได้ ตัวอย่างของออราเคิล ได้แก่ข้อกำหนด สัญญา[ 4 ] ^{ผลิตภัณฑ์ที่ เทียบเคียงได้ เวอร์ชันก่อนหน้าของผลิตภัณฑ์เดียวกัน การอนุมานเกี่ยวกับวัตถุประสงค์ที่ตั้งใจหรือคาดหวัง ความคาดหวัง ของ}ผู้ใช้หรือลูกค้า มาตรฐานที่เกี่ยวข้อง และกฎหมายที่บังคับใช้

การทดสอบซอฟต์แวร์อาจเป็นการทดสอบเชิงฟังก์ชันหรือการทดสอบที่ไม่เกี่ยวข้องกับฟังก์ชันก็ได้

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

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

ข้อมูลที่ได้จากการทดสอบซอฟต์แวร์อาจนำไปใช้เพื่อปรับปรุงกระบวนการพัฒนาซอฟต์แวร์ได้^{[ 5 ] : 41–43}

แนวทางที่แนะนำโดยทั่วไปสำหรับการทดสอบอัตโนมัติคือ "พีระมิดการทดสอบ" ซึ่งการทดสอบส่วนใหญ่เป็นการทดสอบหน่วยตามด้วยชุดการทดสอบการบูรณาการ ที่เล็กกว่า และสุดท้ายคือการทดสอบแบบครบวงจร (e2e) เพียงไม่กี่รายการ ^{[ 6 ] [ 7 ] [ 8 ]}

การศึกษาที่ดำเนินการโดยNISTในปี 2545 รายงานว่าข้อบกพร่องของซอฟต์แวร์ทำให้เศรษฐกิจของสหรัฐฯ เสียหาย 59.5 พันล้านดอลลาร์ต่อปี ค่าใช้จ่ายมากกว่าหนึ่งในสามนี้สามารถหลีกเลี่ยงได้หากมีการทดสอบซอฟต์แวร์ที่ดีขึ้น^{[ 9 ]}

การจ้าง บริษัทภายนอกมาทดสอบซอฟต์แวร์เนื่องจากต้นทุนเป็นเรื่องปกติมาก โดยจีน ฟิลิปปินส์ อินเดีย และปากีสถานเป็นจุดหมายปลายทางที่ได้รับความนิยม^{[ 10 ]}

Glenford J. Myersเป็นผู้ริเริ่มการแยกการดีบักออกจากการทดสอบเป็นครั้งแรกในปี 1979 ^{[ 11 ]}แม้ว่าความสนใจของเขาจะอยู่ที่การทดสอบการแตกหัก ("กรณีทดสอบที่ประสบความสำเร็จคือกรณีที่ตรวจพบข้อผิดพลาดที่ยังไม่ถูกค้นพบ" ^{[ 11 ] : 16} ) แต่มันก็แสดงให้เห็นถึงความปรารถนาของชุมชนวิศวกรรมซอฟต์แวร์ที่จะแยกกิจกรรมการพัฒนาพื้นฐาน เช่น การดีบัก ออกจากการตรวจสอบ การทดสอบซอฟต์แวร์โดยทั่วไปจะรวมถึงการจัดการกับข้อบกพร่องของซอฟต์แวร์ ซึ่งเป็นข้อบกพร่องในโค้ดที่ทำให้เกิดผลลัพธ์ที่ไม่พึงประสงค์^{[ 12 ] : 31} โดยทั่วไปแล้วข้อบกพร่องจะทำให้ความคืบหน้าของการทดสอบช้าลงและต้องอาศัยความช่วยเหลือจากโปรแกรมเมอร์ ใน การดีบักและแก้ไข

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

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

โดยทั่วไปแล้ว การทดสอบซอฟต์แวร์มักมีเป้าหมายที่ชัดเจน

โดยทั่วไป การทดสอบซอฟต์แวร์จะรวมถึงการจัดการข้อบกพร่องของซอฟต์แวร์ ซึ่งเป็นข้อบกพร่องในโค้ดที่ทำให้เกิดผลลัพธ์ที่ไม่พึงประสงค์^{[ 12 ] : 31} ข้อบกพร่องโดยทั่วไปจะทำให้ความคืบหน้าในการทดสอบช้าลง และต้องอาศัย ความช่วยเหลือ จากโปรแกรมเมอร์ในการดีบักและแก้ไข

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

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

ข้อบกพร่องเพียงจุดเดียวอาจส่งผลให้เกิดอาการผิดปกติหลายอย่างได้

การทดสอบซอฟต์แวร์อาจเกี่ยวข้องกับช่องว่างของข้อกำหนด – การละเว้นจากการออกแบบสำหรับข้อกำหนด^{[ 5 ] : 426} ช่องว่างของข้อกำหนดมักจะเป็นข้อกำหนดที่ไม่ใช่ฟังก์ชันเช่นความสามารถในการทดสอบความสามารถในการ ปรับขนาด ความสามารถ ในการบำรุงรักษาประสิทธิภาพและความปลอดภัย

ข้อจำกัดพื้นฐานของการทดสอบซอฟต์แวร์คือ การทดสอบภายใต้ การรวม กันของอินพุตและเงื่อนไขเบื้องต้น (สถานะเริ่มต้น) ทั้งหมดนั้นเป็นไปไม่ได้ แม้แต่กับผลิตภัณฑ์ที่เรียบง่าย^{[ 3 ] : 17–18 [ 14 ]} ข้อบกพร่องที่ปรากฏในสภาวะผิดปกติจะหาได้ยากในการทดสอบ นอกจากนี้ มิติ ที่ไม่ใช่ฟังก์ชันของคุณภาพ (ควรจะเป็น อย่างไร เมื่อเทียบกับสิ่งที่ควรทำ ) – ความสามารถในการใช้งานความ สามารถ ในการปรับขนาดประสิทธิภาพความ เข้ากันได้ และความน่าเชื่อถือ – อาจเป็นเรื่องอัตวิสัย สิ่งที่ถือว่ามีคุณค่าเพียงพอสำหรับคนหนึ่งอาจไม่ใช่สำหรับอีกคนหนึ่ง

แม้ว่าการทดสอบสำหรับอินพุตที่เป็นไปได้ทั้งหมดจะไม่สามารถทำได้ แต่การทดสอบสามารถใช้การจัดเรียงเพื่อเพิ่มความครอบคลุมสูงสุดในขณะที่ลดจำนวนการทดสอบให้น้อยที่สุด^{[ 15 ]}

การทดสอบสามารถแบ่งประเภทได้หลายวิธี^{[ 16 ]}

การทดสอบซอฟต์แวร์สามารถแบ่งระดับได้ตามขอบเขตของระบบซอฟต์แวร์ที่เป็นจุดสนใจของการทดสอบ^{[ 19 ] [ 20 ] [ 21 ] [ 22 ]}

มีวิธีการทดสอบซอฟต์แวร์หลายวิธีการทบทวนการตรวจสอบหรือการตรวจดูเรียกว่า การทดสอบแบบคงที่ ในขณะที่การเรียกใช้โค้ดที่เขียนโปรแกรมไว้พร้อมกับชุดกรณีทดสอบ ที่กำหนด เรียกว่า การ ทดสอบแบบไดนามิก^{[ 24 ] [ 25 ]}

การทดสอบแบบคงที่มักจะเป็นไปโดยปริยาย เช่น การตรวจทานพิสูจน์อักษร รวมถึงเมื่อเครื่องมือการเขียนโปรแกรม/โปรแกรมแก้ไขข้อความตรวจสอบโครงสร้างซอร์สโค้ด หรือคอมไพเลอร์ (พรีคอมไพเลอร์) ตรวจสอบไวยากรณ์และการไหลของข้อมูลเป็นการวิเคราะห์โปรแกรมแบบคงที่การทดสอบแบบไดนามิกจะเกิดขึ้นเมื่อโปรแกรมทำงานจริง การทดสอบแบบไดนามิกอาจเริ่มต้นก่อนที่โปรแกรมจะเสร็จสมบูรณ์ 100% เพื่อทดสอบส่วนต่างๆ ของโค้ด และนำไปใช้กับฟังก์ชันหรือโมดูล ที่แยกจากกัน ^{[ 24 ] [ 25 ]}เทคนิคทั่วไปสำหรับสิ่งเหล่านี้คือการใช้สับ /ไดรเวอร์ หรือการเรียกใช้จากสภาพแวดล้อมดีบักเกอร์^{[ 25 ]}

การทดสอบแบบคงที่เกี่ยวข้องกับการตรวจสอบในขณะที่การทดสอบแบบไดนามิกยังเกี่ยวข้องกับการตรวจสอบความถูกต้องด้วย^{[ 25 ]}

การทดสอบแบบพาสซีฟหมายถึงการตรวจสอบพฤติกรรมของระบบโดยไม่ต้องมีการโต้ตอบกับผลิตภัณฑ์ซอฟต์แวร์ ตรงกันข้ามกับการทดสอบแบบแอคทีฟ ผู้ทดสอบจะไม่ให้ข้อมูลการทดสอบใดๆ แต่จะดูที่บันทึกและร่องรอยของระบบ พวกเขาจะค้นหารูปแบบและพฤติกรรมเฉพาะเพื่อทำการตัดสินใจบางอย่าง^{[ 26 ]}ซึ่งเกี่ยวข้องกับการตรวจสอบรันไทม์ แบบออฟไลน์ และ การ วิเคราะห์ บันทึก

ประเภทของกลยุทธ์การทดสอบที่จะดำเนินการนั้นขึ้นอยู่กับว่าการทดสอบที่จะนำไปใช้กับ IUT ควรได้รับการตัดสินใจก่อนที่แผนการทดสอบจะเริ่มดำเนินการ (การทดสอบที่กำหนดไว้ล่วงหน้า^{[ 29 ]} ) หรือว่าอินพุตแต่ละรายการที่จะนำไปใช้กับ IUT สามารถขึ้นอยู่กับเอาต์พุตที่ได้รับระหว่างการใช้การทดสอบก่อนหน้านี้ได้แบบไดนามิก (การทดสอบแบบปรับตัว^{[ 30 ] [ 31 ]} )

การทดสอบซอฟต์แวร์มักแบ่งออกเป็นแบบกล่องขาวและแบบกล่องดำ แนวทางทั้งสองนี้ใช้เพื่ออธิบายมุมมองที่ผู้ทดสอบใช้เมื่อออกแบบกรณีทดสอบ นอกจากนี้ยังสามารถใช้แนวทางแบบผสมผสานที่เรียกว่าแบบกล่องเทา ซึ่งรวมเอาแง่มุมของทั้งสองแบบเข้ากับวิธีการทดสอบซอฟต์แวร์ได้^{[ 32 ] [ 33 ]}

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

แม้ว่าการทดสอบแบบไวท์บ็อกซ์จะสามารถนำไปใช้ได้ในระดับหน่วยการบูรณาการและระบบของกระบวนการทดสอบซอฟต์แวร์ แต่โดยปกติแล้วจะทำในระดับหน่วย^{[ 34 ]}สามารถทดสอบเส้นทางภายในหน่วย เส้นทางระหว่างหน่วยในระหว่างการบูรณาการ และระหว่างระบบย่อยในระหว่างการทดสอบระดับระบบ แม้ว่าวิธีการออกแบบการทดสอบนี้จะสามารถเปิดเผยข้อผิดพลาดหรือปัญหาได้มากมาย แต่ก็อาจตรวจไม่พบส่วนที่ไม่ได้ใช้งานของข้อกำหนดหรือข้อกำหนดที่ขาดหายไป

เทคนิคที่ใช้ในการทดสอบแบบกล่องขาว ได้แก่: ^{[ 33 ] [ 35 ]}

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

เครื่องมือวัดความครอบคลุมของโค้ดสามารถประเมินความสมบูรณ์ของชุดทดสอบที่สร้างขึ้นด้วยวิธีการใดๆ ก็ได้ รวมถึงการทดสอบแบบกล่องดำ ซึ่งช่วยให้ทีมพัฒนาซอฟต์แวร์สามารถตรวจสอบส่วนต่างๆ ของระบบที่แทบจะไม่ได้รับการทดสอบ และรับประกันว่าจุดฟังก์ชัน ที่สำคัญที่สุด ได้รับการทดสอบแล้ว^{[ 36 ]}ความครอบคลุมของโค้ดในฐานะตัวชี้วัดซอฟต์แวร์สามารถรายงานเป็นเปอร์เซ็นต์ได้ดังนี้: ^{[ 32 ] [ 36 ] [ 37 ]}

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

การครอบคลุมคำสั่ง 100% ช่วยให้มั่นใจได้ว่าเส้นทางโค้ดหรือสาขาทั้งหมด (ในแง่ของการควบคุมการไหล ) จะถูกดำเนินการอย่างน้อยหนึ่งครั้ง ซึ่งเป็นประโยชน์ในการรับประกันการทำงานที่ถูกต้อง แต่ไม่เพียงพอ เนื่องจากโค้ดเดียวกันอาจประมวลผลอินพุตที่แตกต่างกันได้อย่างถูกต้องหรือไม่ถูกต้อง^{[ 38 ]}

การทดสอบแบบกล่องดำ (หรือที่เรียกว่าการทดสอบเชิงฟังก์ชัน) หมายถึงการออกแบบกรณีทดสอบโดยไม่รู้ถึงการใช้งาน โดยไม่ต้องอ่านซอร์สโค้ด ผู้ทดสอบรู้เพียงว่าซอฟต์แวร์ควรจะทำอะไร ไม่ใช่ว่ามันทำอย่างไร^{[ 39 ]}วิธีการทดสอบแบบกล่องดำ ได้แก่การแบ่งส่วนความเท่าเทียมกันการวิเคราะห์ค่าขอบเขตการทดสอบแบบจับคู่ทั้งหมดตารางการเปลี่ยนสถานะ การทดสอบตารางการตัดสินใจการทดสอบ แบบ ฟัซซ์ การทดสอบตามแบบจำลองการทดสอบกรณีการใช้งานการทดสอบเชิงสำรวจและการทดสอบตามข้อกำหนด^{[ 32 ] [ 33 ] [ 37 ]}

การทดสอบตามข้อกำหนดมีจุดมุ่งหมายเพื่อทดสอบการทำงานของซอฟต์แวร์ตามข้อกำหนดที่เกี่ยวข้อง^{[ 40 ]}การทดสอบในระดับนี้มักต้องการกรณีทดสอบ ที่ละเอียดถี่ถ้วน สำหรับผู้ทดสอบ ซึ่งจากนั้นสามารถตรวจสอบได้ง่ายๆ ว่าสำหรับอินพุตที่กำหนด ค่าเอาต์พุต (หรือพฤติกรรม) นั้น "เหมือน" หรือ "ไม่เหมือน" ค่าที่คาดหวังที่ระบุไว้ในกรณีทดสอบ กรณีทดสอบถูกสร้างขึ้นโดยอิงตามข้อกำหนดและเงื่อนไข กล่าวคือ สิ่งที่แอปพลิเคชันควรทำ โดยใช้คำอธิบายภายนอกของซอฟต์แวร์ รวมถึงข้อกำหนด เงื่อนไข และการออกแบบ เพื่อสร้างกรณีทดสอบ การทดสอบเหล่านี้อาจเป็นการทดสอบการทำงานหรือไม่ใช่การทำงานแม้ว่าโดยทั่วไปจะเป็นการทดสอบการทำงาน การทดสอบตามข้อกำหนดอาจจำเป็นเพื่อให้มั่นใจว่าการทำงานถูกต้อง แต่ไม่เพียงพอที่จะป้องกันสถานการณ์ที่ซับซ้อนหรือมีความเสี่ยงสูง^{[ 41 ]}

การทดสอบแบบกล่องดำสามารถใช้กับการทดสอบทุกระดับได้ แม้ว่าโดยปกติจะไม่ใช่การทดสอบในระดับหน่วยก็ตาม^{[ 34 ]}

การทดสอบอินเทอร์เฟซของส่วนประกอบ

การทดสอบอินเทอร์เฟซของส่วนประกอบเป็นรูปแบบหนึ่งของการทดสอบแบบกล่องดำโดยมุ่งเน้นที่ค่าข้อมูลนอกเหนือจากการกระทำที่เกี่ยวข้องของส่วนประกอบย่อยของระบบ^{[ 42 ]}การทดสอบอินเทอร์เฟซของส่วนประกอบสามารถใช้เพื่อตรวจสอบการจัดการข้อมูลที่ส่งผ่านระหว่างหน่วยต่างๆ หรือส่วนประกอบย่อยของระบบ นอกเหนือจากการทดสอบการบูรณาการอย่างเต็มรูปแบบระหว่างหน่วยเหล่านั้น^{[ 43 ] [ 44 ]}ข้อมูลที่ส่งผ่านสามารถพิจารณาได้ว่าเป็น "แพ็กเก็ตข้อความ" และสามารถตรวจสอบช่วงหรือประเภทข้อมูลสำหรับข้อมูลที่สร้างจากหน่วยหนึ่งและทดสอบความถูกต้องก่อนที่จะส่งผ่านไปยังอีกหน่วยหนึ่ง ตัวเลือกหนึ่งสำหรับการทดสอบอินเทอร์เฟซคือการเก็บไฟล์บันทึกแยกต่างหากของรายการข้อมูลที่ส่งผ่าน โดยมักจะมีการบันทึกเวลาไว้เพื่อให้สามารถวิเคราะห์กรณีข้อมูลหลายพันกรณีที่ส่งผ่านระหว่างหน่วยต่างๆ เป็นเวลาหลายวันหรือหลายสัปดาห์ การทดสอบอาจรวมถึงการตรวจสอบการจัดการค่าข้อมูลที่ผิดปกติบางค่า ในขณะที่ตัวแปรอินเทอร์เฟซอื่นๆ ถูกส่งผ่านเป็นค่าปกติ^{[ 43 ]}ค่าข้อมูลที่ผิดปกติในอินเทอร์เฟซสามารถช่วยอธิบายประสิทธิภาพที่ไม่คาดคิดในหน่วยถัดไปได้

จุดประสงค์ของการทดสอบด้วยภาพคือการให้ผู้พัฒนาสามารถตรวจสอบสิ่งที่เกิดขึ้น ณ จุดที่ซอฟต์แวร์ล้มเหลว โดยการนำเสนอข้อมูลในลักษณะที่ผู้พัฒนาสามารถค้นหาข้อมูลที่ต้องการได้อย่างง่ายดาย และข้อมูลนั้นจะถูกแสดงออกมาอย่างชัดเจน^{[ 45 ] [ 46 ]}

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

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

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

การทดสอบแบบ Grey-box (สะกดแบบอเมริกัน: gray-box testing) เกี่ยวข้องกับการใช้ความรู้เกี่ยวกับโครงสร้างข้อมูลภายในและอัลกอริทึมเพื่อวัตถุประสงค์ในการออกแบบการทดสอบในขณะที่ดำเนินการทดสอบเหล่านั้นในระดับผู้ใช้หรือระดับ Black-box ผู้ทดสอบมักจะสามารถเข้าถึงทั้ง "ซอร์สโค้ดและไบนารีที่สามารถเรียกใช้งานได้" ^{[ 48 ]}การทดสอบแบบ Grey-box อาจรวมถึงวิศวกรรมย้อนกลับ (โดยใช้การวิเคราะห์โค้ดแบบไดนามิก) เพื่อกำหนดตัวอย่างเช่น ค่าขอบเขตหรือข้อความแสดงข้อผิดพลาด^{[ 48 ]}การจัดการข้อมูลอินพุตและการจัดรูปแบบเอาต์พุตไม่ถือเป็น Grey-box เนื่องจากอินพุตและเอาต์พุตอยู่นอก "Black-box" ที่เราเรียกว่าระบบที่กำลังทดสอบอย่างชัดเจน ความแตกต่างนี้มีความสำคัญอย่างยิ่งเมื่อทำการทดสอบการบูรณาการระหว่างโมดูลโค้ดสองโมดูลที่เขียนโดยนักพัฒนาสองคนที่แตกต่างกัน โดยที่อินเทอร์เฟซเท่านั้นที่เปิดเผยสำหรับการทดสอบ

ด้วยความรู้เกี่ยวกับแนวคิดพื้นฐานของการทำงานของซอฟต์แวร์ ผู้ทดสอบจะสามารถเลือกการทดสอบที่มีข้อมูลมากขึ้นในขณะที่ทดสอบซอฟต์แวร์จากภายนอก โดยทั่วไป ผู้ทดสอบแบบเกรย์บ็อกซ์จะได้รับอนุญาตให้ตั้งค่าสภาพแวดล้อมการทดสอบแบบแยกส่วนพร้อมกิจกรรมต่างๆ เช่น การใส่ ข้อมูลเริ่มต้นลง ในฐานข้อมูลผู้ทดสอบสามารถสังเกตสถานะของผลิตภัณฑ์ที่กำลังทดสอบหลังจากดำเนินการบางอย่าง เช่น การเรียกใช้ คำสั่ง SQLกับฐานข้อมูล และจากนั้นเรียกใช้การสืบค้นเพื่อให้แน่ใจว่าการเปลี่ยนแปลงที่คาดหวังได้สะท้อนออกมา การทดสอบแบบเกรย์บ็อกซ์ใช้สถานการณ์การทดสอบอัจฉริยะโดยอาศัยข้อมูลที่จำกัด ซึ่งจะนำไปใช้กับการจัดการประเภทข้อมูลการจัดการข้อยกเว้นและอื่นๆ^{[ 49 ]}

ด้วยแนวคิดของการทดสอบแบบกล่องสีเทา "การแบ่งแยกโดยพลการ" ระหว่างการทดสอบแบบกล่องสีดำและกล่องสีขาวจึงจางหายไปบ้าง^{[ 34 ]}

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

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

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

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

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

การทดสอบการยอมรับเป็นการทดสอบระดับระบบเพื่อให้แน่ใจว่าซอฟต์แวร์ตรงตามความคาดหวังของลูกค้า^{[ 53 ] [ 54 ] [ 55 ] [ 56 ]}

การทดสอบการยอมรับอาจดำเนินการในช่วงท้ายหรือช่วงกลางของโครงการ รวมถึงหลังจากเรื่องราวของผู้ใช้แต่ละเรื่องเสร็จสมบูรณ์ในโครงการแบบ Agile ^{[ 57 ]}

โดยทั่วไปการทดสอบจะถูกจัดกลุ่มตามระดับเหล่านี้โดยพิจารณาจากตำแหน่งที่ทำการทดสอบในกระบวนการพัฒนาซอฟต์แวร์ หรือตามระดับความเฉพาะเจาะจงของการทดสอบ^{[ 56 ]}

• การทดสอบการยอมรับของผู้ใช้ (UAT)
• การทดสอบการยอมรับการใช้งาน (OAT)
• การทดสอบการยอมรับตามสัญญาและกฎระเบียบ
• การทดสอบอัลฟ่าและเบต้า

บางครั้ง ลูกค้าเป็นผู้ทำการทดสอบ UAT ในสภาพแวดล้อมของตนเองและบนฮาร์ดแวร์ของตนเอง

OAT (Operational Testing Attribution) ใช้ในการตรวจสอบความพร้อมในการใช้งาน (ก่อนวางจำหน่าย) ของผลิตภัณฑ์ บริการ หรือระบบ ซึ่งเป็นส่วนหนึ่งของระบบการจัดการคุณภาพ OAT เป็นการทดสอบซอฟต์แวร์ที่ไม่เน้นฟังก์ชันการทำงานประเภทหนึ่งที่ใช้กันทั่วไป โดยส่วนใหญ่ใช้ใน โครงการ พัฒนาซอฟต์แวร์และการบำรุงรักษาซอฟต์แวร์การทดสอบประเภทนี้มุ่งเน้นไปที่ความพร้อมในการใช้งานของระบบที่จะได้รับการสนับสนุน หรือที่จะกลายเป็นส่วนหนึ่งของสภาพแวดล้อมการผลิต ดังนั้นจึงเรียกอีกอย่างว่า การทดสอบความพร้อมในการใช้งาน (ORT) หรือ การทดสอบ ความพร้อมและความมั่นใจในการใช้งาน (OR&A) การทดสอบฟังก์ชันการทำงานภายใน OAT นั้นจำกัดเฉพาะการทดสอบที่จำเป็นในการตรวจสอบ ด้าน ที่ไม่เน้นฟังก์ชันการทำงานของระบบเท่านั้น

นอกจากนี้ การทดสอบซอฟต์แวร์ควรตรวจสอบให้แน่ใจว่าระบบสามารถพกพาได้ และทำงานได้ตามที่คาดหวัง โดยไม่ทำให้สภาพแวดล้อมการทำงานเสียหายหรือเสียหายบางส่วน หรือทำให้กระบวนการอื่น ๆ ภายในสภาพแวดล้อมนั้นไม่สามารถใช้งานได้^{[ 58 ]}

การทดสอบการยอมรับตามสัญญาจะดำเนินการตามเกณฑ์การยอมรับของสัญญาที่กำหนดไว้ในระหว่างการตกลงทำสัญญา ในขณะที่การทดสอบการยอมรับตามกฎระเบียบจะดำเนินการตามข้อบังคับที่เกี่ยวข้องกับผลิตภัณฑ์ซอฟต์แวร์ การทดสอบทั้งสองนี้สามารถดำเนินการโดยผู้ใช้หรือผู้ทดสอบอิสระได้ การทดสอบการยอมรับตามกฎระเบียบบางครั้งเกี่ยวข้องกับหน่วยงานกำกับดูแลที่ตรวจสอบผลการทดสอบ^{[ 56 ]}

การทดสอบอัลฟ่าคือการทดสอบการทำงานจำลองหรือการทดสอบการทำงานจริงโดยผู้ใช้/ลูกค้าที่มีศักยภาพหรือทีมทดสอบอิสระที่ไซต์ของผู้พัฒนา การทดสอบอัลฟ่ามักใช้กับซอฟต์แวร์สำเร็จรูปในรูปแบบของการทดสอบการยอมรับภายในก่อนที่ซอฟต์แวร์จะเข้าสู่การทดสอบเบต้า^{[ 59 ]}

การทดสอบเบต้าเกิดขึ้นหลังจากการทดสอบอัลฟ่า และสามารถถือได้ว่าเป็นรูปแบบหนึ่งของการทดสอบการยอมรับของผู้ใช้ ภายนอก เวอร์ชันของซอฟต์แวร์ที่ เรียกว่า เวอร์ชันเบต้าจะถูกเผยแพร่ให้กับกลุ่มเป้าหมายที่จำกัดนอกเหนือจากทีมโปรแกรมเมอร์ ซึ่งเรียกว่าผู้ทดสอบเบต้า ซอฟต์แวร์จะถูกเผยแพร่ให้กับกลุ่มคนเพื่อให้การทดสอบเพิ่มเติมสามารถรับประกันได้ว่าผลิตภัณฑ์มีข้อผิดพลาดหรือบั๊ก น้อย เวอร์ชันเบต้าสามารถเปิดให้สาธารณะชนใช้งานได้เพื่อเพิ่ม จำนวน ข้อเสนอแนะให้มากที่สุดเท่าที่จะเป็นไปได้จากผู้ใช้ในอนาคต และเพื่อส่งมอบคุณค่าได้เร็วขึ้น เป็นระยะเวลานานหรืออาจไม่มีกำหนด ( เบต้าถาวร ) ^{[ 60 ]}

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

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

การทดสอบอย่างต่อเนื่องคือกระบวนการดำเนินการทดสอบอัตโนมัติซึ่งเป็นส่วนหนึ่งของกระบวนการส่งมอบซอฟต์แวร์ เพื่อให้ได้ข้อเสนอแนะทันทีเกี่ยวกับความเสี่ยงทางธุรกิจที่เกี่ยวข้องกับซอฟต์แวร์เวอร์ชันที่จะปล่อย^{[ 61 ] [ 62 ]}การทดสอบอย่างต่อเนื่องรวมถึงการตรวจสอบความถูกต้องของทั้งข้อกำหนดด้านฟังก์ชันและข้อกำหนดที่ไม่ใช่ฟังก์ชันขอบเขตของการทดสอบขยายจากการตรวจสอบความถูกต้องของข้อกำหนดจากล่างขึ้นบนหรือเรื่องราวของผู้ใช้ ไปจนถึงการประเมินข้อกำหนดของระบบที่เกี่ยวข้องกับเป้าหมายทางธุรกิจโดยรวม^{[ 63 ] [ 64 ]}

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

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

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

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

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

การทดสอบความสามารถในการใช้งานคือการตรวจสอบว่าอินเทอร์เฟซผู้ใช้นั้นใช้งานง่ายและเข้าใจง่ายหรือไม่ โดยส่วนใหญ่เกี่ยวข้องกับการใช้งานแอปพลิเคชัน นี่ไม่ใช่การทดสอบประเภทที่สามารถทำให้เป็นอัตโนมัติได้ จำเป็นต้องมีผู้ใช้จริงที่ได้รับการตรวจสอบโดยนักออกแบบ UI ที่มีทักษะ การทดสอบความสามารถในการใช้งานสามารถใช้แบบจำลองที่มีโครงสร้างเพื่อตรวจสอบว่าอินเทอร์เฟซทำงานได้ดีเพียงใด แบบจำลองของ Stanton, Theofanos และ Joshi (2015) พิจารณาประสบการณ์ของผู้ใช้ และแบบจำลองของ Al-Sharafat และ Qadoumi (2016) ใช้สำหรับการประเมินโดยผู้เชี่ยวชาญ ช่วยในการประเมินความสามารถในการใช้งานในแอปพลิเคชันดิจิทัล^{[ 66 ]}

การทดสอบ การเข้าถึงได้นั้นทำขึ้นเพื่อให้แน่ใจว่าซอฟต์แวร์นั้นสามารถเข้าถึงได้สำหรับผู้พิการ การทดสอบการเข้าถึงเว็บไซต์ที่พบบ่อยบางส่วน ได้แก่

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

• พระราชบัญญัติคนพิการแห่งอเมริกา ปี 1990
• มาตรา 508 การแก้ไขเพิ่มเติมพระราชบัญญัติการฟื้นฟูสมรรถภาพปี 1973
• โครงการริเริ่มด้านการเข้าถึงเว็บไซต์ (Web Accessibility Initiative - WAI) ของสมาคมเวิลด์ไวด์เว็บ (World Wide Web Consortium - W3C)

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

องค์การมาตรฐานสากล (ISO) นิยามสิ่งนี้ว่าเป็น "การทดสอบประเภทหนึ่งที่ดำเนินการเพื่อประเมินระดับที่รายการทดสอบและข้อมูลที่เกี่ยวข้องได้รับการปกป้อง เพื่อไม่ให้บุคคลหรือระบบที่ไม่ได้รับอนุญาตสามารถใช้ อ่าน หรือแก้ไขได้ และบุคคลหรือระบบที่ได้รับอนุญาตจะไม่ถูกปฏิเสธการเข้าถึง" ^{[ 67 ]}

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

การทดสอบโลกาภิวัตน์จะตรวจสอบว่าซอฟต์แวร์ได้รับการปรับให้เข้ากับวัฒนธรรมใหม่ เช่น สกุลเงินหรือเขตเวลาที่แตกต่างกัน^{[ 68 ]}

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

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

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

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

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

การทดสอบแบบขนานหรือการทดสอบการทำงานพร้อมกันจะประเมินพฤติกรรมและประสิทธิภาพของซอฟต์แวร์และระบบที่ใช้การประมวลผลแบบขนานโดยทั่วไปภายใต้สภาวะการใช้งานปกติ ปัญหาทั่วไปที่การทดสอบประเภทนี้จะเปิดเผย ได้แก่ การติดตาย (deadlock) สภาวะการแข่งขัน (race condition) และปัญหาเกี่ยวกับการจัดการหน่วยความจำ/ทรัพยากรที่ใช้ร่วมกัน

ในการทดสอบซอฟต์แวร์ การทดสอบความสอดคล้องจะตรวจสอบว่าผลิตภัณฑ์ทำงานได้ตามมาตรฐานที่กำหนดไว้ ตัวอย่างเช่น คอมไพเลอร์จะได้รับการทดสอบอย่างละเอียดเพื่อตรวจสอบว่าตรงตามมาตรฐานที่ยอมรับกันสำหรับภาษานั้นหรือไม่

การสร้างเอาต์พุตที่คาดหวังของการแสดงผล ไม่ว่าจะเป็นการเปรียบเทียบข้อมูลของข้อความหรือภาพหน้าจอของ UI ^{[ 3 ] : 195} บางครั้งเรียกว่าการทดสอบสแนปช็อตหรือการทดสอบ Golden Master ซึ่งแตกต่างจากการทดสอบรูปแบบอื่นๆ ตรงที่ไม่สามารถตรวจจับความล้มเหลวโดยอัตโนมัติได้ และจำเป็นต้องให้มนุษย์ประเมินผลลัพธ์เพื่อหาความไม่สอดคล้องกัน

การทดสอบคุณสมบัติ (Property testing) เป็นเทคนิคการทดสอบที่แทนที่จะยืนยันว่าอินพุตเฉพาะเจาะจงจะสร้างเอาต์พุตที่คาดหวังเฉพาะเจาะจง ผู้ปฏิบัติงานจะสร้างอินพุตจำนวนมากแบบสุ่ม เรียกใช้โปรแกรมกับอินพุตทั้งหมด และยืนยันความจริงของ "คุณสมบัติ" บางอย่างที่ควรเป็นจริงสำหรับทุกคู่ของอินพุตและเอาต์พุต ตัวอย่างเช่น เอาต์พุตทุกอย่างจากฟังก์ชันการแปลงเป็นรูปแบบอนุกรม (serialization function) ควรได้รับการยอมรับจากฟังก์ชันการแปลงกลับเป็นรูปแบบเดิม (deserialization function) ที่สอดคล้องกัน และเอาต์พุตทุกอย่างจากฟังก์ชันการเรียงลำดับ (sort function) ควรเป็นรายการที่เพิ่มขึ้นอย่างต่อเนื่อง (monotonically increasing list) ที่มีองค์ประกอบเหมือนกับอินพุตทุกประการ

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

การทดสอบคุณสมบัติบางครั้งเรียกว่า "การทดสอบแบบสร้าง" หรือ "การทดสอบ QuickCheck" เนื่องจากได้รับการแนะนำและเผยแพร่โดยไลบรารีHaskell QuickCheck ^{[ 69 ]}

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

การทดสอบ VCR หรือที่รู้จักกันในชื่อ "การทดสอบการเล่นซ้ำ" หรือ "การทดสอบบันทึก/เล่นซ้ำ" เป็นเทคนิคการทดสอบเพื่อเพิ่มความน่าเชื่อถือและความเร็วของการทดสอบการถดถอยที่เกี่ยวข้องกับส่วนประกอบที่มีการสื่อสารช้าหรือไม่น่าเชื่อถือ ซึ่งมักจะเป็น API ของบุคคลที่สามที่อยู่นอกเหนือการควบคุมของผู้ทดสอบ โดยจะทำการบันทึก (เทปคาสเซ็ต) การโต้ตอบของระบบกับส่วนประกอบภายนอก แล้วเล่นซ้ำการโต้ตอบที่บันทึกไว้เพื่อใช้แทนการสื่อสารกับระบบภายนอกในการทดสอบครั้งต่อๆ ไป

เทคนิคนี้ได้รับความนิยมในวงการพัฒนาเว็บโดยไลบรารีvcrของ Ruby

การทดสอบ สัญญาซึ่งไม่ควรสับสนกับการทดสอบการยอมรับสัญญาที่มีแรงจูงใจทางกฎหมายที่กล่าวถึงข้างต้น เป็นวิธีการทดสอบจุดเชื่อมต่อระหว่างบริการซอฟต์แวร์สองบริการใดๆ โดยตรวจสอบว่าคำขอและการตอบกลับที่ส่งระหว่างกันนั้นสอดคล้องกับชุดความคาดหวังร่วมกันซึ่งโดยทั่วไปเรียกว่าสัญญาหรือไม่ มักใช้ในบริบทของระบบกระจายระบบสถาปัตยกรรมซอฟต์แวร์ที่เน้นบริการและไมโครเซอร์วิส^{[ 70 ] [ 71 ]}

ตั้งแต่ช่วงต้นทศวรรษ 2020 ปัญญาประดิษฐ์ได้รับการบูรณาการเข้ากับเวิร์กโฟลว์การทดสอบซอฟต์แวร์มากขึ้นเรื่อยๆ วิธีการทดสอบที่ขับเคลื่อนด้วย AI จะทำการสร้างกรณีทดสอบโดยอัตโนมัติ ปรับตัวตามการเปลี่ยนแปลงแบบไดนามิก และใช้ประโยชน์จากการเรียนรู้ของเครื่องเพื่อระบุพื้นที่ที่มีความเสี่ยงสูงในโค้ดเบส ซึ่งเป็นแนวทางที่ช่วยเพิ่ม ประสิทธิภาพ การทดสอบการถดถอยในขณะที่ขยายขอบเขตการทดสอบโดยรวม^{[ 72 ]}

การพัฒนาที่สำคัญคือการทดสอบอัตโนมัติแบบแก้ไขตัวเองได้ซึ่งการทดสอบอัตโนมัติจะตรวจจับและปรับตัวให้เข้ากับการเปลี่ยนแปลงในส่วนติดต่อผู้ใช้โดยอัตโนมัติโดยไม่ต้องมีการแทรกแซงจากมนุษย์ การศึกษาเกี่ยวกับการทดสอบอัตโนมัติที่ขับเคลื่อนด้วย AI จากแหล่งข้อมูลเอกสารสีเทามากกว่า 3,600 แหล่ง ระบุว่าสคริปต์การทดสอบแบบแก้ไขตัวเองได้เป็นหนึ่งในโซลูชัน AI ที่พบได้บ่อยที่สุดในทางปฏิบัติ^{[ 73 ]}

การศึกษาวิจัยระดับอุดมศึกษาที่ตีพิมพ์ในACM Computing Surveys (2023) พบว่าวิธีการ AI ได้ถูกนำไปประยุกต์ใช้อย่างกว้างขวางในทุกขั้นตอนหลักของวงจรการพัฒนาซอฟต์แวร์ และระบุว่าการสร้างกรณีทดสอบ การทำนายข้อผิดพลาด และการซ่อมแซมอัตโนมัติเป็น 3 ด้านที่มีการวิจัยการทดสอบโดยใช้ AI มากที่สุด^{[ 74 ]}

การทดสอบแบบ Shift-leftเป็นแนวปฏิบัติในการบูรณาการกิจกรรมการทดสอบให้เร็วที่สุดเท่าที่จะเป็นไปได้ในวงจรชีวิตการพัฒนาซอฟต์แวร์ เพื่อตรวจจับข้อบกพร่องในขณะที่ต้นทุนในการแก้ไขต่ำที่สุด คำนี้ได้รับการอธิบายครั้งแรกในเอกสารทางวิชาการในDr. Dobb's Journalและได้รับการกำหนดเป็นทางการในการวิจัยACM / IEEE ในเวลาต่อมา ^{[ 75 ]}

งานวิจัยเชิงประจักษ์แสดงให้เห็นว่าการทดสอบแบบเลื่อนไปทางซ้ายส่งผลให้เวลาในการตรวจจับข้อบกพร่องลดลง 40–60% และต้นทุนในการกำจัดข้อบกพร่องลดลง 75–85% เมื่อตรวจพบในระยะเริ่มต้นของการพัฒนา เมื่อเทียบกับวิธีการแบบดั้งเดิมที่การทดสอบถูกเลื่อนไปในระยะหลัง^{[ 76 ]}

กรณีศึกษาที่นำเสนอในการประชุมนานาชาติว่าด้วยการจัดการและเทคโนโลยีสารสนเทศ (ICIMTech) ปี 2023 พบว่าการบูรณาการการทดสอบแบบ shift-left เข้ากับ วิธีการพัฒนา แบบ agileตลอดระยะเวลาหนึ่งปีช่วยลดจำนวนบั๊กที่เข้าสู่ขั้นตอนการผลิตได้อย่างมีนัยสำคัญ^{[ 77 ]}

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

ในช่วงทศวรรษ 1980 คำว่า " ผู้ทดสอบซอฟต์แวร์"เริ่มถูกนำมาใช้เพื่อบ่งชี้ถึงอาชีพที่แยกต่างหาก

บทบาทและตำแหน่งที่โดดเด่นในการทดสอบซอฟต์แวร์ ได้แก่^{[ 78 ]}ผู้จัดการทดสอบหัวหน้าทีมทดสอบนักวิเคราะห์ทดสอบนักออกแบบทดสอบผู้ทดสอบนักพัฒนาการทดสอบอัตโนมัติและ ผู้ ดูแลระบบทดสอบ^{[ 79 ]}

องค์กรที่พัฒนาซอฟต์แวร์จะทำการทดสอบแตกต่างกัน แต่ก็มีรูปแบบทั่วไปอยู่^{[ 2 ]}

ในการพัฒนาแบบน้ำตกโดยทั่วไปการทดสอบจะดำเนินการหลังจากเขียนโค้ดเสร็จแล้ว แต่ก่อนที่จะส่งผลิตภัณฑ์ให้กับลูกค้า^{[ 80 ]}การปฏิบัติเช่นนี้มักส่งผลให้ขั้นตอนการทดสอบถูกใช้เป็น ตัวกันชน ของโครงการเพื่อชดเชยความล่าช้าของโครงการ ซึ่งทำให้เวลาที่ทุ่มเทให้กับการทดสอบลดลง^{[ 11 ] : 145–146}

บางคนโต้แย้งว่ากระบวนการน้ำตกช่วยให้การทดสอบเริ่มต้นเมื่อโครงการพัฒนาเริ่มต้นและเป็นกระบวนการต่อเนื่องจนกว่าโครงการจะเสร็จสิ้น^{[ 81 ]}

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

หนึ่งในแนวทางปฏิบัติแบบ Agile คือ การพัฒนาซอฟต์แวร์แบบทดสอบนำ (Test-Driven Software Development : TDD) ซึ่งเป็นวิธีการทดสอบหน่วยโดยการทดสอบระดับหน่วยจะดำเนินการในขณะที่เขียนโค้ดผลิตภัณฑ์^{[ 82 ]}โค้ดทดสอบจะได้รับการอัปเดตเมื่อมีการเพิ่มฟีเจอร์ใหม่และพบเงื่อนไขความล้มเหลว (แก้ไขบั๊ก) โดยทั่วไป โค้ดทดสอบหน่วยจะถูกเก็บรักษาไว้พร้อมกับโค้ดโครงการ ผสานรวมเข้ากับกระบวนการสร้าง และเรียกใช้ในแต่ละการสร้างและเป็นส่วนหนึ่งของการทดสอบการถดถอย เป้าหมายของการผสานรวมอย่างต่อเนื่อง นี้ คือการสนับสนุนการพัฒนาและลดข้อบกพร่อง^{[ 83 ] [ 82 ]}

แม้แต่ในองค์กรที่แยกทีมตามหน้าที่การเขียนโปรแกรมและการทดสอบ หลายแห่งมักให้โปรแกรมเมอร์ทำการทดสอบหน่วย^{[ 84 ]}

ตัวอย่างด้านล่างนี้เป็นตัวอย่างทั่วไปของการพัฒนาแบบ Waterfall กิจกรรมเดียวกันนี้มักพบได้ในรูปแบบการพัฒนาอื่นๆ แต่การอธิบายอาจแตกต่างกันไป

• การวิเคราะห์ความต้องการ : การทดสอบควรเริ่มต้นในขั้นตอนการกำหนดความต้องการของวงจรชีวิตการพัฒนาซอฟต์แวร์ในระหว่างขั้นตอนการออกแบบ ผู้ทดสอบจะทำงานเพื่อพิจารณาว่าส่วนใดของงานออกแบบที่สามารถทดสอบได้ และการทดสอบเหล่านั้นใช้พารามิเตอร์ใด
• การวางแผนการทดสอบ: กลยุทธ์การทดสอบแผนการทดสอบการ สร้าง สภาพแวดล้อมการทดสอบเนื่องจากจะมีการดำเนินกิจกรรมหลายอย่างระหว่างการทดสอบ จึงจำเป็นต้องมีแผนงาน
• การพัฒนาการทดสอบ: ขั้นตอนการทดสอบ, สถานการณ์ทดสอบ , กรณีทดสอบ , ชุดข้อมูลทดสอบ, สคริปต์ทดสอบที่จะใช้ในการทดสอบซอฟต์แวร์
• การดำเนินการทดสอบ: ผู้ทดสอบจะเรียกใช้ซอฟต์แวร์ตามแผนและเอกสารการทดสอบ จากนั้นรายงานข้อผิดพลาดที่พบให้กับทีมพัฒนา ส่วนนี้อาจมีความซับซ้อนหากทำการทดสอบโดยขาดความรู้ด้านการเขียนโปรแกรม
• การรายงานผลการทดสอบ: เมื่อการทดสอบเสร็จสิ้น ผู้ทดสอบจะสร้างตัวชี้วัดและจัดทำรายงานสรุปเกี่ยวกับความพยายามในการทดสอบและว่าซอฟต์แวร์ที่ทดสอบพร้อมสำหรับการเผยแพร่หรือไม่
• การวิเคราะห์ผลการทดสอบ หรือการวิเคราะห์ข้อบกพร่องมักดำเนินการโดยทีมพัฒนา ร่วมกับลูกค้า เพื่อตัดสินใจว่าข้อบกพร่องใดควรได้รับการแก้ไข ปฏิเสธ (เช่น พบว่าซอฟต์แวร์ทำงานได้อย่างถูกต้อง) หรือเลื่อนไปจัดการในภายหลัง
• การทดสอบซ้ำเพื่อแก้ไขข้อบกพร่อง: เมื่อทีมพัฒนาได้แก้ไขข้อบกพร่องแล้ว ทีมทดสอบจะทำการทดสอบซ้ำอีกครั้ง
• การทดสอบการถดถอย (Regression testing ): เป็นเรื่องปกติที่จะมีโปรแกรมทดสอบขนาดเล็กที่ประกอบด้วยชุดย่อยของการทดสอบ สำหรับการรวมซอฟต์แวร์ใหม่ การแก้ไข หรือการแก้ไขข้อผิดพลาดแต่ละครั้ง เพื่อให้แน่ใจว่าการส่งมอบล่าสุดไม่ได้ทำให้เกิดความเสียหายใด ๆ และผลิตภัณฑ์ซอฟต์แวร์โดยรวมยังคงทำงานได้อย่างถูกต้อง
• การปิดการทดสอบ: เมื่อการทดสอบเป็นไปตามเกณฑ์ที่กำหนดแล้ว กิจกรรมต่างๆ เช่น การรวบรวมผลลัพธ์หลัก บทเรียนที่ได้รับ ผลการวิจัย บันทึกต่างๆ และเอกสารที่เกี่ยวข้องกับโครงการ จะถูกจัดเก็บและใช้เป็นข้อมูลอ้างอิงสำหรับโครงการในอนาคต

การทดสอบซอฟต์แวร์ใช้ควบคู่กับการตรวจสอบและการรับรองความถูกต้อง : ^{[ 85 ]}

• การตรวจสอบ: เราสร้างซอฟต์แวร์ได้ถูกต้องหรือไม่? (เช่น ซอฟต์แวร์ตรงตามข้อกำหนดหรือไม่)
• การตรวจสอบความถูกต้อง: เราได้สร้างซอฟต์แวร์ที่ถูกต้องแล้วหรือไม่? (เช่น ผลลัพธ์ที่ได้ตรงตามความต้องการของลูกค้าหรือไม่)

คำว่าการตรวจสอบและการรับรองความถูกต้องมักใช้สลับกันได้ในอุตสาหกรรม นอกจากนี้ยังพบเห็นได้บ่อยว่าคำทั้งสองคำนี้ถูกกำหนดความหมายที่ขัดแย้งกัน ตามพจนานุกรมศัพท์วิศวกรรมซอฟต์แวร์มาตรฐานของ IEEE : ^{[ 12 ] : 80–81}

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

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

และตามมาตรฐาน ISO 9000:

การตรวจสอบยืนยัน คือ การยืนยันโดยการตรวจสอบและโดยการจัดหาหลักฐานที่เป็นรูปธรรมว่าข้อกำหนดที่ระบุไว้ได้รับการปฏิบัติตามแล้ว

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

ความขัดแย้งเกิดจากการใช้แนวคิดเรื่องข้อกำหนดและข้อกำหนดที่ระบุไว้ แต่มีความหมายแตกต่างกัน

ในกรณีของมาตรฐาน IEEE ข้อกำหนดที่ระบุไว้ในคำจำกัดความของการตรวจสอบความถูกต้อง คือชุดของปัญหา ความต้องการ และความปรารถนาของผู้มีส่วนได้ส่วนเสียที่ซอฟต์แวร์ต้องแก้ไขและตอบสนอง ข้อกำหนดดังกล่าวได้รับการบันทึกไว้ในเอกสารข้อกำหนดซอฟต์แวร์ (Software Requirements Specification หรือ SRS) และผลิตภัณฑ์ที่กล่าวถึงในคำจำกัดความของการตรวจสอบ คือผลลัพธ์ที่ได้จากทุกขั้นตอนของกระบวนการพัฒนาซอฟต์แวร์ ผลิตภัณฑ์เหล่านี้คือข้อกำหนดต่างๆ เช่น ข้อกำหนดการออกแบบสถาปัตยกรรม ข้อกำหนดการออกแบบโดยละเอียด เป็นต้น SRS ก็เป็นข้อกำหนดเช่นกัน แต่ไม่สามารถตรวจสอบความถูกต้องได้ (อย่างน้อยก็ไม่ใช่ในความหมายที่ใช้ในที่นี้ – จะกล่าวถึงเพิ่มเติมในหัวข้อถัดไป)

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

ดังนั้น เมื่อมีการให้ความหมายของคำเหล่านี้ด้วยคำทั่วไป ความขัดแย้งที่ปรากฏก็จะหายไป

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

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

ในบางองค์กร การทดสอบซอฟต์แวร์เป็นส่วนหนึ่งของ กระบวนการ ประกันคุณภาพซอฟต์แวร์ (SQA) ^{[ 3 ] : 347} ใน SQA ผู้เชี่ยวชาญด้านกระบวนการซอฟต์แวร์และผู้ตรวจสอบจะให้ความสำคัญกับกระบวนการพัฒนาซอฟต์แวร์มากกว่าแค่สิ่งประดิษฐ์ เช่น เอกสาร โค้ด และระบบ พวกเขาตรวจสอบและเปลี่ยนแปลง กระบวนการ วิศวกรรมซอฟต์แวร์เองเพื่อลดจำนวนข้อผิดพลาดที่เกิดขึ้นในซอฟต์แวร์ที่ส่งมอบ ซึ่งเรียกว่าอัตราข้อบกพร่อง อัตราข้อบกพร่องที่ยอมรับได้นั้นขึ้นอยู่กับลักษณะของซอฟต์แวร์ เกมจำลองการบินจะมีค่าความคลาดเคลื่อนของข้อบกพร่องสูงกว่าซอฟต์แวร์สำหรับเครื่องบินจริงมาก แม้ว่าจะมีความเชื่อมโยงอย่างใกล้ชิดกับ SQA แต่แผนกทดสอบมักจะแยกตัวออกมาต่างหาก และอาจไม่มีฟังก์ชัน SQA ในบางบริษัท

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

มาตรการด้านคุณภาพประกอบด้วยหัวข้อต่างๆ เช่นความถูกต้องความครบถ้วนความปลอดภัยและ ข้อกำหนด ของISO/IEC 9126เช่น ความสามารถ ความน่าเชื่อถือประสิทธิภาพการพกพาการบำรุงรักษาความ เข้ากันได้ และความสามารถในการใช้งาน

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

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

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

กรณีทดสอบโดยทั่วไปประกอบด้วยตัวระบุที่ไม่ซ้ำกัน การอ้างอิงข้อกำหนดจากข้อกำหนดการออกแบบ เงื่อนไขเบื้องต้น เหตุการณ์ ชุดขั้นตอน (หรือที่เรียกว่าการกระทำ) ที่ต้องปฏิบัติตาม ข้อมูลนำเข้า ข้อมูลส่งออก ผลลัพธ์ที่คาดหวัง และผลลัพธ์จริง ตามคำจำกัดความทางคลินิก กรณีทดสอบคือข้อมูลนำเข้าและผลลัพธ์ที่คาดหวัง^{[ 87 ]}ซึ่งอาจกระชับได้ เช่น "สำหรับเงื่อนไข x ผลลัพธ์ที่ได้คือ y" แม้ว่าโดยปกติแล้วกรณีทดสอบจะอธิบายรายละเอียดเพิ่มเติมเกี่ยวกับสถานการณ์นำเข้าและผลลัพธ์ที่อาจคาดหวังได้ อาจเป็นชุดขั้นตอน (แต่บ่อยครั้งที่ขั้นตอนต่างๆ จะอยู่ในขั้นตอนการทดสอบแยกต่างหากที่สามารถใช้กับกรณีทดสอบหลายกรณีได้ เพื่อความประหยัด) แต่มีผลลัพธ์ที่คาดหวังหรือผลลัพธ์ที่คาดหวังเพียงอย่างเดียว ฟิลด์เสริม ได้แก่ รหัสกรณีทดสอบ ขั้นตอนการทดสอบ หรือหมายเลขลำดับการดำเนินการ ข้อกำหนดที่เกี่ยวข้อง ความลึก หมวดหมู่การทดสอบ ผู้เขียน และช่องทำเครื่องหมายสำหรับว่าการทดสอบนั้นสามารถทำให้เป็นอัตโนมัติได้หรือไม่ และได้ทำการทดสอบแบบอัตโนมัติแล้วหรือไม่ กรณีทดสอบขนาดใหญ่อาจมีสถานะหรือขั้นตอนเบื้องต้น และคำอธิบายเพิ่มเติม กรณีทดสอบควรมีที่สำหรับผลลัพธ์จริงด้วย ขั้นตอนเหล่านี้สามารถบันทึกไว้ในเอกสารประมวลผลคำ สเปรดชีต ฐานข้อมูล หรือแหล่งเก็บข้อมูลทั่วไปอื่นๆ ในระบบฐานข้อมูล คุณอาจสามารถดูผลการทดสอบในอดีต ผู้ที่สร้างผลลัพธ์ และการกำหนดค่าระบบที่ใช้ในการสร้างผลลัพธ์เหล่านั้นได้ด้วย โดยปกติแล้วผลลัพธ์ในอดีตเหล่านี้จะถูกจัดเก็บไว้ในตารางแยกต่างหาก

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

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

ซอฟต์แวร์ เครื่องมือ ตัวอย่างข้อมูลขาเข้าและขาออก และการกำหนดค่าต่างๆ ทั้งหมดนี้เรียกรวมกันว่า " ชุดทดสอบ "

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

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

ประเด็นถกเถียง สำคัญๆ เกี่ยวกับ การทดสอบซอฟต์แวร์ได้แก่:

วิธีการแบบ Agile เทียบกับวิธีการแบบดั้งเดิม

ผู้ทดสอบควรเรียนรู้ที่จะทำงานภายใต้สภาวะความไม่แน่นอนและการเปลี่ยนแปลงอย่างต่อเนื่อง หรือควรตั้งเป้าหมายไปที่"ความสมบูรณ์" ของกระบวนการ ? การเคลื่อนไหว การทดสอบแบบ Agileได้รับความนิยมเพิ่มขึ้นตั้งแต่ต้นทศวรรษ 2000 โดยส่วนใหญ่ในแวดวงธุรกิจ^{[ 89 ] [ 90 ]}ในขณะที่ผู้ให้บริการซอฟต์แวร์ของรัฐบาลและกองทัพ^{[ 91 ]}ใช้ระเบียบวิธีนี้ แต่ก็ยังใช้โมเดลการทดสอบแบบดั้งเดิม (เช่น ในโมเดล Waterfall ) ^{[ 92 ]}

การทดสอบด้วยตนเองเทียบกับการทดสอบอัตโนมัติ

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

มาตรฐานการทดสอบซอฟต์แวร์ ISO 29119มีความจำเป็นหรือไม่?

มีการต่อต้านอย่างมากจากกลุ่มผู้ที่เน้นบริบทในการทดสอบซอฟต์แวร์เกี่ยวกับมาตรฐาน ISO 29119 สมาคมการทดสอบระดับมืออาชีพ เช่น สมาคมการทดสอบซอฟต์แวร์ระหว่างประเทศ ได้พยายามให้มีการยกเลิกมาตรฐานดังกล่าว^{[ 94 ] [ 95 ]}

ผู้ปฏิบัติงานบางรายกล่าวว่า สาขาการทดสอบยังไม่พร้อมสำหรับการรับรอง

^{[ 96 ]}ปัจจุบันไม่มีการรับรองใดที่กำหนดให้ผู้สมัครต้องแสดงความสามารถในการทดสอบซอฟต์แวร์ ไม่มีใบรับรองใดที่อิงตามองค์ความรู้ที่เป็นที่ยอมรับกันอย่างกว้างขวาง การรับรองนั้นไม่สามารถวัดผลผลิต ทักษะ หรือความรู้เชิงปฏิบัติของแต่ละบุคคลได้ และไม่สามารถรับประกันความสามารถหรือความเป็นมืออาชีพในฐานะผู้ทดสอบได้ ^{[ 97 ]}

งานวิจัยต่างๆ เคยแสดงให้เห็นถึงค่าใช้จ่ายที่เกี่ยวข้องกับการแก้ไขข้อบกพร่อง

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

โดยทั่วไปเชื่อกันว่ายิ่งพบข้อบกพร่องเร็วเท่าไร ค่าใช้จ่ายในการแก้ไขก็จะยิ่งถูกลงเท่านั้น ตารางต่อไปนี้แสดงค่าใช้จ่ายในการแก้ไขข้อบกพร่องโดยขึ้นอยู่กับขั้นตอนที่พบ^{[ 98 ]}ตัวอย่างเช่น หากพบปัญหาในข้อกำหนดหลังจากปล่อยเวอร์ชันแล้ว ค่าใช้จ่ายในการแก้ไขจะสูงกว่าถึง 10-100 เท่า หากพบปัญหาตั้งแต่ขั้นตอนการตรวจสอบข้อกำหนดแล้ว ด้วยการเกิดขึ้นของ แนวทาง การปรับใช้แบบต่อเนื่อง สมัยใหม่ และบริการบนคลาวด์ ค่าใช้จ่ายในการปรับใช้ใหม่และการบำรุงรักษาอาจลดลงเมื่อเวลาผ่านไป

ค่าใช้จ่ายในการแก้ไขข้อบกพร่อง		ตรวจพบเวลา
		ความต้องการ	สถาปัตยกรรม	การก่อสร้าง	การทดสอบระบบ	หลังการวางจำหน่าย
เวลาได้แนะนำ	ความต้องการ	1×	3×	5–10 เท่า	10 เท่า	10–100 เท่า
	สถาปัตยกรรม	–	1×	10 เท่า	15×	25–100 เท่า
	การก่อสร้าง	–	–	1×	10 เท่า	10–25 เท่า

ข้อมูลที่ใช้ในการสร้างตารางนี้มีน้อยมาก ลอเรนต์ บอสซาวิต กล่าวในการวิเคราะห์ของเขาว่า:

ปรากฏว่ากราฟ "โครงการขนาดเล็ก" มาจากทีมของนักศึกษาปีหนึ่งเพียงสองทีมเท่านั้น ซึ่งเป็นขนาดตัวอย่างที่เล็กมากจนการสรุปผลไปยัง "โครงการขนาดเล็กโดยทั่วไป" นั้นไม่สามารถยอมรับได้เลย งานวิจัยของ GTE ไม่ได้อธิบายข้อมูลใดๆ นอกจากการบอกว่ามาจากสองโครงการ โครงการหนึ่งขนาดใหญ่และอีกโครงการหนึ่งขนาดเล็ก เอกสารที่อ้างถึงสำหรับโครงการ "Safeguard" ของ Bell Labs ระบุไว้อย่างชัดเจนว่าไม่ได้รวบรวมข้อมูลที่มีรายละเอียดสูงอย่างที่ข้อมูลของ Boehm ชี้ให้เห็น งานวิจัยของ IBM (เอกสารของ Fagan) มีข้อกล่าวอ้างที่ดูเหมือนจะขัดแย้งกับกราฟของ Boehm และไม่มีผลลัพธ์เชิงตัวเลขใดๆ ที่สอดคล้องกับข้อมูลของเขาอย่างชัดเจน

โบห์มไม่ได้อ้างอิงเอกสารใดๆ สำหรับข้อมูล TRW เลย ยกเว้นตอนที่เขียนบทความสำหรับ "Making Software" ในปี 2010 ซึ่งเขาได้อ้างอิงบทความต้นฉบับปี 1976 มีงานวิจัยขนาดใหญ่ที่ดำเนินการที่ TRW ในช่วงเวลาที่เหมาะสมซึ่งโบห์มสามารถอ้างอิงได้ แต่เอกสารนั้นไม่มีข้อมูลประเภทที่จะสนับสนุนข้ออ้างของโบห์ม^{[ 99 ]}

• Meyer, Bertrand (สิงหาคม 2008). "หลักการทดสอบซอฟต์แวร์เจ็ดประการ" (PDF) . Computer . Vol. 41, no. 8. หน้า  99–101 . doi : 10.1109/MC.2008.306 . สืบค้นเมื่อ21 พฤศจิกายน 2017 .

วิกิมีเดียคอมมอนส์มีสื่อที่เกี่ยวข้องกับ การ ทดสอบซอฟต์แวร์

ที่Wikiversityคุณสามารถเรียนรู้เพิ่มเติมและสอนผู้อื่นเกี่ยวกับการทดสอบซอฟต์แวร์ ได้ ที่ภาควิชาการทดสอบซอฟต์แวร์

• "ซอฟต์แวร์ที่ทำให้ซอฟต์แวร์ดียิ่งขึ้น" Economist.com
• การทดสอบซอฟต์แวร์ด้วยโมเดลภาษาขนาดใหญ่: การสำรวจ ภูมิทัศน์ และวิสัยทัศน์