การทดสอบแบบ Agile - การต่อสู้

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

ทั้งทีมทำงานร่วมกันในกลยุทธ์การทดสอบการวางแผนการทดสอบข้อกำหนดการทดสอบการดำเนินการทดสอบการประเมินผลการทดสอบและการรายงานผลการทดสอบ

การสร้างเรื่องราวของผู้ใช้ร่วมกัน

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

ผู้ทดสอบยังกำหนดเกณฑ์การยอมรับสำหรับทุกสถานการณ์ที่ลูกค้าตกลง

ผู้ทดสอบมีส่วนช่วยในการสร้างเรื่องราวของผู้ใช้ที่สามารถทดสอบได้

การวางแผนการวางจำหน่าย

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

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

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

การวางแผน Sprint

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

ผู้ทดสอบควร -

• กำหนดความสามารถในการทดสอบเรื่องราวของผู้ใช้ที่เลือกสำหรับการวิ่ง
• สร้างการทดสอบการยอมรับ
• กำหนดระดับการทดสอบ
• ระบุการทดสอบอัตโนมัติ

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

การวิเคราะห์การทดสอบ

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

การทดสอบ

สมาชิกทุกคนในทีม Scrum ควรเข้าร่วมการทดสอบ

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

• ผู้ทดสอบแสดงคุณสมบัติที่ใช้งานได้และไม่ใช้งานได้ของเรื่องราวของผู้ใช้

• ผู้ทดสอบให้คำปรึกษาแก่สมาชิกคนอื่น ๆ ในทีมต่อสู้ด้วยความเชี่ยวชาญในการทดสอบเพื่อให้ทั้งทีมมีความรับผิดชอบร่วมกันสำหรับคุณภาพของผลิตภัณฑ์

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

• มีการรวบรวมและบำรุงรักษาผลการทดสอบ

การทดสอบอัตโนมัติ

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

การทดสอบด้วยตนเองมุ่งเน้นไปที่การทดสอบเชิงสำรวจความเปราะบางของผลิตภัณฑ์การทำนายข้อบกพร่อง

ระบบอัตโนมัติของกิจกรรมการทดสอบ

ระบบอัตโนมัติของกิจกรรมการทดสอบช่วยลดภาระในการทำงานซ้ำ ๆ และทำให้ประหยัดต้นทุน อัตโนมัติ

• ทดสอบการสร้างข้อมูล
• ทดสอบการโหลดข้อมูล
• สร้างการปรับใช้ในสภาพแวดล้อมการทดสอบ
• ทดสอบการจัดการสภาพแวดล้อม
• การเปรียบเทียบเอาต์พุตข้อมูล

การทดสอบการถดถอย

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

การจัดการการตั้งค่า

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

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

แนวปฏิบัติในการทดสอบแบบ Agile

ผู้ทดสอบในทีม Scrum สามารถปฏิบัติตาม Agile Practices ต่อไปนี้ -

• Pairing- สมาชิกในทีมสองคนนั่งด้วยกันและทำงานร่วมกัน ทั้งสองคนสามารถเป็นผู้ทดสอบสองคนหรือผู้ทดสอบหนึ่งคนและนักพัฒนาหนึ่งคน

• Incremental Test Design - กรณีทดสอบได้รับการพัฒนาเมื่อ Sprints ก้าวหน้าขึ้นเรื่อย ๆ และมีการเพิ่มเรื่องราวของผู้ใช้

เมตริก Agile

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

แนะนำเมตริกหลายรายการสำหรับการพัฒนา Scrum เมตริกที่สำคัญ ได้แก่ -

• Ratio of Successful Sprints - (Number of successful Sprints / Total number of Sprints) * 100. Sprint ที่ประสบความสำเร็จคือสิ่งที่ทีมสามารถตอบสนองความมุ่งมั่น

• Velocity- Velocity ของทีมขึ้นอยู่กับจำนวน Story Points ที่ทีมได้รับระหว่างการวิ่ง Story Points คือการวัดเรื่องราวของผู้ใช้ที่นับระหว่างการประมาณค่า

• Focus Factor - (Velocity / Team’s Work Capacity) / 100. Focus Factor คือเปอร์เซ็นต์ของความพยายามของทีมที่ทำให้เกิดเรื่องราวที่เสร็จสมบูรณ์

• Estimation Accuracy - (Estimated effort / Actual effort) / 100. ความแม่นยำในการประมาณการคือความสามารถของทีมในการประเมินความพยายามอย่างแม่นยำ

• Sprint Burndown- งาน (ใน Story Points หรือเป็นชั่วโมง) ที่เหลือเทียบกับ งานที่ต้องอยู่ในอุดมคติ (ตามการประมาณการ)

  • หากมีมากกว่านั้นแสดงว่าทีมมีงานมากเกินกว่าที่จะทำได้

  • หากน้อยกว่าแสดงว่าทีมประเมินไม่ถูกต้อง

• Defect Count- จำนวนข้อบกพร่องใน Sprint จำนวนข้อบกพร่องคือจำนวนข้อบกพร่องในซอฟต์แวร์เทียบกับสินค้าค้างส่ง

• Severity of Defects- ข้อบกพร่องสามารถแบ่งออกเป็นเล็กน้อยสำคัญและสำคัญตามความรุนแรง ผู้ทดสอบสามารถกำหนดการจัดหมวดหมู่

Sprint Retrospectives

ใน Sprint Retrospectives สมาชิกในทีมทุกคนจะมีส่วนร่วม พวกเขาแบ่งปัน -

• สิ่งที่เป็นไปด้วยดี
• Metrics
• ขอบเขตสำหรับการปรับปรุง
• รายการการดำเนินการที่จะใช้