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
