1. UAT คืออะไร และต่างจาก System Testing อย่างไร?
ก่อนถึง UAT ทีม Implementation มักมีการทดสอบ Function และ Configuration ของระบบอยู่แล้ว
แต่ UAT มีคำถามที่ต่างออกไป
System Testing อาจถามว่า“Function นี้ทำงานหรือไม่?”
แต่ UAT ต้องถามว่า“Business สามารถใช้ Function เหล่านี้ร่วมกัน เพื่อทำ Process จริงได้หรือไม่?”
ตัวอย่างเช่น Purchase Process ไม่ได้จบแค่สร้าง Purchase Order ได้
Purchase Request → Approval → Purchase Order → Receive → Supplier Invoice → Accounting → Payment → Reporting
UAT ต้องพิสูจน์ว่า กระบวนการทั้งหมดสามารถเดินได้จริง ตั้งแต่ต้นจนจบ
2. UAT ต้องย้อนกลับไปหา Business Blueprint
Business Blueprint ควรเป็น Baseline ของ To-Be Process ที่ต้องถูกทดสอบ
ถ้า Blueprint ระบุว่า ใครทำอะไร Approval อยู่ตรงไหน Control ทำงานอย่างไร และ Accounting Result ควรเป็นแบบไหน
UAT ก็ควรใช้สิ่งเหล่านั้น เป็น Expected Process
ไม่ควรเข้า UAT แล้วเพิ่งถามว่า“จริง ๆ แล้วเราต้องการให้ระบบทำแบบไหน?”
เพราะนั่นหมายความว่า Project กำลังใช้ช่วง UAT เป็นช่วง Design ระบบ ซึ่งสายเกินไปแล้ว
UAT Scenario จึงควรสามารถ Trace กลับไปหา
Requirement → To-Be Process → Configuration / Development → UAT Result
3. อย่าทดสอบเฉพาะ Happy Path
Scenario แรก ควรเป็น Normal Transaction เพื่อพิสูจน์ว่า Standard Process ทำงานครบ
แต่ถ้าทดสอบเฉพาะกรณีที่ทุกอย่างถูกต้อง ระบบอาจผ่าน UAT ได้ง่ายเกินไป
โลกจริงมี Exception เช่น
- Invoice ไม่ตรงกับ PO
- Approval ถูก Reject
- ลูกค้าจ่ายเงินไม่ครบ
- Credit Limit เกิน
- User เลือก Account หรือ Dimension ผิด
- Transaction ต้อง Cancel หรือ Reverse
- Interface ส่งข้อมูลไม่สำเร็จ
- Accounting Period ถูกปิดแล้ว
- User ไม่มีสิทธิ์ทำรายการ
ดังนั้น UAT ที่ดีควรมีทั้ง
Happy Path + Exception + Correction
4. ต้องทดสอบ Role และ Approval ด้วย
ระบบอาจคำนวณถูก แต่ยังใช้งานไม่ได้อย่างเหมาะสม หากสิทธิ์และ Approval ผิด
ตัวอย่างเช่น
- User ที่ไม่ควร Post กลับสามารถ Post ได้
- คนสร้างรายการสามารถ Approve รายการตัวเองได้
- Approval Limit ไม่ทำงาน
- User เห็นข้อมูลที่ไม่ควรเห็น
- รายการถูก Reject แล้วไม่สามารถส่งกลับมาแก้ไขได้
UAT จึงควรทดสอบด้วยUser Role จริงหรือ Role ที่จำลองโครงสร้างจริง ให้ใกล้เคียงที่สุด
ไม่ควรทดสอบทุกอย่างด้วย Admin User แล้วสรุปว่าระบบพร้อม Go-live
5. Accounting Result ต้องเป็น Expected Result ของ UAT
สำหรับ Accounting System การที่ Transaction ขึ้นว่า Complete ไม่ได้แปลว่าผลลัพธ์ถูกต้อง
ต้องตรวจต่อว่า
- Dr. / Cr. ถูก Account หรือไม่
- Amount ถูกต้องหรือไม่
- Tax ถูกต้องหรือไม่
- Posting Date ถูกต้องหรือไม่
- Department / Cost Center / Project ถูกหรือไม่
- Sub-ledger กับ GL เชื่อมกันถูกหรือไม่
- Exchange Rate ถูกใช้ตาม Rule หรือไม่
- Correction / Reversal ทำงานถูกหรือไม่
Expected Result จึงไม่ควรเขียนเพียงว่า “ระบบบันทึกสำเร็จ”
แต่ควรพิสูจน์ว่า
Transaction Complete + Accounting Posting ถูกต้อง + Control ทำงาน + Report แสดงผลถูก
6. Integration ต้องทดสอบ End-to-End
ถ้าระบบบัญชี เชื่อมต่อกับระบบอื่น การทดสอบเฉพาะฝั่ง Accounting System ยังไม่เพียงพอ
ระบบที่อาจเชื่อมกัน เช่น Sales, POS, Inventory, Payroll, Bank, Expense, E-commerce หรือ BI
ควรพิสูจน์ Flow ตั้งแต่
Source → Interface → Accounting System → Accounting Result → Report
รวมถึงควรทดสอบกรณี Interface Error เช่น ข้อมูลซ้ำ ข้อมูลไม่ครบ Mapping ผิด Transaction ถูก Reject หรือ Interface หยุดกลางทาง
และต้องรู้ว่า เมื่อ Error เกิดขึ้นใครเป็นคนแก้ และแก้อย่างไร
7. Report ต้องเป็นส่วนหนึ่งของ UAT
Report ไม่ควรถูกทิ้งไว้จนท้ายสุด
แม้ Transaction จะ Post ครบ หาก Report ไม่ได้ข้อมูลที่ Business ต้องการ Requirement ก็ยังไม่สมบูรณ์
ควรทดสอบอย่างน้อยว่า
- ยอดใน Report ตรงกับ Transaction
- GL ตรงกับ Sub-ledger
- Department / Project หรือ Dimension อื่นถูกต้อง
- Filter และ Period ทำงานถูก
- Management Report ให้ข้อมูลตาม Requirement
- Export หรือ Interface ไป BI ทำงานตามที่ออกแบบ
8. Data Migration ต้องทดสอบเหมือน Process หนึ่ง
Data Migration มักถูกมองว่าเป็น Technical Task แต่ข้อมูลเปิดระบบใหม่ มีผลโดยตรงกับการทำงานจริง
ข้อมูลที่ต้องพิจารณาอาจรวมถึง Opening GL, ลูกหนี้, เจ้าหนี้, Inventory, Fixed Assets, Customer, Supplier, Project และ Master Data
ก่อน Go-live ต้องพิสูจน์ว่า
จำนวน Record ถูก → ยอดถูก → Mapping ถูก → Reconcile ได้
ไม่ใช่เพียงเห็นว่า ข้อมูล Import เข้าไปในระบบแล้ว
9. UAT ต้องมี Expected Result ไม่ใช่ให้ User ลองเล่นระบบ
คำว่า “ให้ User เข้าไปลองใช้ดู” ยังไม่ใช่ UAT ที่ควบคุมได้
Test Scenario ควรมีอย่างน้อย
- Scenario
- Precondition
- Test Data
- Steps
- Expected Result
- Actual Result
- Pass / Fail
- Issue / Owner
โครงสร้างนี้ทำให้ทุกฝ่ายรู้ว่า กำลังพิสูจน์อะไร
และเมื่อ Test Fail จะช่วยแยกได้ว่า ต้องแก้ที่ Requirement, Configuration, Data หรือ Program
10. เมื่อไรจึงถือว่าพร้อม Go-live?
คำว่า UAT ผ่าน ไม่ได้หมายความว่า ต้องไม่มี Defect เหลืออยู่เลยทุกกรณี
แต่ Open Issue ต้องถูกมองเห็นและบริหารอย่างชัดเจนว่า
- Issue คืออะไร
- Severity เท่าไร
- กระทบ Business Process หรือไม่
- มี Workaround หรือไม่
- ใครรับผิดชอบ
- จะปิดเมื่อไร
- Business ยอมรับ Risk หรือไม่
Critical Process ที่จำเป็นต่อการดำเนินธุรกิจ ต้องสามารถใช้งานได้
และความพร้อมก่อน Go-live ต้องมองรวมทั้ง
Process + User + Data + Control + Report + Cutover
ไม่ใช่มองเฉพาะ Software
UAT Flow ที่ควรเห็น
Business Blueprint → UAT Scenario → Happy Path + Exception → Accounting Result → Integration & Reporting → Issue Resolution → Go-live Decision
สรุป
UAT ไม่ใช่ช่วงที่ให้ User เข้าไปลองเล่น Software
และไม่ใช่เพียงการตรวจว่า Screen หรือ Function ทำงานโดยไม่ Error
UAT คือการพิสูจน์ว่า
Business Process ที่ออกแบบไว้ สามารถทำงานจริงบนระบบใหม่ได้ ตั้งแต่ต้นจนจบ
ถ้า Business Blueprint คือสิ่งที่บอกว่า“เราตกลงว่าจะทำงานอย่างไร”
UAT ก็คือสิ่งที่พิสูจน์ว่า“สิ่งที่ตกลงนั้นทำงานได้จริง”
Green Light ที่ควรจำคือProcess ครบ → Result ถูก → Control ผ่าน → พร้อม Go-live