การวัด Test Coverage
คำว่า coverage มักถูกเข้าใจผิดว่าแปลว่า 'ยิ่งเยอะยิ่งดี' แต่ในงานทดสอบจริง coverage ที่มีค่าไม่ใช่แค่ตัวเลขสูง มันต้องช่วยให้เรารู้ว่ามีจุดไหนยังเสี่ยง จุดไหนทดสอบซ้ำเกิน และจุดไหนควรเติมต่อ บทนี้จะพาคุณมอง coverage ให้ลึกกว่าคำว่าเปอร์เซ็นต์
จบบทนี้แล้วคุณจะ...
- อธิบายได้ว่า test coverage คืออะไรและไม่ใช่อะไร
- แยก coverage หลายมุม เช่น requirement coverage, risk coverage และ code coverage ได้
- อ่านตัวเลข coverage อย่างไม่หลงกับเปอร์เซ็นต์เพียงอย่างเดียว
- หา coverage gap จาก requirement, scenarios และ risks ได้ดีขึ้น
- ใช้ coverage เป็นเครื่องมือช่วยตัดสินใจ ไม่ใช่ตัวเลขเพื่อความสบายใจ
มันคือภาพว่าของที่ควรคุ้มครอง ถูกคุ้มครองไปแค่ไหน
เมื่อพูดว่า “coverage” คุณควรถามกลับทันทีว่า:
coverage ของอะไร?
เพราะ coverage ไม่ได้มีแบบเดียว
ตัวอย่าง:
- coverage ของ requirement
- coverage ของ user flow
- coverage ของ business rule
- coverage ของ risk
- coverage ของ code
ถ้าเราไม่ระบุให้ชัด คำว่า coverage จะกลายเป็นคำกว้าง ๆ ที่ฟังดีแต่ช่วยตัดสินใจอะไรไม่ได้มาก
แต่ละแบบตอบคนละคำถาม
| ประเภท coverage | ใช้ตอบคำถามอะไร |
|---|---|
| Requirement Coverage | requirement หรือ acceptance criteria ถูกทดสอบหรือยัง |
| Scenario / Flow Coverage | flow หลักและทางเลือกถูกครอบคลุมหรือยัง |
| Risk Coverage | จุดที่เสี่ยงสูงได้รับการทดสอบมากพอหรือยัง |
| Data Coverage | มีการใช้ข้อมูลหลายแบบพอหรือยัง เช่น valid, invalid, boundary |
| Platform Coverage | browser, device, OS ที่สำคัญถูกครอบคลุมหรือยัง |
| Code Coverage | code ถูก execute โดย automated tests มากแค่ไหน |
จุดสำคัญคือ coverage แต่ละแบบมีประโยชน์ต่างกัน และไม่มีแบบไหนแทนกันได้ทั้งหมด
โดยเฉพาะเมื่อตัวเลขนั้นวัดคนละสิ่งกับความเสี่ยงจริง
ตัวอย่างที่พบบ่อย:
- code coverage 95% แต่ยังไม่เคยทดสอบ permission bug ที่สำคัญ
- requirement coverage 100% แต่ทุก requirement มีแค่ happy path ไม่มี negative case
- regression suite ใหญ่มาก แต่ไม่ครอบคลุม flow ที่เพิ่งเปลี่ยนในรอบนี้
ดังนั้น coverage สูงอาจยังมีช่องโหว่ ถ้าสิ่งที่วัดไม่ตรงกับสิ่งที่เสี่ยง
Coverage ที่ดีต้องช่วยให้ทีมเห็น “อะไรยังไม่ถูกคุ้มครอง” ไม่ใช่แค่ทำให้ dashboard ดูสวย
เริ่มจากคำถามง่ายที่สุดก่อน: สิ่งที่ตกลงกันไว้ ถูกเชื่อมกับ test แล้วหรือยัง
นี่คือ coverage แบบที่ตรงกับงาน QA มากที่สุดในหลายทีม
ตัวอย่าง:
| Requirement | Coverage |
|---|---|
| สมัครสมาชิกด้วย email ได้ | Covered |
| email ซ้ำต้องถูกปฏิเสธ | Covered |
| ลิงก์ยืนยันหมดอายุใน 1 ชั่วโมง | Partial |
| คลิกยืนยันซ้ำสองครั้ง | Not Covered |
ตารางแบบนี้ทำให้เห็นทันทีว่า:
- requirement ไหนยังขาด
- requirement ไหนมี test แค่บางส่วน
- requirement ไหนยังไม่มี owner ชัด
บาง requirement ถูก cover แล้ว แต่ risk สำคัญยังไม่ถูกแตะ
สมมติ checkout ถูกทดสอบแล้วในเชิง requirement แต่ risk สำคัญยังอาจตกหล่น:
- duplicate payment
- timeout ระหว่าง callback
- inventory mismatch
- coupon race condition
นี่ทำให้เราเห็นว่า requirement coverage อย่างเดียวไม่พอ ต้องถามด้วยว่า:
- จุดเสี่ยงสูงสุดถูกทดสอบแล้วหรือยัง
- failure modes สำคัญถูกคุ้มครองแล้วหรือยัง
ตัวอย่าง risk coverage:
| Risk | Coverage Status |
|---|---|
| หักเงินซ้ำ | Covered |
| ชำระสำเร็จแต่ order ไม่ถูกสร้าง | Covered |
| callback ช้าแล้วสถานะค้าง | Partial |
| กด submit ซ้ำรัว ๆ | Not Covered |
ถ้าใช้ข้อมูลแบบเดียว ผลลัพธ์ coverage จะหลอกเราได้ง่าย
สมมติ requirement บอกว่า:
“อัปโหลดไฟล์ JPG/PNG ขนาดไม่เกิน 5 MB ได้”
ถ้าคุณทดสอบแค่:
- JPG 1 MB
คุณอาจบอกได้ว่า requirement ถูก test แล้ว
แต่ data coverage ยังต่ำมาก เพราะยังไม่แตะ:
- PNG
- ไฟล์ 4.99 MB
- ไฟล์ 5.00 MB
- ไฟล์ 5.01 MB
- file corrupt
- file ชื่อแปลก
นี่คือเหตุผลที่ coverage ต้องมองหลายชั้น ไม่ใช่ดูแค่ว่ามี test หรือไม่มี test
เป็นข้อมูลที่มีประโยชน์ แต่ไม่ควรถูกตีความเกินจริง
Code coverage มักมาจาก automation และบอกว่า code ถูก execute มากแค่ไหน เช่น:
- line coverage
- branch coverage
- function coverage
ประโยชน์:
- ช่วยเห็นว่ามีส่วนของ code ไหนยังไม่ถูกแตะ
- ช่วยหาบริเวณที่ unit tests ยังบาง
ข้อจำกัด:
- execute แล้ว ไม่ได้แปลว่า assert ถูกเรื่อง
- coverage สูง ไม่ได้แปลว่าทดสอบ business behavior ครบ
- ไม่ได้บอกเรื่อง usability, data correctness, integration risk โดยตรง
ดังนั้น code coverage เป็น “หนึ่งสัญญาณ” ไม่ใช่คำตอบสุดท้าย
Coverage ที่ดีควรพาไปสู่ action ต่อได้
เวลาคุณดู coverage report ให้ถามต่อว่า:
- requirement ไหนยังไม่มี test รองรับ
- risk สูงข้อไหนยัง partial หรือ not covered
- test ที่มีอยู่ซ้ำกันเกินไปไหม
- release นี้แตะส่วนไหนที่ coverage ยังบาง
ถ้าตอบได้ คุณจะใช้ coverage เพื่อ:
- เติม test cases ในจุดที่ขาด
- ตัด test ที่ซ้ำซ้อน
- ปรับ priority ก่อน release
- อธิบาย risk ที่ยังเหลือให้ทีมเข้าใจ
ตัวเลข coverage ที่ดูดี อาจทำให้ทีมสบายใจเกินจริง
1. ไล่ 100% โดยไม่ถามว่าคุ้มไหม
บางส่วนของระบบไม่ต้องใช้ effort เท่ากัน
2. มีแต่ happy path
coverage ดูเหมือนครบ แต่ยังบางมากใน negative และ edge cases
3. วัด coverage เฉพาะ requirement
จนลืมมอง risk, data variation และ platforms
4. ไม่อัปเดต coverage หลัง requirement เปลี่ยน
ทำให้ตัวเลขดูเต็ม ทั้งที่ของจริงเปลี่ยนไปแล้ว
แบบฝึก: อ่าน coverage แบบไม่หลงตัวเลข
ทีมบอกว่า requirement coverage 100% แต่ยังไม่มี test เรื่อง invalid input เลย คุณจะอธิบายปัญหานี้อย่างไร
ดูคำตอบแนะนำ
requirement coverage อาจเต็มในเชิง mapping แต่ quality ของ coverage ยังไม่พอ เพราะมีแต่ happy path ไม่มี negative และ boundary ดังนั้น coverage เชิงเอกสารครบ แต่ coverage เชิงพฤติกรรมยังบาง
code coverage ของโมดูล payment อยู่ที่ 92% แต่ยังไม่เคยทดสอบ timeout จาก gateway เลย คุณควรสรุปอย่างไร
ดูคำตอบแนะนำ
ตัวเลข code coverage สูงบอกว่ามี automation แตะ code จำนวนมาก แต่ยังไม่ได้แปลว่า risk สำคัญถูกคุ้มครองครบ โดยเฉพาะ integration failure อย่าง timeout ที่อาจเป็น business-critical behavior
ถ้า RTM บอกว่า requirement ทุกข้อ covered แล้ว คุณควรถามอะไรต่อ
ดูคำตอบแนะนำ
ควรถามต่อว่าครอบคลุมระดับไหน มีทั้ง positive, negative, alternate, boundary หรือยัง และ risk สูงแต่ละข้อได้รับ attention เพียงพอหรือไม่
coverage report แบบไหนมีประโยชน์กว่ากัน ระหว่าง “80%” กับ “ยังขาด test สำหรับ duplicate submit และ callback delay”
ดูคำตอบแนะนำ
แบบหลังมีประโยชน์ต่อการตัดสินใจมากกว่า เพราะบอก action และบอก risk ที่ยังเหลือจริง ในขณะที่ “80%” เป็นเพียงภาพรวมที่ยังไม่รู้ว่าขาดตรงไหน
สิ่งที่ต้องเอาติดตัวไปจากบทนี้
- coverage ต้องถามเสมอว่า “coverage ของอะไร”
- Requirement, risk, data, platform และ code coverage เป็นคนละมุมและช่วยกันคนละแบบ
- ตัวเลข coverage สูงไม่ได้การันตีว่าความเสี่ยงสำคัญถูกคุ้มครองครบ
- coverage ที่มีค่าคือ coverage ที่ช่วยให้ทีมเห็น gap และตัดสินใจต่อได้
- ถ้าคุณใช้ coverage เพื่อหา “จุดที่ยังเสี่ยง” มากกว่าหา “ตัวเลขที่ดูดี” คุณกำลังใช้มันถูกทาง