การทดสอบแบบ Agile คืออะไร? กระบวนการและวงจรชีวิต
การทดสอบแบบ Agile คืออะไร?
การทดสอบเปรียว เป็นแนวทางปฏิบัติการทดสอบที่เป็นไปตามกฎและหลักการของการพัฒนาซอฟต์แวร์แบบอไจล์ ต่างจากวิธี Waterfall ตรงที่ Agile Testing สามารถเริ่มต้นตั้งแต่เริ่มต้นโปรเจ็กต์โดยมีการบูรณาการอย่างต่อเนื่องระหว่างการพัฒนาและการทดสอบ วิธีการทดสอบแบบ Agile ไม่ใช่แบบต่อเนื่อง (ในแง่ที่ว่าจะดำเนินการหลังจากขั้นตอนการเขียนโค้ดเท่านั้น) แต่เป็นแบบต่อเนื่อง
หลักการทดสอบแบบ Agile
ต่อไปนี้เป็นหลักการสำคัญของการทดสอบแบบ Agile:
- ในรูปแบบการทดสอบแบบ Agile นี้ ซอฟต์แวร์ที่ใช้งานได้คือตัวชี้วัดความก้าวหน้าหลัก
- ผลลัพธ์ที่ดีที่สุดสามารถทำได้โดยทีมงานที่จัดการด้วยตนเอง
- การส่งมอบซอฟต์แวร์อันทรงคุณค่าตั้งแต่เนิ่นๆ และต่อเนื่องถือเป็นสิ่งสำคัญสูงสุดของเรา
- นักพัฒนาซอฟต์แวร์จะต้องรวมตัวกันทุกวันตลอดทั้งโครงการ
- เพิ่มความคล่องตัวด้วยการปรับปรุงทางเทคนิคอย่างต่อเนื่องและการออกแบบที่ดี
- การทดสอบแบบ Agile ช่วยให้มั่นใจได้ว่าผลิตภัณฑ์ขั้นสุดท้ายจะตรงตามความคาดหวังของธุรกิจโดยการให้ข้อเสนอแนะอย่างต่อเนื่อง
- ในกระบวนการ Agile Test เราจำเป็นต้องดำเนินกระบวนการทดสอบระหว่างการใช้งาน ซึ่งจะช่วยลดเวลาในการพัฒนา
- กระบวนการทดสอบใน Agile ควรดำเนินไปอย่างต่อเนื่อง
- ให้ใคร่ครวญอย่างสม่ำเสมอเกี่ยวกับวิธีการที่จะมีประสิทธิภาพมากขึ้น
- สถาปัตยกรรม ความต้องการ และการออกแบบที่ดีที่สุดเกิดจากการจัดระเบียบทีมด้วยตนเอง
- ทุกครั้งที่ทีมพบกันจะทบทวนและปรับพฤติกรรมให้มีประสิทธิภาพมากขึ้น
- การสนทนาแบบเห็นหน้ากับทีมพัฒนาเป็นวิธีการที่มีประสิทธิภาพและประสิทธิผลสูงสุดในการถ่ายทอดข้อมูลภายในทีม
การทดสอบ Agile มีหลักการต่างๆ มากมายที่ช่วยเราเพิ่มประสิทธิภาพการทำงานของซอฟต์แวร์
วงจรชีวิตการทดสอบแบบ Agile
วงจรชีวิตการทดสอบแบบ Agile เสร็จสมบูรณ์ใน 5 เฟสที่แตกต่างกัน ดังที่เราเห็นได้จากภาพต่อไปนี้:
ขั้นตอนการทดสอบกระบวนการ Agile มีดังนี้
ระยะที่ 1: การประเมินผลกระทบ: ในระยะเริ่มแรกนี้ เรารวบรวมข้อมูลจากผู้มีส่วนได้ส่วนเสียและผู้ใช้ ระยะนี้เรียกอีกอย่างว่าระยะป้อนกลับ เนื่องจากช่วยวิศวกรทดสอบในการกำหนดวัตถุประสงค์สำหรับวงจรชีวิตถัดไป
ระยะที่ 2: การวางแผนการทดสอบแบบ Agile: เป็นระยะที่สองของวงจรการทดสอบแบบ Agile ซึ่งผู้มีส่วนได้ส่วนเสียทั้งหมดมารวมตัวกันเพื่อวางแผนกำหนดการของกระบวนการทดสอบและการส่งมอบ
ระยะที่ 3: ความพร้อมในการเปิดตัว: ในขั้นตอนนี้ เราจะตรวจสอบฟีเจอร์ที่ได้รับการพัฒนา/ใช้งานว่าพร้อมเผยแพร่หรือไม่ ในขั้นตอนนี้ จะมีการตัดสินใจว่าจะต้องย้อนกลับไปที่ขั้นตอนการพัฒนาครั้งก่อนด้วย
ระยะที่ 4: การแย่งชิงรายวัน: ขั้นตอนนี้รวมการประชุมทุกเช้าเพื่อติดตามสถานะการทดสอบและตั้งเป้าหมายตลอดทั้งวัน
ระยะที่ 5: ทดสอบความคล่องตัว Revเอียว: ขั้นตอนสุดท้ายของวงจรชีวิตแบบ Agile คือความคล่องตัว Revนั่นคือการประชุม ประกอบด้วยการประชุมรายสัปดาห์กับผู้มีส่วนได้ส่วนเสียเพื่อประเมินและประเมินความก้าวหน้าตามเป้าหมายอย่างสม่ำเสมอ
แผนการทดสอบแบบเปรียว
แผนการทดสอบแบบเปรียว รวมถึงประเภทของการทดสอบที่ทำในการวนซ้ำนั้น เช่น ข้อกำหนดข้อมูลการทดสอบ โครงสร้างพื้นฐาน สภาพแวดล้อมการทดสอบและผลการทดสอบ แผนการทดสอบจะถูกเขียนและอัปเดตสำหรับทุกรุ่น ซึ่งต่างจากโมเดล Waterfall ตรงที่ในโมเดล Agile แผนการทดสอบทั่วไปใน Agile ประกอบด้วย
- ขอบเขตการทดสอบ
- ฟังก์ชั่นใหม่ที่กำลังทดสอบ
- ระดับหรือประเภทของการทดสอบตามความซับซ้อนของคุณลักษณะ
- การทดสอบโหลดและประสิทธิภาพ
- การพิจารณาโครงสร้างพื้นฐาน
- แผนบรรเทาผลกระทบหรือความเสี่ยง
- การจัดสรรทรัพยากร
- การส่งมอบและเหตุการณ์สำคัญ
กลยุทธ์การทดสอบแบบคล่องตัว
วงจรชีวิตของการทดสอบแบบ Agile ครอบคลุมสี่ขั้นตอน
0 ซ้ำ
ระหว่างขั้นตอนแรกหรือการวนซ้ำ 0 คุณจะดำเนินการงานการตั้งค่าเบื้องต้น ซึ่งได้แก่ การระบุบุคลากรสำหรับการทดสอบ การติดตั้งเครื่องมือทดสอบ การจัดตารางทรัพยากร (ห้องทดลองการทดสอบการใช้งาน) เป็นต้น ขั้นตอนต่อไปนี้ได้รับการกำหนดไว้เพื่อให้สำเร็จในการวนซ้ำ 0
- การสร้างกรณีธุรกิจสำหรับโครงการ
- กำหนดเงื่อนไขขอบเขตและขอบเขตของโครงการ
- สรุปข้อกำหนดหลักและกรณีการใช้งานที่จะผลักดันให้เกิดข้อด้อยด้านการออกแบบ
- โครงร่างสถาปัตยกรรมผู้สมัครหนึ่งรายการหรือมากกว่า
- การระบุความเสี่ยง
- ประมาณการต้นทุนและจัดทำโครงการเบื้องต้น
การก่อสร้างซ้ำ
ขั้นตอนที่สองของวิธีการทดสอบแบบ Agile คือ Construction Iterations การทดสอบส่วนใหญ่จะเกิดขึ้นในระหว่างขั้นตอนนี้ ระยะนี้ถูกมองว่าเป็นชุดของการวนซ้ำเพื่อสร้างส่วนเพิ่มของโซลูชัน ในการทำเช่นนั้น ภายในการวนซ้ำแต่ละครั้ง ทีมงานดำเนินการ การผสมผสานระหว่างแนวทางปฏิบัติจาก XP, Scrum, การสร้างแบบจำลอง Agile และข้อมูล Agile และอื่นๆ
ในการวนซ้ำของการก่อสร้าง ทีมงานที่คล่องตัวจะปฏิบัติตามแนวทางปฏิบัติด้านความต้องการที่ได้รับการจัดลำดับความสำคัญ: ในการวนซ้ำแต่ละครั้ง พวกเขาจะนำข้อกำหนดที่สำคัญที่สุดที่เหลืออยู่จากกลุ่มรายการงานและนำไปปฏิบัติ
การทำซ้ำการก่อสร้างแบ่งออกเป็นสองประเภท คือ การทดสอบเพื่อยืนยัน และการทดสอบเชิงสืบสวน การทดสอบเชิงยืนยันมีความเข้มข้น ในการตรวจสอบว่าระบบเป็นไปตามเจตนาของผู้มีส่วนได้ส่วนเสียตามที่อธิบายให้ทีมทราบจนถึงปัจจุบัน และดำเนินการโดยทีมงาน ขณะที่การทดสอบเชิงสืบสวนตรวจพบปัญหาที่ทีมงานยืนยันข้ามหรือเพิกเฉย ในการทดสอบเชิงสืบสวน ผู้ทดสอบจะกำหนดปัญหาที่อาจเกิดขึ้นในรูปแบบของเรื่องราวข้อบกพร่อง การทดสอบเชิงสืบสวนเกี่ยวข้องกับปัญหาทั่วไป เช่น การทดสอบบูรณาการ การทดสอบโหลด/ความเครียด และการทดสอบความปลอดภัย
อีกครั้งสำหรับการทดสอบเพื่อยืนยันมีสองด้าน การทดสอบของนักพัฒนา และ การทดสอบการยอมรับแบบคล่องตัว- เขาทั้งคู่ เป็นแบบอัตโนมัติเพื่อให้สามารถทดสอบการถดถอยอย่างต่อเนื่องตลอดวงจรการใช้งาน การทดสอบเพื่อยืนยันมีความคล่องตัวเทียบเท่ากับการทดสอบตามข้อกำหนด
การทดสอบการยอมรับแบบ Agile เป็นการผสมผสานระหว่างการทดสอบการทำงานแบบดั้งเดิมและการทดสอบการยอมรับแบบดั้งเดิมในฐานะทีมพัฒนา และผู้มีส่วนได้ส่วนเสียกำลังทำร่วมกัน ในขณะที่การทดสอบของนักพัฒนาซอฟต์แวร์เป็นการผสมผสานระหว่างการทดสอบหน่วยแบบดั้งเดิมและการทดสอบการรวมบริการแบบดั้งเดิม การทดสอบของนักพัฒนาจะตรวจสอบทั้งรหัสแอปพลิเคชันและสคีมาฐานข้อมูล
ปล่อยเกมจบหรือช่วงการเปลี่ยนภาพ
เป้าหมายของ "Release, End Game" คือการปรับใช้ระบบของคุณให้ประสบความสำเร็จในการผลิต กิจกรรมต่างๆ ในขั้นตอนนี้ ได้แก่ การฝึกอบรมผู้ใช้ปลายทาง เจ้าหน้าที่ฝ่ายสนับสนุน และเจ้าหน้าที่ฝ่ายปฏิบัติการ นอกจากนี้ยังรวมถึงการตลาดของการเปิดตัวผลิตภัณฑ์ การสำรองข้อมูลและการกู้คืน การจัดทำเอกสารระบบและคู่มือผู้ใช้ให้เสร็จสมบูรณ์
ขั้นตอนการทดสอบระเบียบวิธีแบบ Agile สุดท้ายประกอบด้วยการทดสอบระบบเต็มรูปแบบและการทดสอบการยอมรับ เพื่อให้ขั้นตอนการทดสอบสุดท้ายของคุณเสร็จสิ้นโดยไม่มีอุปสรรคใดๆ คุณควรทดสอบผลิตภัณฑ์อย่างเข้มงวดมากขึ้นในขณะที่อยู่ในขั้นตอนการก่อสร้าง ในช่วงท้ายเกม ผู้ทดสอบจะทำงานเกี่ยวกับเรื่องราวข้อบกพร่องของมัน
การผลิต
หลังจากระยะการเปิดตัว ผลิตภัณฑ์จะย้ายไปยังขั้นตอนการผลิต
Quadrant การทดสอบแบบ Agile
การทดสอบแบบ Agile จะแยกกระบวนการทั้งหมดออกเป็น 4 Quadrant และช่วยให้เข้าใจว่าการทดสอบแบบ Agile ดำเนินการอย่างไร
Agile Quadrant I
คุณภาพโค้ดภายในเป็นจุดสนใจหลักในควอแดรนท์นี้ และประกอบด้วยกรณีทดสอบที่ขับเคลื่อนด้วยเทคโนโลยีและนำไปใช้เพื่อสนับสนุนทีม ซึ่งได้แก่
- การทดสอบหน่วย
- การทดสอบส่วนประกอบ
Agile Quadrant II
ประกอบด้วยกรณีทดสอบที่ขับเคลื่อนธุรกิจและนำไปใช้เพื่อสนับสนุนทีม Quadrant นี้มุ่งเน้นไปที่ข้อกำหนด ประเภทของการทดสอบที่ทำในระยะนี้คือ
- การทดสอบตัวอย่างสถานการณ์และขั้นตอนการทำงานที่เป็นไปได้
- การทดสอบประสบการณ์ผู้ใช้เช่นต้นแบบ
- การทดสอบคู่
อไจล์ควอแดรนท์ III
จตุภาคนี้ให้ผลป้อนกลับกับจตุภาคที่หนึ่งและสอง กรณีทดสอบสามารถใช้เป็นพื้นฐานในการดำเนินการทดสอบระบบอัตโนมัติได้ ในควอแดรนท์นี้ จะมีการทบทวนซ้ำหลายรอบเพื่อสร้างความมั่นใจในผลิตภัณฑ์ ประเภทของการทดสอบที่ทำในควอแดรนท์นี้คือ
- การทดสอบการใช้งาน
- การทดสอบเชิงสำรวจ
- ทดสอบคู่กับลูกค้า
- การทดสอบการทำงานร่วมกัน
- การทดสอบการยอมรับของผู้ใช้
Agile Quadrant IV
ควอแดรนท์นี้มุ่งเน้นไปที่ข้อกำหนดที่ไม่สามารถใช้งานได้ เช่น ประสิทธิภาพ ความปลอดภัย ความเสถียร ฯลฯ ด้วยความช่วยเหลือของควอแดรนท์นี้ แอปพลิเคชันถูกสร้างขึ้นเพื่อส่งมอบคุณภาพที่ไม่สามารถใช้งานได้และมูลค่าที่คาดหวัง
- การทดสอบที่ไม่ใช้งาน เช่น การทดสอบความเครียดและประสิทธิภาพ
- การทดสอบความปลอดภัยด้วยความเคารพ การรับรอง และการแฮ็ก
- การทดสอบโครงสร้างพื้นฐาน
- การทดสอบการย้ายข้อมูล
- การทดสอบความสามารถในการปรับขนาด
- โหลดการทดสอบ
ความท้าทายด้าน QA ด้วยการพัฒนาซอฟต์แวร์ที่คล่องตัว
- โอกาสที่จะเกิดข้อผิดพลาดมีความคล่องตัวมากขึ้น เนื่องจากเอกสารได้รับการให้ความสำคัญน้อยกว่า ในที่สุดก็สร้างแรงกดดันให้กับทีม QA มากขึ้น
- มีการเปิดตัวฟีเจอร์ใหม่ๆ อย่างรวดเร็ว ซึ่งช่วยลดเวลาของทีมทดสอบในการระบุว่าฟีเจอร์ล่าสุดเป็นไปตามข้อกำหนดหรือไม่ และตรงกับความต้องการทางธุรกิจอย่างแท้จริงหรือไม่
- ผู้ทดสอบมักต้องมีบทบาทกึ่งนักพัฒนา
- รอบการดำเนินการทดสอบมีการบีบอัดสูง
- มีเวลาน้อยมากในการเตรียมแผนการทดสอบ
- สำหรับการทดสอบการถดถอย จะมีเวลาน้อยที่สุด
- เปลี่ยนบทบาทจากการเป็นผู้เฝ้าประตูคุณภาพมาเป็นพันธมิตรด้านคุณภาพ
- การเปลี่ยนแปลงข้อกำหนดและการอัปเดตมีอยู่ในวิธีการที่คล่องตัว ซึ่งกลายเป็นความท้าทายที่ใหญ่ที่สุดสำหรับ QA
ความเสี่ยงของระบบอัตโนมัติในกระบวนการ Agile
- UI แบบอัตโนมัติให้ความมั่นใจในระดับสูง แต่ดำเนินการได้ช้า ดูแลรักษาง่าย และมีค่าใช้จ่ายสูงในการสร้าง ระบบอัตโนมัติอาจไม่สามารถปรับปรุงประสิทธิภาพการทดสอบได้อย่างมีนัยสำคัญ เว้นแต่ผู้ทดสอบจะรู้วิธีการทดสอบ
- การทดสอบที่ไม่น่าเชื่อถือถือเป็นข้อกังวลหลักในการทดสอบอัตโนมัติ การแก้ไขการทดสอบที่ล้มเหลวและการแก้ไขปัญหาที่เกี่ยวข้องกับการทดสอบที่เปราะควรมีความสำคัญสูงสุดเพื่อหลีกเลี่ยงผลบวกลวง
- หากการทดสอบอัตโนมัติเริ่มต้นด้วยตนเองแทนที่จะดำเนินการผ่าน CI (Continuous Integration) แสดงว่ามีความเสี่ยงที่จะไม่ทำงานเป็นประจำ และอาจทำให้การทดสอบล้มเหลว
- การทดสอบอัตโนมัติไม่สามารถทดแทนการทดสอบด้วยตนเองเชิงสำรวจได้ เพื่อให้ได้คุณภาพตามที่คาดหวังของผลิตภัณฑ์ จำเป็นต้องมีประเภทการทดสอบและระดับผสมกัน
- เครื่องมืออัตโนมัติที่มีจำหน่ายในเชิงพาณิชย์จำนวนมากมีคุณสมบัติที่เรียบง่าย เช่น การบันทึกและเล่นซ้ำกรณีทดสอบด้วยตนเองโดยอัตโนมัติ เครื่องมือดังกล่าวสนับสนุนการทดสอบผ่าน UI และทำให้การทดสอบมีความเปราะบางและยากต่อการบำรุงรักษา นอกจากนี้ การจัดเก็บกรณีทดสอบนอกระบบควบคุมเวอร์ชันยังทำให้เกิดความซับซ้อนที่ไม่จำเป็นอีกด้วย
- เพื่อประหยัดเวลา หลายครั้งที่แผนการทดสอบระบบอัตโนมัติมีการวางแผนไม่ดีหรือไม่ได้วางแผนไว้ ซึ่งส่งผลให้การทดสอบล้มเหลว
- ขั้นตอนการตั้งค่าและการแยกการทดสอบมักจะพลาดไปในระหว่างการทดสอบอัตโนมัติ ในขณะที่การดำเนินการทดสอบด้วยตนเอง ขั้นตอนการตั้งค่าและการแยกการทดสอบฟังดูราบรื่น
- ตัวชี้วัดประสิทธิภาพการทำงาน เช่น กรณีทดสอบจำนวนหนึ่งที่สร้างขึ้นหรือดำเนินการต่อวันอาจทำให้เข้าใจผิดอย่างมาก และอาจนำไปสู่การลงทุนจำนวนมากในการทำการทดสอบที่ไม่มีประโยชน์
- สมาชิกของทีมอัตโนมัติแบบคล่องตัวจะต้องเป็นที่ปรึกษาที่มีประสิทธิภาพ เข้าถึงได้ ให้ความร่วมมือ และมีทรัพยากรเพียงพอ มิฉะนั้น ระบบนี้จะล้มเหลวอย่างรวดเร็ว
- ระบบอัตโนมัติอาจเสนอและส่งมอบโซลูชันการทดสอบที่ต้องมีการบำรุงรักษาอย่างต่อเนื่องมากเกินไปเมื่อเทียบกับค่าที่ให้ไว้
- การทดสอบอัตโนมัติอาจขาดความเชี่ยวชาญในการคิดและนำเสนอโซลูชันที่มีประสิทธิภาพ
- การทดสอบอัตโนมัติอาจประสบความสำเร็จมากจนหมดปัญหาสำคัญที่ต้องแก้ไข และหันไปสู่ปัญหาที่ไม่สำคัญ
สรุป
ระเบียบวิธีแบบ Agile ในการทดสอบซอฟต์แวร์เกี่ยวข้องกับการทดสอบโดยเร็วที่สุดใน วงจรชีวิตการพัฒนาซอฟต์แวร์- ต้องการการมีส่วนร่วมของลูกค้าสูงและโค้ดทดสอบทันทีที่พร้อมใช้งาน รหัสควรมีความเสถียรพอที่จะนำไปทดสอบระบบได้ การทดสอบการถดถอยอย่างกว้างขวางสามารถทำได้เพื่อให้แน่ใจว่าจุดบกพร่องได้รับการแก้ไขและทดสอบแล้ว โดยพื้นฐานแล้วการสื่อสารระหว่างทีมทำให้การทดสอบโมเดลแบบ Agile ประสบความสำเร็จ!!!