Requirements Traceability Matrix (RTM) ในการทดสอบคืออะไร
โธมัส แฮมิลตัน
⚡ สรุปอย่างชาญฉลาด
เมทริกซ์การตรวจสอบย้อนกลับข้อกำหนด (RTM) คือเอกสารที่มีโครงสร้างซึ่งเชื่อมโยงข้อกำหนดของโครงการกับกรณีทดสอบที่เกี่ยวข้อง เพื่อให้มั่นใจว่าครอบคลุมและผ่านการตรวจสอบอย่างครบถ้วน เมทริกซ์นี้มีบทบาทสำคัญในการทดสอบซอฟต์แวร์ โดยป้องกันฟังก์ชันการทำงานที่ขาดหายไป สนับสนุนการปฏิบัติตามข้อกำหนด และให้การมองเห็นที่ชัดเจนแก่ผู้มีส่วนได้ส่วนเสีย
Traceability Matrix (TM) คืออะไร
เมทริกซ์การตรวจสอบย้อนกลับคือเอกสารที่เชื่อมโยงเอกสารพื้นฐานสองฉบับที่ต้องการความสัมพันธ์แบบหลายต่อหลายเพื่อตรวจสอบความสมบูรณ์ของความสัมพันธ์นั้น
ใช้เพื่อติดตามความต้องการและตรวจสอบว่าเป็นไปตามข้อกำหนดของโครงการปัจจุบันหรือไม่
เมทริกซ์การตรวจสอบความต้องการคืออะไร?
เมทริกซ์การติดตามความต้องการ (RTM) เป็นเอกสารที่จัดทำแผนที่และติดตามความต้องการของผู้ใช้ด้วยกรณีทดสอบ โดยรวบรวมข้อกำหนดทั้งหมดที่ลูกค้าเสนอและความสามารถในการติดตามข้อกำหนดไว้ในเอกสารฉบับเดียว ซึ่งส่งมอบเมื่อเสร็จสิ้นกระบวนการ วงจรชีวิตการพัฒนาซอฟต์แวร์วัตถุประสงค์หลักของเมทริกซ์การตรวจสอบความต้องการคือเพื่อตรวจสอบว่าความต้องการทั้งหมดได้รับการตรวจสอบผ่านกรณีทดสอบ เพื่อไม่ให้มีฟังก์ชันการทำงานใดที่ไม่ได้ถูกตรวจสอบระหว่างการทดสอบซอฟต์แวร์
เหตุใด RTM จึงมีความสำคัญ?
ภารกิจหลักของนักทดสอบทุกคนคือการทำความเข้าใจความต้องการของลูกค้า และตรวจสอบให้แน่ใจว่าผลิตภัณฑ์ที่ได้นั้นปราศจากข้อบกพร่อง เพื่อให้บรรลุเป้าหมายนี้ QA ทุกคนควรทำความเข้าใจข้อกำหนดอย่างถ่องแท้ และสร้างกรณีทดสอบทั้งเชิงบวกและเชิงลบ
ซึ่งหมายความว่าข้อกำหนดซอฟต์แวร์ที่ลูกค้ากำหนดไว้จะต้องถูกแยกย่อยออกเป็นสถานการณ์ต่างๆ และกรณีทดสอบ โดยแต่ละกรณีจะต้องดำเนินการแยกกัน
มีคำถามเกิดขึ้นว่าจะทำอย่างไรให้มั่นใจว่าข้อกำหนดนั้นได้รับการทดสอบ โดยพิจารณาจากสถานการณ์/กรณีที่เป็นไปได้ทั้งหมด? แล้วจะมั่นใจได้อย่างไรว่าข้อกำหนดใดๆ จะไม่ถูกละเลยจากวงจรการทดสอบ?
วิธีง่ายๆ คือการติดตามข้อกำหนดด้วยสถานการณ์การทดสอบที่เกี่ยวข้องและ กรณีทดสอบเรียกสิ่งนี้ว่า 'เมทริกซ์การติดตามความต้องการ'
โดยทั่วไปเมทริกซ์การตรวจสอบย้อนกลับจะเป็นแผ่นงานที่มีข้อกำหนดพร้อมความเป็นไปได้ทั้งหมด สถานการณ์ทดสอบ และกรณีต่างๆ และสถานะปัจจุบัน เช่น ผ่านหรือไม่ผ่าน ซึ่งจะช่วยให้ทีมทดสอบเข้าใจระดับกิจกรรมการทดสอบที่ดำเนินการสำหรับผลิตภัณฑ์นั้นๆ
ใครต้องการ RTM?
A ข้อกำหนดเมทริกซ์การตรวจสอบย้อนกลับ (RTM) ไม่ใช่แค่สำหรับผู้ทดสอบเท่านั้น แต่ยังมีคุณค่าสำหรับใครก็ตามที่เกี่ยวข้องกับการส่งมอบซอฟต์แวร์หรือโครงการคุณภาพสูง
- QA และผู้ทดสอบ → รับรองการครอบคลุมความต้องการ 100% ด้วยกรณีทดสอบที่แมปไว้อย่างดี
- นักวิเคราะห์ธุรกิจ → ติดตามข้อกำหนดจาก SRS/User Stories จนถึงการดำเนินการ
- ผู้จัดการโครงการ → รับการมองเห็นขอบเขต ความคืบหน้า และข้อกำหนดที่หายไป
- นักพัฒนา → ทำความเข้าใจว่าฟีเจอร์ต่างๆ เชื่อมโยงกับเป้าหมายทางธุรกิจอย่างไร
- อุตสาหกรรมที่มีการควบคุม (การดูแลสุขภาพ ยานยนต์ อวกาศ การเงิน) → พิสูจน์การปฏิบัติตามและผ่านการตรวจสอบด้วยการติดตามที่ชัดเจน
- ลูกค้าและผู้มีส่วนได้ส่วนเสีย → รับความมั่นใจได้ว่าข้อกำหนดของพวกเขาได้รับการดำเนินการและทดสอบแล้ว
👉 สรุปคือ ใครก็ตามที่รับผิดชอบ การสร้าง การตรวจสอบ หรือการอนุมัติข้อกำหนดของซอฟต์แวร์ ได้ประโยชน์จาก RTM
พารามิเตอร์ใดบ้างที่จะรวมอยู่ในเมทริกซ์การติดตามความต้องการ?
- รหัสความต้องการ
- ประเภทความต้องการและ Descriptไอออน
- กรณีทดสอบที่มีสถานะ
ด้านบนคือเมทริกซ์การตรวจสอบย้อนกลับความต้องการตัวอย่าง
แต่ในลักษณะทั่วไป การทดสอบซอฟต์แวร์ โครงการ เมทริกซ์การตรวจสอบย้อนกลับจะมีมากกว่าพารามิเตอร์เหล่านี้
ดังที่แสดงไว้ข้างต้น เมทริกซ์การตรวจสอบย้อนกลับตามข้อกำหนดสามารถ:
- แสดงความครอบคลุมข้อกำหนดในจำนวนกรณีทดสอบ
- สถานะการออกแบบและสถานะการดำเนินการสำหรับกรณีทดสอบเฉพาะ
- หากมีการทดสอบการยอมรับของผู้ใช้ที่ต้องดำเนินการโดยผู้ใช้ สถานะ UAT ก็จะถูกบันทึกไว้ในเมทริกซ์เดียวกันได้เช่นกัน
- ข้อบกพร่องที่เกี่ยวข้องและสถานะปัจจุบันสามารถกล่าวถึงในเมทริกซ์เดียวกันได้
เมทริกซ์ประเภทนี้จะให้ ร้านค้าครบวงจร สำหรับกิจกรรมการทดสอบทั้งหมด
นอกจากการดูแลรักษา Excel แยกต่างหากแล้ว ทีมทดสอบยังสามารถเลือกใช้การติดตามความต้องการที่มีอยู่ในเครื่องมือการจัดการการทดสอบได้อีกด้วย
ประเภทของเมทริกซ์การทดสอบการตรวจสอบย้อนกลับ
ในวิศวกรรมซอฟต์แวร์ เมทริกซ์การตรวจสอบย้อนกลับสามารถแบ่งออกได้เป็นสามส่วนประกอบหลัก ดังต่อไปนี้:
- ส่งต่อการตรวจสอบย้อนกลับ: เมทริกซ์นี้ใช้เพื่อตรวจสอบว่าโครงการดำเนินไปในทิศทางที่ต้องการและสำหรับผลิตภัณฑ์ที่เหมาะสมหรือไม่ ทำให้แน่ใจว่าข้อกำหนดแต่ละข้อถูกนำไปใช้กับผลิตภัณฑ์และมีการทดสอบข้อกำหนดแต่ละข้ออย่างละเอียด โดยจะแมปข้อกำหนดเพื่อทดสอบกรณีต่างๆ
- การตรวจสอบย้อนกลับหรือย้อนกลับ: ใช้เพื่อรับรองว่าผลิตภัณฑ์ปัจจุบันยังคงดำเนินไปอย่างถูกต้อง วัตถุประสงค์ของการตรวจสอบย้อนกลับประเภทนี้คือเพื่อตรวจสอบว่าเราไม่ได้ขยายขอบเขตของโครงการด้วยการเพิ่มโค้ด องค์ประกอบการออกแบบ การทดสอบ หรืองานอื่นๆ ที่ไม่ได้ระบุไว้ในข้อกำหนด โดยจะจับคู่กรณีทดสอบกับข้อกำหนด
- การตรวจสอบย้อนกลับแบบสองทิศทาง (เดินหน้า+ถอยหลัง): เมทริกซ์การตรวจสอบย้อนกลับนี้ช่วยให้มั่นใจว่ากรณีทดสอบครอบคลุมข้อกำหนดทั้งหมด เมทริกซ์นี้จะวิเคราะห์ผลกระทบของการเปลี่ยนแปลงข้อกำหนดที่ได้รับผลกระทบจาก ข้อบกพร่อง ในผลิตภัณฑ์งานและในทางกลับกัน
วิธีการสร้างเมทริกซ์การติดตามความต้องการ
มาทำความเข้าใจแนวคิดของ Requirement Traceability Matrix ผ่านโครงการธนาคาร Guru99 กันดีกว่า
บนพื้นฐานของ เอกสารข้อกำหนดทางธุรกิจ (BRD) และ เอกสารข้อกำหนดทางเทคนิค (TRD)ผู้ทดสอบเริ่มเขียนกรณีทดสอบ
สมมติว่าตารางต่อไปนี้เป็นเอกสารความต้องการทางธุรกิจของเราหรือ BRD สำหรับ โครงการธนาคาร Guru99.
สถานการณ์ในกรณีนี้คือลูกค้าควรสามารถเข้าสู่ระบบเว็บไซต์ธนาคาร Guru99 ได้ด้วยรหัสผ่านและรหัสผู้ใช้ที่ถูกต้อง ในขณะที่ผู้จัดการควรสามารถเข้าสู่ระบบเว็บไซต์ผ่านทางหน้าเข้าสู่ระบบของลูกค้าได้
ตารางด้านล่างนี้เป็นของเรา เอกสารข้อกำหนดทางเทคนิค (TRD).
หมายเหตุ ทีม QA ไม่ได้จัดทำเอกสาร BRD และ TRD นอกจากนี้บางบริษัทก็ใช้ เอกสารข้อกำหนดฟังก์ชัน (FRD)ซึ่งคล้ายกับเอกสารข้อกำหนดทางเทคนิค แต่กระบวนการสร้างเมทริกซ์การตรวจสอบย้อนกลับยังคงเหมือนเดิม
ก้าวต่อไปและสร้าง RTM ในการทดสอบ
ขั้นตอน 1) Our กรณีทดสอบตัวอย่าง is
“ยืนยันการเข้าสู่ระบบ: เมื่อป้อน ID และรหัสผ่านที่ถูกต้องแล้ว จะสามารถเข้าสู่ระบบได้สำเร็จ”
ขั้นตอน 2) ระบุข้อกำหนดทางเทคนิคที่กรณีทดสอบนี้กำลังตรวจสอบ สำหรับกรณีทดสอบของเรา ข้อกำหนดทางเทคนิค T94 กำลังได้รับการตรวจสอบ
ขั้นตอน 3) โปรดสังเกตข้อกำหนดทางเทคนิค (T94) นี้ในกรณีทดสอบ
ขั้นตอน 4) ระบุข้อกำหนดทางธุรกิจที่กำหนด TR (ข้อกำหนดทางเทคนิค-T94) นี้
ขั้นตอน 5) จดบันทึก BR (ข้อกำหนดทางธุรกิจ) ในกรณีทดสอบ
ขั้นตอน 6) ดำเนินการข้างต้นสำหรับกรณีทดสอบทั้งหมด Laterแยก 3 คอลัมน์แรกจากชุดทดสอบของคุณ RTM ในการทดสอบพร้อมแล้ว!
ข้อดีของเมทริกซ์การตรวจสอบความต้องการ
- ยืนยันความครอบคลุมการทดสอบ 100%
- โดยเน้นย้ำถึงข้อกำหนดใดๆ ที่ขาดหายไปหรือความไม่สอดคล้องกันของเอกสาร
- โดยจะแสดงข้อบกพร่องโดยรวมหรือสถานะการดำเนินการโดยเน้นที่ข้อกำหนดทางธุรกิจ
- ช่วยในการวิเคราะห์หรือประเมินผลกระทบต่อการทำงานของทีม QA ที่เกี่ยวข้องกับการตรวจสอบหรือแก้ไขกรณีทดสอบอีกครั้ง
แนวทางปฏิบัติที่ดีที่สุดและเคล็ดลับสำหรับการใช้ RTM
เมทริกซ์การตรวจสอบข้อกำหนด (RTM) มีประสิทธิภาพสูงสุดเมื่อ ให้เรียบง่าย สม่ำเสมอ และอัปเดตเป็นประจำนี่คือแนวทางปฏิบัติที่ดีที่สุดที่จะช่วยให้ทีมสามารถมั่นใจได้ ครอบคลุมเต็มรูปแบบ การแก้ไขงานน้อยที่สุด และความมั่นใจที่เพิ่มขึ้นในการส่งมอบโครงการ:
- เริ่มก่อน → สร้าง RTM ของคุณในช่วงเริ่มต้นของโครงการ
- ให้มันอัปเดต → อัปเดตเมทริกซ์ทุกครั้งที่มีการเปลี่ยนแปลงข้อกำหนดหรือกรณีทดสอบ
- ใช้รหัส Clear ID → กำหนดรหัสเฉพาะให้กับข้อกำหนดและกรณีทดสอบเพื่อให้ติดตามได้ง่าย
- ครอบคลุมทั้งกรณีบวกและลบ → รับรองว่าข้อกำหนดทั้งหมดได้รับการตรวจสอบจากมุมการทดสอบหลายมุม
- ทำงานร่วมกันข้ามทีม → ให้ผู้ทดสอบ นักพัฒนา BA และผู้จัดการโครงการมีส่วนร่วมในการบำรุงรักษา RTM
- เครื่องมืองัด → แทนที่จะใช้สเปรดชีต ควรพิจารณาใช้เครื่องมือการจัดการการทดสอบ (เช่น Jira, HP ALM หรือ Zephyr) เพื่อความสามารถในการปรับขนาด
- การควบคุมเวอร์ชัน → เก็บเวอร์ชันประวัติศาสตร์เพื่อติดตามการเปลี่ยนแปลงและรักษาความสอดคล้อง
- เน้นความเรียบง่าย → หลีกเลี่ยงการโอเวอร์โหลดเมทริกซ์ เน้นเฉพาะพารามิเตอร์ที่จำเป็นเท่านั้น
- ตรวจสอบเป็นประจำ → ตรวจสอบ RTM เป็นระยะๆ เพื่อจับช่องว่างก่อนถึงกำหนดเส้นตายการทดสอบ
- ลิงค์สู่มูลค่าทางธุรกิจ → ระบุข้อกำหนดกลับไปยังเป้าหมายทางธุรกิจเพื่อแสดง ROI
ความท้าทายและแนวทางแก้ไข RTM ทั่วไป
- ความท้าทาย: การอัปเดต RTM
ข้อกำหนดและกรณีทดสอบมักเปลี่ยนแปลงบ่อยครั้ง ทำให้ RTM ล้าสมัยอย่างรวดเร็ว
วิธีการแก้: ใช้เครื่องมือการจัดการการทดสอบอัตโนมัติที่ซิงค์ข้อกำหนด กรณีทดสอบ และข้อบกพร่องแบบเรียลไทม์ - ความท้าทาย: ความซับซ้อนมากเกินไป
การเพิ่มพารามิเตอร์มากเกินไปทำให้ RTM ยากต่อการบำรุงรักษาและตีความ
วิธีการแก้: รักษา RTM ให้กระชับโดยมุ่งเน้นเฉพาะข้อมูลที่จำเป็น เช่น ID คำอธิบาย และสถานะ - ความท้าทาย: การทำงานร่วมกันเป็นทีมไม่ดี
ทีมงานที่แตกต่างกันอาจไม่ตรงกันในเรื่องความเป็นเจ้าของหรือการอัปเดต
วิธีการแก้: กำหนดบทบาทที่ชัดเจน เกี่ยวข้องกับผู้ทดสอบ นักพัฒนา และนักวิเคราะห์ และกำหนดตารางการตรวจสอบ RTM เป็นประจำ - ความท้าทาย: ความต้องการครอบคลุมไม่ครบถ้วน
ข้อกำหนดบางประการอาจขาดกรณีทดสอบ ส่งผลให้สูญเสียฟังก์ชันการทำงาน
วิธีการแก้: ตรวจสอบความครอบคลุมเป็นประจำ ใช้การตรวจสอบย้อนกลับแบบสองทิศทาง และดำเนินการตรวจสอบก่อนการเผยแพร่ครั้งใหญ่ - ความท้าทาย: ความพยายามด้วยมือในโครงการขนาดใหญ่
การจัดการ RTM ในสเปรดชีตกลายเป็นเรื่องใช้เวลานานสำหรับระบบที่ซับซ้อน
วิธีการแก้: นำเครื่องมือ RTM เช่น Jira, HP ALM หรือ Zephyr มาใช้ในการทำแผนที่และรายงานโดยอัตโนมัติ
มาเรียนรู้ RTM ด้วยตัวอย่างในวิดีโอ
คลิก Good Farm Animal Welfare Awards หากไม่สามารถเข้าถึงวิดีโอได้
เทมเพลต Requirements Traceability Matrix (RTM)
คลิกด้านล่างเพื่อดาวน์โหลดไฟล์ Excel เทมเพลต RTM
ดาวน์โหลดเทมเพลต RTM Excel(.xlsx)
