Regression​ ​Testing​ ​คือ​อะไร​ ​และ​เหตุ​ใด​ระบบ​ที่​แก้​ฟีเจอร์​หนึ่ง​อาจ​ทำให้​อีก​ส่วน​เสีย

Regression Testing คือการตรวจว่าพฤติกรรมที่เคยทำงานยังถูกต้องหลังมีการเปลี่ยนโค้ด การตั้งค่า ข้อมูล หรือ Dependency เพราะส่วนต่าง ๆ ของระบบใช้กฎและองค์ประกอบร่วมกัน การแก้หน้าเดียวอาจกระทบ API หรือรูปแบบข้อมูลที่หน้าอื่นใช้อยู่

เหตุใดผลกระทบจึงข้ามฟีเจอร์

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

ภาพที่ 1: เลือก Regression Test จากพื้นที่ที่เปลี่ยนและผู้ใช้งานร่วม ไม่อาศัยชื่อไฟล์ที่แก้เท่านั้น

วิธีสร้างชุดตรวจที่คุ้มค่า

เก็บ Test ของบั๊กที่เคยเกิด กฎธุรกิจที่มีผลสูง และเส้นทางหลักที่ผู้ใช้ทำบ่อย รัน Test ระดับเล็กให้เร็วในทุกการเปลี่ยน แล้วรัน Integration/E2E ที่ครอบคลุมจุดเชื่อมสำคัญตามความเสี่ยง เมื่อพบว่า E2E ล้มเหลวจากกฎย่อยที่ไม่มี Test ระดับต่ำ ควรเพิ่ม Test ที่ชี้สาเหตุได้ง่ายกว่า ไม่สะสมชุดทดสอบซ้ำจนทีมเลิกดูผล

ตัวอย่างสมมติ: เปลี่ยนสิทธิ์ผู้ตรวจ

เดิมผู้ตรวจเห็นงานทั้งบริษัท เปลี่ยนให้เห็นเฉพาะสาขา ควรตรวจทั้งหน้ารายการ การเปิด URL รายการตรง การส่งออก และงานแจ้งเตือนที่อ่านข้อมูลผ่าน API เดียวกัน หากทดสอบแต่เมนูที่ซ่อน อาจยังเปิดข้อมูลข้ามสาขาผ่าน API ได้

สำหรับรายงาน

ระบุการเปลี่ยนแปลง พื้นที่ที่อาจกระทบ เหตุผลเลือก Test ผลก่อน/หลัง และข้อจำกัดที่ยังไม่ได้ตรวจ แยกผล Test ผ่านจากหลักฐานว่า Production ทำงานจริง เพราะการตั้งค่าหรือข้อมูลจริงอาจต่างจากสภาพทดสอบ

อ่าน Unit, Integration และ E2E และ Git Workflow หรือดู บริการ Web Application

วิเคราะห์กรณีศึกษาเพื่อนำไปเขียนรายงาน

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

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

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

แหล่งข้อมูลประกอบ

• The Practical Test Pyramid — การจัดชุดทดสอบเพื่อกันข้อผิดพลาดย้อนกลับ
• ISTQB: Standard Glossary — คำศัพท์ Regression Testing