V-Model — แผนที่ที่ map V&V ลงทุก phase ของ SDLC#

วงการมี diagram คลาสสิคชื่อ V-Model ที่วาง phase ของ SDLC เป็นรูปตัว V — ฝั่งซ้ายไล่ ลง (เขียน spec ละเอียดขึ้นเรื่อยๆ) ฝั่งขวาไล่ ขึ้น (testing จากเล็กไปใหญ่). จุดต่ำสุดของ V คือ coding. แต่ละ phase ฝั่งซ้ายมี phase ฝั่งขวาเป็นคู่ — เขียน spec ไว้ยังไง ต้อง test ตามนั้น

ลองอ่านเป็นตาราง คู่ Verification ↔ Validation ก่อน:

อ่านยังไง:

1. Project Owner กำหนด ใน Analysis (1) ว่า “อยากให้ระบบทำอะไร” → จะถูก ตรวจ ใน UAT (9) ว่าระบบทำสิ่งนั้นได้จริง
2. IT Project Team เขียน Functional Specs (2) ว่า “feature ต้องมีอะไรบ้าง” → จะถูก ตรวจ ใน System Testing (8) ว่าทุก feature work
3. V&V Team ออกแบบ Technical Specs (3) ว่า “module ต่อกันยังไง” → จะถูก ตรวจ ใน Integration Testing (7)
4. Developer เขียน Detailed Specs (4) ว่า “function แต่ละตัวทำอะไร” → จะถูก ตรวจ ใน Unit Testing (6)
5. กลางคือ Development (5) — coding จริง

ถ้าวาดเป็นแผนภาพ phase ไหลตามเวลาจะออกมาเป็นรูปตัว V:

graph TD
  A1["1. Analysis"] --> A2["2. Functional Specs"]
  A2 --> A3["3. Technical Specs"]
  A3 --> A4["4. Detailed Specs"]
  A4 --> A5["5. Development<br/>(coding)"]
  A5 --> A6["6. Unit Testing"]
  A6 --> A7["7. Integration Testing"]
  A7 --> A8["8. System Testing"]
  A8 --> A9["9. User Acceptance Testing"]

  A1 -.ตรวจกัน.-> A9
  A2 -.ตรวจกัน.-> A8
  A3 -.ตรวจกัน.-> A7
  A4 -.ตรวจกัน.-> A6

  style A1 fill:#a5b4fc,color:#000
  style A2 fill:#a5b4fc,color:#000
  style A3 fill:#a5b4fc,color:#000
  style A4 fill:#a5b4fc,color:#000
  style A5 fill:#fca5a5,color:#000
  style A6 fill:#fcd34d,color:#000
  style A7 fill:#fcd34d,color:#000
  style A8 fill:#fcd34d,color:#000
  style A9 fill:#fcd34d,color:#000

ม่วง = Verification phases (เขียน spec ลงลึก) / แดง = Development (coding) / เหลือง = Validation phases (testing ไล่กลับขึ้นมา). เส้นประคือ “phase นี้ test phase ไหน” — เป็น mapping ที่ V-Model บังคับให้คิดก่อน build

อ่าน V-Model ยังไง:

• ฝั่งซ้าย (1→4) — ระบุความต้องการละเอียดขึ้นเรื่อยๆ จาก business need ลงถึง detailed spec
• จุดต่ำสุด (5) — coding
• ฝั่งขวา (6→9) — testing ไล่ขึ้นมา จาก unit ที่เล็กที่สุด ไป UAT ที่ตอบ business
• เส้นคู่ที่จับกัน — แต่ละ phase ของซ้ายมี testing คู่กันที่ขวา

ตัวอย่าง:

• Detailed Specs (4) เขียนว่า function calculateVAT() รับ amount → return amount * 0.07 → Unit Testing (6) test ว่า function นี้ทำตรงตามนั้นไหม
• Functional Specs (2) เขียนว่า ระบบต้องคำนวณ VAT 7% ทุก invoice → System Testing (8) test ว่าระบบทั้งระบบทำงานตามนั้นจริงไหม
• Analysis (1) บอกว่า business ต้องคำนวณภาษี Thai law → UAT (9) ตอบว่าระบบใช้ได้ใน workflow ภาษีจริงของบริษัทไหม

เหตุผลที่ V-Model จับใจวงการ — มัน บังคับให้ define test ก่อน build. เพราะถ้าวาด V-Model ก่อน coding คุณจะรู้ทันทีว่า “Phase 2 เขียน spec แบบนี้ Phase 8 ต้อง test อะไร” — ป้องกัน trap ที่ spec ไม่มีทาง verify

Mapping กลับ QAT vs UAT#

ที่ Section 3.5 พูดถึง QAT กับ UAT — แท้จริงคือ V&V ในอีกชื่อ

ดังนั้นเวลาเห็นข้อสอบ CISA ใช้คำว่า “V&V activities” หรือ “verification techniques” หรือ “validation requirements” — ไม่ใช่ศัพท์ใหม่ มันคือ QAT/UAT/testing types ทั้งหมดที่กำลังจะคุยถัดไป แค่เปลี่ยน label ให้ตรงมาตรฐานวงการ

กับดัก ⚠️: Verification และ Validation ใช้แทนกันได้

ไม่ได้ครับ Verification = “ทำถูกตามแบบ” / Validation = “แบบถูกตั้งแต่แรกไหม” คำคนละความหมายในข้อสอบ. ถ้าโจทย์ถามเรื่อง “spec compliance” → Verification ถ้าถามเรื่อง “business need fit” → Validation

ทำไมต้องเริ่มที่ V&V ก่อน#

เพราะ activity ทุกอย่างใน Section 3.5 — testing types / certification / CAATs — คือเครื่องมือของ V&V. ถ้าไม่เห็นภาพ V&V ทั้งหมดดูเหมือนรายการศัพท์ที่ต้องท่องจำ; พอเห็นภาพแล้วทุกอย่างมีบ้านของตัวเอง

ลองเก็บคำถาม “Are we building it right?” vs “Are we building the right thing?” ไว้ใน mind. ต่อจากนี้ทุก testing ที่จะคุยจะตอบคำถามไหนคำถามหนึ่งใน 2 ข้อนี้

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