สารบัญ
ผมเพิ่งเข้าใจว่าทำไม ITF, GAS, SCARF, snapshot, parallel simulation — ชื่อทั้งหมดที่ฟังเหมือน sci-fi — จริงๆ คือ ส่วนขยายของ auditor เอง ไม่ใช่เครื่องมือของ developer
ตอนผมอ่าน Section 3.5 รอบแรก ผมรู้สึก intimidated มากครับ alphabet soup เต็มไปหมด UAT, QAT, ITF, GAS, SCARF, CAATs — และทั้งหมดดูเป็นเรื่องของ developer ที่ผมไม่ใช่ ผมต้องหยุดอ่านหลายครั้งเพราะรู้สึกว่ามันไม่ใช่โลกของผม
จุดที่ทำให้ผมเริ่มไม่กลัวคือตอนเข้าใจว่าบทนี้แบ่งเป็น 2 ฝั่งชัดเจน ครับ ฝั่งหนึ่งคือ testing ที่ “ทีมโปรเจ็คทำ” (Unit, Integration, System, UAT, QAT) — ตรงนี้ auditor มีหน้าที่ “ตรวจว่าทำเพียงพอไหม”; ฝั่งสองคือ tools ที่ “auditor ใช้ทดสอบเอง” (ITF, GAS, SCARF) — ตรงนี้คือเครื่องมือของผมในฐานะ auditor ไม่ใช่ของทีม dev
พอแยกสองฝั่งออก ความรู้สึก intimidated หายไปเยอะครับ เพราะผมไม่ต้องเป็น developer ที่เขียน code ตามมาตรฐาน QAT ผมแค่ต้องเข้าใจมากพอที่จะถามว่า “QAT ผ่านแล้วทำไมยังต้องทำ UAT” หรือ “ITF กับ test environment ต่างกันยังไง” คำถามพวกนี้ผมตอบได้ — แม้ผมจะไม่ได้เป็นคน implement ระบบเอง
มี application control แล้ว แต่ control ที่ “design ดี” ไม่จำเป็นต้อง “ทำงานจริง” เสมอไป
นี่คือเรื่องของ Section 3.5 testing คือ quality gate ก่อน go-live และเป็นจุดที่ IS auditor มี dual role:
- ตรวจว่า testing process ของบริษัทเพียงพอไหม (ตรวจคนอื่น)
- ใช้ testing tool ของตัวเองเพื่อ verify control independently (ทดสอบเอง)
บทนี้คุยทั้ง 2 มิติ testing ที่ทีมโปรเจ็คทำ + tools ที่ auditor ใช้
Mental Model: Testing แต่ละแบบตอบคำถามคนละข้อ
ก่อนเริ่ม ขอวาง mental model ก่อนครับ testing ไม่ใช่กิจกรรมเดียว แต่เป็น family ของ activity ที่แต่ละแบบตอบคำถามคนละข้อ
| Testing | คำถามที่ตอบ |
|---|---|
| Unit testing | Module นี้ทำงานถูกตามที่ design ไหม |
| Integration testing | Module หลายตัวทำงานร่วมกันได้ไหม |
| System testing | ระบบทั้งระบบทำงานตาม spec ไหม |
| Recovery testing | ระบบ recover ได้เมื่อ fail ไหม |
| Security testing | คนที่ไม่ได้ authorize เข้าระบบได้ไหม |
| Load testing | ระบบรับข้อมูลปริมาณมากได้ไหม |
| Volume testing | ระบบ handle data volume ที่คาดได้ไหม |
| Stress testing | ระบบรับ concurrent users สูงสุดได้เท่าไหร่ก่อน fail |
| Performance testing | ระบบตอบสนองในเวลาที่ acceptable ไหม |
| QAT | ระบบตรง technical specification ไหม |
| UAT | ระบบทำงานตรงกับ business process จริงไหม |
ทุกแบบต้องทำ ไม่ใช่เลือกอย่างใดอย่างหนึ่ง
กับดัก: Load testing = Stress testing
ไม่ใช่ครับ load = data volume, stress = concurrent users คนละ dimension ของ performance
QAT vs UAT — กับดักคลาสสิคของ exam
นี่คือกับดักที่ออกข้อสอบบ่อยที่สุดของ Section 3.5
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
Other Testing Types ที่ทดสอบบ่อย
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) โดยไม่รบกวนกันไหม
Data Integrity Testing
เรื่องนี้เป็นเรื่องคู่ขนานกับ ACID ที่คุยใน ตอน 27 — ทดสอบว่า data integrity ในระบบ + ระหว่างระบบ ไม่เสียหาย
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 แล้วระบบล่ม ข้อมูลยังอยู่ไหม
IS Auditor’s Own Testing Tools — CAATs ใน SDLC context
ถึงตรงนี้คือเนื้อหาที่ผมว่ามีค่าที่สุดของบท เครื่องมือที่ auditor ใช้ทดสอบเอง
ตอน Domain 1 ตอน 11 เราคุยเรื่อง CAATs (Computer-Assisted Audit Techniques) ในมุม continuous auditing ที่นี่เราคุย CAATs ในมุม SDLC เครื่องมือทดสอบ application controls ที่ auditor ใช้
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 + Certification
ทดสอบครบทุกแบบแล้ว ก่อนระบบ go-live ยังต้องผ่าน 2 ขั้นตอนสำคัญ:
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
ทำไมเรื่องนี้สำคัญกับ exam
ผมเห็น 6 trap pattern หลักของ Section 3.5:
- UAT delegate ให้ vendor ได้ — ผิด buyer ทำเอง
- QAT = UAT — ผิด คนละทีม คนละคำถาม
- White box = 100% coverage — ผิด adequate coverage ของ critical path
- Parallel testing = ตลอดไป — ผิด เทคนิคชั่วคราว
- Stress = Load — ผิด stress = concurrent users, load = data volume
- ITF = ไม่ปลอดภัยเพราะใส่ test data ใน production — ผิด ถ้า planned ดี + test entity แยกชัด = valid
จำ 6 ข้อนี้ + ชื่อ tools (ITF, GAS, SCARF, snapshot, mapping, parallel simulation) — Section 3.5 ผ่านระดับแนวคิดไปแล้วเกินครึ่ง
สิ่งที่ผมเก็บได้จากบทนี้
ในมุมผม Section 3.5 สอนเรื่องที่ใหญ่กว่า testing เยอะ — มันสอนว่า independence ของ auditor ไม่ใช่แค่ “ไม่เกี่ยวข้องกับ project” แต่คือ “มีเครื่องมือทดสอบของตัวเองที่ไม่พึ่ง output ของทีม” ครับ ถ้า auditor เชื่อแค่ test results ที่ทีมเตรียมให้ ก็คือไม่ได้ตรวจอะไรเลย ITF กับ GAS เลยไม่ใช่เครื่องมือที่ “เท่” — มันคือเครื่องมือที่ทำให้คำว่า “audit” มีความหมายจริง
ที่ผมคิดว่าจะติดอยู่ในใจเป็นพิเศษคือกฎ UAT ห้าม delegate ให้ vendor ครับ ฟังดูชัดเจน แต่ในความเป็นจริงคือกับดักที่หลายโปรเจ็คตกเพราะ vendor มี test team ที่พร้อมและ “ใจดี” ที่จะทำให้ ปัญหาคือ vendor มีแรงจูงใจให้ตัวเองผ่าน buyer ที่ delegate UAT ให้ vendor = จ่ายเงินซื้อ rubber stamp ของตัวเอง ตรงนี้เป็น insight ที่ผมเชื่อว่าจะติดตัวผมต่อแม้จบ CISA ไปแล้ว
อีกคู่ที่ผมต้องท่องคือ certification (technical) vs accreditation (management approval) — ก่อนระบบ go-live ทั้งสองต้องครบ ที่สำคัญคือ accreditation = senior management accept residual risk ไม่ใช่แค่เซ็นชื่อ — ใครเซ็นต้องรับผิดชอบความเสี่ยงนั้น ผูกกลับไปที่หลัก governance ทั้งหมดของ Domain 2
สิ่งที่ผมจดสำหรับวันสอบ — UAT = buyer ทำเอง, QAT ≠ UAT, White box ≠ 100% coverage, Parallel = ชั่วคราว, Stress (concurrent users) ≠ Load (data volume), ITF planned ดี = valid ไม่ใช่อันตราย หกอันนี้คือ trap pattern หลักของบท
ทดสอบครบ certified แล้ว approval แล้ว เหลือขั้นตอนสุดท้ายที่หลายโปรเจ็คล้มเหลวตรงนี้แม้ทุกอย่างผ่านมาแล้วทุกด่าน
Go-Live Day วันที่ความเสี่ยงสูงสุดของโปรเจ็คทั้งหมด
ตอนหน้าจะลง config management + release + migration + data conversion เรื่องของการ transition ที่มีหลายจุดที่อาจพังได้
อ้างอิง CRM (CISA Review Manual 28th Edition): Domain 3: Section 3.5 System Readiness and Implementation Testing
