UAT Web App ก่อนขึ้น Production ต้องเช็กอะไร? อย่าเปิดจริงแล้วค่อยพบว่าปุ่มอนุมัติหาย

คำตอบสั้น ๆ: UAT Web App คือการให้คนฝั่งธุรกิจหรือผู้ใช้ที่เข้าใจงานจริงตรวจว่า ระบบที่พัฒนามา ทำงานตาม Workflow, สิทธิ์, ข้อมูล และผลลัพธ์ที่ตกลงไว้หรือไม่ ก่อนยอมรับงานหรือเปิดใช้บน Production โดยการทดสอบควรมี Test Case, Expected Result, ผู้รับผิดชอบ, หลักฐาน และเกณฑ์ว่า Bug ระดับไหนถือว่าเปิดระบบต่อได้หรือไม่ได้

ถ้าแผน UAT ของทีมคือส่งลิงก์ในกลุ่ม LINE แล้วพิมพ์ว่า “ช่วยลองกด ๆ ดูหน่อยครับ ถ้าไม่เจออะไรพรุ่งนี้ขึ้นจริงเลย” อันนั้นไม่ใช่ UAT ครับ อันนั้นคือกิจกรรมลุ้นโชคที่บังเอิญมีหน้า Login ประกอบอยู่ด้วย เพราะทุกคนอาจกดคนละเรื่อง ไม่มีใครรู้ว่าอะไรต้องผ่าน และพอเจอปัญหาก็เริ่มวงสนทนาคลาสสิกว่า “อันนี้ Bug หรือยังไม่ได้อยู่ใน Scope?”

การตรวจรับที่ดีไม่ต้องทำเอกสารหนาเหมือนคู่มือเครื่องจักร แต่ต้องทำให้คำว่า “ผ่าน” มีความหมายตรงกัน เช่น พนักงานขายสร้างคำขอได้, หัวหน้ามองเห็นเฉพาะทีมตัวเอง, Finance อนุมัติแล้วสถานะเปลี่ยนถูกต้อง, รายการที่ขาดข้อมูลบังคับส่งต่อไม่ได้ และเมื่อระบบภายนอกตอบ Error ต้องไม่สร้างข้อมูลซ้ำแบบเงียบ ๆ ถ้าสิ่งเหล่านี้เขียนเป็นข้อทดสอบได้ ทีมก็เริ่มคุยกันด้วยหลักฐานแทนการใช้ความทรงจำว่า “ตอนประชุมเหมือนจะพูดไว้แล้วนะ”

UAT คืออะไร และจริง ๆ แล้วกำลังตรวจอะไรอยู่

ISTQB แยก Acceptance Testing เป็นพื้นที่ของการตรวจยอมรับระบบ โดยครอบคลุม User Acceptance Testing (UAT) รวมถึงรูปแบบการยอมรับอื่น ๆ และเน้นการทำงานร่วมกันระหว่างฝั่ง Product/Business กับผู้ทดสอบ การมองแบบนี้สำคัญเพราะ UAT ไม่ได้มีเป้าหมายหลักเพื่อพิสูจน์ว่า Developer เขียนโค้ดเก่งหรือไม่ แต่เพื่อพิสูจน์ว่า สิ่งที่สร้างขึ้นตอบโจทย์ที่ธุรกิจตกลงจะใช้จริง หรือเปล่า ดูแนวทาง Acceptance Testing จาก ISTQB

ตัวอย่างง่าย ๆ สมมติระบบมีฟังก์ชัน “อนุมัติค่าใช้จ่าย” Developer อาจทดสอบแล้วว่าปุ่มกดได้ API ตอบ 200 และฐานข้อมูลอัปเดต แต่ UAT ต้องถามต่อว่า คนที่กดปุ่มนี้ควรเป็นใคร? วงเงิน 5,000 กับ 500,000 บาทใช้ผู้อนุมัติคนเดียวกันหรือไม่? คนสร้างรายการอนุมัติรายการตัวเองได้ไหม? ถ้าถูก Reject แล้วแก้ไขส่งใหม่ สถานะและประวัติควรเป็นอย่างไร? รายงานปลายเดือนต้องนับรายการไหน?

นี่คือเหตุผลที่ Web App อาจ “ไม่พัง” ทางเทคนิค แต่ยัง “ใช้ไม่ได้” ทางธุรกิจได้อย่างสง่างามมาก เช่น หน้าจอสวย โหลดเร็ว ปุ่มทุกปุ่มกดติด แต่สถานะคำสั่งซื้อมีเพียง Open กับ Closed ทั้งที่ทีมจริงต้องแยก Waiting Stock, Waiting Payment, Ready to Ship และ Cancelled แบบนี้จะบอกว่าระบบไม่มี Bug ก็ได้ แต่คนใช้จริงก็ยังทำงานต่อไม่ได้อยู่ดี

UAT ไม่ใช่ QA รอบสุดท้าย และไม่ใช่ข้ออ้างให้โยนการทดสอบทั้งหมดให้ลูกค้า

ควรแยกบทบาทให้ชัดตั้งแต่ต้น เพราะคำว่า “เดี๋ยวให้ User ทดสอบ” ถูกใช้เป็นผ้าห่มคลุมงานที่ยังไม่พร้อมได้ง่ายมาก ทีมพัฒนาควรผ่านการทดสอบทางเทคนิคของตัวเองก่อน เช่น Functional Test, Integration Test, Validation, Error Handling และ Regression ในระดับที่เหมาะสม แล้วจึงส่ง Build ที่มีความเสถียรให้ผู้ใช้ทำ UAT

GOV.UK Service Manual แนะนำให้การประกันคุณภาพตรวจทั้งการใช้งานและด้านเทคนิค รวมถึงความเสถียร ความปลอดภัย และประสิทธิภาพ ไม่ใช่ดูแค่ว่าฟังก์ชันหลักกดได้หรือไม่ อ่าน Quality Assurance guidance ของ GOV.UK ดังนั้น UAT ควรเป็นอีกชั้นหนึ่งของการยืนยันงาน ไม่ใช่ชั้นเดียวที่เหลืออยู่เพราะทีมก่อนหน้า “น่าจะลองมาแล้ว”

สรุปให้ตรงไปตรงมา: QA ถามว่า “ระบบทำงานถูกตามที่ออกแบบไหม” ส่วน UAT ถามว่า “สิ่งที่ออกแบบและสร้างมานี้ใช้ทำงานจริงได้ตามที่ธุรกิจยอมรับไหม” สองคำถามนี้เกี่ยวกัน แต่ไม่ใช่คำถามเดียวกัน

ก่อนเริ่ม UAT Web App ต้องเตรียมอะไรบ้าง

สิ่งที่ทำให้ UAT ล่มบ่อยไม่ใช่เพราะคนทดสอบขี้เกียจ แต่เพราะเริ่มทดสอบทั้งที่ยังไม่รู้ว่าจะทดสอบอะไร บางทีมได้ URL มาแล้วก็เริ่มทันที จากนั้นใช้เวลาครึ่งวันถาม Username, ข้อมูลตัวอย่าง และว่าเมนูนี้ยังทำไม่เสร็จหรือเป็น Bug ถ้าไม่อยากให้วัน UAT กลายเป็นวันตอบ FAQ ภายในทีม ควรเตรียมอย่างน้อย 7 เรื่องนี้ก่อน

• Scope ที่ยืนยันแล้ว: ฟังก์ชันไหนอยู่ในรอบส่งมอบนี้ ฟังก์ชันไหนอยู่ Phase ถัดไป จะได้ไม่เปิด Bug ว่า “ทำไมไม่มีระบบสะสมแต้ม” ทั้งที่ไม่เคยอยู่ใน Scope
• Workflow หลัก: ระบุจุดเริ่ม เหตุการณ์ ผู้รับผิดชอบ สถานะ และผลลัพธ์ปลายทางของงานจริง
• Role และสิทธิ์: เตรียมบัญชีตัวอย่างสำหรับแต่ละ Role เช่น Staff, Supervisor, Finance, Admin ไม่ใช่ให้ทุกคนทดสอบด้วย Super Admin แล้วประกาศว่าสิทธิ์ผ่าน
• ข้อมูลทดสอบ: มีทั้งข้อมูลปกติ ข้อมูลขาด ข้อมูลซ้ำ ค่าขอบเขตต่ำ/สูง และเคสที่ควรถูกปฏิเสธ
• Environment: บอกให้ชัดว่า URL ไหนคือ UAT/Staging และข้อมูลตรงนั้นจะถูกล้างหรือไม่ อย่าให้คนทดสอบนึกว่าเป็น Sandbox แต่ข้อความแจ้งเตือนดันส่งหาลูกค้าจริง
• Test Case และ Expected Result: คนทดสอบต้องรู้ว่าทำขั้นตอนอะไรและผลที่ถูกต้องคืออะไร
• ช่องทางบันทึกปัญหา: ใช้ Sheet, Issue Tracker หรือระบบใดระบบหนึ่งเป็น Source of Truth แทนการกระจาย Bug อยู่ในแชต 4 ห้องและเสียงโทรศัพท์อีก 2 สาย

ถ้าระบบมีหลายสิทธิ์และยังไม่เคยตกลงว่าใครควรเห็นหรือแก้อะไร แนะนำให้ย้อนกลับไปทำ Permission Matrix สำหรับระบบหลังบ้าน ก่อน เพราะการมานั่งนิยามสิทธิ์ตอน UAT เท่ากับกำลังออกแบบ Requirement หลังพัฒนาเสร็จแล้ว ซึ่งทำได้ แต่เป็นวิธีที่ค่าแก้ไขมักชอบโตอย่างมีวินัย

UAT Checklist: 8 กลุ่มที่ควรตรวจให้ครบก่อนขึ้น Production

1. Core Workflow — งานหลักเดินจากต้นจนจบได้จริงหรือไม่

เริ่มจาก Workflow ที่ทำให้ธุรกิจยอมลงทุนทำระบบก่อน เช่น รับ Lead → มอบหมาย Sales → อัปเดตสถานะ → ออกใบเสนอราคา → ปิดงาน หรือ Request → Approve → Process → Complete อย่าเริ่มจากการไล่เมนูตาม Sidebar เพราะผู้ใช้ไม่ได้ทำงานโดยคิดว่า “วันนี้จะทดสอบเมนูที่สามก่อน” เขาคิดเป็นงานหนึ่งชิ้นที่ต้องเดินให้จบ

สำหรับแต่ละ Workflow ควรมีอย่างน้อย Happy Path หนึ่งชุด และ Alternate/Error Path ที่สำคัญ เช่น ยกเลิก, ตีกลับ, แก้ไขหลัง Reject, หมดเวลา, ข้อมูลไม่ครบ หรือผู้รับผิดชอบลาออก ถ้าระบบเดินได้เฉพาะกรณีที่ทุกคนทำถูกหมด ก็เหมือนสร้างถนนที่ใช้งานได้เฉพาะวันที่ไม่มีรถเลี้ยวผิดครับ ดูดีบนแผนที่ แต่วันจริงเหนื่อย

2. Role & Permission — ลองด้วยบัญชีของคนธรรมดา ไม่ใช่ Admin ผู้เป็นอมตะ

ทดสอบทั้งสิ่งที่ ควรทำได้ และ ไม่ควรทำได้ เช่น Staff เห็นเฉพาะรายการทีมตัวเอง, Supervisor อนุมัติทีมตัวเองได้แต่แก้ยอดหลังอนุมัติไม่ได้, Finance เห็นข้อมูลการเงินแต่ไม่จัดการ User, Admin สร้างผู้ใช้ได้แต่ไม่จำเป็นต้องเปิดดูข้อมูลอ่อนไหวทุกชุด

อย่าตรวจสิทธิ์เพียงว่าเมนูถูกซ่อน เพราะการซ่อนปุ่มคือ UX ไม่ใช่ Authorization ที่แท้จริง ควรมีการตรวจฝั่งระบบด้วย หากงานมีความเสี่ยงด้านข้อมูลหรือการเข้าถึง ควรมีการทดสอบความปลอดภัยตามขอบเขตที่เหมาะสม โดย OWASP Web Security Testing Guide มีกรอบสำหรับการทดสอบ Web Application ทั้ง Identity, Authentication, Authorization, Session, Configuration และ Business Logic ดู OWASP Web Security Testing Guide

3. Data & Validation — ข้อมูลผิดต้องถูกหยุดตรงไหน

Web App ที่ดีไม่ได้แค่รับข้อมูลได้ แต่ต้องรู้ว่าอะไรไม่ควรถูกยอมรับ ตรวจ Required Field, รูปแบบวันที่, จำนวนเงินติดลบ, ตัวเลขเกินขอบเขต, Duplicate, อีเมลหรือเบอร์โทรตามกติกาที่ระบบใช้ รวมถึงความสัมพันธ์ของข้อมูล เช่น วันที่สิ้นสุดไม่ควรก่อนวันที่เริ่ม ถ้า Status = Paid อาจต้องมี Payment Date หรือ Reference ตาม Requirement

ให้ทดสอบด้วยข้อมูลที่ดู “กวนระบบ” บ้าง ไม่ใช่กรอกทุกอย่างสวยเหมือน Demo เช่น ช่องชื่อยาวมาก ตัวอักษรพิเศษ การเว้นวรรค ข้อมูลภาษาไทย/อังกฤษ ค่าศูนย์ การลบค่าที่เคยมี และการกด Submit ซ้ำ เพราะผู้ใช้จริงมีพรสวรรค์ในการทำสิ่งที่ตอนประชุม Requirement ไม่มีใครจินตนาการถึงเสมอ

4. Search, Filter, Report และ Export — หาไม่เจอก็เท่ากับมีข้อมูลไว้ประดับฐานข้อมูล

ระบบหลังบ้านจำนวนมากพัฒนา CRUD ได้ครบ แต่พอใช้จริงกลับเสียเวลาที่หน้ารายการ เพราะค้นหายาก Filter ไม่สัมพันธ์กัน Sort สลับ และ Export ได้ข้อมูลคนละชุดกับที่เห็นบนหน้าจอ UAT จึงควรตรวจว่า User หา Record ด้วยข้อมูลที่ใช้จริงได้หรือไม่ Filter สำคัญทำงานร่วมกันได้ไหม Pagination หรือจำนวนรายการสมเหตุสมผล และ Export เคารพสิทธิ์กับตัวกรองหรือเปล่า

ถ้ามี Dashboard หรือรายงาน ต้องตกลงสูตรให้ชัด เช่น “ยอดเดือนนี้” นับจาก Created Date, Approved Date หรือ Paid Date? “งานค้าง” รวมรายการที่ Reject ไหม? คำถามแบบนี้ไม่ใช่เรื่องกราฟ มันคือ Business Definition ถ้าไม่ตกลง ต่อให้กราฟวาดถูก 100% ก็สามารถผิดความหมายได้ 100% เช่นกัน

5. Integration & Notification — ระบบคุยกันได้ตอน Demo แล้วตอน Error ทำยังไง

ถ้ามี Email, LINE, Payment Gateway, CRM, Accounting, Webhook หรือ API ให้ทดสอบอย่างน้อยเคสสำเร็จ เคสข้อมูลผิด เคสปลายทางไม่ตอบ เคส Token/สิทธิ์มีปัญหา และเคส Request ซ้ำตามความเสี่ยง อย่าหยุดที่ “ยิง API ติดแล้ว” เพราะ Production มีนิสัยชอบเจอ Timeout ในวันที่คนที่ตั้งค่า Integration ลาพอดี

สำหรับการเตรียมระบบต้นทาง-ปลายทาง Field Mapping, Error และ Acceptance Criteria โดยเฉพาะ สามารถดูต่อที่ Checklist ก่อนเชื่อม API สำหรับธุรกิจ บทความนั้นเจาะ Integration Readiness ส่วนบทความนี้เน้นการตรวจรับ Web App ทั้งระบบ เพื่อไม่ให้สองเรื่องมารวมเป็นกอง Test Case ที่ไม่มีเจ้าภาพ

6. Error, Retry และ Recovery — ผิดแล้วกลับมาได้ไหม

ทดสอบว่าถ้าผู้ใช้ทำผิด ระบบอธิบายได้ไหมว่าต้องแก้อะไร ถ้าการบันทึกล้มเหลว ข้อมูลครึ่งหนึ่งถูกสร้างค้างหรือไม่ กด Refresh แล้วเกิดรายการซ้ำไหม Back แล้วค่าหายหรือเปล่า Session หมดอายุระหว่างกรอกข้อมูลเป็นอย่างไร และถ้า Upload ไฟล์ไม่สำเร็จ ผู้ใช้เริ่มใหม่ตรงไหน

ข้อความ Error ที่ดีควรช่วยให้คนไปต่อ ไม่ใช่แจ้งว่า Something went wrong แล้วทิ้งผู้ใช้ไว้กับปรัชญาชีวิต ระบบไม่จำเป็นต้องเปิดเผยรายละเอียดทางเทคนิค แต่ควรบอกได้ว่าเกิดอะไรในระดับที่ผู้ใช้เข้าใจและควรทำอะไรต่อ เช่น “บันทึกไม่สำเร็จ กรุณาตรวจเลขเอกสารซ้ำ” ดีกว่า “Error 500” ที่มีประโยชน์มากสำหรับการทำให้คนเปิดแชตถาม Admin

7. Desktop, Mobile และ Browser ที่อยู่ใน Scope — Responsive ต้องลองใช้งาน ไม่ใช่ย่อหน้าต่างแล้วพยักหน้า

ถ้าหน้างานใช้มือถือ ให้เอามือถือจริงมาทดสอบ Flow สำคัญ เช่น กรอกฟอร์ม เปิด Select อัปโหลดรูป กดปุ่มท้ายหน้า อ่านตาราง ค้นหา และยืนยัน Dialog ตรวจ Keyboard บังช่องหรือไม่ ปุ่มเล็กเกินแตะไหม Modal เลื่อนต่อได้หรือเปล่า และข้อความสำคัญถูกตัดจนเหลือคำว่า “อนุมั...” หรือไม่

บริการ พัฒนา Web App และระบบหลังบ้าน ควรกำหนดอุปกรณ์และ Browser ที่รองรับใน Scope ก่อน เพราะคำว่า “ใช้ได้ทุกเครื่อง” ฟังดีมากจนถึงวันที่ต้องรองรับ Browser เก่าบนแท็บเล็ตที่ไม่มีใครกล่าวถึงตั้งแต่เริ่มงาน

8. Audit Trail และประวัติ — พอเกิดปัญหาแล้วตอบได้ไหมว่าใครทำอะไร

งานที่มีการอนุมัติ เปลี่ยนสถานะ แก้ยอด หรือจัดการข้อมูลสำคัญควรทดสอบประวัติตาม Scope เช่น ใครสร้าง ใครแก้ จากค่าอะไรเป็นอะไร เมื่อไร ใครอนุมัติหรือ Reject และหมายเหตุถูกเก็บหรือไม่ ถ้าระบบมี Audit Trail แต่ผู้ใช้แก้รายการแล้วประวัติบอกเพียง “Updated” ก็ต้องถามว่าเพียงพอกับการใช้งานจริงหรือไม่

จุดนี้เชื่อมกับการออกแบบระบบตั้งแต่แรก ถ้ายังไม่แน่ใจว่าเวอร์ชันแรกควรมีข้อมูล สถานะ ผู้รับผิดชอบ และประวัติแค่ไหน ลองดู ระบบหลังบ้าน SME ควรเริ่มจากฟังก์ชันไหนก่อน เพื่อจัด Workflow หลักก่อนค่อยเอามาแตกเป็น UAT

Test Case UAT ควรเขียนอย่างไรให้คนอื่นเปิดมาแล้วทดสอบต่อได้

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

ช่อง	ควรระบุอะไร	ตัวอย่าง
Case ID	รหัสอ้างอิงไม่ซ้ำ	UAT-APV-003
Scenario	สิ่งที่กำลังพิสูจน์	Supervisor อนุมัติคำขอของทีมตัวเอง
Role	บัญชี/สิทธิ์ที่ใช้	Supervisor
Precondition	สภาพก่อนเริ่ม	มี Request สถานะ Pending ของ Staff ในทีมเดียวกัน
Steps	ขั้นตอนที่ผู้ทดสอบทำ	เปิดรายการ → ตรวจรายละเอียด → กด Approve
Expected	ผลที่ต้องเกิด	สถานะเป็น Approved, บันทึกผู้อนุมัติและเวลา, Staff เห็นผล
Actual	ผลที่เกิดจริง	กรอกหลังทดสอบ
Status	Pass / Fail / Blocked	Pass
Evidence	ภาพ/วิดีโอ/Record ID	Request #REQ-1024 + screenshot

Expected Result ควรตรวจได้ อย่าเขียนว่า “ระบบทำงานถูกต้อง” เพราะประโยคนี้สุภาพมากแต่แทบใช้ตัดสินอะไรไม่ได้ เขียนให้ชัดว่า “สร้าง Record 1 รายการ, Status = Pending, Owner = ผู้สร้าง, Supervisor เห็นในคิวของทีม, Staff คนอื่นแก้ไม่ได้” จะรู้ทันทีว่าต้องมองอะไร

ตัวอย่าง UAT สำหรับ Approval Workflow แบบที่เอาไปดัดแปลงได้

สมมติบริษัทมีระบบขออนุมัติค่าใช้จ่ายที่มี Staff, Supervisor และ Finance ตัวอย่าง Test Case ที่ควรมีอาจเป็นดังนี้

1. สร้างคำขอปกติ: Staff กรอกข้อมูลครบและส่ง ระบบสร้างเลขรายการ สถานะ Pending และส่งเข้าคิว Supervisor ถูกคน
2. ข้อมูลไม่ครบ: Staff ไม่ใส่ Cost Center หรือยอดเงิน ระบบต้องไม่ส่งและบอกช่องที่ต้องแก้
3. สิทธิ์ข้ามทีม: Supervisor ทีม A เปิด URL รายการทีม B โดยตรง ต้องถูกปฏิเสธตาม Permission ที่ตกลง ไม่ใช่แค่ไม่มีลิงก์ให้กด
4. Approve: Supervisor อนุมัติแล้ว Status เปลี่ยน บันทึกชื่อ/เวลา และรายการเข้า Step ถัดไป
5. Reject: Supervisor ตีกลับพร้อมเหตุผล Staff เห็นเหตุผล แก้ไข และส่งใหม่ได้ตามกติกา
6. Double Submit: กด Approve ซ้ำหรือ Network ช้าจนกดสองครั้ง ต้องไม่สร้าง Transaction ซ้ำ
7. แก้หลังอนุมัติ: ลองแก้ยอดหรือไฟล์หลัง Approved เพื่อยืนยันว่าระบบอนุญาตหรือห้ามตาม Requirement
8. Audit: ประวัติต้องตอบได้ว่าใครสร้าง ใคร Reject ใครแก้ และใคร Approve ตามลำดับ
9. Notification: ผู้เกี่ยวข้องได้รับแจ้งเฉพาะเหตุการณ์ที่อยู่ใน Scope และลิงก์พาไปยัง Record ถูกต้อง
10. Report: รายการ Approved แสดงในรายงานตามวันที่และยอดที่นิยามไว้ โดยไม่เอา Reject มาปน

Notice ว่า Test Case เหล่านี้ไม่ได้ไล่ตามปุ่ม แต่ไล่ตาม ความเสี่ยงของงาน นั่นคือแนวคิดที่ช่วยให้ UAT มีมูลค่ามากกว่า Checklist หน้าตาดีที่ทุกแถวเป็นสีเขียวเพราะไม่มีใครลองเคสที่ไม่น่ารัก

Severity ของ Bug ต้องตกลงก่อนเจอ Bug ไม่ใช่เจอแล้วค่อยต่อรอง

คำว่า Critical, High, Medium, Low ไม่มีมาตรฐานตายตัวที่ทุกบริษัทต้องใช้เหมือนกัน สิ่งสำคัญคือกำหนดความหมายให้ทีมเข้าใจตรงกันก่อน UAT ตัวอย่างกรอบแบบง่ายสำหรับระบบธุรกิจคือ

ระดับ	ตัวอย่างผลกระทบ	แนวทางก่อน Go-Live
P0 / Critical	ข้อมูลเสียหรือสูญหาย, สิทธิ์รั่วร้ายแรง, Workflow หลักใช้ไม่ได้ทั้งระบบ, ความเสี่ยงความปลอดภัยสูง	No-Go จนกว่าจะแก้และ Retest
P1 / High	งานสำคัญทำต่อไม่ได้ ไม่มี Workaround ที่ยอมรับได้ หรือผลลัพธ์ธุรกิจผิด	โดยทั่วไปควรแก้ก่อน Go-Live
P2 / Medium	ฟังก์ชันรองผิด มี Workaround ที่ใช้งานได้ และไม่ทำให้ข้อมูลหลักผิด	พิจารณา Known Issue + กำหนดรอบแก้
P3 / Low	ข้อความ UI, ระยะห่าง, Cosmetic issue หรือความไม่สะดวกเล็กน้อย	อาจเปิดได้หาก Owner ยอมรับและบันทึกไว้

นี่เป็นเพียงตัวอย่าง ไม่ใช่กฎหมายสากล โครงการที่เกี่ยวกับเงิน สุขภาพ ข้อมูลส่วนบุคคล หรือกระบวนการที่มีผลกระทบสูงควรตั้งเกณฑ์เข้มกว่านี้ตามความเสี่ยง อย่าลด Severity เพราะ “นัดเปิดไว้แล้ว” วันที่บนปฏิทินไม่มีคุณสมบัติทางเทคนิคในการซ่อมฐานข้อมูลครับ

Acceptance Criteria คือสะพานระหว่าง Requirement กับ UAT

ถ้า Requirement เขียนว่า “ระบบต้องมีระบบค้นหาลูกค้า” ยังคลุมเครือมาก Acceptance Criteria ควรช่วยทำให้ตรวจได้ เช่น “ผู้ใช้ Role Sales ค้นหาลูกค้าด้วยชื่อ เบอร์โทร และเลขลูกค้าได้; ผลลัพธ์แสดงเฉพาะลูกค้าใน Scope ที่มีสิทธิ์; การค้นหาไม่แสดงข้อมูลที่ถูก Archive หากไม่ได้เลือก Include Archived” แบบนี้ทีมพัฒนารู้สิ่งที่ต้องสร้างและทีม UAT รู้สิ่งที่ต้องพิสูจน์

หน้า ตัวอย่าง Web App และระบบหลังบ้าน ของ Social Plus System ก็ใช้แนวคิด Scope → Prototype & Build → Acceptance Criteria → Launch เป็นส่วนหนึ่งของการอธิบายกระบวนการ เพราะถ้าไม่มีเงื่อนไขรับงานที่ตรวจได้ คำว่า “เสร็จ” มักยืดหยุ่นตามจำนวนข้อความที่ยังไม่ได้อ่านในแชต

Acceptance Criteria ที่ดีควรมีลักษณะดังนี้

• ระบุพฤติกรรมหรือผลลัพธ์ที่สังเกตได้
• ผูกกับ Role หรือเงื่อนไขเมื่อจำเป็น
• มีขอบเขตชัดว่าอะไรอยู่/ไม่อยู่ใน Scope
• ไม่ผูกกับวิธี Implement ภายในมากเกินไปถ้าไม่ใช่ Requirement
• ทดสอบซ้ำได้โดยคนอื่นแล้วได้ข้อสรุปเดียวกัน
• มีตัวอย่างข้อมูลหรือ Boundary หากเป็น Logic ที่ตีความได้หลายแบบ

Go/No-Go: เมื่อไรถึงควรบอกว่า “พร้อมขึ้น Production”

หลัง UAT อย่าปิดประชุมด้วยประโยค “โดยรวมโอเคนะ” แล้วถือว่านั่นคือ Sign-off ควรมีเกณฑ์ Go/No-Go แบบสั้นแต่ชัด ตัวอย่างเช่น

• Test Case ของ Core Workflow ผ่าน 100% ตามรายการที่กำหนด
• ไม่มี P0/Critical เปิดค้าง
• P1/High ที่เหลือมีเพียงรายการที่ Business Owner ยอมรับเป็นลายลักษณ์อักษร พร้อม Workaround และวันแก้ที่ตกลง
• Permission Test ของ Role สำคัญผ่าน
• ข้อมูลที่ต้อง Migration ผ่านการตรวจ Sampling/Count/Mapping ตามแผน
• บัญชี Production และสิทธิ์ Admin ถูกกำหนดผู้รับผิดชอบ
• Backup/Restore หรือแผน Recovery ถูกยืนยันตาม Scope
• Monitoring/Log ที่จำเป็นพร้อมให้ตรวจเมื่อเกิดปัญหา
• ผู้ใช้หลักรู้ URL, วิธี Login, ช่องทางแจ้งปัญหา และเวลาที่ระบบเริ่มใช้จริง
• มี Rollback หรือ Contingency Plan หากเปิดแล้วพบปัญหาที่รับไม่ได้

ข้อสังเกตคือครึ่งหลังของรายการนี้ไม่ใช่ UAT โดยตรง แต่เป็น Production Readiness ที่ต้องอยู่โต๊ะเดียวกันก่อน Go-Live เพราะการผ่าน UAT แล้วลืม Backup เปรียบเหมือนตรวจรถเสร็จทุกปุ่มแล้วออกเดินทางโดยไม่ดูว่ามีน้ำมันไหม รถดีครับ แต่แผนยังน่าสนใจอยู่

ทดสอบด้วยข้อมูลจริงแค่ไหนถึงพอดี

หลักคือให้ข้อมูล สมจริงพอที่จะเปิดเผยปัญหา แต่ไม่เอาข้อมูลจริงที่มีความอ่อนไหวมาใช้แบบไม่จำเป็น หากต้องใช้ข้อมูลจาก Production ควรพิจารณา Mask/Anonymize ตามความเหมาะสมและนโยบายองค์กร ที่สำคัญคือ Test Data ต้องสะท้อนความหลากหลายของงาน เช่น ชื่อยาว ภาษาไทย/อังกฤษ รายการไม่มีไฟล์ รายการมีหลายไฟล์ ยอดใกล้ขอบเขตสิทธิ์ วันที่ข้ามเดือน ลูกค้าที่ซ้ำชื่อ และเคสที่เคยสร้างปัญหาในระบบเดิม

ถ้าปัจจุบันทีมยังทำงานใน Excel และกำลังย้ายขึ้นระบบ การเอาตัวอย่างเคสจริงจากไฟล์เดิมมาทดสอบจะช่วยมาก เพราะมักเจอ Exceptions ที่ตอนทำ Requirement ถูกมองข้าม เช่น ลูกค้าหนึ่งรายมีหลายสาขา, เลขเอกสารเคยซ้ำ, บางรายการไม่มีวันที่ปิด หรือ Status เดิมถูกพิมพ์หลายแบบ หากยังอยู่ช่วงตัดสินใจว่าจะทำระบบหรือไม่ อ่าน ใช้ Excel อยู่ เมื่อไรควรเปลี่ยนเป็น Web App จะช่วยแยกปัญหาที่ควรแก้ด้วย Workflow ออกจากปัญหาที่แค่จัดไฟล์ใหม่ก็พอ

คนทำ UAT ควรเป็นใคร? อย่าเลือกเฉพาะคนที่ว่าง

ผู้ทดสอบควรเป็นตัวแทน Role และ Workflow จริง มีอำนาจหรือความเข้าใจพอที่จะบอกว่าผลลัพธ์ยอมรับได้หรือไม่ สำหรับระบบเล็กอาจเป็นเจ้าของธุรกิจกับพนักงานหลัก 2–3 คน สำหรับระบบหลายฝ่ายอาจต้องมี Process Owner ของ Sales, Operations, Finance และ Admin ตามส่วนที่เกี่ยวข้อง

คนที่เหมาะไม่ได้แปลว่าต้องเก่งไอทีที่สุด บางครั้งคนหน้างานที่ใช้กระบวนการทุกวันจะเจอปัญหาที่ทีมบริหารไม่เห็น เช่น ต้องกรอกข้อมูลเดิมสองรอบ ปุ่มอยู่ไกลตอนใช้มือถือ หรือสถานะที่ดูสมเหตุสมผลบน Flowchart จริง ๆ แล้วทำให้ฝ่ายถัดไปรอโดยไม่รู้ตัว นี่คือคุณค่าของ UAT ที่ Test Automation อย่างเดียวแทนไม่ได้

แต่ก็ไม่ควรโยน UAT ให้ผู้ใช้โดยไม่มี Guide แล้วสรุปว่า “User ไม่ยอมเทสต์” ทีมโครงการควรจัด Test Session, แบ่ง Scenario, ให้บัญชีพร้อม, อธิบายวิธีบันทึก Bug และช่วยแยกว่าอะไรคือ Bug, Change Request หรือ Training Issue ไม่อย่างนั้นผู้ใช้จะใช้เวลาเรียนระบบมากกว่าตรวจระบบ

Bug, Change Request และ “ผมนึกว่าได้” ต้องแยกออกจากกัน

ช่วง UAT เป็นเวลาที่ Requirement ที่ไม่ชัดจะเดินออกมาทักทายเราอย่างสุภาพมาก ปัญหาหนึ่งจึงอาจอยู่ใน 3 กลุ่มหลัก

• Bug: ระบบทำไม่ตรงสิ่งที่ตกลงหรือผิดจาก Expected Result เช่น Role Staff เห็นข้อมูลทุกทีมทั้งที่ Matrix ระบุ Own Team
• Change Request: ระบบทำตาม Scope เดิม แต่ผู้ใช้ต้องการเปลี่ยนหรือเพิ่ม เช่น จากอนุมัติ 1 ขั้นเป็น 3 ขั้นหลังเห็นของจริง
• Training/Understanding: ระบบทำถูก แต่ผู้ใช้ไม่รู้วิธีหรือคาดพฤติกรรมต่างออกไป เช่น ต้องกด Save Draft ก่อนแนบไฟล์ตาม Flow ที่ตกลง

การแยกสามกลุ่มนี้ไม่ได้มีไว้เพื่อเถียงว่าใครผิด แต่ช่วยให้จัดคิวและต้นทุนถูก Bug ต้องแก้ตามเงื่อนไขรับงาน Change Request ต้องประเมิน Scope/เวลา และ Training Issue ต้องแก้ด้วย UX, คู่มือ หรือการสื่อสารตามความเหมาะสม ถ้าโยนทุกอย่างเข้า Bucket “Bug” โครงการจะดูเหมือนพังหมด ถ้าโยนทุกอย่างเข้า “นอก Scope” ความสัมพันธ์ก็พังแทน เลือกให้พอดีครับ

ข้อผิดพลาด UAT ที่เจอบ่อย และบางข้อก็เจอบ่อยเกินกว่าจะเรียกว่าอุบัติเหตุ

ทดสอบเฉพาะ Happy Path

กรอกครบ กดถูก ลำดับถูก อินเทอร์เน็ตดี ทุกคนมีสิทธิ์ถูกต้อง แล้วระบบผ่านหมด เยี่ยมครับ เราเพิ่งพิสูจน์ว่าระบบทำงานได้ในจักรวาลที่ผู้ใช้ทุกคนมีสมาธิ 100% ซึ่งน่าเสียดายที่ Production ไม่ได้อยู่จักรวาลนั้น

ใช้ Admin ทดสอบทุกอย่าง

เร็วดีและผ่านง่าย แต่ทำให้ Permission defect หลุดได้มาก ควรใช้บัญชีแต่ละ Role จริงและลอง direct URL/Action ตามขอบเขตที่ทีมเทคนิคกำหนดด้วย

ไม่มี Expected Result

คนหนึ่งบอก Pass เพราะกดได้ อีกคนบอก Fail เพราะคิดว่าควรมี Notification สุดท้ายประชุม 40 นาทีเพื่อค้นหาความจริงจากความทรงจำ แก้ได้ด้วยการเขียน Expected ก่อนทดสอบ

เปิด Bug ในแชตอย่างเดียว

ภาพหน้าจอหนึ่งใบกับข้อความ “อันนี้ยังไม่ได้ค่ะ” อาจรู้เรื่องในวินาทีนั้น แต่สองวันผ่านไปไม่มี Record ID, ไม่มี Role, ไม่รู้ Browser และไม่รู้ว่าซ่อม Build ไหนแล้ว ใช้ Issue Log กลางแล้วแปะลิงก์ในแชตแทน

แก้แล้วไม่ Retest

สถานะ Fixed จาก Developer ไม่เท่ากับ Accepted จาก UAT ต้อง Retest เคสเดิม และถ้าการแก้กระทบจุดอื่นควรทำ Regression ตามความเสี่ยง ไม่เช่นนั้น Bug จะเปลี่ยนอาชีพจาก “พบแล้ว” เป็น “พบอีกทีหลังเปิดจริง”

นัด Go-Live ก่อน UAT แล้วใช้วันนั้นเป็นเหตุผลให้ทุกอย่างผ่าน

กำหนดการสำคัญ แต่ต้องมีเงื่อนไขเลื่อนถ้าพบ P0/P1 ตามที่ตกลง ถ้าทุก Bug ถูกตอบว่า “เปิดก่อน เดี๋ยวแก้ทีหลัง” UAT ก็เหลือบทบาทแค่พิธีตัดริบบิ้นทางดิจิทัล

Checklist สั้นสำหรับประชุม Sign-off UAT

• Scope รอบนี้ถูก Freeze และรายการนอก Scope แยกแล้ว
• ผู้ทดสอบครบ Role สำคัญ
• Core Workflow ผ่านตาม Test Case
• Permission ทั้ง Positive/Negative case ผ่าน
• Validation และข้อมูลสำคัญผ่าน
• Integration หลักผ่านทั้ง Success/Error case ที่ตกลง
• Mobile/Desktop ตาม Scope ผ่าน
• Report/Export ใช้สูตรและสิทธิ์ถูกต้อง
• Bug เปิดค้างถูกจัด Severity และ Owner
• รายการ Known Issue มี Workaround/กำหนดแก้
• Business Owner ยืนยัน Go/No-Go
• Deployment, Backup, Monitoring, Migration และ Rollback พร้อมตาม Scope

Checklist นี้ตั้งใจให้ใช้เป็นจุดเริ่ม ไม่ใช่แทน Test Plan ของทุกระบบ เพราะ Web App รับออเดอร์กับระบบอนุมัติการเงินย่อมมีความเสี่ยงไม่เท่ากัน หากระบบมี Payment, ข้อมูลอ่อนไหว, Compliance หรือ Integration ซับซ้อน ต้องเพิ่ม Test และผู้เชี่ยวชาญตามความเหมาะสม อย่าใช้ Checklist 12 ข้อเป็นยันต์กัน Production Incident แล้วโทษยันต์ภายหลัง

ถ้า UAT ไม่ผ่าน ควรทำอย่างไรโดยไม่ให้โครงการวนเป็นวงกลม

อย่าเปิดรอบใหม่แบบ “แก้ทั้งหมดแล้วลองใหม่” โดยไม่มีขอบเขต ให้ Freeze รายการ Defect, จัด Severity, ระบุ Owner และ Target Build จากนั้น Developer แก้ตามลำดับ ส่ง Change Log ว่า Build ใหม่แตะอะไรบ้าง แล้วให้ผู้ใช้ Retest เฉพาะ Fail/Blocked case พร้อม Regression เฉพาะพื้นที่เสี่ยงที่เกี่ยวข้อง วิธีนี้ทำให้รอบแก้มีจุดจบและรู้ว่าอะไรเปลี่ยน

ถ้าพบว่า Fail จำนวนมากเกิดจาก Requirement ไม่ชัด ไม่ควรฝืนเรียกทุกอย่างว่า Bug ให้กลับไปอัปเดต Scope/Acceptance Criteria ก่อนแล้วค่อยพัฒนาต่อ เพราะการ Retest บนกติกาที่ทุกคนตีความต่างกันจะสร้างตารางสีแดงได้เรื่อย ๆ โดยไม่เพิ่มความรู้ว่า “เสร็จหน้าตาเป็นอย่างไร”

UAT ที่ดีช่วยเรื่องงบและการส่งมอบ ไม่ใช่แค่เรื่องคุณภาพ

เมื่อ Acceptance Criteria และ Test Case ชัด ทีมจะเห็นเร็วขึ้นว่าอะไรคือ Defect ใน Scope และอะไรคือ Feature ใหม่ ทำให้คุยเรื่องรอบแก้ Deadline และค่าใช้จ่ายตรงขึ้น เจ้าของธุรกิจเองก็เห็นว่าระบบเวอร์ชันแรกครอบคลุมงานที่สำคัญแค่ไหนก่อนเพิ่มของใหม่ เช่น AI, Dashboard ขั้นสูง หรือ Automation เพิ่มเติม

ถ้ากำลังเริ่มวางระบบและยังไม่รู้ว่าจะทำหน้าจออะไรก่อน แนะนำให้ดู แนวทางเลือกฟังก์ชันแรกของระบบหลังบ้าน SME แล้วค่อยแตกแต่ละ Workflow เป็น Acceptance Criteria ตั้งแต่ก่อนพัฒนา วิธีนี้ถูกกว่าการรอให้ UI เสร็จสวยแล้วค่อยถามว่า “อ้าว แล้วฝ่ายบัญชีต้องกดตรงไหน”

สรุป: UAT ไม่ได้มีไว้จับผิดทีมพัฒนา แต่มีไว้จับความเข้าใจผิดก่อน Production

เป้าหมายของ UAT Web App ไม่ใช่การพยายามพิสูจน์ว่าระบบไม่มี Bug เหลืออยู่เลย เพราะซอฟต์แวร์จริงต้องอาศัยการทดสอบหลายระดับและการดูแลต่อเนื่อง เป้าหมายคือทำให้ผู้รับระบบมั่นใจว่า Workflow สำคัญ, สิทธิ์, ข้อมูล, ผลลัพธ์ และกรณีผิดพลาดที่จำเป็นต่อธุรกิจทำงานตามเกณฑ์ที่ตกลง และรู้ชัดว่าปัญหาที่เหลือมีอะไร ใครรับผิดชอบ และมีผลต่อการ Go-Live แค่ไหน

จำสูตรง่าย ๆ ได้ว่า Scenario → Role → Step → Expected → Evidence → Severity → Decision ถ้า UAT ตอบ 7 เรื่องนี้ได้ การ Sign-off จะไม่ต้องพึ่งความรู้สึกมากนัก และคำว่า “พร้อมขึ้น Production” จะมีหลักฐานรองรับมากกว่าความหวังกับอีโมจิ 👍 ในกลุ่มแชต

สำหรับธุรกิจที่กำลังวาง Scope ระบบใหม่ สามารถดูขอบเขต บริการพัฒนา Web App สำหรับ SME และระบบหลังบ้าน และ ตัวอย่างแนวคิด Web App เพื่อเห็นว่าการกำหนด User, Data, Flow, Screen และ Acceptance Criteria ควรเชื่อมกันตั้งแต่ก่อนเริ่ม Build ไม่ใช่ค่อยนึกถึงตอนกำลังจะกด Deploy