RTM – מטריצת הקשר בין מקרי בדיקה (test cases) לדרישות.

מטריצת הקשר RTM מאפשרת לנו לתכנן איזו מקרי בדיקה יש לממש ולהיות בטוחים שיש כיסוי מלא לכל דרישות.

נניח במסמך BRS יש שתי דרישות:

BRS1  Flight Booking Module :

User book flight tickets with different options



BRS2  Payment Module:

User should able to make payment by PayPal, Credit Card like VISA, MasterCard

במסמך FRS יש תיאור של הדרישות של מסמך BRS

BRS1  Flight Booking Module :

FRS1 : One Way Ticket booking

     Buy ticket only forward

FRS2 Round Way Ticket

     Buy ticket forward and back

FRS3 Multicity Ticket booking

        Buy ticket forward and back with different locations

BRS2  Payment Module:

   FRS4: By PayPal

    Only verified PayPal accounts can do it. 

FRS5 By Credit Card

  Visa, MasterCard, IsraCard

FRS6 By Cash

It should allows user to make payment by cash at airport 

Requirement Traceability Matrix – RTM

במקרה שלעיל יש כיסוי מלא של מקרי בדיקות (למרות שהם ללא פירוט _#TC) עבור הדרישות.

מקרי בדיקה VS תסריטי בדיקות ומטריצת דרישות RTM:

ניתן לראות לפי מטריצת הדרישות RTM שיש כיסוי מלא במקרי בדיקות (כל מיני וריאציות לשני תסריטים) וכיסוי בשני תסריטי בדיקות את הדרישה פונקציונלית ממסמך SRS -"כרטיס רק לכיוון אחת" .

אם זאת אין כיסוי מלא בתסריטי בדיקות ומקרי בדיקות של דרישה פונקציונלית עבור טיסה הלוך וחזור ובכך אין כיסוי מלא לדרישה עסקית "כרטיסי טיסות".

הערה להבי מסמך STP: בזמן כתיבת מקרי בדיקות לתסריטים שלנו, בדרך כלל מנהל בדיקות מעריך כמה זמן יקח להריץ מקרי בדיקה ועל סמך זה בונים לוח זמנים להרצת מקרי בדיקות במסמך Software Test Plan.

ניתן לקרוא יותר פרטים על מסמך בדיקות STP בקישור:
qablog.co.il/stp-software-test-plan