ฉันเขียนซอฟต์แวร์ทดสอบคอมพิวเตอร์ส่วนใหญ่เมื่อ 25 ปีที่แล้ว ฉันชี้ไปที่หนังสือหลายเล่มที่ฉันคิดว่าล้าสมัยหรือผิดไป ดูhttp://www.kaner.com/pdfs/TheOngoingRevolution.pdf
คุณสามารถดูเพิ่มเติม (มุมมองปัจจุบัน แต่ไม่มีตัวชี้ชัดเจนกลับไปที่ TCS) ที่เว็บไซต์ของฉันสำหรับหลักสูตรการทดสอบซอฟต์แวร์กล่องดำ (วิดีโอและสไลด์ให้บริการฟรี), www.testingeducation.org/BBST
วัฒนธรรมการทดสอบในตอนนั้นเป็นสิ่งยืนยันอย่างมาก
ในการทดสอบที่ทันสมัยวิธีการทดสอบหน่วยนั้นได้รับการยืนยันแล้ว - เราเขียนคอลเลกชันการทดสอบอัตโนมัติจำนวนมากซึ่งเพียงตรวจสอบว่าซอฟต์แวร์ยังคงทำงานได้ตามที่ตั้งใจไว้ การทดสอบทำหน้าที่เป็นตัวตรวจจับการเปลี่ยนแปลง - ถ้ามีบางอย่างในส่วนอื่น ๆ ของรหัสและส่วนนี้มีปัญหาหรือถ้าค่าข้อมูลที่เคยเป็นไปไม่ได้ในโลกแห่งความเป็นจริงกำลังมาถึงแอพพลิเคชั่นแล้ว โปรแกรมเมอร์เพื่อแก้ไขปัญหาการบำรุงรักษา
ฉันคิดว่าความคิดเชิงยืนยันนั้นเหมาะสมสำหรับการทดสอบหน่วย แต่ลองจินตนาการถึงโลกที่การทดสอบระบบทั้งหมดเป็นการยืนยัน (สำหรับผู้ที่มีความแตกต่างโปรดตีความ "การทดสอบการรวมระบบ" และ "การทดสอบการยอมรับ" ซึ่งรวมอยู่ในข้อคิดเห็นของฉันในระบบ การทดสอบ) จุดประสงค์ของการทดสอบคือเพื่อยืนยันว่าโปรแกรมตรงตามข้อกำหนดของมันและวิธีการที่โดดเด่นคือการสร้างการทดสอบการถดถอยระดับระบบ (zillion หรืออย่างน้อยสองสามร้อย) ที่ทดสอบส่วนของข้อมูลจำเพาะกับพฤติกรรมของโปรแกรม (ฉันคิดว่าการยืนยันแบบเจาะจงเพื่อพฤติกรรมมีประโยชน์ แต่ฉันคิดว่ามันเป็นส่วนเล็ก ๆ ของวัตถุประสงค์ที่ใหญ่กว่า)
ยังคงมีกลุ่มทดสอบที่ดำเนินการในลักษณะนี้ แต่มันก็ไม่ใช่มุมมองที่โดดเด่นอีกต่อไป ย้อนกลับไปตอนนั้น ฉันเขียนอย่างเด่นชัดและดึงความแตกต่างที่คมชัดเพื่อให้ชี้ไปยังผู้ที่ได้รับการฝึกฝนอย่างต่อเนื่องในความคิดนี้ วันนี้ความแตกต่างที่คมชัดบางส่วน (รวมถึงที่ยกมาที่นี่) ล้าสมัย พวกเขาตีความผิดว่าเป็นการโจมตีในมุมมองที่ผิด
อย่างที่ฉันเห็นการทดสอบซอฟต์แวร์เป็นกระบวนการเชิงประจักษ์สำหรับการเรียนรู้ข้อมูลที่เกี่ยวข้องกับคุณภาพเกี่ยวกับผลิตภัณฑ์หรือบริการซอฟต์แวร์
การทดสอบควรออกแบบเพื่อเปิดเผยข้อมูลที่เป็นประโยชน์
ย้อนกลับไปโดยวิธีการที่ไม่มีใครพูดคุยเกี่ยวกับการทดสอบเป็นวิธีการเปิดเผย "ข้อมูล" ย้อนกลับไปการทดสอบนั้นใช้สำหรับ (บางรุ่น ... ) ค้นหาข้อบกพร่องหรือ (บางรุ่น ... ) กำลังตรวจสอบ (ตรวจสอบ) โปรแกรมกับข้อกำหนด ฉันไม่คิดว่าการยืนยันว่าการทดสอบมีไว้เพื่อเปิดเผยข้อมูลที่เป็นประโยชน์เข้ามาในคำศัพท์การทดสอบจนกระทั่งศตวรรษนี้
ลองนึกภาพการทดสอบการให้คะแนนในแง่ของค่าข้อมูลของพวกเขา การทดสอบที่น่าจะสอนเราบางอย่างที่เราไม่รู้เกี่ยวกับซอฟต์แวร์จะมีค่าข้อมูลสูงมาก การทดสอบที่มีแนวโน้มมากที่จะยืนยันบางสิ่งบางอย่างที่เราคาดว่าจะได้รับและแสดงให้เห็นแล้วหลายครั้งก่อนหน้านี้จะมีค่าข้อมูลต่ำ วิธีหนึ่งในการจัดลำดับความสำคัญการทดสอบคือการรันการทดสอบค่าข้อมูลที่สูงขึ้นก่อนการทดสอบค่าข้อมูลที่ต่ำกว่า
ถ้าฉันจะใช้การจัดลำดับความสำคัญเกินความสำคัญนี้เพื่อที่จะดึงดูดความสนใจของโปรแกรมเมอร์ผู้จัดการโครงการหรือผู้จัดการกระบวนการที่มีความรู้เกี่ยวกับการทดสอบซอฟต์แวร์ฉันจะพูดว่า "การทดสอบที่ไม่ได้ออกแบบมาเพื่อเปิดเผย BUG เป็นเวลานาน ." มันไม่ใช่การแปลที่สมบูรณ์แบบ แต่สำหรับผู้อ่านที่ไม่สามารถหรือจะไม่เข้าใจความละเอียดหรือคุณสมบัติใด ๆ นั่นก็ใกล้เคียงที่สุดเท่าที่จะเป็นไปได้
ย้อนกลับไปและฉันเห็นอีกครั้งที่นี่บางคนที่ไม่เข้าใจการทดสอบจะตอบสนองว่าการทดสอบที่ออกแบบมาเพื่อค้นหามุมกรณีเสียเวลาเมื่อเทียบกับการทดสอบการใช้งานที่สำคัญของฟังก์ชั่นหลัก พวกเขาไม่เข้าใจสองสิ่ง ครั้งแรกโดยผู้ทดสอบหาเวลาเพื่อตรวจสอบค่าขอบเขตการใช้งานที่สำคัญของฟังก์ชั่นหลักได้รับการออกกำลังกายหลายครั้งแล้ว (ใช่มีข้อยกเว้นและกลุ่มการทดสอบส่วนใหญ่จะให้ความสนใจกับข้อยกเว้นเหล่านั้นอย่างระมัดระวัง) ประการที่สองเหตุผลในการทดสอบที่มีค่ามากที่สุดคือโปรแกรมนั้นมีแนวโน้มที่จะล้มเหลวด้วยค่าที่มากที่สุด ถ้ามันไม่ได้ล้มเหลวอย่างสุดขีดคุณจะต้องลองอย่างอื่น นี่เป็นกฎที่มีประสิทธิภาพ ในทางกลับกันถ้ามันล้มเหลวด้วยค่าที่มากเกินไปผู้ทดสอบอาจหยุดและรายงานข้อผิดพลาดหรือผู้ทดสอบอาจแก้ไขปัญหาเพิ่มเติม เพื่อดูว่าโปรแกรมล้มเหลวในลักษณะเดียวกันกับค่าปกติมากกว่าหรือไม่ ใครทำการแก้ไขปัญหานั้น (ผู้ทดสอบหรือโปรแกรมเมอร์) เป็นเรื่องของวัฒนธรรมองค์กร บริษัท บางแห่งกำหนดงบประมาณเวลาของผู้ทดสอบสำหรับเรื่องนี้บางคนวางแผนงบประมาณโปรแกรมเมอร์และบางคนคาดหวังว่าโปรแกรมเมอร์จะแก้ไขข้อผิดพลาดที่มุมกรณีไม่ว่าจะเป็นแบบทั่วไปหรือไม่เพื่อให้การแก้ไขปัญหาไม่เกี่ยวข้อง ความเข้าใจผิดที่พบบ่อย - ผู้ทดสอบกำลังเสียเวลา (มากกว่าการเพิ่มประสิทธิภาพสูงสุด) โดยการทดสอบค่าสุดขีดเป็นอีกเหตุผลหนึ่งที่ "การทดสอบที่ไม่ได้ออกแบบมาเพื่อเปิดเผยข้อผิดพลาดคือการเสียเวลา" เป็นข้อความที่เหมาะสมสำหรับผู้ทดสอบ มันเป็นข้อแตกต่างจากการให้กำลังใจจากโปรแกรมเมอร์บางคนถึง (โดยผล) ไม่เคยทำการทดสอบที่อาจท้าทายโปรแกรม ข้อความนี้มีขนาดใหญ่เกินไป แต่การสนทนาทั้งหมดนั้นมีขนาดใหญ่เกินไป
โดยวิธีการ "ค่าข้อมูล" ไม่สามารถเป็นระบบการจัดลำดับความสำคัญเท่านั้น มันไม่ใช่กฎของฉันเมื่อฉันออกแบบชุดทดสอบหน่วย ไม่ใช่กฎของฉันเมื่อฉันออกแบบการทดสอบการตรวจสอบบิลด์ ในทั้งสองกรณีนี้ฉันสนใจประเภทการครอบคลุมมากกว่าพลังของการทดสอบรายบุคคล มีอีกหลายกรณี (เช่นการทดสอบอัตโนมัติในปริมาณมากที่ราคาถูกตั้งค่ารันและตรวจสอบ) ซึ่งพลังของการทดสอบแต่ละรายการนั้นไม่เกี่ยวข้องกับการออกแบบของฉัน ฉันแน่ใจว่าคุณสามารถคิดถึงตัวอย่างเพิ่มเติมได้
แต่ตามกฎทั่วไปถ้าฉันสามารถระบุเพียงหนึ่งกฎเท่านั้น (เช่นการพูดกับผู้บริหารที่หัวหน้าหัวระเบิดถ้าเขาพยายามประมวลผลมากกว่าหนึ่งประโยค) มันอาจเป็นไปได้ว่าการทดสอบข้อมูลที่มีค่าต่ำมักเป็นการเสียเวลาเปล่า