Test Levels: ทดสอบ "ระดับไหน" ตอบคำถามคนละแบบ

มันคือขอบเขตของสิ่งที่เรากำลังพิสูจน์

เวลาพูดถึง test level ให้คิดถึงคำถามนี้:

ไม่ใช่ทุกการทดสอบจะมองระบบด้วยระยะเท่ากัน

• บางครั้งเราดูแค่ function เดียว
• บางครั้งเราดูการคุยกันของหลาย service
• บางครั้งเราดูทั้งระบบจากมุมผู้ใช้
• บางครั้งเราถามผู้ใช้จริงเลยว่ายอมรับระบบไหม

นั่นคือเหตุผลที่เราต้องมีหลาย level

อย่าสับสนกับ Test Type

Level และ Type มักทำให้คนใหม่สับสน

ตัวอย่าง:

• regression test เป็น type
• system test เป็น level

ดังนั้นคุณอาจมี regression at system level ได้ และคุณอาจมี functional test at integration level ได้เช่นกัน

ถ้าจะจำแบบสั้น

• Unit = ชิ้นเล็ก
• Integration = จุดเชื่อม
• System = ทั้งระบบ
• Acceptance = มุมของผู้ใช้/ธุรกิจ

ใช้ตอบว่าโค้ดชิ้นเล็กที่สุดถูกไหม

unit test เหมาะกับการตรวจ logic ย่อย เช่น:

• คำนวณส่วนลด
• validate input
• แปลง data format
• เช็ก business rule ที่แยกทดสอบได้

ตัวอย่าง

สมมติมี function calculateDiscount(price, coupon)

สิ่งที่ unit test อาจเช็ก:

• คูปองถูก → ลดถูกต้อง
• คูปองหมดอายุ → ไม่ลด
• ราคาเป็น 0 → ไม่ error
• coupon ว่าง → ได้ราคาเดิม

จุดเด่น

• เร็วมาก
• รันบ่อยได้
• ช่วยให้ dev ได้ feedback ตั้งแต่ยังไม่ต้องเปิดระบบ

สิ่งที่ unit test ไม่ตอบ

มันไม่ได้บอกว่า:

• หน้า UI แสดงผลถูกไหม
• API ต่อกันถูกไหม
• database เขียนข้อมูลจริงไหม
• ผู้ใช้เข้าใจ flow ไหม

นั่นคือเหตุผลที่ unit test ผ่านทั้งหมด ไม่ได้แปลว่าระบบพร้อมเสมอไป

ใช้ตอบว่าจุดเชื่อมระหว่างส่วนต่าง ๆ ยังทำงานกันได้จริงไหม

integration test สำคัญมากเพราะ defect จำนวนมากไม่ได้อยู่ที่ logic ของแต่ละชิ้น แต่เกิดตอนเอาหลายชิ้นมาคุยกัน

ตัวอย่างจุดเชื่อมที่มักพัง:

• frontend ส่ง payload ไม่ตรงกับ backend
• backend map field ลง database ผิด
• service หนึ่งตีความ status code ต่างจากอีก service
• payment callback กลับมารูปแบบไม่ตรงที่ระบบคาด

ตัวอย่าง

ฟีเจอร์ checkout อาจมี integration points เช่น:

• cart service → pricing service
• checkout service → payment gateway
• order service → notification service

ถึงแต่ละส่วนจะ unit test ผ่านหมด แต่ integration อาจพังเพราะ contract ไม่ตรงกัน

defect แบบไหนที่ชอบอยู่ตรงนี้

• field name mismatch
• timezone mismatch
• data type mismatch
• sequence ของ state change ไม่ถูก

ใช้ตอบว่าระบบทั้งก้อนทำงานได้จากมุมผู้ใช้หรือไม่

system test คือการมองจาก flow จริงของระบบมากขึ้น เช่น:

• สมัครสมาชิก
• login
• ค้นหา
• checkout
• ขอ refund

ระดับนี้มักรันบน staging หรือ test environment ที่ใกล้ของจริง

ตัวอย่าง

ผู้ใช้:

1. login
2. search สินค้า
3. เพิ่มลง cart
4. ใช้คูปอง
5. จ่ายเงิน
6. ได้ order confirmation

ถ้า flow นี้ผ่าน แปลว่าองค์ประกอบหลักหลายชิ้นทำงานร่วมกันได้จากมุมผู้ใช้

สิ่งที่ system test ดีมาก

• จับ defect ที่กระทบ flow หลัก
• ช่วยให้เห็นว่าผู้ใช้จะเจออะไรจริง
• เหมาะกับ regression ชุดสำคัญ

แต่ก็มีข้อจำกัด

• ช้ากว่า unit/integration
• เปราะกว่า
• maintain ยากกว่า

ดังนั้นไม่ควรหวังให้ system test รับภาระทุกอย่างแทนระดับอื่น

ใช้ตอบว่าสิ่งที่สร้างมาตอบโจทย์ของผู้ใช้หรือธุรกิจจริงไหม

นี่คือระดับที่เชื่อมกับคำว่า validation มากที่สุด

system test อาจผ่านได้ทั้งหมด แต่ UAT ยัง fail ได้ ถ้าของที่ทำมาตรงสเปกแต่ไม่ตรงการใช้งานจริง

ตัวอย่าง

ทีมทำ report export CSV ตาม requirement ทุกข้อ

• format ถูกตามเอกสาร
• field ครบ
• download ได้

แต่ finance ใช้จริงแล้วบอกว่า import เข้าโปรแกรมบัญชีไม่ได้

ในมุม system test อาจผ่าน แต่ในมุม acceptance มันยังไม่ผ่าน

ใครทำ

ไม่จำเป็นต้องเป็น user ปลายทางเสมอไป แต่อาจเป็น:

• product owner
• BA
• stakeholder ฝั่ง business
• ตัวแทนลูกค้า

สิ่งสำคัญคือคนที่เข้าใจบริบทการใช้งานจริง

สิ่งที่ต้องจำ

ถ้า defect อยู่คนละประเภท คุณใช้ระดับเดียวจับไม่หมด

เช่น:

• ใช้ unit test อย่างเดียว จับ UX issue ไม่ได้
• ใช้ system test อย่างเดียว อาจช้าเกินกว่าจะเจอ logic defect จำนวนมาก
• ใช้ acceptance อย่างเดียว ต้นทุนการเจอ defect จะแพงเกินไป

นั่นคือเหตุผลที่ทีมคุณภาพดีจะกระจายการทดสอบหลายระดับ

• unit test ผ่านหมด = ระบบพร้อมแล้ว
• UAT ทำแล้ว งั้น system test ไม่ต้องทำ
• integration test คือ system test แบบย่อ
• test level เยอะไปเสียเวลา

ความจริงคือแต่ละระดับป้องกัน defect คนละชนิด และช่วยให้ feedback มาในเวลาที่ต่างกัน