7 หลักการทดสอบ ISTQB ที่สำคัญ | #3 ขั้นตอนแรกในการทดสอบซอฟต์แวร์

การทดสอบซอฟต์แวร์ที่แม่นยำและถูกต้องนั้นเป็นไปตามหลักการหลายประการ International Software Testing Qualifications Board แยกความแตกต่างพื้นฐานเจ็ดประการ ซึ่งเราจะพูดถึงในวันนี้ อยากรู้อยากเห็นเพื่อหา? อ่านบทความเกี่ยวกับหลักการทดสอบ ISTQB ที่สำคัญ!

หลักการทดสอบ ISTQB – สารบัญ:

1. การทดสอบพบข้อบกพร่องแต่ไม่สามารถพิสูจน์ได้ว่าไม่มี
2. การทดสอบอย่างละเอียดเป็นไปไม่ได้
3. การทดสอบในช่วงต้นช่วยประหยัดเวลาและค่าใช้จ่าย
4. เอฟเฟกต์ก้อนหิมะทำงานผิดปกติ
5. ความขัดแย้งของสารกำจัดศัตรูพืช
6. ขึ้นอยู่กับบริบท
7. การโฆษณาซอฟต์แวร์ไร้ที่ติเป็นสิ่งที่ไม่ต้องทำ
8. สรุป

การทดสอบพบข้อบกพร่องแต่ไม่สามารถพิสูจน์ได้ว่าไม่มี

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

การทดสอบอย่างละเอียดเป็นไปไม่ได้

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

การทดสอบในช่วงต้นช่วยประหยัดเวลาและค่าใช้จ่าย

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

• การทดสอบแบบสถิต – การประเมินผลิตภัณฑ์ tne โดยไม่ต้องรันโค้ด
• การทดสอบแบบไดนามิก – การประเมินโค้ดของโมดูลหรือระบบระหว่างการปฏิบัติงาน

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

เอฟเฟกต์ก้อนหิมะทำงานผิดปกติ

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

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

ความขัดแย้งของสารกำจัดศัตรูพืช

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

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

ขึ้นอยู่กับบริบท

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

การโฆษณาซอฟต์แวร์ไร้ที่ติเป็นสิ่งที่ไม่ต้องทำ

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

หลักการทดสอบ ISTQB – สรุป

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

การทดสอบซอฟต์แวร์คืออะไร? ตอนนี้คุณรู้คำตอบแล้ว! ตรวจสอบชุดอื่นๆ ของเราเกี่ยวกับ Python และ Javascript!

หากคุณชอบเนื้อหาของเรา เข้าร่วมชุมชนผึ้งที่วุ่นวายบน Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest

ผู้เขียน: โรเบิร์ต วิทนีย์

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

ดูกระทู้ทั้งหมด

ขั้นตอนแรกในการทดสอบซอฟต์แวร์:

1. การทดสอบซอฟต์แวร์คืออะไร?
2. 1 ความจริงที่ยิ่งใหญ่เกี่ยวกับข้อผิดพลาดของซอฟต์แวร์
3. หลักการทดสอบ ISTQB หลักเจ็ดประการ
4. 6 ขั้นตอนของSTLC
5. การทดสอบกับการดีบัก
6. การตรวจสอบและรับรองความถูกต้องในกระบวนการทดสอบซอฟต์แวร์