การตรวจสอบความถูกต้อง เทียบกับการพิสูจน์ยืนยัน: ความแตกต่างที่สำคัญในการทดสอบ

ทีมพัฒนาสามารถสร้างซอฟต์แวร์ที่ตรงตามข้อกำหนดทุกข้อ แต่ยังส่งมอบผลิตภัณฑ์ที่ผิดได้ หรือในทางกลับกัน อาจสร้างผลิตภัณฑ์ที่ตอบโจทย์ผู้ใช้บนโค้ดที่มีบั๊กเต็มไปหมด ปัญหาแรกคือ การตรวจสอบ (Verification) ส่วนปัญหาที่สองคือ การรับรองความถูกต้อง (Validation) หากแยกสองคำนี้ไม่ชัด กระบวนการ QA จะดูยุ่งมาก แต่จับปัญหาที่สำคัญไม่ครบ

ลองใช้ Apidog วันนี้

บทความนี้สรุปความต่างระหว่าง Verification และ Validation พร้อมแนวทางนำไปใช้กับการทดสอบ API ด้วย Apidog

การตรวจสอบ (Verification) คืออะไร?

Verification ถามว่า: เรากำลังสร้างผลิตภัณฑ์ได้ถูกต้องตามที่ระบุไว้หรือไม่?

เป้าหมายคือเช็กว่าโค้ด การออกแบบ และพฤติกรรมของระบบตรงกับข้อกำหนดหรือสัญญาที่ตกลงไว้หรือไม่ เช่น API spec, OpenAPI schema, design document หรือ coding standard

Verification ไม่ได้ถามว่าข้อกำหนดนั้นดีพอหรือไม่ แต่ถามว่า implementation ทำตามข้อกำหนดนั้นจริงหรือเปล่า

กิจกรรม Verification ที่ควรทำระหว่างพัฒนา ได้แก่:

• Code review และ walkthrough
• Static analysis และ linting
• ตรวจสอบ design และ architecture
• Schema validation และ contract check
• Unit test ที่ตรวจว่าฟังก์ชันทำงานตาม signature และ logic ที่ระบุไว้
• API assertion เช่น status code, headers, response body และ schema

ตัวอย่างเช่น ถ้า specification ระบุว่า POST /orders ต้องส่งกลับ 201 Created พร้อม header Location การตรวจสอบคือการยืนยันว่า endpoint นั้นส่งกลับตามนี้จริง

POST /orders
Content-Type: application/json

{
  "sku": "A-100",
  "quantity": 2
}

ผลลัพธ์ที่ควรถูกตรวจสอบ:

HTTP/1.1 201 Created
Location: /orders/ord_123
Content-Type: application/json

{
  "id": "ord_123",
  "status": "created"
}

ถ้า response ตรงตาม status code, header และ schema ที่กำหนดไว้ ถือว่า Verification ผ่าน

การรับรองความถูกต้อง (Validation) คืออะไร?

Validation ถามว่า: เรากำลังสร้างผลิตภัณฑ์ที่ถูกต้องสำหรับผู้ใช้จริงหรือไม่?

Validation ตรวจว่าซอฟต์แวร์ตอบโจทย์ผู้ใช้ แก้ปัญหาจริง และใช้งานได้ในบริบทจริงหรือไม่ แม้ระบบจะตรงตามเอกสารทุกข้อ ก็ยังอาจไม่ผ่าน Validation ได้ หากเอกสารหรือ requirement ตั้งต้นผิด

กิจกรรม Validation ที่มักใช้ ได้แก่:

• User acceptance testing
• Beta program และ usability testing
• End-to-End test ของ workflow จริง
• Demo และ stakeholder sign-off
• การทดสอบ scenario ที่จำลองการใช้งานของลูกค้าจริง

ตัวอย่าง API ที่ผ่าน Verification แต่ไม่ผ่าน Validation:

• Schema ถูกต้อง แต่ pagination ใช้งานยากเกินไปสำหรับ client
• Auth flow ตรงตาม spec แต่ไม่เหมาะกับระบบ integration ของลูกค้า
• Endpoint ส่งข้อมูลครบตามเอกสาร แต่ไม่มีข้อมูลที่ frontend ต้องใช้จริง
• ตัวอย่างในเอกสารใช้ได้ แต่ไม่สะท้อน workflow ที่ผู้ใช้ทำจริง

ดังนั้น Validation คือการทดสอบกับ “วัตถุประสงค์จริง” ไม่ใช่แค่กับเอกสาร

Verification vs Validation: ความแตกต่างหลัก

มิติ	การตรวจสอบ (Verification)	การรับรองความถูกต้อง (Validation)
คำถามหลัก	เราสร้างมันได้ถูกต้องหรือไม่?	เราสร้างสิ่งที่ถูกต้องหรือไม่?
เปรียบเทียบกับ	ข้อกำหนด, การออกแบบ, มาตรฐาน	ความต้องการของผู้ใช้, การใช้งานจริง
ช่วงเวลา	ต่อเนื่องตลอดการพัฒนา	เมื่อมีระบบหรือ workflow ให้ทดลองใช้
วิธีทั่วไป	Code review, static analysis, unit test, schema check	UAT, beta test, End-to-End test, demo
ทิศทาง	ภายใน: artifact เทียบกับ artifact	ภายนอก: product เทียบกับ reality
ตรวจพบ	บั๊ก, ความไม่ตรง spec, contract mismatch	requirement ผิด, workflow ไม่เหมาะ, usability gap
ถ้าละเลย	ได้โค้ดที่ไม่เสถียร	ได้ผลิตภัณฑ์ที่ทำงานถูก แต่แก้ปัญหาผิด

ทั้งสองอย่างแทนกันไม่ได้

• Verification แข็งแรง แต่ Validation อ่อนแอ → ได้ระบบที่ตรง spec แต่ไม่มีใครอยากใช้
• Validation แข็งแรง แต่ Verification อ่อนแอ → ได้แนวคิดที่ถูก แต่ implementation ไม่เสถียร

จำง่าย ๆ:

Verification = ทดสอบกับ เอกสาร

Validation = ทดสอบกับ วัตถุประสงค์

สิ่งนี้มีผลอย่างไรกับการทดสอบ API

API เหมาะมากสำหรับอธิบายความต่างนี้ เพราะ API มักมีสัญญาชัดเจน เช่น OpenAPI schema, request/response schema และ status code ที่ระบุไว้

Verification สำหรับ API

Verification สำหรับ API คือการตรวจ implementation เทียบกับ contract เช่น:

• แต่ละ endpoint ส่ง status code ตามเอกสารหรือไม่? ดูแนวทางเพิ่มเติมได้ที่ รหัสสถานะ HTTP ที่ REST API ควรสื่อสาร
• Response body ตรงกับ schema หรือไม่?
• Field name และ data type ถูกต้องหรือไม่?
• Required parameter ถูกบังคับใช้จริงหรือไม่?
• Error response ตรงกับรูปแบบที่ระบุไว้หรือไม่?
• Header ที่จำเป็น เช่น Location, Content-Type, Authorization ถูกส่งกลับหรือไม่?

ตัวอย่าง assertion ที่ควรมีสำหรับ endpoint หนึ่ง:

POST /payments:
  expected:
    status: 201
    headers:
      Content-Type: application/json
    body:
      payment_id: string
      status: string
      amount: integer
      currency: string

นี่คือจุดที่ การทดสอบสัญญา API มีบทบาท เพราะ contract test คือ Verification โดยตรง: ตรวจว่า API ยังรักษาข้อตกลงที่ consumer พึ่งพาอยู่หรือไม่

ในระดับ test case คุณสามารถใช้ การยืนยัน API เพื่อตรวจ status, schema, header และ response body

Validation สำหรับ API

Validation สำหรับ API คือการตรวจว่า API ใช้งานได้จริงใน workflow ของ consumer หรือไม่ เช่น:

• ลูกค้าสามารถ login → create → update → delete ได้ครบ flow หรือไม่?
• Response มีข้อมูลที่ frontend หรือ integration ต้องใช้จริงหรือไม่?
• Auth model เหมาะกับระบบของลูกค้าหรือไม่?
• ตัวอย่าง request/response ในเอกสารสะท้อน usage จริงหรือไม่?
• Error message ช่วยให้ developer แก้ปัญหาได้จริงหรือไม่?

ตัวอย่าง workflow ที่เป็น Validation มากกว่า Verification:

1. Register user
2. Login
3. Create payment method
4. Create payment
5. Query payment status
6. Reconcile result with invoice

การตรวจ schema ของ endpoint เดียวคือ Verification แต่การรัน workflow หลาย step แบบนี้คือ Validation เพราะมันวัดว่า API ใช้งานได้จริงในเส้นทางของผู้ใช้หรือไม่

หากต้องแยกเลเยอร์การทดสอบให้ชัดเจน ลองดูแนวคิดเรื่อง สถานการณ์การทดสอบเทียบกับกรณีการทดสอบ

Apidog เข้ามามีบทบาทอย่างไร

Apidog รวมการออกแบบ API, การทดสอบ และเอกสารไว้ใน workspace เดียว ทำให้ทีมใช้ source of truth เดียวกันได้ทั้ง Verification และ Validation

ใช้ Apidog สำหรับ Verification

ในการตรวจสอบระดับ contract ให้เริ่มจาก API design หรือ schema ที่เป็นข้อกำหนดหลัก จากนั้นสร้าง test ที่ยืนยัน response เทียบกับ schema เดียวกัน

สิ่งที่ควรตั้งค่า:

1. กำหนด endpoint, request, response และ schema
2. เพิ่ม assertion สำหรับ status code
3. เพิ่ม assertion สำหรับ response schema
4. เพิ่ม assertion สำหรับ required header
5. เพิ่ม negative test สำหรับ error response
6. รัน test ทุกครั้งใน CI/CD

ตัวอย่างสิ่งที่ควรตรวจใน POST /payments:

{
  "statusCode": 201,
  "schema": {
    "payment_id": "string",
    "amount": "integer",
    "currency": "string",
    "status": "string"
  }
}

เมื่อ test เหล่านี้รันในทุก commit ทีมจะตรวจพบ contract mismatch ได้เร็วขึ้น ดูแนวทางเพิ่มเติมได้ที่ การทำให้การทดสอบ API เป็นไปโดยอัตโนมัติใน CI/CD

ใช้ Apidog สำหรับ Validation

สำหรับ Validation ให้สร้าง test scenario ที่เชื่อมหลาย endpoint เข้าด้วยกันเป็น workflow จริง เช่น:

Register user
→ Login
→ Create resource
→ Update resource
→ Query resource
→ Delete resource

เป้าหมายไม่ใช่แค่ดูว่าแต่ละ endpoint ตรง schema หรือไม่ แต่ดูว่า workflow ทั้งหมดแก้ปัญหาได้จริงหรือเปล่า

ตัวอย่าง scenario สำหรับ API ชำระเงิน:

1. Create customer
2. Add payment method
3. Create payment
4. Fetch payment status
5. Verify amount and invoice reference

ถ้า endpoint เดี่ยวผ่านทั้งหมด แต่ workflow นี้ล้มเหลว แปลว่าปัญหาอาจอยู่ที่ design หรือ requirement ไม่ใช่แค่ bug ใน endpoint เดียว

Apidog ยังช่วยให้เห็นผลลัพธ์เป็น step-by-step จึงแยกได้ชัดขึ้นว่า failure เป็นแบบใด:

• Schema mismatch → ปัญหา Verification
• Workflow ใช้งานไม่ได้ → ปัญหา Validation

คุณสามารถ ดาวน์โหลด Apidog เพื่อจัดการทั้ง contract-level verification และ workflow-level validation สำหรับ API ของคุณ

ตัวอย่างในโลกจริง: API การชำระเงิน

สมมติทีมกำลังสร้าง Payment API โดย spec ระบุว่า:

• POST /payments รับ amount และ currency
• ถ้าสำเร็จ ส่งกลับ 201 พร้อม payment_id
• ถ้า currency ไม่ถูกต้อง ส่งกลับ 400

ตัวอย่าง request:

POST /payments
Content-Type: application/json

{
  "amount": 19.99,
  "currency": "USD"
}

Verification อาจผ่านครบทุกข้อ:

• Handler ตรงกับ design
• Response มี field ตาม schema
• 201 และ 400 ถูกส่งกลับถูกต้อง
• Error format ตรงตามเอกสาร
• Contract test ผ่านทุก endpoint

แต่เมื่อลูกค้าจริงเริ่มใช้งาน กลับพบปัญหา: API รับ amount เป็น floating-point number ทำให้เกิด rounding error เช่น:

0.1 + 0.2
// 0.30000000000000004

สำหรับระบบการเงิน นี่เป็นปัญหาร้ายแรง แม้ implementation จะตรงกับ spec ที่เขียนว่า amount: number ทุกประการ

นี่คือ failure ของ Validation ไม่ใช่ Verification

การแก้ไม่ใช่ “แก้โค้ดให้ตรง spec” เพราะโค้ดตรง spec แล้ว แต่ต้องแก้ spec เอง เช่น เปลี่ยนจาก decimal number เป็น integer minor unit:

{
  "amount_minor": 1999,
  "currency": "USD"
}

ความหมายคือ 19.99 USD ถูกส่งเป็น 1999 cents แทน

บทเรียนคือ Verification จะยืนยันว่าเราสร้างตาม contract ได้ถูกต้อง แต่ Validation จะบอกว่า contract นั้นเหมาะกับโลกจริงหรือไม่

รายการตรวจสอบเชิงปฏิบัติสำหรับ API Release

ก่อนปล่อย API ให้เช็กทั้งสองฝั่ง

Verification: ตรวจเทียบกับข้อกำหนด

• [ ] ทุก endpoint ส่ง status code ตามเอกสาร
• [ ] ทุก response ตรงกับ schema
• [ ] Required parameter ถูก validate
• [ ] Error response ตรงตามรูปแบบที่กำหนด
• [ ] Header ที่จำเป็นถูกส่งกลับครบ
• [ ] Contract test ผ่านสำหรับ endpoint ที่ consumer ใช้งาน
• [ ] Test ถูกผูกกับ CI/CD และรันซ้ำได้

Validation: ตรวจเทียบกับวัตถุประสงค์

• [ ] ผู้ใช้ใหม่ทำ workflow หลักแบบ End-to-End ได้
• [ ] Response มีข้อมูลที่ client ต้องใช้จริง
• [ ] Auth flow เหมาะกับ integration จริง
• [ ] ตัวอย่างในเอกสารตรงกับ usage จริง
• [ ] Error message ช่วยให้ developer debug ได้
• [ ] Stakeholder ยืนยันว่า API แก้ปัญหาตามที่ตั้งใจ
• [ ] มี feedback จาก consumer หรือทีมที่ integrate จริง

ถ้าผ่านเฉพาะ Verification คุณอาจมี implementation ที่ถูกต้องของ requirement ที่ผิด

ถ้าผ่านเฉพาะ Validation คุณอาจมีแนวคิดที่ถูก แต่ระบบยังไม่เสถียรพอสำหรับ production

การ release ที่มั่นใจต้องผ่านทั้งสองฝั่ง

คำถามที่พบบ่อย

Verification หรือ Validation ควรทำก่อน?

Verification เริ่มก่อนได้และควรทำต่อเนื่อง เพราะทันทีที่มี code หรือ API contract ก็สามารถตรวจเทียบกับข้อกำหนดได้ ส่วน Validation ต้องมี workflow หรือ product ที่ใช้งานได้พอให้ทดสอบกับความต้องการจริง

Testing เหมือนกับ Validation หรือไม่?

ไม่เหมือนกัน Testing ครอบคลุมทั้ง Verification และ Validation เช่น unit test และ schema check เป็น Verification ส่วน UAT และ End-to-End workflow test เป็น Validation

ซอฟต์แวร์สามารถผ่าน Verification แต่ไม่ผ่าน Validation ได้หรือไม่?

ได้ และเกิดขึ้นบ่อย ระบบอาจตรงตาม specification ทุกข้อ แต่ specification นั้นแก้ปัญหาผิดจุด ผลลัพธ์คือ product ผ่าน Verification แต่ไม่ผ่าน Validation

API contract testing อยู่ฝั่งไหน?

API contract testing คือ Verification เพราะตรวจว่า API ยังรักษาข้อตกลงที่ระบุไว้กับ consumer หรือไม่ แต่มันไม่ได้ตอบว่าข้อตกลงนั้นเหมาะกับผู้ใช้จริงหรือเปล่า นั่นเป็นหน้าที่ของ Validation

อะไรพบ bug ได้มากกว่ากัน?

Verification มักพบ issue จำนวนมากกว่า เพราะรันได้บ่อยและตรวจจับความผิดเล็ก ๆ ได้เร็ว เช่น schema mismatch หรือ status code ผิด ส่วน Validation มักพบ issue น้อยกว่า แต่ impact สูงกว่า เพราะมักเกี่ยวกับ requirement หรือ design ที่ผิด

Automation ครอบคลุมทั้งสองอย่างได้ไหม?

Automation ครอบคลุม Verification ได้ดี เช่น schema validation, contract testing และ status assertion ส่วน Validation ทำ automation ได้บางส่วนผ่าน End-to-End workflow test แต่ยังต้องอาศัยการตัดสินใจจากมนุษย์เพื่อประเมินว่า API เหมาะกับบริบทจริงหรือไม่