วิธีทดสอบซอฟต์แวร์: โมเดล QA

วิธีการทดสอบซอฟต์แวร์คืออะไร?

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

หมายเหตุ: เนื่องจากการทดสอบซอฟต์แวร์เป็นส่วนสำคัญของวิธีการพัฒนา บริษัทหลายแห่งจึงใช้คำว่า Development Methodologies & Testing Methodologies เรียกขานกันทั่วไป ดังนั้นวิธีการทดสอบยังสามารถอ้างถึงโมเดล Waterfall, Agile และ QA อื่นๆ เมื่อเทียบกับคำจำกัดความข้างต้นของวิธีการทดสอบ การอภิปรายเกี่ยวกับการทดสอบประเภทต่างๆ ไม่ได้เพิ่มมูลค่าให้กับผู้อ่าน ดังนั้นเราจะหารือเกี่ยวกับรูปแบบการพัฒนาต่างๆ

วิธีการทดสอบ เทียบกับ ประเภทการทดสอบ เทียบกับ กลยุทธ์การทดสอบ

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

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

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

น้ำตกจำลอง

มันคืออะไร?

ตัว Vortex Indicator ได้ถูกนำเสนอลงในนิตยสาร แบบจำลองน้ำตก, ความก้าวหน้าในการพัฒนาซอฟต์แวร์ผ่านขั้นตอนต่างๆ เช่น การวิเคราะห์ความต้องการ, การออกแบบ ฯลฯ – ตามลำดับ.

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

แนวทางการทดสอบคืออะไร?

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

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

ในวิธีการนี้ ทีมทดสอบจะเข้าสู่ระยะถัดไปก็ต่อเมื่อระยะก่อนหน้าเสร็จสมบูรณ์เท่านั้น

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

การพัฒนาซ้ำๆ

มันคืออะไร?

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

แนวทางการทดสอบคืออะไร?

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

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

ระเบียบวิธีว่องไว

มันคืออะไร?

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

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

แนวทางการทดสอบคืออะไร?

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

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

การเขียนโปรแกรมสุดขีด

มันคืออะไร?

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

สำหรับนักพัฒนาโปรแกรมระดับ Extreme มักจะทำงานเป็นคู่

การเขียนโปรแกรมขั้นสูง ใช้ในสถานที่ที่ความต้องการของลูกค้าเปลี่ยนแปลงตลอดเวลา

แนวทางการทดสอบคืออะไร?

การเขียนโปรแกรมขั้นสูงเป็นไปตามการพัฒนาที่ขับเคลื่อนด้วยการทดสอบซึ่งอธิบายไว้ดังต่อไปนี้ -

1. เพิ่ม กรณีทดสอบ ไปยังชุดทดสอบเพื่อตรวจสอบฟังก์ชันการทำงานใหม่ที่ยังอยู่ในระหว่างการพัฒนา
2. รันการทดสอบทั้งหมด และแน่นอนว่ากรณีทดสอบใหม่ที่เพิ่มจะต้องล้มเหลว เนื่องจากฟังก์ชันการทำงานยังไม่ได้เขียนโค้ด
3. เขียนโค้ดเพื่อใช้คุณลักษณะ/ฟังก์ชันการทำงาน
4. เรียกใช้ชุดการทดสอบอีกครั้ง คราวนี้ กรณีทดสอบใหม่ควรผ่านเนื่องจากมีการเขียนโค้ดตามฟังก์ชันแล้ว

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

แบบจำลองตัววีและแบบจำลองเกลียว

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

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

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

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

ระเบียบวิธีซอฟต์แวร์ใดให้เลือก

มีวิธีการมากมายสำหรับการพัฒนาซอฟต์แวร์และการทดสอบที่เกี่ยวข้อง เทคนิคและวิธีการทดสอบแต่ละอย่างได้รับการออกแบบมาเพื่อวัตถุประสงค์เฉพาะและมีข้อดีและข้อเสียที่สัมพันธ์กัน

การเลือกวิธีการเฉพาะขึ้นอยู่กับหลายปัจจัย เช่น ลักษณะของโครงการ ความต้องการของลูกค้า กำหนดการของโครงการ เป็นต้น

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

จะตั้งค่าวิธีการทดสอบซอฟต์แวร์ได้อย่างไร?

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

การกำหนด

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

การส่งมอบที่กำหนด

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

แนวทางการทดสอบ

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

การรายงาน

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

คำถามที่พบบ่อย