เมื่อ Test Scope ต้องปรับ ทีมตัดสินว่า “พร้อม” ก่อน Deploy อย่างไร?

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

ในการทำงานจริง Test Scope อาจต้องปรับตามข้อจำกัดและระดับ Impact ของแต่ละ Change คำถามสำคัญจึงไม่ใช่เพียงว่า จะลด Test Case ลงเท่าไร แต่อะไรคือพฤติกรรมหลักที่ต้องได้รับการยืนยัน? การเปลี่ยนแปลงนี้อาจส่งผลกระทบต่อส่วนใด? Test Status ปัจจุบันครอบคลุมความเสี่ยงสำคัญแล้วหรือยัง? ใครบ้างที่ต้องรับรู้ข้อมูลก่อนตัดสินใจเดินหน้าต่อ? สำหรับทีม M‑LOAN ของ Krungsri Nimble การปรับ Test Scope ไม่ได้ขึ้นอยู่กับ Dev หรือ QA เพียงฝ่ายเดียว แต่เกิดจากการนำข้อมูลของ Dev, QA, SA และ PO มาพิจารณาร่วมกัน เพื่อให้ทุกฝ่ายเข้าใจสถานะของงานและความเสี่ยงชุดเดียวกันก่อน Deploy

Test Scope เริ่มจากสิ่งที่ระบบต้องทำได้

ก่อนตัดสินใจว่าจะทดสอบอะไร ทีมต้องมีจุดอ้างอิงร่วมกันก่อน จุดเริ่มต้นนั้นคือ Acceptance Criteria ที่ระบุไว้ในการ์ดงาน Acceptance Criteria ช่วยอธิบายว่า Feature หรือการเปลี่ยนแปลงควรทำงานอย่างไร และมีเงื่อนไขใดที่ต้องได้รับการยืนยัน QA จึงใช้ข้อมูลส่วนนี้เป็นฐานในการออกแบบ Test Case และกำหนด Test Scope ให้สอดคล้องกับ Expected Behavior ของงาน เมื่อทุกฝ่ายอ้างอิง Acceptance Criteria ชุดเดียวกัน ทีมจะเห็นชัดขึ้นว่าอะไรคือพฤติกรรมหลักที่ต้องรักษา เงื่อนไขใดมีความสำคัญต่อผู้ใช้งาน และจุดใดอาจสร้างความเสี่ยงหากไม่ได้รับการทดสอบ Test Scope สามารถปรับตามบริบทได้ แต่ความเข้าใจร่วมกันว่า “งานนี้ต้องทำอะไรได้” ต้องไม่หายไป

ก่อนปรับ Test Scope ทีมต้องเห็น Impact

Acceptance Criteria บอกว่างานควรทำอะไรได้ แต่ยังไม่เพียงพอสำหรับการประเมิน Test Scope เพราะการเปลี่ยน Code ในจุดหนึ่งอาจเชื่อมโยงกับส่วนอื่นของระบบ

Dev จึงต้องระบุว่าแก้ไขอะไร และการเปลี่ยนแปลงนั้นอาจส่งผลต่อ Code, Database, Gateway หรือระบบที่เกี่ยวข้องอย่างไร ขณะที่ SA รวบรวมข้อมูลจากการ์ดและงานส่วนต่าง ๆ เพื่อให้ทีมเห็นภาพรวมที่ต้องเตรียมก่อน Deploy ข้อมูล Impact ช่วยให้ QA และผู้เกี่ยวข้องประเมินได้ว่า Test Scope ควรครอบคลุมบริเวณใด ส่วนไหนต้องได้รับความสำคัญ และการเปลี่ยนแปลงครั้งนี้มีความเชื่อมโยงกับระบบอื่นมากน้อยเพียงใด

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

เมื่อ Test Scope ต้องเปลี่ยน ทีมเลือกทดสอบอะไร?

เมื่อข้อจำกัดทำให้ทีมไม่สามารถดำเนินการตาม Test Scope เดิมได้ครบทุกส่วน ทีมอาจจัดลำดับการทดสอบจากองค์ประกอบสำคัญ เช่น

• Main Flow: เส้นทางหลักที่ผู้ใช้งานต้องผ่าน • Success Case: กรณีที่ใช้ยืนยันว่าฟังก์ชันทำงานตามเป้าหมาย • Key Error Case: กรณีผิดพลาดสำคัญที่อาจส่งผลต่อผู้ใช้งานหรือระบบ

ลำดับนี้ไม่ใช่สูตรตายตัวสำหรับทุก Change เพราะ Error Case บางประเภทอาจมี Impact สูงและต้องได้รับความสำคัญตั้งแต่ต้น ทีมจึงต้องพิจารณา Expected Behavior, Impact, ความเสี่ยง และข้อจำกัดของงานร่วมกัน

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

Test Status และ Residual Risk ต้องมองเห็นได้

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

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

แล้วใครเป็นคนตัดสินว่า “พร้อม”?

Pre-deployment Safety Check ต้องอาศัยข้อมูลจากหลายบทบาท • QA ใช้ Acceptance Criteria เป็นฐานในการออกแบบ Test Case พร้อมสรุป Test Status ว่าส่วนใดได้รับการทดสอบแล้วและส่วนใดยังไม่ครอบคลุม • Dev ให้รายละเอียดเกี่ยวกับสิ่งที่เปลี่ยนแปลง รวมถึง Impact ที่อาจเกิดขึ้นกับ Code, Database, Gateway และระบบที่เกี่ยวข้อง • SA รวบรวมข้อมูลจากการ์ดและงานส่วนต่าง ๆ เพื่อให้ทีมเห็นภาพรวมที่ต้องเตรียมสำหรับการ Deploy • PO รับรู้การปรับ Test Scope ข้อจำกัด และความเสี่ยงที่เหลืออยู่ เพื่อร่วมพิจารณาการเดินหน้าต่อบนข้อมูลที่ทุกฝ่ายเข้าใจตรงกัน

ในบางกรณี ทีมอาจให้ User เข้ามาตรวจสอบเพิ่มเติมผ่าน UAT เพื่อยืนยันการทำงานจากมุมของผู้ใช้งานตามความเหมาะสม User จึงไม่จำเป็นต้องเข้ามาในทุกการตัดสินใจ แต่จะมีบทบาทเมื่อทีมต้องการข้อมูลหรือการยืนยันเพิ่มเติมจากการใช้งานจริงแต่ละ Role มองเห็นงานจากคนละมุม QA เห็นสถานะของการทดสอบ Dev เข้าใจ Impact ทางเทคนิค SA มองเห็นความเชื่อมโยงของงาน และ PO รับรู้บริบทของสิ่งที่กำลังจะส่งมอบ เมื่อนำข้อมูลทั้งหมดมาพิจารณาร่วมกัน ทีมจึงประเมินได้ว่า Test Scope สอดคล้องกับระดับความเสี่ยงของงานหรือไม่ และมีเรื่องใดที่ต้องจัดการเพิ่มเติมก่อนเดินหน้าต่อ

Residual Risk ไม่ควรถูกซ่อนไว้หลังคำว่า “ผ่าน Test”

การผ่าน Test Case ที่ทีมเลือกไว้ ไม่ได้หมายความว่าความเสี่ยงทั้งหมดหายไป ส่วนที่ยังไม่ได้ทดสอบ ประเด็นที่ต้องติดตาม หรือ Dependency ที่ยังคงอยู่ ล้วนเป็น Residual Risk ที่ต้องถูกทำให้มองเห็น การสื่อสาร Residual Risk ไม่ได้หมายความว่าทีมกำลังผลักภาระให้ฝ่ายอื่น แต่เป็นการทำให้การตัดสินใจก่อน Deploy สอดคล้องกับสถานะจริงของงาน เมื่อทุกฝ่ายรู้ว่าอะไรได้รับการยืนยันแล้วและอะไรยังมีข้อจำกัด ทีมจะสามารถวางแผนติดตาม ทดสอบเพิ่มเติม หรือเตรียมแนวทางรองรับได้เหมาะสมกว่าการเดินหน้าต่อด้วยความเข้าใจว่า “น่าจะไม่มีปัญหา”

Shared Judgement ทำให้การตัดสินใจมีหลักฐานรองรับ

ความพร้อมก่อน Deploy เกิดจากการที่ Dev, QA, SA และ PO มองเห็นข้อมูลชุดเดียวกัน ทั้ง Expected Behavior, Impact, Test Status และ Residual Risk Shared Judgement จึงไม่ใช่ความมั่นใจของคนใดคนหนึ่ง แต่เป็นการนำ Acceptance Criteria ผลการทดสอบ ข้อมูล Impact และข้อจำกัดของงานมาใช้เป็นหลักฐานประกอบการตัดสินใจ

แนวทางนี้สะท้อนหลักของ Risk-based Testing ซึ่งไม่ได้มีเป้าหมายเพื่อลดจำนวนการทดสอบ แต่เพื่อกำหนด Test Scope ให้สัมพันธ์กับ Impact และความเสี่ยง พร้อมทำให้ข้อมูลที่จำเป็นต่อการตัดสินใจมองเห็นได้สำหรับทุกฝ่าย

ก่อนถามว่างาน “ผ่าน Test แล้วหรือยัง” ทีมจึงอาจต้องตอบคำถามที่สำคัญกว่านั้นก่อนว่า ทุกคนเข้าใจตรงกันหรือยังว่า เราทดสอบอะไรไปแล้ว และมีความเสี่ยงใดที่ต้องรับรู้หรือวางแนวทางรองรับก่อน Deploy?

ติดตาม Krungsri Nimble เพื่ออ่านเบื้องหลังแนวคิด กระบวนการ และวิธีทำงานของทีมเทคที่ร่วมกันสร้างระบบธนาคารให้พร้อมใช้งานอย่างมั่นใจยิ่งขึ้น