การทดสอบแบบ Agile - ผลงาน

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

เนื้อหาทั่วไปของแผนการทดสอบ ได้แก่ -

  • กลยุทธ์การทดสอบ
  • สภาพแวดล้อมการทดสอบ
  • ความครอบคลุมการทดสอบ
  • ขอบเขตการทดสอบ
  • ทดสอบความพยายามและกำหนดเวลา
  • เครื่องมือทดสอบ

ในโครงการ Agile สมาชิกในทีมทุกคนต้องรับผิดชอบต่อคุณภาพของผลิตภัณฑ์ ดังนั้นทุกคนจึงมีส่วนร่วมในการวางแผนการทดสอบเช่นกัน

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

เรื่องราวของผู้ใช้

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

ผู้ทดสอบยังตรวจสอบให้แน่ใจว่าเรื่องราวของผู้ใช้ทั้งหมดสามารถทดสอบได้และตรวจสอบเกณฑ์การยอมรับ

การทดสอบด้วยตนเองและอัตโนมัติ

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

  • การทดสอบหน่วย
  • การทดสอบการรวมระบบ
  • การทดสอบการทำงาน
  • การทดสอบที่ไม่ใช่หน้าที่
  • การทดสอบการยอมรับ

จากนั้นการทดสอบจะเป็นแบบอัตโนมัติสำหรับการรันในภายหลัง

ใน Test Driven Development, การทดสอบหน่วยจะเขียนก่อนที่จะล้มเหลว, โค้ดได้รับการพัฒนาและทดสอบเพื่อให้แน่ใจว่าการทดสอบผ่าน

ใน Acceptance Test Driven Development, การทดสอบการยอมรับจะถูกเขียนขึ้นก่อนที่จะล้มเหลว, โค้ดได้รับการพัฒนาและทดสอบเพื่อให้แน่ใจว่าการทดสอบผ่าน

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

ในวิธีการทุกประเภทการรวมแบบต่อเนื่องจะเกิดขึ้นซึ่งรวมถึงการทดสอบการรวมแบบต่อเนื่อง

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

ใน Scrumการทำซ้ำเป็นแบบกำหนดเวลา ดังนั้นหากการทดสอบ User Story ไม่สามารถเสร็จสิ้นใน Sprint เฉพาะผู้ทดสอบสามารถรายงานในการประชุม standup รายวันว่าเรื่องราวของผู้ใช้ไม่สามารถเข้าถึง Done Status ภายใน Sprint นั้นได้และด้วยเหตุนี้จึงต้องรอดำเนินการ Sprint ถัดไป

ผลการทดสอบ

เนื่องจากการทดสอบส่วนใหญ่ในโครงการ Agile เป็นแบบอัตโนมัติเครื่องมือจึงสร้างบันทึกผลการทดสอบที่จำเป็น ผู้ทดสอบตรวจสอบบันทึกผลการทดสอบ ผลการทดสอบจะต้องได้รับการดูแลสำหรับแต่ละ sprint / release

นอกจากนี้ยังสามารถจัดเตรียมสรุปการทดสอบซึ่งประกอบด้วย -

  • ขอบเขตการทดสอบ (สิ่งที่ทดสอบและสิ่งที่ไม่ได้ทดสอบ)
  • การวิเคราะห์ข้อบกพร่องพร้อมกับการวิเคราะห์สาเหตุรากถ้าเป็นไปได้
  • สถานะการทดสอบการถดถอยหลังจากการแก้ไขข้อบกพร่อง
  • ปัญหาและความละเอียดที่เกี่ยวข้อง
  • ปัญหาที่รอดำเนินการถ้ามี
  • การปรับเปลี่ยนใด ๆ ที่จำเป็นในกลยุทธ์การทดสอบ
  • เมตริกการทดสอบ

ทดสอบรายงานเมตริก

ในโครงการ Agile เมตริกการทดสอบรวมถึงสิ่งต่อไปนี้สำหรับแต่ละ Sprint -

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

Sprint ตรวจสอบและรายงานย้อนหลัง

ผู้ทดสอบยังมีส่วนร่วมในการทบทวน Sprint และรายงานย้อนหลัง เนื้อหาทั่วไปคือ -

  • เมตริกการทดสอบ
  • ผลการตรวจสอบบันทึกผลการทดสอบ
  • สิ่งที่ถูกต้องและสิ่งที่สามารถปรับปรุงได้จากมุมมองการทดสอบ
  • ปฏิบัติที่ดีที่สุด
  • บทเรียนที่เรียนรู้
  • Issues
  • ความคิดเห็นของลูกค้า