QAT — Quality Assurance Testing#

คนทำ: ทีม IT / QA team

ตอบคำถาม: ระบบทำงาน ตรงกับ technical specification ที่เขียนไว้ไหม

ตัวอย่าง:

• API ตอบกลับใน 200ms ไหม (ตรง spec)
• field “amount” รับค่าได้ถึง 999,999,999.99 ไหม (ตรง spec)
• ระบบ handle 1,000 concurrent users ได้ไหม (ตรง spec)

UAT — User Acceptance Testing#

คนทำ: end users — คนที่จะใช้ระบบจริงหลัง go-live

ตอบคำถาม: ระบบทำงาน ตรงกับ business process จริง ไหม

ตัวอย่าง:

• ฝ่ายบัญชีปิดเดือนด้วยระบบใหม่ — workflow ใช้งานได้จริงไหม
• พนักงานขาย create quote → convert เป็น order → ออก invoice ได้ใน 3 click ไหม
• ระบบรองรับ exception case ที่ business เจอจริง (เช่น customer ขอลด VAT ผ่าน workflow approval) ไหม

ทำไมต้องมีทั้งคู่#

QAT ผ่านไม่ได้แปลว่า UAT จะผ่าน — เพราะ specification อาจ “ถูกต้องแต่ไม่ตรงกับความต้องการจริง”

ตัวอย่างที่เห็นบ่อย: spec เขียนว่า “ระบบต้องรองรับการอนุมัติ 3 ระดับ” — implement ตามนั้น QAT ผ่าน แต่ UAT พบว่า process จริงต้องการ 4 ระดับสำหรับ transaction เกิน 1 ล้าน — spec ผิดตั้งแต่แรก

UAT คือ โอกาสสุดท้าย ที่ end user จะบอกว่า “นี่ไม่ใช่สิ่งที่ฉันต้องการ” ก่อนระบบ go-live ที่แก้ยากกว่ามาก

กับดัก ⚠️: UAT delegate ให้ vendor ได้

ผิดครับ — vendor มีแรงจูงใจให้ตัวเองผ่าน buyer ต้องทำเอง ใช้ test cases ที่ buyer เขียน + รัน test ในสภาพแวดล้อมที่ buyer ควบคุม

นี่คือเรื่องที่ผูกกลับไป ตอน 25 — vendor acquisition trap

Alpha + Beta Testing#

• Alpha — ทดสอบโดยทีมภายในก่อนปล่อยออกนอกบริษัท
• Beta — ทดสอบโดยกลุ่ม user จริงนอกบริษัท ก่อนปล่อย mass

Pilot Testing#

ปล่อยให้ user บางส่วน ใช้ก่อน เก็บ feedback แล้วค่อยขยาย — ลดความเสี่ยงจากการ rollout ทันที

White Box vs Black Box Testing#

• White box — ทดสอบโดยรู้โครงสร้างภายใน (logic paths, code branches) developer / programmer ใช้
• Black box — ทดสอบจาก functionality ภายนอก ไม่สนโครงสร้างภายใน end user / QA ใช้

กับดัก: White box = ครอบคลุม 100%

ผิด — ทดสอบ logic paths ทุกเส้นใน application ใหญ่เป็นไปไม่ได้ในทางปฏิบัติ เป้าหมายคือ adequate coverage ของ critical path

Regression Testing#

หลังแก้ไข code ใดๆ — ทดสอบว่าส่วนที่ดีอยู่แล้วยังทำงานได้ตามปกติ ไม่ใช่เน้นเฉพาะส่วนที่แก้

ในระบบที่ใช้ DevOps → regression test มักถูก automate เป็น test suite ที่รันทุก commit

Parallel Testing#

รันระบบใหม่ + ระบบเก่า พร้อมกันชั่วคราว เปรียบเทียบ output → ถ้าตรงกันต่อเนื่อง ระบบใหม่พร้อมรับ load เต็ม

กับดัก: Parallel = run ทั้ง 2 ระบบตลอดไป

ผิด — เป็นเทคนิค validation ชั่วคราว เมื่อมั่นใจแล้วต้อง decommission ระบบเก่า

Sociability Testing#

ระบบใหม่ “อยู่ร่วม” กับระบบที่มีอยู่ในบริษัทแล้ว (database, network, other apps) ไม่รบกวนกันไหม

Relational Integrity#

ความสัมพันธ์ระหว่าง record ใน table ถูกต้องไหม — เช่น primary key ไม่ซ้ำ, NOT NULL constraint ทำงาน

Referential Integrity#

Foreign key ชี้ไปยัง record ที่มีอยู่จริงไหม — เช่น order ที่อ้าง customer_id = ต้องมี customer record นั้นจริง

ถ้า referential integrity break — มี orphan record ในระบบที่ไม่มีคนเป็น parent — เป็น control gap ที่ทำให้ report ไม่ตรง

ACID Verification#

ทดสอบว่า:

• Atomicity — fail ระหว่าง transaction ทำให้ rollback ครบไหม
• Consistency — รัน transaction ที่ violate constraint ระบบ block ไหม
• Isolation — รัน 2 transaction พร้อมกัน เห็นกันไหม
• Durability — commit แล้วระบบล่ม ข้อมูลยังอยู่ไหม

ITF — Integrated Test Facility#

หลักการ: สร้าง “test entity” หลอกในระบบ production แล้วส่ง test transaction เข้าไปเหมือนเป็น real customer ดูว่าระบบ process ถูกไหม

ลองนึกถึงธนาคารที่มี “บัญชีทดสอบของ auditor” ซ่อนอยู่ในระบบ production — auditor ส่ง dummy transaction ผ่านระบบจริงเพื่อดูว่า:

• Edit checks ทำงานไหม
• Calculation ถูกไหม
• Workflow approval ตามที่ design ไหม

ข้อดี — ทดสอบใน production environment จริง ไม่ใช่ test environment ที่อาจต่างจาก prod

ข้อระวัง:

• Test entity ต้อง clearly separated จาก real data — ป้องกัน test transaction ปนกับ real ใน report
• Test transaction ต้องถูก reverse / cleanup หลังทดสอบ
• Audit team ต้องประสานกับ operations เพื่อไม่ให้ระบบเข้าใจผิดว่ามี customer ใหม่

กับดัก: ITF = ใส่ test data เข้า production = ไม่ปลอดภัย

ไม่จริงเสมอไป — ITF ที่ planned ดี + test entity แยกชัดเจน = valid technique ที่ใช้ในธนาคารหลายแห่งทั่วโลก

GAS — Generalized Audit Software#

หลักการ: software ที่ auditor ใช้ทำ data analysis บน production data — เช่น ACL, IDEA หรือ Python script ที่ auditor เขียนเอง

ใช้สำหรับ:

• Parallel simulation — รัน calculation logic ของ auditor บน production data → เปรียบเทียบกับ output ของระบบ → ถ้าตรงกัน = control การคำนวณทำงาน
• Exception identification — หา outlier, duplicate, missing record
• Trend analysis — ดูพฤติกรรมข้อมูลข้าม period

ผูกกับ Domain 1: GAS เป็น CAATs ที่หลักของ continuous auditing — ทำได้ตลอด ไม่ใช่แค่ตอน go-live

Snapshot#

หลักการ: บันทึก state ของ data ก่อน transaction รันและหลัง transaction รัน → ดูว่า logic ของ transaction ทำงานตรงตาม design ไหม

ใช้สำหรับตรวจ logic ของ specific transaction ที่ซับซ้อน

Mapping#

หลักการ: identify ส่วนของ code ที่ ไม่เคย execute — เพราะ logic อาจ unreachable หรือมี dead code ที่อันตราย

Tracing / Logging#

หลักการ: บันทึก execution path ของ specific transaction — ดูว่ามันผ่าน logic branch ไหนบ้าง ตรงตามที่ design ไหม

SCARF — System Control Audit Review File#

หลักการ: ระบบฝัง logic ที่ trigger เมื่อเจอ transaction “ที่ผิดปกติ” → บันทึกไว้ใน SCARF file ให้ auditor review ทีหลัง

ลองนึกถึงระบบ banking ที่ฝัง logic ว่า “ถ้า transaction > 1 ล้านบาทจาก IP ต่างประเทศที่ไม่ใช่ customer ปกติ → log ไปที่ SCARF” auditor เปิด SCARF file ทุกสัปดาห์เพื่อ review

นี่คือ embedded audit — auditor logic ฝังในระบบเลย

Test Databases / Parallel Simulation#

ทดสอบ application logic บน database ของตัวเอง (clone จาก production) — แยกจากระบบจริง

Embedded Audit Data Collection#

ระบบบันทึกข้อมูลเฉพาะ event ที่ audit สนใจ ตลอดเวลา ไม่ใช่แค่ตอน auditor มาตรวจ

มุมที่ผู้บริหารต้องเข้าใจ: Auditor ที่ใช้ tools เหล่านี้ — evidence ที่ได้ น่าเชื่อถือมากกว่า เอกสาร test results ที่บริษัทจัดเตรียมให้ เพราะเป็น independent testing — ตรงตามหลัก audit evidence ใน Domain 1 ตอน 09-10

Production Promotion Controls#

โค้ดที่ผ่านทดสอบแล้วต้อง promote ไปยัง production environment อย่างมีการควบคุม:

• คนที่ promote ต้องไม่ใช่ developer ที่เขียนโค้ด (SoD)
• Version ที่ promote ต้องตรงกับ version ที่ผ่านทดสอบเป๊ะ
• มี audit trail ของการ promote (ใคร, เมื่อ, version ไหน, จาก/ไปที่ไหน)
• มี rollback procedure ถ้า production ขึ้นแล้วเจอปัญหา

Certification + Accreditation#

• Certification = process ที่ระบบถูก evaluate ว่า ตรงตาม security + business requirement ที่ตั้งไว้ — โดยทีม technical
• Accreditation = senior management อนุมัติให้ระบบขึ้น production — โดย accept residual risk ที่ certification ระบุไว้

นี่คือจุดที่ executive accountability ฝังเข้ามา — ผู้บริหารที่ accredit ระบบที่ยังมี risk สูง = รับผิดชอบ residual risk นั้น

มุม IS auditor: ดู certification + accreditation document ก่อนระบบ go-live — ถ้าไม่มี / มีแต่ไม่ครบ = control gap ระดับ governance