Section 02 · Module 07 · Lesson 01 · ~22–26 นาที

Requirement Traceability Matrix (RTM)

พอ test cases เริ่มเยอะขึ้น คำถามจะเปลี่ยนจาก 'เราเขียนอะไรไปบ้าง' เป็น 'ของที่เขียนไปครอบคลุม requirement จริงไหม' RTM คือเครื่องมือที่ช่วยเชื่อม requirement, test และ defect เข้าหากัน เพื่อให้ทีมมอง coverage ได้เป็นระบบ

เวลาเรียน: 22–26 นาที ต้องรู้มาก่อน: Module 06 ทั้งหมด รูปแบบ: อ่าน + ตัวอย่าง matrix + แบบฝึกสั้น

จบบทนี้แล้วคุณจะ...

อธิบายได้ว่า RTM คืออะไรและช่วยทีมเรื่องอะไร
สร้าง matrix แบบง่ายที่เชื่อม requirement กับ test cases ได้
มองเห็น coverage gap และ duplicate coverage ได้ชัดขึ้น
ใช้ RTM ช่วยคุยเรื่อง impact เมื่อ requirement เปลี่ยนได้
แยกให้ออกว่าเมื่อไรควรทำ RTM แบบเบา และเมื่อไรควรละเอียดขึ้น

1 · ทำไมต้องมี traceability

เพราะพอเอกสารหลายชิ้นเริ่มโต เราจะหลงง่ายมาก

ช่วงแรกของโปรเจกต์ คุณอาจยังจำได้ว่า:

requirement ข้อไหนมี test case อะไรบ้าง
defect นี้กระทบ requirement ไหน
ฟีเจอร์ไหนยังไม่ได้ออกแบบ test

แต่พอระบบโตขึ้น สิ่งเหล่านี้จะเริ่มตอบจากความจำไม่ได้แล้ว

ปัญหาที่มักเกิดคือ:

มี requirement แต่ไม่มี test case รองรับ
มี test cases จำนวนมาก แต่ไม่รู้ว่าปกป้อง requirement ไหน
requirement เปลี่ยนแล้วไม่รู้ว่าต้องแก้ test cases ตัวไหนตาม
defect เกิดขึ้น แต่ทีมตอบไม่ได้ว่ามี coverage gap ตรงไหน

RTM ถูกสร้างมาเพื่อแก้ปัญหาเหล่านี้

2 · RTM คืออะไร

มันคือแผนที่เชื่อม “สิ่งที่ต้องสร้าง” กับ “สิ่งที่เราตรวจ”

RTM ย่อมาจาก Requirement Traceability Matrix

พูดง่าย ๆ คือ ตารางที่เอา requirement มาเชื่อมกับ:

test scenarios
test cases
defects
สถานะ coverage

โครงสร้างที่พบบ่อย:

Requirement ID	Requirement	Test Scenario / Case	Status	Notes
AC-01	ผู้ใช้ login ได้ด้วย email/password	TC-01, TC-02, TC-03	Covered	มีทั้ง valid/invalid
AC-02	lock บัญชีเมื่อ login ผิด 5 ครั้ง	TC-04, TC-05	Partially Covered	ยังไม่มี case เรื่อง reset counter

ตารางนี้ทำให้ทีมตอบได้เร็วขึ้นว่า “requirement นี้ถูกปกป้องแค่ไหน”

3 · RTM ไม่ได้มีไว้เพื่อความสวย

มันช่วยตอบคำถามที่เจอบ่อยมากในงานจริง

ตัวอย่างคำถามที่ RTM ช่วยได้:

requirement ข้อนี้มี test รองรับหรือยัง
test case นี้เขียนไว้เพราะ requirement อะไร
ถ้า acceptance criteria เปลี่ยน ต้องแก้ test cases ไหน
defect นี้เกิดในพื้นที่ที่เราไม่มี test หรือมีแต่ test ไม่พอ

นั่นทำให้ RTM เป็นเครื่องมือที่มีค่ามากในงานที่:

requirement เยอะ
คนในทีมหลายคน
มีการเปลี่ยนแปลงบ่อย
ต้องอธิบาย coverage ให้คนอื่นเข้าใจ

4 · รูปแบบ RTM แบบง่ายที่ใช้ได้จริง

ไม่ต้องเริ่มจาก matrix ใหญ่เสมอไป

สำหรับทีมเล็ก คุณอาจเริ่มจากแค่ 4 คอลัมน์:

Source	สิ่งที่ต้องพิสูจน์	Test Output	Coverage
AC-01	สมัครสมาชิกสำเร็จ	SCN-01, TC-01	Covered
AC-02	email ซ้ำต้องถูกปฏิเสธ	TC-02	Covered
AC-03	ส่ง email ยืนยัน	SCN-03, CHK-01	Partial

จุดสำคัญคือ “trace กลับได้” ไม่ใช่ “มีช่องครบทุกอย่าง”

5 · ตัวอย่าง: RTM สำหรับฟีเจอร์ Newsletter Signup

requirement เดียวอาจเชื่อมกับ output หลายแบบ

สมมติ requirement:

ผู้ใช้สมัคร newsletter ด้วย email ได้
email ต้องไม่ซ้ำ
ต้องยืนยันผ่านลิงก์ในอีเมลก่อน activate

ตัวอย่าง RTM:

Requirement ID	รายการ	Linked Tests	Coverage
AC-01	สมัครด้วย email valid	SCN-01, TC-01	Covered
AC-02	email ซ้ำถูกปฏิเสธ	TC-02	Covered
AC-03	ส่งอีเมลยืนยัน	SCN-03, CHK-01	Covered
AC-04	ลิงก์ยืนยันหมดอายุ	TC-05	Covered
AC-05	ยืนยันซ้ำสองครั้ง	-	Gap

แค่ตารางนี้ทีมก็เห็นแล้วว่ามี Gap อยู่ตรง AC-05

6 · RTM ช่วยตอน requirement เปลี่ยนได้อย่างไร

นี่คือหนึ่งในประโยชน์ที่ชัดที่สุด

สมมติ BA เปลี่ยน requirement จาก:

“ลิงก์ยืนยันมีอายุ 24 ชั่วโมง”

เป็น:

“ลิงก์ยืนยันมีอายุ 1 ชั่วโมง”

ถ้าคุณไม่มี traceability คุณอาจต้องไล่เดาว่าเอกสารไหนกระทบ

แต่ถ้ามี RTM คุณจะรู้ทันทีว่าต้องไปดู:

scenario ที่เกี่ยวกับ email confirmation
test case ของ expiry
checklist ที่ใช้ smoke flow
defect เก่าที่เกี่ยวกับ token expiry

RTM จึงช่วยลดการตกหล่นเมื่อ requirement เปลี่ยน

7 · Coverage Gap กับ Duplicate Coverage

RTM ไม่ได้ช่วยหาแค่ของที่ขาด แต่ช่วยหา “ของที่ซ้ำเกิน” ด้วย

ปัญหาสองแบบที่ RTM ช่วยให้เห็น:

Coverage Gap

requirement มี แต่ไม่มี test รองรับ
หรือมี test แค่ happy path แต่ไม่มี negative / alternate ที่สำคัญ

Duplicate Coverage

มีหลาย test cases ทดสอบเรื่องเดียวกันแทบทั้งหมด
ใช้ effort มาก แต่ไม่ได้เพิ่มความมั่นใจมากขึ้น

ทั้งสองอย่างทำให้ทีมใช้เวลาทดสอบไม่คุ้ม:

gap = เสี่ยงหลุด
duplicate = เสียแรงซ้ำ

8 · เมื่อไรควรทำ RTM ให้ละเอียดขึ้น

ไม่ใช่ทุกโปรเจกต์ต้องทำระดับเดียวกัน

RTM มักควรละเอียดขึ้นเมื่อ:

มี compliance หรือ audit requirement
มีหลายทีมหลายคนช่วยกันทดสอบ
requirement เปลี่ยนบ่อย
feature มี business rules เยอะ
release ต้องการอธิบาย coverage ต่อ stakeholder ชัดเจน

ส่วนงานเล็กหรือ prototype อาจใช้แค่ mapping เบา ๆ ก็พอ

เป้าหมายคือ “พอดีกับความเสี่ยงและขนาดของงาน” ไม่ใช่ทำเอกสารใหญ่ที่สุด

Practice

แบบฝึก: มองหา gap จาก matrix

ถ้า requirement มี 5 ข้อ แต่ใน RTM มี test case เชื่อมอยู่แค่ 3 ข้อ คุณควรสรุปอย่างไร

ดูคำตอบแนะนำ

สรุปได้ว่ายังมี coverage gap อย่างน้อย 2 requirement ที่ยังไม่มี test รองรับ หรือยังไม่ได้ใส่ mapping ชัด ต้องกลับไปตรวจว่าหลุดจริง หรือยังไม่อัปเดตเอกสาร
requirement เปลี่ยนเรื่อง expiry time ของ OTP คุณจะใช้ RTM ยังไง

ดูคำตอบแนะนำ

ใช้หา test scenarios, test cases, smoke checklist และ defect เก่าที่ trace กับ requirement ข้อนั้น เพื่ออัปเดตเฉพาะส่วนที่กระทบอย่างมีระบบ
ถ้าคุณเห็น test case 6 ตัวเชื่อมกับ requirement เดียวกันหมด คุณควรถามอะไรเพิ่ม

ดูคำตอบแนะนำ

ควรถามว่าทั้ง 6 ตัวครอบคลุมคนละมุมจริงไหม หรือแค่ซ้ำกัน เช่น ทุกตัวทดสอบ happy path เหมือนกันเกือบหมด ถ้าเป็นแบบหลังอาจมี duplicate coverage
ทีมเล็ก 3 คนจำเป็นต้องมี RTM ไหม

ดูคำตอบแนะนำ

ไม่จำเป็นต้องเป็น matrix ใหญ่เสมอไป แต่ควรมีอย่างน้อยการ trace แบบเบา ๆ ระหว่าง requirement กับ test outputs เพื่อให้รู้ว่าอะไรครอบคลุมแล้ว อะไรยังขาด โดยเฉพาะเมื่อ feature เริ่มซับซ้อนขึ้น

สิ่งที่ต้องเอาติดตัวไปจากบทนี้

RTM คือเครื่องมือเชื่อม requirement กับ test outputs เพื่อให้ทีมมอง coverage ได้ชัด
มันช่วยทั้งตอนหา coverage gap และตอนวิเคราะห์ impact จาก requirement change
RTM ที่ดีไม่จำเป็นต้องใหญ่ แต่ต้อง trace กลับได้จริง
งานที่ซับซ้อนขึ้น, เปลี่ยนบ่อยขึ้น, หรือมีคนเกี่ยวข้องมากขึ้น มักได้ประโยชน์จาก RTM มากขึ้น
ถ้าคุณตอบได้ว่า “requirement นี้มีอะไรคุ้มครองอยู่บ้าง” คุณกำลังใช้ traceability ได้ถูกทาง

← บทเรียนก่อนหน้า บทเรียนถัดไป →