Requirements Traceability Matrix (RTM) ในการทดสอบคืออะไร

Traceability Matrix (TM) คืออะไร

เมทริกซ์การตรวจสอบย้อนกลับเป็นเอกสารที่เชื่อมโยงเอกสารพื้นฐานสองรายการใดๆ ที่จำเป็นต้องมีความสัมพันธ์แบบกลุ่มต่อกลุ่มเพื่อตรวจสอบความสมบูรณ์ของความสัมพันธ์

ใช้เพื่อติดตามข้อกำหนดและเพื่อตรวจสอบข้อกำหนดของโครงการในปัจจุบัน

Requirement Traceability Matrix คืออะไร

เมทริกซ์การตรวจสอบย้อนกลับความต้องการ (RTM) เป็นเอกสารที่แมปและติดตามความต้องการของผู้ใช้ด้วยกรณีทดสอบ โดยรวบรวมข้อกำหนดทั้งหมดที่ลูกค้าเสนอและความสามารถในการตรวจสอบย้อนกลับความต้องการไว้ในเอกสารฉบับเดียว ซึ่งจัดส่งในตอนท้ายของรายงาน วงจรชีวิตการพัฒนาซอฟต์แวร์- วัตถุประสงค์หลักของ Requirement Traceability Matrix คือการตรวจสอบว่ามีการตรวจสอบข้อกำหนดทั้งหมดผ่านกรณีทดสอบ โดยจะไม่มีการตรวจสอบฟังก์ชันการทำงานใด ๆ ในระหว่างการทดสอบซอฟต์แวร์

ทำไม RTM จึงมีความสำคัญ?

วาระหลักของผู้ทดสอบทุกคนควรคือการทำความเข้าใจความต้องการของลูกค้า และตรวจสอบให้แน่ใจว่าผลิตภัณฑ์ที่ส่งออกควรปราศจากข้อบกพร่อง เพื่อให้บรรลุเป้าหมายนี้ QA ทุกคนควรเข้าใจข้อกำหนดอย่างละเอียด และสร้างกรณีทดสอบเชิงบวกและเชิงลบ

นี่หมายความว่าข้อกำหนดซอฟต์แวร์ที่ลูกค้ามอบให้จะต้องแยกออกเป็นสถานการณ์ที่แตกต่างกันและเพิ่มเติมไปยังกรณีทดสอบ แต่ละกรณีนี้จะต้องดำเนินการเป็นรายบุคคล

มีคำถามเกิดขึ้นที่นี่เกี่ยวกับวิธีการตรวจสอบให้แน่ใจว่าข้อกำหนดได้รับการทดสอบโดยพิจารณาสถานการณ์/กรณีที่เป็นไปได้ทั้งหมด จะแน่ใจได้อย่างไรว่าข้อกำหนดใดๆ จะไม่ถูกละเลยจากรอบการทดสอบ

วิธีง่ายๆ คือการติดตามข้อกำหนดด้วยสถานการณ์การทดสอบที่เกี่ยวข้องและ กรณีทดสอบ- สิ่งนี้เรียกเพียงว่า 'เมทริกซ์ความสามารถในการตรวจสอบย้อนกลับความต้องการ'

โดยทั่วไปเมทริกซ์การตรวจสอบย้อนกลับคือแผ่นงานที่มีข้อกำหนดที่เป็นไปได้ทั้งหมด สถานการณ์ทดสอบ และกรณีต่างๆ และสถานะปัจจุบัน เช่น ผ่านหรือไม่ผ่าน สิ่งนี้จะช่วยให้ทีมทดสอบเข้าใจระดับของกิจกรรมการทดสอบที่ทำสำหรับผลิตภัณฑ์เฉพาะ

พารามิเตอร์ใดที่จะรวมไว้ใน Requirement Traceability Matrix

• รหัสความต้องการ
• ประเภทความต้องการและ Descriptไอออน
• กรณีทดสอบที่มีสถานะ

ด้านบนคือเมทริกซ์การตรวจสอบย้อนกลับความต้องการตัวอย่าง

แต่ในลักษณะทั่วไป การทดสอบซอฟต์แวร์ โครงการ เมทริกซ์การตรวจสอบย้อนกลับจะมีมากกว่าพารามิเตอร์เหล่านี้

ดังที่แสดงไว้ข้างต้น เมทริกซ์การตรวจสอบย้อนกลับตามข้อกำหนดสามารถ:

• แสดงความครอบคลุมข้อกำหนดในจำนวนกรณีทดสอบ
• สถานะการออกแบบและสถานะการดำเนินการสำหรับกรณีทดสอบเฉพาะ
• หากมีการทดสอบการยอมรับของผู้ใช้ที่ต้องทำโดยผู้ใช้ สถานะ UAT ก็สามารถบันทึกไว้ในเมทริกซ์เดียวกันได้เช่นกัน
• ข้อบกพร่องที่เกี่ยวข้องและสถานะปัจจุบันสามารถกล่าวถึงในเมทริกซ์เดียวกันได้

เมทริกซ์ประเภทนี้จะจัดให้ One Stop ร้าน สำหรับกิจกรรมการทดสอบทั้งหมด

นอกเหนือจากการรักษา Excel แยกกัน ทีมทดสอบยังสามารถเลือกใช้เครื่องมือการจัดการการทดสอบเพื่อติดตามข้อกำหนดที่มีอยู่ได้

ประเภทของเมทริกซ์การทดสอบการตรวจสอบย้อนกลับ

ในวิศวกรรมซอฟต์แวร์ เมทริกซ์การตรวจสอบย้อนกลับสามารถแบ่งออกได้เป็น 3 องค์ประกอบหลักดังนี้

• ส่งต่อการตรวจสอบย้อนกลับ: เมทริกซ์นี้ใช้เพื่อตรวจสอบว่าโครงการดำเนินไปในทิศทางที่ต้องการและสำหรับผลิตภัณฑ์ที่เหมาะสมหรือไม่ ทำให้แน่ใจว่าข้อกำหนดแต่ละข้อถูกนำไปใช้กับผลิตภัณฑ์และมีการทดสอบข้อกำหนดแต่ละข้ออย่างละเอียด โดยจะแมปข้อกำหนดเพื่อทดสอบกรณีต่างๆ
• การตรวจสอบย้อนกลับหรือย้อนกลับ: ใช้เพื่อให้แน่ใจว่าผลิตภัณฑ์ปัจจุบันยังคงอยู่ในแนวทางที่ถูกต้องหรือไม่ วัตถุประสงค์เบื้องหลังการตรวจสอบย้อนกลับประเภทนี้คือการตรวจสอบว่าเราไม่ได้ขยายขอบเขตของโครงการโดยการเพิ่มโค้ด องค์ประกอบการออกแบบ การทดสอบ หรืองานอื่น ๆ ที่ไม่ได้ระบุไว้ในข้อกำหนด มันแม็ปกรณีทดสอบตามความต้องการ
• การตรวจสอบย้อนกลับแบบสองทิศทาง (เดินหน้า+ถอยหลัง): เมทริกซ์การตรวจสอบย้อนกลับนี้ช่วยให้แน่ใจว่าข้อกำหนดทั้งหมดครอบคลุมโดยกรณีทดสอบ จะวิเคราะห์ผลกระทบของการเปลี่ยนแปลงข้อกำหนดที่ได้รับผลกระทบจาก ข้อบกพร่อง ในผลิตภัณฑ์งานและในทางกลับกัน

วิธีสร้าง Requirement Traceability Matrix

มาทำความเข้าใจแนวคิดของ Requirement Traceability Matrix ผ่านโครงการธนาคาร Guru99 กันดีกว่า

บนพื้นฐานของ เอกสารข้อกำหนดทางธุรกิจ (BRD) และ เอกสารข้อกำหนดทางเทคนิค (TRD)ผู้ทดสอบเริ่มเขียนกรณีทดสอบ

สมมติว่าตารางต่อไปนี้เป็นเอกสารความต้องการทางธุรกิจของเราหรือ BRD สำหรับ โครงการธนาคาร Guru99.

ต่อไปนี้เป็นสถานการณ์ที่ลูกค้าควรจะสามารถเข้าสู่ระบบเว็บไซต์ธนาคารของ Guru99 ด้วยรหัสผ่านที่ถูกต้องและ user#id ในขณะที่ผู้จัดการควรจะสามารถเข้าสู่ระบบเว็บไซต์ผ่านทางหน้าเข้าสู่ระบบของลูกค้าได้

ในขณะที่ตารางด้านล่างนี้เป็นของเรา เอกสารข้อกำหนดทางเทคนิค (TRD).

หมายเหตุ ทีม QA ไม่ได้จัดทำเอกสาร BRD และ TRD นอกจากนี้บางบริษัทก็ใช้ เอกสารข้อกำหนดฟังก์ชัน (FRD) ซึ่งคล้ายกับ Technical Requirement Document แต่กระบวนการสร้าง Traceability Matrix ยังคงเหมือนเดิม

ก้าวต่อไปและสร้าง RTM ในการทดสอบ

ขั้นตอน 1) ที่สุดของ กรณีทดสอบตัวอย่าง is

“ยืนยันการเข้าสู่ระบบ เมื่อกรอก ID และรหัสผ่านที่ถูกต้อง ก็ควรเข้าสู่ระบบได้สำเร็จ”

ขั้นตอน 2) ระบุข้อกำหนดทางเทคนิคที่กรณีการทดสอบนี้กำลังตรวจสอบ สำหรับกรณีทดสอบของเรา ข้อกำหนดทางเทคนิคคือ T94 กำลังได้รับการตรวจสอบ

ขั้นตอน 3) โปรดสังเกตข้อกำหนดทางเทคนิค (T94) นี้ในกรณีทดสอบ

ขั้นตอน 4) ระบุข้อกำหนดทางธุรกิจที่กำหนด TR (ข้อกำหนดทางเทคนิค-T94) นี้

ขั้นตอน 5) สังเกต BR (ข้อกำหนดทางธุรกิจ) ในกรณีทดสอบ

ขั้นตอน 6) ทำข้างต้นสำหรับกรณีทดสอบทั้งหมด Later แยก 3 คอลัมน์แรกออกจากชุดทดสอบของคุณ RTM ในการทดสอบพร้อมแล้ว!

ข้อดีของเมทริกซ์ความสามารถในการตรวจสอบย้อนกลับความต้องการ

• ยืนยันความครอบคลุมการทดสอบ 100%
• โดยเน้นย้ำถึงข้อกำหนดใดๆ ที่ขาดหายไปหรือความไม่สอดคล้องกันของเอกสาร
• โดยจะแสดงข้อบกพร่องโดยรวมหรือสถานะการดำเนินการโดยเน้นที่ข้อกำหนดทางธุรกิจ
• ช่วยในการวิเคราะห์หรือประมาณผลกระทบต่อการทำงานของทีม QA เกี่ยวกับการทบทวนหรือการทำงานซ้ำในกรณีทดสอบ

มาเรียนรู้ RTM ด้วยตัวอย่างในวิดีโอ

คลิก Good Farm Animal Welfare Awards หากไม่สามารถเข้าถึงวิดีโอได้

เทมเพลต Requirements Traceability Matrix (RTM)

คลิกด้านล่างเพื่อดาวน์โหลดไฟล์ Excel เทมเพลต RTM

ดาวน์โหลดเทมเพลต RTM Excel(.xlsx)