การทดสอบซ้ำๆ ซากๆ Regression Testing เราสามารถวางแผน หรือจัดเตรียมออกได้เป็น 3 แบบ คือ

Retest All ทดสอบซ้ำๆ ซากๆ แบบทั้งหมด

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

Selection ทดสอบซ้ำๆ ซากๆ แบบเลือก

แบบนี้จะลดความโหดลงมาโดยจะมีการคัด และเลือก Test cases และ Test Scenarios ออกเป็นสองกลุ่ม คือ

1. กลุ่มที่สามารถนำมาทดสอบซ้ำๆ ซากๆ ได้อยู่ ได้แก่ Test Cases และ Test Scenarios ที่ เงื่อนไขทางธุรกิจ และเงื่อนไขทางความสามารถของซอฟต์แวร์ ยังคงถูกใช้งานเพื่อให้บริการหรือใช้งานอยู่
2. กลุ่มที่ไม่สามารถทำมาทดสอบซ้ำๆ ซากๆ ได้แล้ว ได้แก่ Test Cases และ Test Scenarios ที่ เงื่อนไขทางธุรกิจ และเงื่อนไขทางความสามารถของซอฟต์แวร์ ถูกลบออก และ/หรือ ไม่การการให้บริการหรือใช้งานแล้ว

Prioritization ทดสอบซ้ำๆ ซากๆ แบบลำดับความสำคัญ

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

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

1. Test Cases และ Test Scenarios ที่ตรวจสอบ และทดสอบความสามารถ และคุณสมบัติของซอฟต์แวร์ที่มีการเปลี่ยนแปลงแก้ไขล่าสุด ไม่ว่า จะเพิ่ม ปรับ เปลี่ยน แก้ และลบ
2. Test Cases และ Test Scenarios ที่จากสถิติแล้วเจอ Bugs และ Defects บ่อยมากๆ
3. Test Cases และ Test Scenarios ที่ตรวจสอบ และทดสอบความสามารถ และคุณสมบัติของซอฟต์แวร์ที่ผู้ใช้งานจะต้องเข้ามาใช้บริการอยู่บ่อยๆ
4. Test Cases และ Test Scenarios ที่ตรวจสอบ และทดสอบความสามารถ และคุณสมบัติหลักของซอฟต์แวร์
5. Test Cases และ Test Scenarios ที่ตรวจสอบ และทดสอบความสามารถ และคุณสมบัติของซอฟต์แวร์ที่มีความซับซ้อนมาก และสูง
6. Test Cases และ Test Scenarios ที่ตรวจสอบ และทดสอบ การทำงานร่วมกันของความสามารถ และคุณสมบัติต่างๆ ที่เกิดขึ้นภายในของซอฟต์แวร์
7. Test Cases และ Test Scenarios ที่ตรวจสอบ และทดสอบ การทำงานร่วมกันของความสามารถ และคุณสมบัติต่างๆ ของซอฟต์แวร์ที่ต้องทำงานร่วมกับ ระบบ หรือซอฟต์แวร์อื่นๆ
8. Test Cases ที่ตรวจสอบ และทดสอบ ค่าขอบต่างๆ ของเงื่อนไข (Boudary Values)

นอกจากการคัดกรอง และจัดลำดับการทดสอบซ้ำๆ ซากๆ ว่า Test Cases และ Test Scenarios แล้ว อีกหนึ่งเรื่องที่ต้องทำคือ Configuration Management หรือแปลเป็นภาษาไทยว่า การจัดการการกำหนดค่า (หากมีคำที่ส่ือความได้ดีกว่านี้ ต้องรบกวนแจ้งใน Reply ครับ)

การจัดการการกำหนดค่า (Configuration Management)

นั้นมีความสำคัญมากๆ กับการทดสอบซ้ำๆ ซากๆ Regression Testing เพื่อให้ทั้งผลการทดสอบนั้นมีความน่าเชื่อถือมากๆ โดยเฉพาะอย่างยิ่งหาก Production Source Code มีการเปลี่ยนแปลงอย่างต่อเนื่อง เช่น รูปแบบของการพัฒนา ตรวจสอบ ทดสอบ เพื่อส่งมอบสัมฤทธิ์จากซอฟต์แวร์ในรูปแบบของ Agile Software Development รวมถึงการแก้ไข Bugs หรือ Defects บน Production Server ที่มีคำเรียกอย่างเป็นทางการในฝั่งของการบริหารจัดการระบบสารสนเทศว่า Incident ด้วย

การทดสอบซ้ำๆ ซากๆ Regression Testing นั้นจึงต้องควงแขนมาพร้อมๆ กับ การจัดการการกำหนดค่า (Configuration Management)

1. Product Source Code ที่จะถูกดำเนินการตรวจสอบ และทดสอบแบบซ้ำๆ ซากๆ Regression Test นั้นจะต้องอยู่ภายใต้การจัดเตรียม กำหนดขั้นตอน และควบคุมดูแลของ Configuration Management Tool ซึ่งจะมาเขียนขยายความให้ในตอนต่อๆ ไป
2. ระหว่างที่ดำเนินการทดสอบซ้ำๆ ซากๆ Regression Testing นั้น จะต้องไม่มีการแก้ไขใดๆ ทั้งสิ้นกับ Production Source Code ดังนั้น ต้องมีการกำหนดกฎของการทำงานร่วมกันออกมาให้ชัดเจนของสมาชิกทุกๆ คนที่เกี่ยวข้อง
3. ข้อมูลสำหรับการทดสอบที่จัดเก็บในฐานข้อมูลนั้นต้องมีการควบคุม ดูแล และแยกอิสระ ออกมาเพื่อไม่ให้เกิดการเปลี่ยนแปลงใดๆ ทั้งสิ้นที่จะส่งผลต่อผลของการทดสอบซ้ำๆ ซากๆ Regression Testing

จากรูป What is the goal of the Automation Testing? นี้ การทดสอบซ้ำๆ ซากๆ แบบ Regression Testing นั้นจึงเลี่ยงไม่ได้ที่จะเป็นแบบ การทดสอบแบบอัตโนมัติ มิใช่แบบ อัตโนมือ

ทำ Regression Test เมื่อใด ?

เมื่อมีการเปลี่ยนแปลงใดๆ เกิดขึ้นที่ Production Source Code ยกตัวอย่างเช่น

1. มีการขอเพิ่มความสามารถ และคุณสมบัติเข้าไปในซอฟต์แวร์
2. มีการขอเปลี่ยนแปลงแก้ไขความสามารถ และคุณสมบัติของซอฟต์แวร์
3. มีการขอให้ลบความสามารถ และคุณสมบัติออกจากซอฟต์แวร์
4. มีการแก้ไข Bug และ/หรือ Defect
5. มีการแก้ไขปัญหาในส่วนของประสิทธิภาพ (Performance) ของซอฟต์แวร์

กามนั้นารทดสอบซ้ำๆ ซากๆ ที่เรียกขานว่า Regression Testing นั้นจะต้องครอบคลุมทั้งในส่วนของ Functional Testing และ Non-Functional Testing ด้วย

Repeatability ถ้าแปลเป็นภาษาไทยนั้ขอใช้ว่า การทำซ้ำ และผมขอใช้ว่า ซ้ำๆ ซากๆ

Frequently เท่ากันกับ บ่อยๆ ซึ่งความบ่อยๆ ที่ประสบพบเจอมานั้นคือ ทุกครั้งที่ Production Source Code มีการแก้ไขในระดับของ Function หรือ Module ก็ต้องทดสอบซ้ำๆ ซากๆ เลยทันที

เพื่อให้เกิด การทดสอบซ้ำๆ ซากๆ อย่างบ่อยๆ ทุกๆ ครั้งที่ Production Source Code ถูกเปลี่ยนแปลงแก้ไข สิ่งที่ตามมาคือ เวลา

สำหรับ เวลา นั้น ผมใช้ตัวเลขจากหนึ่งในหลักปฏิบัติของ Extreme Programming คือ Ten-Minute Build ที่ถูกเขียนอธิบายไว้ในหนังสือชื่อ Extreme Programming Explained โดย Kent Beck ผู้คิด และร่วมพัฒนา Extreme Programming

เริ่มต้น และจัดเตรียม Regression Testing การทดสอบซ้ำๆ ซากๆ ที่

การทดสอบซ้ำๆ ซากๆ แบบ Regession Testing นั้น จะต้องจัดเตรียมการตั้งแต่ ณ ช่วงต้นๆ ของการเริ่มต้นวางแผนเตรียมการสร้างซอฟต์แวร์ หรือปรับเปลี่ยน ซึ่งโดยปกติผมจะใส่ไว้ในช่วงของ Release Planning ซึ่งจะมาเขียนขยายความอีกครั้งในตอนต่อไป

ในการจัดเตรียมชุดการทดสอบ Regression Test Suite นั้น ผมจะอ้างอิงจาก Automation Test Pyramid ของ Mike Cohn ที่สามารถครอบคลุ่มได้ทั้ง Functional Testing และ Non-Functional Testing ด้วยเช่นกัน และจะขยายความในตอนต่อไป

Ref:

1. https://welovebug.com/%E0%B8%88%E0%B8%B2%E0%B8%81-regression-testing-%E0%B9%80%E0%B8%A3%E0%B8%B7%E0%B9%88%E0%B8%AD%E0%B8%87%E0%B8%9E%E0%B8%B7%E0%B9%89%E0%B8%99%E0%B8%90%E0%B8%B2%E0%B8%99%E0%B8%97%E0%B8%B5%E0%B9%88%E0%B8%95%E0%B9%89%E0%B8%AD%E0%B8%87%E0%B8%97%E0%B8%B3%E0%B8%84%E0%B8%A7%E0%B8%B2%E0%B8%A1%E0%B9%80%E0%B8%82%E0%B9%89%E0%B8%B2%E0%B9%83%E0%B8%88%E0%B8%81%E0%B9%88%E0%B8%AD%E0%B8%99%E0%B9%84%E0%B8%9B-automation-testing-%E0%B8%95%E0%B8%AD%E0%B8%99%E0%B8%97%E0%B8%B5%E0%B9%88-1-8af473c6eb2c
2. Regression Testing คืออะไร? โดย สมเกียรติ ปุ๋ยสูงเนิน
3. [สรุปหนังสือ XP 2nd Edition by Kent Beck] : บทที่ 7 Primary Practices: Ten-Minute Build (ชุดทดสอบ 10 นาที) โดย Suthasinee Lieopairoj