การตรวจสอบและการตรวจสอบเป็นส่วนหนึ่งของกระบวนการทดสอบหรือไม่

จากแหล่งข้อมูลหลายแห่งฉันไม่เชื่อว่าคำจำกัดความง่ายๆที่เป้าหมายของการทดสอบคือการค้นหาข้อบกพร่องให้ได้มากที่สุด - เราทำการทดสอบเพื่อให้แน่ใจว่ามันใช้งานได้หรือไม่ เช่น followint เป็นเป้าหมายของการทดสอบแบบฟอร์ม ISTQB:

1. ตรวจสอบว่า (ผลิตภัณฑ์ซอฟต์แวร์) เป็นไปตามข้อกำหนดที่ระบุไว้ (ฉันคิดว่าเป็นของจริง)

2. แสดงให้เห็นว่า (ผลิตภัณฑ์ซอฟต์แวร์) เหมาะสำหรับวัตถุประสงค์ (ฉันคิดว่าเป็นการตรวจสอบ)

3. ตรวจหาข้อบกพร่อง

   ฉันยอมรับว่าการทดสอบคือการตรวจสอบความถูกต้องและการตรวจจับข้อบกพร่อง ถูกต้องหรือไม่

ฉันคิดว่าคุณเข้าใจถูกต้อง

1. การตรวจสอบและการตรวจสอบความถูกต้องเป็นสิ่งที่แตกต่างกันและในความเป็นจริงแล้วค่อนข้างชัดเจน แม้ว่าฉันไม่ชอบเอกสารมาก ISO 9000ff มีความเกี่ยวข้องอย่างมากกับ QA และกำหนดการตรวจสอบว่าเป็นการเปรียบเทียบผลิตภัณฑ์กับข้อกำหนดและการตรวจสอบความถูกต้องเป็นการตรวจสอบว่าเหมาะสมกับความต้องการของลูกค้า / ผู้ใช้จริงหรือไม่ .

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

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

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

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

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

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

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

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

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

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

ความแตกต่างที่สำคัญอยู่ในใจของผู้ทดสอบ มันง่ายกว่ามากในการสร้างเคสทดสอบซึ่งแสดงว่าซอฟต์แวร์ทำงานได้ตามที่ต้องการ (ตรวจสอบความสอดคล้อง) กว่าสร้างเคสทดสอบซึ่งแสดงว่าซอฟต์แวร์ล้มเหลว (ค้นหาข้อบกพร่อง)

ผู้ทดสอบที่ยอดเยี่ยมมีความหลงใหลในการทำลายซอฟต์แวร์ไม่ใช่การออกกำลังกายอย่างปลอดภัย

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

ดังนั้นสำหรับส่วนนั้นของคำถามการค้นหาข้อบกพร่องและการตรวจสอบอาจเป็นเพียงสองด้านของกระบวนการเดียวกัน:

• การทดสอบล้มเหลว: พบข้อบกพร่อง

• การทดสอบผ่าน: การตรวจสอบเสร็จสิ้น (อย่างน้อยในระดับหนึ่งหากคุณมีการทดสอบที่เพียงพอและเหมาะสม)

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

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

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

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

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