การทดสอบแบบ Agile: วิธีการและวงจรชีวิต

การทดสอบแบบ Agile คืออะไร?

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

หลักการทดสอบแบบ Agile

หลักการสำคัญของการทดสอบแบบ Agile มีดังนี้:

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

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

วงจรชีวิตการทดสอบแบบ Agile

วงจรชีวิตการทดสอบแบบ Agile ประกอบด้วยห้าขั้นตอน ดังแสดงด้านล่าง

ขั้นตอนต่างๆ มีดังนี้:

• ขั้นตอนที่ 1: การประเมินผลกระทบ รวบรวมข้อมูลจากผู้มีส่วนได้ส่วนเสียและผู้ใช้งาน ขั้นตอนนี้เรียกอีกอย่างว่าขั้นตอนการรับฟังความคิดเห็น เพราะช่วยให้วิศวกรทดสอบกำหนดเป้าหมายสำหรับวงจรชีวิตผลิตภัณฑ์ในรอบต่อไปได้
• ขั้นตอนที่ 2: การวางแผนการทดสอบแบบ Agile ผู้มีส่วนได้ส่วนเสียทุกฝ่ายร่วมกันวางแผนกำหนดการทดสอบ ขอบเขต และผลลัพธ์ที่คาดหวัง
• ขั้นตอนที่ 3: ความพร้อมสำหรับการเปิดตัว Revตรวจสอบฟีเจอร์ต่างๆ ที่ได้รับการพัฒนาแล้ว และตัดสินใจว่าฟีเจอร์ใดพร้อมใช้งานได้ทันที และฟีเจอร์ใดต้องกลับไปพัฒนาต่อ
• ขั้นตอนที่ 4: การประชุม Scrum รายวัน การประชุมประจำวันตอนเช้าที่ทีมจะติดตามสถานะการทดสอบและกำหนดเป้าหมายสำหรับวันนั้นๆ
• ระยะที่ 5: ทดสอบความคล่องตัว Revนั่นคือ ประชุมกับผู้มีส่วนได้ส่วนเสียทุกสัปดาห์เพื่อประเมินความคืบหน้าเทียบกับเป้าหมายและปรับกลยุทธ์

แผนการทดสอบแบบเปรียว

An แผนการทดสอบแบบ Agile อธิบายประเภทของการทดสอบที่ดำเนินการในแต่ละรอบ ข้อมูลและโครงสร้างพื้นฐานที่จำเป็น และอื่นๆ สภาพแวดล้อมการทดสอบและผลการทดสอบ แตกต่างจากโมเดลแบบ Waterfall แผนการทดสอบแบบ Agile จะถูกเขียนและปรับปรุงใหม่ทุกครั้งที่มีการออกเวอร์ชันใหม่ แผนการทดสอบทั่วไปประกอบด้วย:

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

กลยุทธ์การทดสอบแบบคล่องตัว

วงจรชีวิตการทดสอบแบบ Agile ประกอบด้วยสี่ขั้นตอนเชิงกลยุทธ์

0 ซ้ำ

ในขั้นตอนแรก คุณจะดำเนินการตั้งค่าเบื้องต้น ซึ่งรวมถึงการระบุบุคคลที่จะเข้ารับการทดสอบ การติดตั้งเครื่องมือทดสอบ และการจัดตารางเวลาทรัพยากร เช่น ห้องปฏิบัติการทดสอบการใช้งาน เป้าหมายของขั้นตอนที่ 0 คือ:

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

การก่อสร้างซ้ำ

ขั้นตอนที่สองของการทดสอบแบบ Agile คือ การทำซ้ำเพื่อสร้างโซลูชัน (Construction Iterations) ซึ่งเป็นขั้นตอนที่ทำการทดสอบส่วนใหญ่ ขั้นตอนนี้ประกอบด้วยการทำซ้ำหลายรอบเพื่อสร้างโซลูชันทีละน้อย โดยในแต่ละรอบ ทีมจะนำแนวทางปฏิบัติจาก XP, Scrum, การสร้างแบบจำลองแบบ Agile และข้อมูลแบบ Agile มาประยุกต์ใช้ผสมผสานกัน

ทีมต่างๆ ปฏิบัติตามหลักการจัดลำดับความสำคัญของข้อกำหนด: ในแต่ละรอบการทำงาน พวกเขาจะดึงรายการที่สำคัญที่สุดจากรายการงานค้างและนำไปปฏิบัติ การทำงานในแต่ละรอบของการก่อสร้างจะแบ่งออกเป็นสองส่วนของการทดสอบที่เสริมซึ่งกันและกัน:

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

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

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

ระยะปล่อยตัว ระยะจบเกม หรือระยะเปลี่ยนผ่าน

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

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

การผลิต

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

Quadrant การทดสอบแบบ Agile

แผนภาพการทดสอบแบบ Agile แบ่งกระบวนการทั้งหมดออกเป็นสี่ส่วน และช่วยให้ทีมเข้าใจวิธีการทดสอบแบบ Agile ได้ดียิ่งขึ้น

Agile Quadrant I

ควอดแรนต์ที่ 1 เน้นคุณภาพโค้ดภายในด้วยการทดสอบที่ขับเคลื่อนด้วยเทคโนโลยีซึ่งสนับสนุนการทำงานของทีม:

• การทดสอบหน่วย (Unit tests)
• การทดสอบส่วนประกอบ

Agile Quadrant II

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

• ทดสอบตัวอย่างสถานการณ์และขั้นตอนการทำงานที่เป็นไปได้
• การทดสอบชิ้นงานที่เกี่ยวข้องกับประสบการณ์ผู้ใช้ เช่น ต้นแบบผลิตภัณฑ์
• การทดสอบแบบจับคู่

อไจล์ควอแดรนท์ III

ควอแดรนต์ที่ 3 ให้ข้อมูลป้อนกลับไปยังควอแดรนต์ที่ 1 และ 2 กรณีทดสอบในส่วนนี้มักเป็นพื้นฐานสำหรับการทำงานอัตโนมัติ และการตรวจสอบซ้ำหลายรอบจะช่วยสร้างความมั่นใจในผลิตภัณฑ์ งานทั่วไปประกอบด้วย:

• การทดสอบการใช้งาน
• การทดสอบเชิงสำรวจ
• การทดสอบแบบจับคู่กับลูกค้า
• การทดสอบแบบร่วมมือกัน
• การทดสอบการยอมรับของผู้ใช้

Agile Quadrant IV

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

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

ความท้าทายด้านการประกันคุณภาพในการพัฒนาซอฟต์แวร์แบบ Agile

การส่งมอบงานแบบ Agile นำมาซึ่งประโยชน์มากมาย แต่ก็สร้างความท้าทายใหม่ๆ ให้กับทีม QA ด้วยเช่นกัน:

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

ความเสี่ยงของการใช้ระบบอัตโนมัติในกระบวนการแบบ Agile

ระบบอัตโนมัติมีความสำคัญอย่างยิ่งในวิธีการทำงานแบบ Agile แต่ก็มีความเสี่ยงที่ทีมต้องจัดการอย่างแข็งขัน:

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

แนวปฏิบัติที่ดีที่สุดสำหรับการทดสอบแบบ Agile ที่มีประสิทธิภาพ

แนวทางปฏิบัติต่อไปนี้ช่วยให้การทดสอบแบบ Agile รวดเร็ว น่าเชื่อถือ และมีคุณค่าต่อทีม:

• Shift ซ้าย: เริ่มทำการทดสอบตั้งแต่ช่วงกำหนดความต้องการ ไม่ใช่ตอนสิ้นสุดรอบการพัฒนา
• ทำงานร่วมกับนักพัฒนา: ทบทวนเกณฑ์การยอมรับร่วมกัน เพื่อป้องกันข้อบกพร่องตั้งแต่เริ่มต้น ไม่ใช่การเขียนโค้ดที่ผิดพลาด
• การทำงานอัตโนมัติของเลเยอร์: สร้างพีระมิดที่แข็งแกร่งของการทดสอบระดับหน่วย การทดสอบระดับบริการ และการทดสอบระดับ UI
• ทำการทดสอบอย่างเป็นอิสระ: แยกการทดสอบแต่ละครั้งเพื่อให้ความล้มเหลวชี้ไปยังสาเหตุหลักเพียงสาเหตุเดียว
• Tracการทดสอบที่ไม่เสถียร k รายการ: กักกันและแก้ไขการทดสอบที่ไม่เสถียรโดยทันที เพื่อป้องกันการบั่นทอนความเชื่อมั่นในชุดทดสอบ
• ใช้การวิเคราะห์ข้อมูลโดยใช้ AI ช่วย: ให้เครื่องมือต่างๆ ระบุการทดสอบที่ได้รับผลกระทบ จัดกลุ่มความล้มเหลว และแนะนำตำแหน่งที่เสถียรหลังจากการรวมแต่ละครั้ง

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