ماتریس ردیابی نیازمندی‌ها (RTM) چیست؟ راهنمای کامل Requirements Traceability Matrix

تصور کنید تیم توسعه و QA فقط یک هفته تا انتشار نسخه جدید یک فروشگاه اینترنتی فاصله دارد. 🛒

همه‌چیز تقریباً آماده است؛ تست‌ها اجرا شده‌اند، بیشتر Bugها برطرف شده‌اند و تیم منتظر تأیید نهایی است.

اما ناگهان Product Owner یک خبر مهم می‌دهد:

«قانون محاسبه تخفیف برای سفارش‌های بالای یک مبلغ مشخص تغییر کرده است.»

در نگاه اول، تغییر ساده به نظر می‌رسد. اما برای تیم QA یک سؤال مهم ایجاد می‌شود:

دقیقاً کدام بخش‌های سیستم و کدام تست‌ها تحت تأثیر این تغییر قرار می‌گیرند؟

• آیا فقط یک Test Case باید تغییر کند؟
• یا چندین Test Case؟
• آیا Component مربوط به سبد خرید هم تحت تأثیر قرار می‌گیرد؟
• آیا تست‌های مربوط به محاسبه مبلغ نهایی سفارش باید دوباره اجرا شوند؟
• آیا Bugهای قبلی که به این Requirement مربوط بوده‌اند نیز باید بررسی شوند؟

اگر ارتباط بین این موارد مشخص نباشد، پیدا کردن پاسخ می‌تواند زمان زیادی از تیم بگیرد و حتی باعث شود یک Requirement تغییر کند، اما یکی از Test Caseهای مرتبط با آن فراموش شود. 🐞

اینجاست که مفهوم Traceability یا ردیابی‌پذیری اهمیت پیدا می‌کند.

در یک پروژه نرم‌افزاری، فقط داشتن Requirement، Test Case یا Defect به‌تنهایی کافی نیست. مهم است بدانیم این Artefactها چه ارتباطی با یکدیگر دارند و چگونه می‌توان مسیر یک نیازمندی را در بخش‌های مختلف چرخه توسعه و تست دنبال کرد.

Requirements Traceability Matrix یا RTM یکی از روش‌های رایج برای ثبت، نمایش و مدیریت این ارتباط‌هاست. 🔗

در ساده‌ترین و رایج‌ترین شکل، RTM می‌تواند ارتباط زیر را نشان دهد:

Requirement → Test Case

اما Traceability در پروژه‌های مختلف می‌تواند گسترده‌تر باشد و Relationshipهای دیگری را نیز شامل شود. برای مثال:

Requirement → User Story → Test Case → Test Result → Defect

یا در برخی پروژه‌ها ممکن است ارتباط Requirement با Component یا ارتباط Test Case با Component نیز مورد نیاز باشد.

بنابراین اگر جایی RTM را فقط به‌عنوان «جدولی برای اتصال Requirementها به Test Caseها» معرفی کرده‌اند، این تعریف رایج‌ترین کاربرد RTM را توضیح می‌دهد، اما تمام ظرفیت Traceability در یک پروژه نرم‌افزاری را پوشش نمی‌دهد.

1. ماتریس ردیابی نیازمندی‌ها (RTM) چیست؟

فرض کنیم همان پروژه فروشگاه اینترنتی را ادامه می‌دهیم.

تیم محصول چند نیازمندی برای نسخه جدید تعریف کرده است. یکی از آن‌ها این است:

REQ-015: اگر مبلغ سفارش کاربر از ۵ میلیون تومان بیشتر باشد، سیستم باید ۱۰٪ تخفیف اعمال کند.

حالا تیم QA باید مطمئن شود که این Requirement به‌درستی پیاده‌سازی شده و رفتار سیستم مطابق انتظار است.

برای بررسی این Requirement، چند Test Case طراحی می‌شود:

• TC-101: سفارش با مبلغ کمتر از ۵ میلیون تومان
• TC-102: سفارش دقیقاً برابر با ۵ میلیون تومان
• TC-103: سفارش بیشتر از ۵ میلیون تومان
• TC-104: بررسی سقف یا محدودیت تخفیف

اینجا یک سؤال مهم مطرح می‌شود:

از کجا بدانیم این Test Caseها واقعاً برای REQ-015 طراحی شده‌اند؟

و برعکس، اگر چند ماه بعد REQ-015 تغییر کند، چطور بفهمیم کدام تست‌ها باید دوباره بررسی یا اجرا شوند؟ 🔍

اینجاست که Requirements Traceability Matrix یا RTM به کمک تیم می‌آید.

RTM چیست؟

Requirements Traceability Matrix (RTM) یا ماتریس ردیابی نیازمندی‌ها ساختاری برای ثبت و نمایش ارتباط بین Requirementها و Artefactهای مرتبط در طول چرخه توسعه و تست نرم‌افزار است.

در رایج‌ترین شکل، RTM ارتباط بین Requirement و Test Case را نشان می‌دهد:

Requirement ID	Requirement	Test Case ID
REQ-015	اعمال ۱۰٪ تخفیف برای سفارش بالای ۵ میلیون تومان	TC-101
REQ-015	اعمال ۱۰٪ تخفیف برای سفارش بالای ۵ میلیون تومان	TC-102
REQ-015	اعمال ۱۰٪ تخفیف برای سفارش بالای ۵ میلیون تومان	TC-103
REQ-015	اعمال ۱۰٪ تخفیف برای سفارش بالای ۵ میلیون تومان	TC-104

حالا اگر REQ-015 تغییر کند، تیم QA می‌تواند به‌سرعت Test Caseهای مرتبط با آن را پیدا کند و بررسی کند که آیا نیاز به اصلاح، اجرای مجدد یا Regression Testing دارند یا خیر.

🔗 این قابلیت، نمونه‌ای از کاربرد Traceability در مدیریت نیازمندی‌ها و تست است.

اما RTM فقط Requirement → Test Case نیست

اینجا یکی از نکات مهمی است که باید از همان ابتدا درک کنیم.

در پروژه‌های مختلف، سازمان ممکن است بخواهد Relationshipهای بیشتری را ردیابی کند. برای مثال:

• Requirement → User Story
• Requirement → Test Case
• Test Case → Component
• Requirement → Component
• Requirement → Test Case → Test Result → Defect

بنابراین نباید RTM را صرفاً به یک جدول با سه ستون ثابت محدود کنیم.

RTM یک قالب واحد و اجباری ندارد؛ ساختار آن به هدف Traceability، نوع پروژه، فرآیند توسعه، سطح ریسک و ابزارهای مورد استفاده بستگی دارد.

هدف اصلی RTM چیست؟

اگر بخواهیم کاربرد اصلی RTM را در یک سؤال خلاصه کنیم، می‌توانیم بگوییم:

«آیا می‌توانیم ارتباط یک Requirement را با Artefactهای مرتبط آن در طول چرخه توسعه و تست دنبال کنیم؟»

این ردیابی به تیم کمک می‌کند بفهمد:

• هر Requirement چگونه و با چه Test Caseهایی Verification شده است؟ 🧪
• آیا Requirementای وجود دارد که هیچ Test Case یا روش Verification مشخصی نداشته باشد؟
• یک Test Case به کدام Requirement یا Requirementها مربوط است؟
• تغییر یک Requirement چه Test Caseهایی را تحت تأثیر قرار می‌دهد؟
• یک Defect به کدام Requirement و Test Case مربوط است؟ 🐞
• کدام Component یا Module با یک Requirement خاص ارتباط دارد؟
• آیا Requirementهای مهم، به‌خصوص Requirementهای پرریسک، Coverage مناسبی دارند؟

بنابراین RTM را بهتر است نه صرفاً به‌عنوان «یک جدول»، بلکه به‌عنوان ساختاری برای مدیریت و مشاهده Traceability بین Requirementها و Artefactهای مرتبط پروژه در نظر بگیریم.

2. Traceability یا ردیابی‌پذیری چیست؟

قبل از اینکه بیشتر وارد RTM شویم، باید یک مفهوم مهم‌تر را بشناسیم: Traceability.

چون RTM یکی از روش‌های ثبت و نمایش Traceability است، اگر خود مفهوم Traceability را درست درک نکنیم، ممکن است RTM را فقط به یک جدول ساده برای ارتباط Requirement و Test Case محدود کنیم.

Traceability یعنی چه؟

Traceability یا ردیابی‌پذیری یعنی بتوانیم ارتباط یک مورد را با موارد مرتبط در بخش‌های مختلف چرخه توسعه و تست نرم‌افزار دنبال کنیم.

به زبان ساده:

Traceability یعنی بتوانیم بفهمیم «این مورد از کجا آمده، به چه چیزهایی مرتبط است و تغییر یا وضعیت آن چه چیزهایی را تحت تأثیر قرار می‌دهد؟»

برای مثال، فرض کنیم یک نیازمندی داریم:

REQ-025: کاربر باید بتواند رمز عبور خود را بازیابی کند.

این Requirement ممکن است در طول چرخه توسعه و تست با Artefactهای مختلفی ارتباط داشته باشد:

REQ-025
↓
User Story
↓
Acceptance Criteria
↓
Test Scenario
↓
Test Cases 🧪
↓
Password Recovery Component
↓
Test Result
↓
Defect 🐞

Traceability کمک می‌کند این ارتباط‌ها قابل مشاهده و قابل پیگیری باشند.

چرا Traceability در تست نرم‌افزار مهم است؟

فرض کنید بعد از انتشار نسخه جدید، یک کاربر گزارش می‌دهد:

«ایمیل بازیابی رمز عبور برای بعضی کاربران ارسال نمی‌شود.»

تیم QA یک Defect ایجاد می‌کند:

BUG-142

اگر Traceability مناسبی داشته باشیم، می‌توانیم مسیر را به عقب دنبال کنیم:

BUG-142 ← TC-208 ← REQ-025

یعنی می‌توانیم متوجه شویم این Bug با کدام Test Case و در نهایت با کدام Requirement مرتبط است.

اما Traceability فقط برای دنبال کردن مسیر به عقب نیست.

اگر Requirement تغییر کند نیز می‌توانیم مسیر را به جلو دنبال کنیم.

مثلاً:

REQ-025 تغییر کرده است.

حالا می‌خواهیم بدانیم:

• کدام Test Caseها باید بررسی یا اصلاح شوند؟
• کدام Componentها تحت تأثیر قرار گرفته‌اند؟
• آیا Test Scenarioها باید تغییر کنند؟
• آیا Regression Testing لازم است؟

اینجاست که Traceability می‌تواند به Impact Analysis کمک کند. 🔍

Traceability فقط بین Requirement و Test Case نیست

یکی از سوءبرداشت‌های رایج این است که Traceability را مساوی با این رابطه بدانیم:

Requirement ↔ Test Case

این رابطه بسیار مهم و رایج است، اما Traceability مفهوم گسترده‌تری دارد.

بسته به ساختار پروژه، ممکن است Relationshipهای مختلفی برای ایجاد Traceability مورد استفاده قرار گیرند، از جمله:

• Business Requirement → System Requirement
• Requirement → User Story
• User Story → Acceptance Criteria
• Requirement → Test Case
• Test Case → Component
• Requirement → Defect
• Test Case → Defect

در پروژه‌های پیچیده‌تر حتی ممکن است زنجیره‌ای مانند این داشته باشیم:

Business Requirement
↓
System Requirement
↓
Design
↓
Component
↓
Test Case
↓
Test Result
↓
Defect

بنابراین Traceability را بهتر است یک شبکه ارتباطی بین Artefactهای مرتبط پروژه در نظر بگیریم، نه صرفاً یک رابطه دوطرفه بین Requirement و Test Case.

تفاوت Traceability و RTM چیست؟

حالا می‌توانیم تفاوت این دو مفهوم را مشخص کنیم.

مفهوم	توضیح
Traceability	قابلیت دنبال کردن و بررسی ارتباط بین Artefactهای مرتبط پروژه
RTM	ماتریس یا ساختاری برای ثبت و نمایش Relationshipهای موردنیاز در Traceability

یک مثال ساده:

Traceability را می‌توان مانند شبکه‌ای از مسیرها بین نقاط مختلف در نظر گرفت.

RTM مانند یک نقشه یا جدول است که بخشی از این ارتباط‌ها را به شکلی سازمان‌یافته و قابل مشاهده ثبت می‌کند. 🗺️

بنابراین:

Traceability یک مفهوم و قابلیت است؛ RTM یکی از روش‌های سازمان‌دهی و نمایش این ارتباط‌هاست.

Traceability Chain چیست؟

وقتی چند Artefact به‌صورت زنجیره‌ای به یکدیگر متصل می‌شوند، می‌توانیم از مفهوم Traceability Chain صحبت کنیم.

برای مثال:

REQ-015
↓
US-042
↓
AC-042-01
↓
TC-101
↓
BUG-087

حالا اگر REQ-015 تغییر کند، می‌توانیم زنجیره را دنبال کنیم و مواردی را که ممکن است تحت تأثیر قرار بگیرند شناسایی کنیم.

این موضوع در پروژه‌های بزرگ اهمیت بیشتری پیدا می‌کند. هرچه تعداد Requirementها، Test Caseها، Componentها و Defectها بیشتر شود، ردیابی دستی Relationshipها دشوارتر می‌شود و داشتن یک ساختار مشخص برای مدیریت آن‌ها ارزش بیشتری پیدا می‌کند.

یک نکته مهم

Traceability لزوماً به این معنا نیست که همه‌چیز باید به همه‌چیز متصل شود.

هدف، ایجاد یک شبکه عظیم و پیچیده از Relationshipها نیست.

هدف این است که ارتباط‌های معنادار و موردنیاز پروژه قابل ردیابی باشند.

به همین دلیل، در یک پروژه ممکن است Traceability عمدتاً روی:

Requirement ↔ Test Case

متمرکز باشد، در حالی که در پروژه‌ای دیگر روابط بیشتری مانند:

Requirement ↔ User Story ↔ Test Case ↔ Component ↔ Defect

نیز مدیریت شوند.

حالا که مفهوم Traceability روشن شد، می‌توانیم وارد یکی از مهم‌ترین بخش‌های مقاله شویم:

3. RTM چه ارتباط‌هایی را نشان می‌دهد؟ 🔗

حالا که تفاوت Traceability و RTM را می‌دانیم، به یکی از مهم‌ترین سؤال‌های مقاله می‌رسیم:

وقتی می‌گوییم «ردیابی نیازمندی‌ها»، دقیقاً چه چیزهایی را به چه چیزهایی متصل می‌کنیم؟

پاسخ این است که یک رابطه واحد و اجباری برای تمام پروژه‌ها وجود ندارد.

در پروژه‌های مختلف، بسته به فرآیند توسعه، نوع محصول، سطح ریسک و ابزارهای مورد استفاده، ممکن است Relationshipهای متفاوتی ردیابی شوند.

با این حال، چند رابطه از بقیه رایج‌تر هستند.

3.1. ارتباط Requirement ↔ Test Case 🧪

این رایج‌ترین و کلاسیک‌ترین کاربرد RTM است.

در این حالت، هر Requirement به Test Caseهای مربوط به خودش متصل می‌شود.

Requirement	Test Case
REQ-001 – ورود کاربر	TC-001
REQ-001 – ورود کاربر	TC-002
REQ-002 – بازیابی رمز عبور	TC-003
REQ-002 – بازیابی رمز عبور	TC-004

این ارتباط به تیم QA کمک می‌کند بررسی کند:

• آیا برای هر Requirement تست طراحی شده است؟
• هر Requirement چند Test Case دارد؟
• کدام Requirement هنوز Coverage مناسبی ندارد؟
• با تغییر یک Requirement، کدام Test Caseها باید بررسی شوند؟

به همین دلیل، وقتی در منابع مختلف عبارت Requirements Traceability Matrix را می‌بینید، معمولاً یکی از مهم‌ترین کاربردهای آن همین رابطه است:

Requirement → Test Case

3.2. ارتباط Requirement ↔ Test Scenario

گاهی به جای اینکه Requirement مستقیماً به Test Case متصل شود، ارتباط با Test Scenario نیز ردیابی می‌شود.

مثلاً:

REQ-010: کاربر باید بتواند محصول را خریداری کند.

ممکن است این Requirement به Scenario زیر متصل شود:

TS-005: بررسی فرآیند خرید محصول

و این Scenario خودش چند Test Case داشته باشد:

TS-005 → TC-021, TC-022, TC-023, TC-024

این ساختار زمانی مفید است که تعداد Test Caseها زیاد باشد و تیم بخواهد Coverage را ابتدا در سطح Scenario بررسی کند.

3.3. ارتباط Requirement ↔ User Story

در پروژه‌هایی که از Agile استفاده می‌کنند، Requirementها ممکن است با User Storyها مرتبط شوند.

مثلاً:

REQ-015: کاربر باید بتواند سفارش خود را لغو کند.

⬇️

US-042: به‌عنوان یک کاربر، می‌خواهم بتوانم سفارش خود را لغو کنم تا در صورت نیاز خرید خود را متوقف کنم.

این ارتباط کمک می‌کند مشخص شود هر نیازمندی چگونه به یک قابلیت قابل توسعه در Product Backlog تبدیل شده است.

3.4. ارتباط User Story ↔ Test Case

در تیم‌های Agile، ممکن است تیم اصلاً یک Requirement Document سنتی نداشته باشد و ردیابی بیشتر حول User Story انجام شود.

مثلاً:

US-042 → TC-101, TC-102, TC-103

در این حالت، Test Caseها مستقیماً به User Story مربوط می‌شوند. این مدل در ابزارهای مدیریت پروژه و Test Management رایج است.

3.5. ارتباط Requirement ↔ Acceptance Criteria

یک Requirement ممکن است به معیارهایی متصل باشد که مشخص می‌کنند چه شرایطی باید برقرار باشد تا بتوان آن Requirement یا قابلیت را پذیرفته‌شده در نظر گرفت.

مثلاً:

REQ-020: کاربر باید بتواند رمز عبور خود را تغییر دهد.

Acceptance Criteria می‌تواند شامل موارد زیر باشد:

• کاربر باید رمز فعلی را وارد کند.
• رمز جدید باید حداقل ۸ کاراکتر باشد.
• رمز جدید و تکرار آن باید یکسان باشند.
• پس از تغییر موفق، پیام تأیید نمایش داده شود.

سپس این Acceptance Criteriaها می‌توانند مبنای طراحی Test Caseها قرار بگیرند.

بنابراین ممکن است زنجیره‌ای مانند این داشته باشیم:

Requirement → Acceptance Criteria → Test Case

3.6. ارتباط Requirement ↔ Component / Module

این همان نوع ارتباطی است که در ابتدای مقاله به آن اشاره کردیم.

فرض کنیم Requirement این باشد:

REQ-030: سیستم باید امکان پرداخت آنلاین را فراهم کند.

این Requirement ممکن است با Componentهای زیر ارتباط داشته باشد:

• Payment Service
• Order Service
• Payment Gateway Integration

بنابراین می‌توان Relationshipهایی مانند این داشت:

REQ-030 → Payment Service

یا:

REQ-030 → Payment Service → Payment Gateway

این نوع Traceability بیشتر برای Impact Analysis و درک وابستگی‌های سیستم مفید است.

3.7. ارتباط Test Case ↔ Component / Module

گاهی هدف تیم این نیست که Requirement را مستقیماً به Component وصل کند؛ بلکه می‌خواهد بداند:

هر Test Case دقیقاً کدام بخش سیستم را تست می‌کند؟

Test Case	Component
TC-101	Login Service
TC-102	Authentication API
TC-103	User Database
TC-104	Payment Service

این همان رابطه‌ای است که ممکن است در بعضی ماتریس‌ها ببینید و می‌تواند برای Impact Analysis و مدیریت پوشش Componentها مفید باشد.

اما یک نکته مهم وجود دارد:

هر ماتریسی که Test Case و Component را به یکدیگر متصل می‌کند، الزاماً RTM به معنای کلاسیک Requirements Traceability Matrix نیست.

ممکن است چنین جدولی بخشی از یک سیستم گسترده‌تر برای مدیریت Traceability باشد یا به‌عنوان یک Test-to-Component Traceability Matrix مورد استفاده قرار گیرد.

3.8. ارتباط Requirement ↔ Defect 🐞

فرض کنیم:

REQ-045: سیستم باید در صورت وارد کردن رمز اشتباه، پیام خطای مناسب نمایش دهد.

در زمان تست، Bug زیر پیدا می‌شود:

BUG-103: سیستم به جای پیام خطا، صفحه سفید نمایش می‌دهد.

حالا می‌توان Relationship زیر را ثبت کرد:

REQ-045 → BUG-103

این ارتباط برای تحلیل وضعیت Requirement بسیار ارزشمند است؛ مثلاً می‌توان بررسی کرد کدام Requirementها در حال حاضر Defect باز دارند.

3.9. ارتباط Test Case ↔ Defect

یک رابطه رایج دیگر این است:

TC-205 → BUG-103

یعنی BUG-103 هنگام اجرای TC-205 شناسایی شده است.

حالا اگر زنجیره را کامل کنیم:

REQ-045
↓
TC-205
↓
BUG-103

می‌توانیم مسیر را از Requirement تا Test Case و سپس تا Defect دنبال کنیم. 🔍

پس RTM دقیقاً چه چیزی را می‌تواند نشان دهد؟

ارتباط	کاربرد اصلی
Requirement ↔ Test Case	Test Coverage و بررسی کامل بودن تست
Requirement ↔ Test Scenario	ردیابی Requirement در سطح Scenario
Requirement ↔ User Story	ارتباط نیازمندی با Backlog در Agile
User Story ↔ Test Case	ردیابی تست در Agile
Requirement ↔ Acceptance Criteria	ارتباط نیازمندی با معیار پذیرش
Requirement ↔ Component	Impact Analysis و درک وابستگی‌های سیستم
Test Case ↔ Component	مشخص کردن بخش مورد تست
Requirement ↔ Defect	شناسایی Defectهای مرتبط با Requirement
Test Case ↔ Defect	مشخص کردن تستی که Defect را کشف کرده است

اما یک نکته بسیار مهم وجود دارد:

قرار نیست همه این روابط را داخل یک جدول قرار دهیم.

اگر تمام این Relationshipها را در یک ماتریس عظیم قرار دهیم، خیلی زود با جدولی مواجه می‌شویم که مدیریت، نگهداری و استفاده از آن دشوار می‌شود.

بهتر است بسته به نیاز پروژه، Traceability موردنیاز را انتخاب کنیم.

یک نگاه حرفه‌ای‌تر به RTM

در یک پروژه پیچیده، ممکن است Traceability به شکل یک شبکه دیده شود:

Business Requirement
↓
System Requirement
↓
User Story
↓
Acceptance Criteria
↓
Test Scenario
↓
Test Case
↓
Test Result
↓
Defect

و در کنار این زنجیره ممکن است Relationshipهای دیگری نیز وجود داشته باشند، مانند:

Requirement → Component

یا:

Test Case → Component

بنابراین RTM می‌تواند بخشی از یک Traceability Network گسترده‌تر باشد.

اما حالا یک سؤال مهم‌تر مطرح می‌شود:

اگر بتوانیم Requirement را هم به سمت Testها دنبال کنیم و هم از Testها به سمت Requirement برگردیم، چه انواعی از Traceability خواهیم داشت؟

اینجا به سه مفهوم مهم می‌رسیم:

Forward Traceability، Backward Traceability و Bidirectional Traceability. 🔗

4. انواع Traceability در RTM 🔗

تا اینجا دیدیم که RTM می‌تواند ارتباط‌های مختلفی را بین Requirementها، Test Caseها، User Storyها، Componentها و Defectها ثبت و نمایش دهد.

اما یک سؤال دیگر باقی می‌ماند:

آیا فقط نوع ارتباط مهم است، یا جهت ردیابی هم اهمیت دارد؟

پاسخ این است که جهت ردیابی نیز اهمیت دارد. از این منظر، معمولاً سه نوع Traceability مطرح می‌شود:

1. Forward Traceability
2. Backward Traceability
3. Bi-directional Traceability

برای درک بهتر، همان مثال فروشگاه اینترنتی را ادامه دهیم. 🛒

4.1. Forward Traceability چیست؟

Forward Traceability یا ردیابی رو به جلو یعنی حرکت از Requirement به سمت Artefactهای مرتبطی که در ادامه چرخه توسعه و تست ایجاد شده‌اند.

برای مثال:

Requirement → Test Case → Test Result

فرض کنید Requirement زیر را داریم:

REQ-015: سفارش‌های بالای ۵ میلیون تومان باید شامل ۱۰٪ تخفیف شوند.

این Requirement به Test Caseهای زیر مرتبط است:

• TC-101: سفارش کمتر از ۵ میلیون تومان
• TC-102: سفارش برابر با ۵ میلیون تومان
• TC-103: سفارش بیشتر از ۵ میلیون تومان

پس می‌توانیم مسیر را از Requirement به سمت تست دنبال کنیم:

REQ-015 → TC-101
REQ-015 → TC-102
REQ-015 → TC-103

اگر هدف این باشد که مطمئن شویم Requirementهای تعریف‌شده به Test Caseهای مناسب متصل هستند، Forward Traceability بسیار مفید است. 🧪

Forward Traceability چه سؤالی را پاسخ می‌دهد؟

«برای این Requirement چه چیزی در ادامه مسیر تعریف، پیاده‌سازی یا تست شده است؟»

این نوع Traceability می‌تواند برای بررسی Test Coverage و شناسایی Requirementهایی که Test Case مرتبط ندارند، مورد استفاده قرار گیرد.

4.2. Backward Traceability چیست؟

در Backward Traceability یا ردیابی رو به عقب، جهت حرکت برعکس می‌شود.

به جای اینکه از Requirement شروع کنیم، از یک Artefact مانند Test Case شروع می‌کنیم و بررسی می‌کنیم این مورد به کدام Requirement مرتبط است.

مثلاً:

TC-103 → REQ-015

یعنی:

«این Test Case برای بررسی کدام Requirement ایجاد شده است؟»

فرض کنید در یک پروژه ۵۰۰ Test Case داریم.

اگر متوجه شویم Test Case زیر وجود دارد:

TC-387: بررسی تخفیف سفارش

اما هیچ Requirement مشخصی به آن متصل نیست، یک سؤال مهم ایجاد می‌شود:

چرا این تست وجود دارد؟

ممکن است:

• Requirement مربوطه حذف شده باشد.
• Requirement تغییر کرده باشد.
• Test Case قدیمی باشد.
• Test Case به اشتباه ایجاد شده باشد.
• یا Relationship در مستندات یا ابزار ثبت نشده باشد.

بنابراین Backward Traceability می‌تواند به شناسایی Test Caseهایی که Requirement مرتبط مشخصی ندارند کمک کند.

Backward Traceability چه سؤالی را پاسخ می‌دهد؟

«این Test Case یا Artefact برای کدام Requirement ایجاد شده است؟»

4.3. Bi-directional Traceability چیست؟

Bi-directional Traceability یا ردیابی دوطرفه یعنی بتوانیم یک Relationship را در هر دو جهت دنبال کنیم.

مثلاً:

Requirement ↔ Test Case

از Requirement می‌توانیم به Test Case برسیم:

REQ-015 → TC-103

و از Test Case نیز می‌توانیم به Requirement برگردیم:

TC-103 → REQ-015

در نتیجه، می‌توانیم هم Coverage را از سمت Requirement بررسی کنیم و هم Relevance و Justification تست‌ها را از سمت Test Case ارزیابی کنیم.

یک مثال واقعی‌تر

فرض کنیم سه Requirement داریم:

Requirement	شرح
REQ-001	کاربر بتواند وارد حساب شود
REQ-002	کاربر بتواند رمز عبور را بازیابی کند
REQ-003	کاربر بتواند از حساب خارج شود

و Test Caseها:

Test Case	شرح
TC-001	Login با اطلاعات صحیح
TC-002	Login با رمز اشتباه
TC-003	Password Recovery
TC-004	Logout

Relationshipها:

Requirement	Test Case
REQ-001	TC-001
REQ-001	TC-002
REQ-002	TC-003
REQ-003	TC-004

حالا Forward Traceability می‌پرسد:

REQ-001 چه Test Caseهایی دارد؟

پاسخ: TC-001 و TC-002

اما Backward Traceability می‌پرسد:

TC-002 مربوط به کدام Requirement است؟

پاسخ: REQ-001

و Bi-directional Traceability هر دو مسیر را قابل ردیابی می‌کند.

تفاوت سه نوع Traceability

نوع	جهت	سؤال اصلی
Forward	Requirement → Test	برای این Requirement چه تست‌هایی وجود دارد؟
Backward	Test → Requirement	این تست برای کدام Requirement است؟
Bi-directional	Requirement ↔ Test	آیا ارتباط از هر دو جهت قابل ردیابی است؟

چرا Bi-directional Traceability ارزشمند است؟

فرض کنیم یک Requirement حذف یا تغییر کرده است.

با Forward Traceability می‌توانیم از Requirement به سمت Test Caseها حرکت کنیم و بفهمیم چه تست‌هایی مستقیماً با آن مرتبط هستند.

اما اگر فقط Test Caseها را بررسی کنیم، ممکن است Test Caseهایی داشته باشیم که دیگر به هیچ Requirement فعالی مربوط نیستند.

Bi-directional Traceability هر دو دیدگاه را پوشش می‌دهد:

• Requirement → Test Case: برای بررسی Coverage
• Test Case → Requirement: برای بررسی Relevance و دلیل وجود تست

به همین دلیل، در پروژه‌های حساس و بزرگ، داشتن Traceability دوطرفه می‌تواند ارزشمند باشد.

یک نکته ظریف

نباید این سه مفهوم را با نوع ماتریس اشتباه بگیریم.

Forward، Backward و Bi-directional در اصل جهت و نحوه دنبال کردن یک Relationship را توصیف می‌کنند.

مثلاً همان RTM ساده:

Requirement ↔ Test Case

می‌تواند برای ایجاد و بررسی Bi-directional Traceability مورد استفاده قرار گیرد.

RTM ساختار ثبت و نمایش Relationshipهاست؛ Forward، Backward و Bi-directional جهت و نحوه دنبال کردن این Relationshipها را توصیف می‌کنند.

حالا که انواع Traceability را شناختیم، وقت آن است ببینیم این ردیابی دقیقاً چه مشکلی را برای تیم پروژه حل می‌کند.

5. چرا RTM مهم است؟ 🔍

ممکن است تا اینجا با خودتان بگویید:

«خب، می‌توانم Requirementها و Test Caseها را در دو فایل جداگانه داشته باشم. چرا باید ارتباط بین آن‌ها را هم ثبت کنم؟»

در یک پروژه کوچک شاید این کار در ابتدا ضروری به نظر نرسد.

اما تصور کنید پروژه‌ای با ۳۰۰ Requirement، هزاران Test Case و ده‌ها یا صدها Defect دارید.

در چنین شرایطی، یک تغییر کوچک در Requirement می‌تواند مثل افتادن یک دومینو، بخش‌های مختلف پروژه را تحت تأثیر قرار دهد.

مثلاً:

Requirement تغییر می‌کند
↓
Acceptance Criteria تغییر می‌کند
↓
Test Caseها باید بررسی شوند
↓
Component ممکن است تحت تأثیر قرار بگیرد
↓
Regression Testing ممکن است لازم شود
↓
ممکن است Defect جدیدی ایجاد شود 🐞

اگر این ارتباط‌ها مشخص نباشند، پیدا کردن اثرات یک تغییر می‌تواند بسیار زمان‌بر و مستعد خطا باشد.

اینجاست که RTM ارزش خود را نشان می‌دهد.

5.1. بررسی Test Coverage 🧪

یکی از مهم‌ترین کاربردهای RTM، بررسی پوشش تست (Test Coverage) در ارتباط با Requirementهاست.

فرض کنید ۱۰ Requirement داریم، اما فقط برای ۸ مورد Test Case مرتبط تعریف شده است.

RTM می‌تواند این وضعیت را به‌سرعت آشکار کند:

Requirement	Test Case	وضعیت
REQ-001	TC-001, TC-002	Covered
REQ-002	TC-003	Covered
REQ-003	—	❌ بدون تست مرتبط
REQ-004	TC-004, TC-005	Covered

در اینجا مشخص است که:

REQ-003 → هیچ Test Case مرتبطی ندارد.

یعنی یک Requirement ممکن است در اسناد پروژه وجود داشته باشد، اما در فرآیند طراحی تست فراموش شده باشد.

5.2. جلوگیری از فراموش شدن Requirementها

در پروژه‌های واقعی، Requirementها ممکن است زیاد باشند و در طول پروژه نیز تغییر کنند.

بدون Traceability، ممکن است تیم QA به‌صورت ناخواسته یک Requirement را از قلم بیندازد.

RTM کمک می‌کند بتوانیم سؤال ساده اما مهم زیر را پاسخ دهیم:

آیا برای تمام Requirementهای موردنیاز، Test Case یا روش Verification مناسبی در نظر گرفته شده است؟

این موضوع به‌خصوص در پروژه‌هایی که Requirementهای زیادی دارند اهمیت بیشتری پیدا می‌کند.

5.3. Impact Analysis یا تحلیل تأثیر تغییرات 🔍

یکی از کاربردهای بسیار مهم RTM، Impact Analysis است.

فرض کنید Requirement زیر تغییر کند:

REQ-015: سفارش بالای ۵ میلیون تومان شامل ۱۰٪ تخفیف است.

حالا قانون جدید می‌گوید:

«تخفیف فقط برای مشتریان Premium اعمال شود.»

بدون Traceability باید به‌صورت دستی جستجو کنیم و بفهمیم چه چیزهایی ممکن است تحت تأثیر قرار گرفته باشند.

اما اگر Relationshipها ثبت شده باشند:

REQ-015
↓
TC-101, TC-102, TC-103
↓
Discount Component
↓
BUG-087

می‌توانیم سریع‌تر محدوده احتمالی تأثیر تغییر را مشخص کنیم.

بنابراین RTM فقط برای اثبات اینکه Requirement تست شده است نیست؛ بلکه می‌تواند در زمان تغییر Requirement نیز به تحلیل اثرات تغییر کمک کند.

5.4. کمک به Regression Testing

وقتی یک بخش از سیستم تغییر می‌کند، همیشه این سؤال مطرح است:

«کدام تست‌ها را باید دوباره اجرا کنیم؟»

اگر ارتباط بین Requirementها و Test Caseها مشخص باشد، می‌توانیم تست‌های مرتبط را راحت‌تر شناسایی کنیم.

مثلاً:

REQ-015 تغییر کرده
↓
TC-101، TC-102، TC-103
↓
بررسی در Regression Testing

البته در عمل، Regression Testing فقط به Test Caseهای مستقیم مرتبط با Requirement محدود نمی‌شود و باید وابستگی‌های سیستم، Componentهای تحت تأثیر و ریسک تغییر نیز در نظر گرفته شوند. با این حال، RTM می‌تواند نقطه شروع مناسبی برای تحلیل محدوده Regression باشد.

5.5. شناسایی Test Caseهای بدون Requirement

RTM فقط به ما نمی‌گوید چه Requirementهایی تست مرتبط ندارند؛ از جهت مخالف نیز می‌تواند اطلاعات ارزشمندی ارائه دهد.

Test Case	Requirement
TC-001	REQ-001
TC-002	REQ-002
TC-003	REQ-003
TC-004	—

TC-004 هیچ Requirement مشخصی ندارد.

این موضوع الزاماً به معنی اشتباه بودن Test Case نیست؛ ممکن است تستی برای یک نیازمندی فنی، Security، Usability یا یک هدف دیگر ایجاد شده باشد.

اما وجود چنین Test Caseای یک علامت است که باید بررسی شود:

«چرا این تست وجود دارد و چه چیزی را پوشش می‌دهد؟»

این همان جایی است که Backward Traceability اهمیت پیدا می‌کند.

5.6. ارتباط دادن Defectها به Requirementها 🐞

فرض کنیم یک Defect جدی در فرآیند پرداخت پیدا شده است.

اگر بدانیم:

BUG-142 → TC-205 → REQ-034

می‌توانیم بفهمیم این Defect با کدام Test Case و در نهایت با کدام Requirement ارتباط دارد.

این اطلاعات برای گزارش‌دهی و تحلیل وضعیت محصول مفید است. مثلاً می‌توان بررسی کرد:

• کدام Requirementها Defectهای بیشتری دارند؟
• کدام بخش‌های محصول پرریسک‌تر هستند؟
• آیا یک Requirement خاص دائماً با مشکل مواجه می‌شود؟

5.7. کمک به Change Management

Requirementها همیشه ثابت نمی‌مانند.

در بسیاری از پروژه‌ها، Requirementها در طول توسعه تغییر می‌کنند.

مثلاً:

REQ-020 – امکان لغو سفارش

در نسخه اول:

«کاربر تا ۳۰ دقیقه بعد از ثبت سفارش می‌تواند آن را لغو کند.»

در نسخه جدید:

«کاربر تا زمانی که سفارش وارد مرحله ارسال نشده باشد می‌تواند آن را لغو کند.»

این تغییر ممکن است روی چندین Test Case اثر بگذارد.

اگر Traceability داشته باشیم، می‌توانیم مسیر را دنبال کنیم:

REQ-020
↓
Acceptance Criteria
↓
Test Cases
↓
Order Component
↓
Regression Tests

در نتیجه، تغییر Requirement از یک تغییر مبهم به یک تغییر قابل تحلیل تبدیل می‌شود.

5.8. کمک به Audit و Compliance

در برخی پروژه‌ها، مخصوصاً پروژه‌های حساس یا دارای الزامات قانونی، باید بتوان نشان داد که:

«هر Requirement چگونه پیاده‌سازی و Verification شده است؟»

در چنین شرایطی Traceability اهمیت بیشتری پیدا می‌کند.

ممکن است لازم باشد مسیرهایی مانند این قابل اثبات باشند:

• Requirement → Implementation → Test → Test Result
• Requirement → Test Case → Test Evidence

در این پروژه‌ها، RTM می‌تواند بخشی از شواهد موردنیاز برای Audit و Compliance باشد.

5.9. افزایش شفافیت بین اعضای تیم

RTM فقط برای Testerها نیست.

افراد مختلف می‌توانند از Traceability و اطلاعات RTM استفاده کنند، از جمله:

• Business Analyst
• Product Owner
• Developer
• QA Engineer
• Test Manager
• Project Manager

مثلاً Product Owner می‌تواند ببیند:

«این Requirement چه تست‌هایی دارد و وضعیت آن چیست؟»

QA می‌تواند ببیند:

«کدام Requirementها هنوز Coverage مناسبی ندارند؟»

Developer می‌تواند بفهمد:

«این Component در ارتباط با کدام Requirement قرار دارد؟»

و مدیر پروژه می‌تواند دید کلی‌تری نسبت به Coverage، وضعیت تست و ارتباط بین بخش‌های مختلف محصول داشته باشد.

پس RTM دقیقاً چه مشکلی را حل می‌کند؟

اگر بخواهیم تمام این مزایا را در یک جمله خلاصه کنیم:

RTM کمک می‌کند ارتباط بین Requirementها و Artefactهای مرتبط پروژه قابل مشاهده، قابل پیگیری و قابل بررسی باشد.

به همین دلیل RTM را نباید صرفاً یک جدول برای پر کردن چند ستون دانست.

ارزش واقعی RTM زمانی مشخص می‌شود که یک Requirement تغییر کند، یک تست Fail شود، یک Defect پیدا شود یا تیم بخواهد بفهمد یک قابلیت دقیقاً چه بخش‌هایی از محصول و فرآیند تست را تحت تأثیر قرار داده است.

حالا سؤال بعدی این است:

RTM را چه زمانی باید ایجاد کنیم؟ آیا باید صبر کنیم تا همه Requirementها و Test Caseها آماده شوند و بعد RTM بسازیم؟

6. RTM چه زمانی در پروژه ایجاد می‌شود؟ ⏱️

یکی از اشتباهات رایج درباره RTM این است که تصور کنیم باید صبر کنیم تا همه Test Caseها نوشته و اجرا شوند و در پایان پروژه یک RTM درست کنیم.

در واقع، اگر RTM قرار است برای Traceability و مدیریت تغییرات استفاده شود، بهتر است از مراحل ابتدایی پروژه شکل بگیرد و در طول پروژه به‌روزرسانی شود.

بیایید همان پروژه فروشگاه اینترنتی را دنبال کنیم. 🛒

6.1 شروع کار با Requirementها

فرض کنیم Business Analyst یا Product Owner چند Requirement برای نسخه جدید تعریف کرده است:

• REQ-001: کاربر بتواند ثبت‌نام کند.
• REQ-002: کاربر بتواند وارد حساب خود شود.
• REQ-003: کاربر بتواند محصول را به سبد خرید اضافه کند.
• REQ-004: کاربر بتواند هزینه سفارش را آنلاین پرداخت کند.

در همین مرحله هنوز Test Caseای وجود ندارد.

اما می‌توانیم اطلاعات اولیه Traceability را ایجاد کنیم:

Requirement ID	Requirement	Test Case
REQ-001	ثبت‌نام کاربر	—
REQ-002	ورود کاربر	—
REQ-003	افزودن محصول به سبد	—
REQ-004	پرداخت آنلاین	—

علامت — به این معنا نیست که Requirement تست نشده و پروژه مشکل دارد؛ بلکه نشان می‌دهد Test Caseها هنوز طراحی نشده‌اند.

6.2 هنگام طراحی Test Caseها

وقتی QA وارد مرحله Test Design می‌شود، Test Caseها به Requirementهای مربوط متصل می‌شوند.

Requirement	Test Case
REQ-001	TC-001, TC-002
REQ-002	TC-003, TC-004
REQ-003	TC-005, TC-006
REQ-004	TC-007, TC-008, TC-009

حالا RTM به تیم نشان می‌دهد که برای هر Requirement چه تست‌هایی طراحی شده است. 🧪

6.3 هنگام اجرای Test Caseها

با اجرای تست‌ها، می‌توان اطلاعات بیشتری به Traceability اضافه کرد.

Requirement	Test Case	Result
REQ-001	TC-001	Pass
REQ-001	TC-002	Pass
REQ-002	TC-003	Pass
REQ-002	TC-004	Fail
REQ-003	TC-005	Pass
REQ-004	TC-007	Fail

حالا RTM فقط نشان نمی‌دهد که Requirement تست شده است؛ بلکه می‌تواند وضعیت اجرای تست را نیز نشان دهد.

6.4 هنگام ثبت Defect

فرض کنیم TC-004 Fail شده و تیم QA یک Bug ثبت کرده است:

BUG-023: ورود کاربر با رمز صحیح در برخی شرایط انجام نمی‌شود.

اکنون می‌توانیم Traceability را گسترش دهیم:

REQ-002 → TC-004 → BUG-023 🐞

این ارتباط مشخص می‌کند Bug به کدام Requirement و کدام Test Case مربوط بوده است.

6.5 هنگام تغییر Requirement

حالا فرض کنیم Product Owner اعلام کند:

«قوانین ورود تغییر کرده است. بعد از پنج بار ورود ناموفق، حساب کاربر باید برای ۱۵ دقیقه قفل شود.»

Requirement مربوطه تغییر می‌کند.

در این مرحله RTM می‌تواند به QA کمک کند بفهمد چه تست‌هایی باید بازبینی شوند.

REQ-002
↓
TC-003
TC-004
TC-010
TC-011

حالا QA می‌داند که این Test Caseها احتمالاً تحت تأثیر تغییر قرار گرفته‌اند.

این همان جایی است که RTM با Impact Analysis و Change Management ارتباط پیدا می‌کند. 🔍

بنابراین RTM یک سند Static نیست

یکی از نکات مهم این است که RTM نباید فایلی باشد که یک بار ساخته شود و بعد تا پایان پروژه دست‌نخورده باقی بماند.

در یک پروژه واقعی، ممکن است مرتباً تغییر کند:

• Requirement جدید اضافه می‌شود → RTM به‌روزرسانی می‌شود.
• Requirement تغییر می‌کند → ارتباط‌های مربوطه بررسی می‌شوند.
• Test Case جدید ایجاد می‌شود → به Requirement مناسب متصل می‌شود.
• Test Case حذف می‌شود → Traceability آن اصلاح می‌شود.
• Defect جدید پیدا می‌شود → در صورت نیاز ارتباط آن با Test Case و Requirement ثبت می‌شود.

آیا همیشه باید RTM از ابتدای پروژه ساخته شود؟

لزومی ندارد در اولین روز پروژه یک جدول کامل با صدها ردیف ایجاد کنیم.

مهم این است که Traceability همزمان با شکل‌گیری Artefactهای پروژه ایجاد و نگهداری شود.

در یک پروژه Waterfall ممکن است RTM از مرحله Requirements شروع شود و به‌تدریج تکمیل شود.

در Agile نیز ممکن است Traceability در هر Sprint شکل بگیرد:

User Story → Acceptance Criteria → Test Case → Test Result → Defect

بنابراین روش ایجاد RTM به فرآیند توسعه و ابزارهای تیم بستگی دارد.

RTM در چه مرحله‌ای کامل می‌شود؟

در واقع بهتر است به جای اینکه بگوییم:

«RTM در فلان مرحله ساخته می‌شود.»

بگوییم:

RTM در طول چرخه عمر پروژه ساخته، تکمیل و به‌روزرسانی می‌شود.

ممکن است در پایان یک Sprint یا Release، RTM وضعیت کامل‌تری داشته باشد، اما Traceability نباید فقط به پایان پروژه موکول شود.

یک قانون ساده برای به خاطر سپردن

اگر بخواهیم این بخش را خیلی ساده خلاصه کنیم:

هر وقت یک Artefact جدید ایجاد یا یک Artefact موجود تغییر می‌کند، باید بررسی کنیم آیا Traceability آن نیز باید به‌روزرسانی شود یا نه.

این نگاه باعث می‌شود RTM از یک جدول اداری به یک ابزار واقعی برای مدیریت کیفیت تبدیل شود.

7. ساختار و اجزای RTM 📋

حالا که فهمیدیم RTM چیست، چه ارتباط‌هایی را می‌تواند نشان دهد و چه زمانی باید آن را ایجاد و به‌روزرسانی کرد، وقت آن است که خود ماتریس را بسازیم.

اولین نکته این است که RTM یک Template ثابت و اجباری ندارد.

ممکن است یک تیم فقط Requirement و Test Case را ردیابی کند، در حالی که تیم دیگری اطلاعاتی مانند Test Result، Defect یا Component را نیز اضافه کند.

بنابراین ساختار RTM باید بر اساس هدف Traceability طراحی شود.

7.1 ساده‌ترین ساختار RTM

رایج‌ترین شکل RTM می‌تواند بسیار ساده باشد:

Requirement ID	Requirement	Test Case ID
REQ-001	ثبت‌نام کاربر	TC-001, TC-002
REQ-002	ورود کاربر	TC-003, TC-004
REQ-003	بازیابی رمز عبور	TC-005

این ساختار برای پروژه‌های ساده کاملاً می‌تواند کافی باشد.

اما در پروژه‌های واقعی ممکن است اطلاعات بیشتری موردنیاز باشد.

7.2 ستون Requirement ID

اولین ستون معمولاً Requirement ID است.

• REQ-001
• REQ-002
• REQ-003

وجود ID یکتا اهمیت زیادی دارد.

به جای اینکه در تمام سیستم بنویسیم «نیازمندی مربوط به ورود کاربر»، می‌توانیم فقط از شناسه آن استفاده کنیم:

REQ-002

این شناسه می‌تواند در ابزارهای مختلف پروژه نیز مورد استفاده قرار گیرد.

7.3 ستون Requirement

در این ستون شرح کوتاهی از Requirement قرار می‌گیرد.

مثلاً:

REQ-002

کاربر باید بتواند با استفاده از Email و Password وارد حساب کاربری خود شود.

البته در پروژه‌های بزرگ بهتر است متن کامل Requirement الزاماً داخل RTM تکرار نشود و RTM به سند یا ابزار مدیریت Requirement لینک شود.

7.4 ستون Test Case ID 🧪

این ستون یکی از مهم‌ترین بخش‌های RTM است.

مثلاً:

REQ-002 → TC-003, TC-004, TC-005

یعنی سه Test Case برای این Requirement وجود دارد.

این ارتباط به ما اجازه می‌دهد Coverage را بررسی کنیم.

اگر یک Requirement هیچ Test Caseای نداشته باشد:

REQ-006 → —

باید بررسی کنیم که آیا Requirement واقعاً تست نشده یا Traceability ناقص است.

7.5 ستون Test Scenario

اگر تیم Test Scenarioها را نیز مدیریت کند، می‌توان این ستون را اضافه کرد.

Requirement	Test Scenario	Test Case
REQ-002	Login	TC-003, TC-004
REQ-003	Password Recovery	TC-005, TC-006

این ساختار زمانی مفید است که بخواهیم Traceability را در چند سطح مدیریت کنیم.

7.6 ستون Test Result

گاهی لازم است وضعیت اجرای Test Case نیز در RTM دیده شود.

Requirement	Test Case	Result
REQ-001	TC-001	Pass
REQ-001	TC-002	Pass
REQ-002	TC-003	Fail

مقادیر این ستون می‌توانند مثلاً شامل موارد زیر باشند:

• Pass
• Fail
• Blocked
• Not Run

البته در ابزارهای حرفه‌ای Test Management، این اطلاعات ممکن است در جای دیگری نگهداری شود و RTM فقط به آن‌ها ارجاع دهد.

7.7 ستون Defect ID 🐞

اگر هدف پروژه ردیابی Defectها نیز باشد، می‌توان این ستون را اضافه کرد.

Requirement	Test Case	Result	Defect
REQ-002	TC-004	Fail	BUG-023

حالا یک زنجیره بسیار مفید داریم:

REQ-002 → TC-004 → BUG-023

با این ساختار، می‌توانیم مسیر یک Requirement را تا Defect دنبال کنیم.

7.8 ستون Component / Module

در بعضی پروژه‌ها Component نیز در Traceability اهمیت دارد.

Requirement	Test Case	Component
REQ-004	TC-010	Payment Service
REQ-004	TC-011	Payment Gateway
REQ-005	TC-012	Order Service

این اطلاعات می‌تواند برای Impact Analysis بسیار مفید باشد.

اگر Payment Service تغییر کند، می‌توانیم بررسی کنیم چه Requirementها و Test Caseهایی با آن ارتباط دارند.

7.9 یک RTM نسبتاً کامل

اگر بخواهیم چند نوع Traceability را در یک ساختار نشان دهیم، ممکن است جدولی مانند این داشته باشیم:

Req ID	User Story	Test Case	Component	Result	Defect
REQ-001	US-001	TC-001	Auth Service	Pass	—
REQ-001	US-001	TC-002	Auth Service	Fail	BUG-012
REQ-002	US-002	TC-003	User Service	Pass	—
REQ-003	US-005	TC-010	Payment Service	Fail	BUG-021

این جدول می‌تواند اطلاعات بسیار زیادی به ما بدهد.

اما آیا این بدان معناست که همیشه باید چنین جدول بزرگی ایجاد کنیم؟

خیر. ❌

اتفاقاً در بسیاری از پروژه‌ها چنین کاری می‌تواند باعث شود RTM بیش از حد پیچیده و دشوار برای نگهداری شود.

7.10 RTM نباید به یک جدول غول‌پیکر تبدیل شود

هدف RTM این نیست که تمام اطلاعات پروژه را در یک جدول قرار دهیم.

اگر تیمی برای هر Requirement ده‌ها ستون اضافه کند، ممکن است بعد از مدتی کسی دیگر حوصله یا امکان به‌روزرسانی آن را نداشته باشد.

در نتیجه:

RTM پیچیده → نگهداری سخت → اطلاعات قدیمی → Traceability غیرقابل اعتماد

بنابراین یک اصل مهم وجود دارد:

RTM باید به اندازه‌ای اطلاعات داشته باشد که Traceability موردنیاز پروژه را پوشش دهد، نه بیشتر.

7.11 حداقل ستون‌های پیشنهادی

برای یک پروژه معمولی که هدف اصلی آن ردیابی Requirement و تست است، این ساختار می‌تواند کاملاً مناسب باشد:

Requirement ID	Requirement	Test Case ID	Test Result	Defect ID
REQ-001	ثبت‌نام	TC-001	Pass	—

اما اگر پروژه Agile باشد، ممکن است ساختار مناسب‌تر این باشد:

Requirement / Story	Acceptance Criteria	Test Case	Result	Defect
US-042	AC-01	TC-101	Pass	—

و در پروژه‌ای که Component Traceability اهمیت زیادی دارد، می‌توان Component را نیز اضافه کرد.

یک نکته مهم درباره RTM و ابزارها

در گذشته RTM اغلب با Excel ساخته می‌شد.

اما امروزه در بسیاری از تیم‌ها، این ارتباط‌ها مستقیماً در ابزارهای مدیریت Requirement، تست و Defect نگهداری می‌شوند.

مثلاً ممکن است ارتباط‌ها به شکل زیر باشند:

User Story → Test Case → Test Result → Defect

و ابزار به‌صورت خودکار Traceability را نمایش دهد.

بنابراین:

RTM الزاماً یک فایل Excel نیست.

Excel فقط یکی از روش‌های پیاده‌سازی آن است.

حالا که ساختار RTM را می‌شناسیم، وقت آن است که از جدول‌های تئوری فاصله بگیریم و همان پروژه فروشگاه اینترنتی را واقعاً وارد RTM کنیم. 🛒

8. مثال عملی ساخت RTM در یک پروژه واقعی 🛒🔗

تا اینجا بیشتر درباره RTM از زاویه مفهومی صحبت کردیم. اما واقعیت این است که RTM زمانی بهتر فهمیده می‌شود که آن را داخل یک پروژه ببینیم.

پس به همان مثال فروشگاه اینترنتی برگردیم.

فرض کنید تیم قرار است قابلیت جدیدی برای اعمال تخفیف روی سفارش‌ها پیاده‌سازی کند.

8.1 تعریف Requirement

REQ-015: اگر مبلغ سفارش کاربر بیشتر از ۵ میلیون تومان باشد، سیستم باید ۱۰٪ تخفیف روی مبلغ سفارش اعمال کند.

در این مرحله هنوز نمی‌دانیم دقیقاً چه Test Caseهایی خواهیم داشت، اما Requirement یک شناسه یکتا دارد: REQ-015.

8.2 تبدیل Requirement به User Story

در یک تیم Agile ممکن است همین نیازمندی به یک User Story تبدیل شود:

US-042: به‌عنوان یک مشتری، می‌خواهم برای سفارش‌های بالاتر از ۵ میلیون تومان تخفیف دریافت کنم تا بتوانم از مزایای خرید بیشتر استفاده کنم.

حالا یک ارتباط ایجاد شده است:

REQ-015 → US-042

8.3 تعریف Acceptance Criteria

• AC-01: اگر مبلغ سفارش کمتر یا مساوی ۵ میلیون تومان باشد، تخفیف اعمال نشود.
• AC-02: اگر مبلغ سفارش بیشتر از ۵ میلیون تومان باشد، ۱۰٪ تخفیف اعمال شود.
• AC-03: مبلغ تخفیف باید به‌درستی در مبلغ نهایی سفارش محاسبه شود.

حالا Traceability ما گسترده‌تر شده است:

REQ-015 → US-042 → AC-01 / AC-02 / AC-03

8.4 طراحی Test Scenario

QA بر اساس Acceptance Criteria یک Test Scenario طراحی می‌کند:

TS-010: بررسی اعمال تخفیف بر اساس مبلغ سفارش

8.5 طراحی Test Caseها 🧪

Test Case ID	سناریو	نتیجه مورد انتظار
TC-101	سفارش ۴ میلیون تومانی	تخفیف اعمال نشود
TC-102	سفارش دقیقاً ۵ میلیون تومانی	تخفیف اعمال نشود
TC-103	سفارش ۶ میلیون تومانی	۱۰٪ تخفیف اعمال شود
TC-104	سفارش ۱۰ میلیون تومانی	۱۰٪ تخفیف اعمال شود
TC-105	بررسی محاسبه مبلغ نهایی	مبلغ نهایی صحیح باشد

حالا رابطه مهم زیر شکل گرفته است:

REQ-015 → TC-101, TC-102, TC-103, TC-104, TC-105

8.6 اتصال Test Case به Component

فرض کنیم معماری سیستم شامل این بخش‌ها باشد:

• Order Service
• Discount Service
• Checkout Service

Test Case	Component
TC-101	Discount Service
TC-102	Discount Service
TC-103	Discount Service
TC-104	Discount Service
TC-105	Checkout Service

در نتیجه می‌توانیم Traceability را یک مرحله دیگر گسترش دهیم:

REQ-015 → Test Case → Component

8.7 اجرای تست‌ها

Test Case	Result
TC-101	Pass
TC-102	Pass
TC-103	Pass
TC-104	Fail
TC-105	Pass

در اینجا یک سؤال مهم ایجاد می‌شود:

چرا TC-104 Fail شده است؟

8.8 ثبت Defect 🐞

تستر بررسی می‌کند و متوجه می‌شود سیستم برای سفارش ۱۰ میلیون تومانی به جای ۱ میلیون تومان تخفیف، فقط ۵۰۰ هزار تومان تخفیف اعمال می‌کند.

BUG-087: محاسبه تخفیف برای سفارش‌های بالاتر از سقف مشخص، اشتباه انجام می‌شود.

حالا ارتباط‌ها به شکل زیر درآمده‌اند:

REQ-015 → TC-104 → BUG-087

8.9 RTM نهایی این Requirement

Req ID	User Story	Test Case	Component	Result	Defect
REQ-015	US-042	TC-101	Discount Service	Pass	—
REQ-015	US-042	TC-102	Discount Service	Pass	—
REQ-015	US-042	TC-103	Discount Service	Pass	—
REQ-015	US-042	TC-104	Discount Service	Fail	BUG-087
REQ-015	US-042	TC-105	Checkout Service	Pass	—

حالا فقط با نگاه کردن به این جدول می‌توانیم مسیر Requirement را دنبال کنیم:

REQ-015 → US-042 → TC-101 تا TC-105 → Discount / Checkout Service → Test Results → BUG-087

8.10 حالا Requirement تغییر می‌کند!

Product Owner چند روز بعد اعلام می‌کند:

«از این به بعد سفارش دقیقاً ۵ میلیون تومان هم باید شامل تخفیف شود.»

Requirement جدید:

REQ-015 – نسخه جدید: اگر مبلغ سفارش ۵ میلیون تومان یا بیشتر باشد، سیستم باید ۱۰٪ تخفیف اعمال کند.

حالا اولین چیزی که تیم QA باید بررسی کند این است:

کدام Test Caseها تحت تأثیر این تغییر هستند؟

از بین Test Caseهای مرتبط، TC-102 مستقیماً تحت تأثیر تغییر قرار گرفته است.

قبلاً:

سفارش دقیقاً ۵ میلیون تومان → بدون تخفیف

اکنون:

سفارش دقیقاً ۵ میلیون تومان → ۱۰٪ تخفیف

پس Test Case باید اصلاح شود.

8.11 RTM و Impact Analysis 🔍

با Traceability می‌توانیم بفهمیم:

REQ-015 تغییر کرده
↓
Test Caseهای مرتبط باید بررسی شوند
↓
TC-102 باید اصلاح شود
↓
Discount Service تحت تأثیر است
↓
Regression Testing باید بررسی شود

حتی BUG-087 نیز باید دوباره بررسی شود تا مشخص شود آیا با تغییر Requirement همچنان معتبر است یا خیر.

8.12 این مثال چه چیزی را نشان داد؟

در این مثال دیدیم که RTM می‌تواند در ساده‌ترین حالت فقط این رابطه را نشان دهد:

Requirement → Test Case

اما در یک پروژه واقعی‌تر می‌توان Traceability را گسترش داد:

Requirement → User Story → Acceptance Criteria → Test Scenario → Test Case → Component → Test Result → Defect

لازم نیست همه این روابط حتماً در یک جدول واحد قرار بگیرند. ممکن است سازمان برای Requirement ↔ Test Case یک RTM داشته باشد و ارتباط Test Case ↔ Component را در یک ماتریس یا ابزار دیگر مدیریت کند.

هدف اصلی این نیست که یک جدول بسیار بزرگ بسازیم؛ هدف این است که هر رابطه‌ای که برای مدیریت کیفیت، Coverage، تغییرات و Impact Analysis اهمیت دارد، قابل ردیابی باشد.

9. RTM و Test Coverage؛ آیا همه نیازمندی‌ها تست شده‌اند؟ 🧪📊

یکی از مهم‌ترین دلایلی که تیم‌های QA از RTM استفاده می‌کنند، بررسی Test Coverage است.

فرض کنید در یک پروژه ۵۰ Requirement داریم و تیم QA می‌گوید: «همه تست‌ها اجرا شده‌اند.» این جمله به‌تنهایی اطلاعات زیادی به ما نمی‌دهد.

ممکن است ۹۰٪ Test Caseها اجرا شده باشند، اما یکی از Requirementهای مهم اصلاً تست نشده باشد.

آیا Test Caseهای ما تمام Requirementهای موردنیاز را پوشش می‌دهند؟

9.1 Requirement Coverage چیست؟

به‌صورت ساده، Requirement Coverage نشان می‌دهد چه درصدی از Requirementها حداقل به یک Test Case مرتبط هستند.

Requirement	Test Case	Coverage
REQ-001	TC-001	✅
REQ-002	TC-002, TC-003	✅
REQ-003	TC-004	✅
REQ-004	—	❌
REQ-005	TC-005	✅
REQ-006	TC-006	✅
REQ-007	TC-007	✅
REQ-008	TC-008	✅
REQ-009	TC-009	✅
REQ-010	TC-010	✅

در این مثال، ۹ Requirement از ۱۰ Requirement حداقل یک Test Case دارند.

Requirement Coverage = تعداد Requirementهای دارای Test / تعداد کل Requirementها × 100

بنابراین Requirement Coverage برابر با 90% است.

9.2 Coverage صددرصدی یعنی نرم‌افزار بدون Bug است؟

خیر. ❌

اگر RTM نشان دهد 100% Requirement Coverage داریم، فقط یعنی برای Requirementهای موردنظر Test Case مرتبط تعریف شده است.

این موضوع تضمین نمی‌کند که همه Test Caseها Pass شده‌اند، هیچ Bugای وجود ندارد یا تمام حالات ممکن آزمایش شده‌اند.

بنابراین:

Coverage بالا لزوماً به معنی کیفیت بالای تست نیست.

9.3 Requirement بدون Test Case

یکی از مهم‌ترین چیزهایی که RTM می‌تواند نشان دهد، Requirementهایی هستند که هیچ Test Caseای ندارند.

REQ-025 → —

این وضعیت باید بررسی شود. ممکن است Requirement جدید باشد، Test Case هنوز طراحی نشده باشد، ارتباط ثبت نشده باشد یا Requirement نیاز به بازتعریف داشته باشد.

پس وجود یک خانه خالی همیشه به معنی Bug در فرآیند نیست؛ اما یک سیگنال برای بررسی است.

9.4 Test Case بدون Requirement

ردیابی باید در جهت مخالف نیز انجام شود.

TC-150 → —

این Test Case ممکن است مربوط به یک Requirement فنی، Security، Usability، Regression یا Exploratory Testing باشد. بنابراین نباید فوراً آن را حذف کنیم؛ ابتدا باید مشخص شود هدف Test Case چیست و آیا هنوز ارزش نگهداری دارد.

9.5 Test Coverage فقط یک عدد نیست

گاهی تیم‌ها بیش از حد روی عددی مانند 95% Coverage تمرکز می‌کنند.

اما سؤال مهم‌تر این است:

آن ۵٪ باقی‌مانده کدام Requirementها هستند؟

ممکن است آن ۵٪ شامل Requirementهای کم‌اهمیت باشد؛ اما ممکن است شامل یک Requirement بسیار حساس مربوط به Payment یا Security باشد.

به همین دلیل Coverage باید در کنار Risk، Priority و Business Importance تحلیل شود.

9.6 ارتباط RTM با Risk-Based Testing

فرض کنید سه Requirement داریم:

Requirement	اهمیت
REQ-001	نمایش رنگ پس‌زمینه
REQ-002	ورود کاربر
REQ-003	پرداخت آنلاین

هر سه Requirement ممکن است Coverage داشته باشند، اما نباید الزاماً برای هر سه دقیقاً به یک اندازه تست طراحی کنیم. REQ-003 – پرداخت آنلاین ریسک بسیار بالاتری دارد.

Req ID	Risk	Test Cases	Coverage
REQ-001	Low	TC-001	Covered
REQ-002	Medium	TC-002, TC-003	Covered
REQ-003	High	TC-004, TC-005, TC-006	Covered

9.7 Coverage در مراحل مختلف پروژه

Coverage می‌تواند در طول پروژه تغییر کند.

• ابتدای Sprint: 40%
• بعد از طراحی Test Caseها: 90%
• بعد از تکمیل طراحی: 100%

اما حتی در Coverage صددرصدی نیز ممکن است تست‌ها هنوز اجرا نشده باشند. بنابراین باید بین Requirement Coverage، Test Execution Status و Test Pass Rate تفاوت قائل شویم.

9.8 RTM به‌تنهایی معیار Release Readiness نیست

ممکن است کسی بگوید:

«RTM ما 100% است، پس پروژه آماده Release است.»

این نتیجه‌گیری درست نیست.

تصمیم Release به عوامل بیشتری وابسته است:

• Test Results
• Severity و Priority Defectها
• Risk
• Regression Testing
• Non-Functional Testing
• Acceptance Criteria
• Business Approval

RTM به تصمیم‌گیری کمک می‌کند؛ اما به‌تنهایی معیار Release Readiness نیست.

10. RTM و Defect Management؛ از Requirement تا Bug 🐞

تا اینجا دیدیم که RTM می‌تواند نشان دهد هر Requirement با چه Test Caseهایی ارتباط دارد و وضعیت اجرای آن‌ها چیست. اما در دنیای واقعی، تست همیشه با Pass تمام نمی‌شود.

گاهی Test Case Fail می‌شود و پشت آن یک Defect قرار دارد. Traceability می‌تواند ارتباط بین Requirement، Test Case و Defect را نیز مشخص کند.

10.1 وقتی یک Test Case Fail می‌شود چه اتفاقی می‌افتد؟

فرض کنیم:

REQ-030: کاربر باید بتواند با استفاده از Email و Password وارد حساب کاربری خود شود.

TC-201: ورود کاربر با Email و Password صحیح.

Expected Result: کاربر باید با موفقیت وارد حساب خود شود.

اما هنگام اجرای تست، سیستم با وجود اطلاعات صحیح خطای Invalid credentials نشان می‌دهد.

TC-201 → Fail

تستر پس از بررسی یک Defect ثبت می‌کند:

BUG-145: ورود کاربر با Credentialهای معتبر با خطای Invalid credentials مواجه می‌شود.

10.2 ایجاد زنجیره Traceability

REQ-030 → TC-201 → BUG-145

این زنجیره مشخص می‌کند Bug به کدام Requirement مربوط بوده و هنگام اجرای کدام Test Case شناسایی شده است.

10.3 آیا هر Fail یک Defect است؟

خیر. ❗

وقتی Test Case Fail می‌شود، الزاماً به این معنی نیست که یک Defect نرم‌افزاری پیدا شده است.

• Test Data اشتباه باشد.
• محیط تست مشکل داشته باشد.
• سرویس خارجی در دسترس نباشد.
• Configuration اشتباه باشد.
• Test Case قدیمی شده باشد.
• Requirement تغییر کرده باشد.
• مشکل در خود Test Automation باشد.

بنابراین فرآیند معمول می‌تواند این‌گونه باشد:

Test Case → Fail → Investigation → در صورت تأیید مشکل محصول → Defect

10.4 RTM و Retesting

فرض کنیم BUG-145 توسط Developer برطرف شده است. حالا QA باید Test Case مربوطه را دوباره اجرا کند.

TC-201 → Retest → Pass

و وضعیت Bug نیز می‌تواند به Closed تغییر کند.

بنابراین Traceability می‌تواند چرخه زیر را نشان دهد:

Requirement → Test Case → Failure → Defect → Fix → Retest → Pass

10.5 Requirement ↔ Defect و Test Case ↔ Defect

گاهی لازم است ارتباط مستقیم بین Requirement و Defect نیز ثبت شود:

REQ-030 → BUG-145

همچنین ارتباط Test Case و Defect می‌تواند برای Test Management مفید باشد:

TC-201 → BUG-145

این ارتباط‌ها کمک می‌کنند وضعیت Bug، تست و Requirement در کنار یکدیگر تحلیل شود.

با این حال، لازم نیست همه اطلاعات حتماً در یک جدول واحد قرار بگیرند. ممکن است RTM فقط Requirement ↔ Test Case را نگهداری کند و Defectها در Bug Tracker مدیریت شوند.

11. RTM، Change Management و Impact Analysis 🔍

یکی از مهم‌ترین ارزش‌های Traceability زمانی مشخص می‌شود که Requirement تغییر کند.

در پروژه‌های واقعی ممکن است Requirement جدید اضافه شود، حذف شود، متن آن تغییر کند، Acceptance Criteria تغییر کند یا یک قانون کسب‌وکار اصلاح شود.

11.1 یک تغییر کوچک که چند چیز را تحت تأثیر قرار می‌دهد

Requirement اولیه:

REQ-015: سفارش‌های بیشتر از ۵ میلیون تومان شامل ۱۰٪ تخفیف هستند.

بعد از مدتی Business تصمیم می‌گیرد قانون را تغییر دهد:

سفارش‌های ۵ میلیون تومان و بیشتر شامل ۱۰٪ تخفیف هستند.

به نظر می‌رسد فقط یک شرط تغییر کرده است، اما همین تغییر می‌تواند چند بخش را تحت تأثیر قرار دهد.

11.2 بدون Traceability چه اتفاقی می‌افتد؟

اگر Requirement در یک سند تغییر کند، تیم باید به‌صورت دستی پیدا کند کدام Test Caseها، Componentها و سایر Artefactها تحت تأثیر هستند. در پروژه‌های بزرگ این فرآیند می‌تواند زمان‌بر و مستعد خطا باشد.

11.3 با Traceability چه اتفاقی می‌افتد؟

اگر ارتباط‌ها به‌درستی ثبت شده باشند، مسیر بسیار روشن‌تر است:

REQ-015
↓
TC-101، TC-102، TC-103، TC-104
↓
Discount Service
↓
BUG-087

به این فرآیند Impact Analysis یا تحلیل تأثیر می‌گوییم؛ یعنی بررسی اینکه یک تغییر چه بخش‌هایی از سیستم، Requirementها، تست‌ها، Componentها یا سایر Artefactها را تحت تأثیر قرار می‌دهد.

11.4 RTM چگونه به Impact Analysis کمک می‌کند؟

با دنبال کردن Traceability می‌توانیم به این موارد برسیم:

REQ-015 → Acceptance Criteria → Test Scenarios → Test Cases → Components → Defects

حالا تیم می‌تواند برای هر مورد تصمیم بگیرد آیا باید تغییر کند، دوباره تست شود، Review شود یا در Regression Strategy قرار گیرد.

11.5 RTM و Regression Testing 🧪

فرض کنید Requirement مربوط به محاسبه تخفیف تغییر کرده است. تیم QA Test Caseهای مستقیم مرتبط را پیدا می‌کند؛ اما آیا فقط همان تست‌ها کافی هستند؟

لزومی ندارد. اگر Discount Service با Order Service و Checkout Service تعامل داشته باشد، تغییر ممکن است رفتار بخش‌های دیگر را نیز تحت تأثیر قرار دهد.

RTM نقطه شروع Impact Analysis است، اما جایگزین تحلیل فنی و Regression Strategy نمی‌شود.

11.6 RTM و Change Request

در پروژه‌های رسمی‌تر، تغییر Requirement ممکن است به شکل یک Change Request ثبت شود.

CR-024: تغییر قانون تخفیف از «بیشتر از ۵ میلیون» به «۵ میلیون و بیشتر».

حالا می‌توان Traceability زیر را داشت:

CR-024 → REQ-015 → TC-101 تا TC-104 → Discount Service

11.7 Impact Analysis فقط برای Test Case نیست

وقتی Requirement تغییر می‌کند، فقط Test Caseها را نباید بررسی کنیم. ممکن است موارد مختلفی تحت تأثیر قرار بگیرند:

Requirement → Design → Component → API → Test Case → Documentation → Defect

11.8 یک مثال دیگر؛ تغییر قانون Password

REQ-020: رمز عبور باید حداقل ۸ کاراکتر باشد.

• TC-201: رمز ۷ کاراکتری
• TC-202: رمز ۸ کاراکتری
• TC-203: رمز ۱۲ کاراکتری

حالا Requirement تغییر می‌کند:

رمز عبور باید حداقل ۱۲ کاراکتر باشد.

اگر Traceability داشته باشیم:

REQ-020 → TC-201، TC-202، TC-203

به‌سرعت متوجه می‌شویم که حداقل TC-202 و TC-203 باید بررسی شوند. اگر Component مربوط به Password Validation نیز مشخص باشد، محدوده تغییر بهتر قابل تحلیل خواهد بود.

11.9 Traceability؛ نقشه‌ای برای تغییرات

یکی از بهترین روش‌ها برای درک ارزش RTM این است که آن را یک نقشه ارتباطی در نظر بگیریم.

«اگر این نقطه تغییر کند، چه چیزهایی ممکن است تحت تأثیر قرار بگیرند؟»

RTM و سایر روابط Traceability کمک می‌کنند مسیرهای مرتبط را سریع‌تر پیدا کنیم. هرچه سیستم پیچیده‌تر و وابستگی بین بخش‌های مختلف بیشتر باشد، داشتن Traceability مناسب ارزش بیشتری پیدا می‌کند.

11.10 جمع‌بندی

RTM در Change Management می‌تواند برای سه سؤال مهم به تیم کمک کند:

1. چه چیزی تغییر کرده است؟
2. چه Artefactهایی به آن مرتبط هستند؟
3. کدام موارد باید بررسی، اصلاح یا دوباره تست شوند؟

اما RTM به‌تنهایی Impact Analysis کامل نیست؛ بلکه یکی از منابع مهم اطلاعاتی برای انجام آن است.

12. RTM در Agile و Scrum 🚀

وقتی صحبت از RTM می‌شود، بعضی‌ها تصور می‌کنند این مفهوم بیشتر مخصوص پروژه‌های سنتی و مستندمحور مانند Waterfall است. این تصور کاملاً درست نیست.

Traceability در Agile نیز اهمیت دارد؛ اما شکل پیاده‌سازی آن می‌تواند با پروژه‌های سنتی متفاوت باشد.

در یک پروژه Waterfall ممکن است با یک سند رسمی Requirement و یک فایل Excel به نام RTM مواجه شویم. اما در Agile، بسیاری از همین ارتباط‌ها ممکن است به‌صورت Link و Relationship داخل ابزارهای مدیریت پروژه و تست نگهداری شوند.

12.1 Traceability در Agile چه شکلی دارد؟

فرض کنیم در یک Sprint قرار است قابلیت بازیابی رمز عبور توسعه داده شود.

در Product Backlog یک User Story داریم:

US-042

به‌عنوان یک کاربر، می‌خواهم بتوانم رمز عبور خود را بازیابی کنم تا در صورت فراموش کردن Password بتوانم دوباره وارد حسابم شوم.

برای این User Story چند Acceptance Criteria تعریف می‌شود:

• کاربر بتواند یک Email معتبر وارد کند.
• لینک بازیابی به Email کاربر ارسال شود.
• لینک بازیابی فقط برای مدت مشخصی معتبر باشد.
• کاربر بتواند Password جدید تعیین کند.

حالا QA بر اساس این موارد Test Case طراحی می‌کند:

• TC-101
• TC-102
• TC-103
• TC-104

در نتیجه Traceability می‌تواند چنین مسیری داشته باشد:

User Story → Acceptance Criteria → Test Case 🧪

12.2 آیا در Agile باید حتماً RTM داشته باشیم؟

خیر.

Agile الزام نمی‌کند که حتماً یک فایل با نام RTM.xlsx داشته باشیم. آنچه اهمیت دارد، قابلیت ردیابی موردنیاز پروژه است.

ممکن است یک تیم Agile از ابزارهایی استفاده کند که ارتباط‌ها را به‌صورت مستقیم ثبت کنند:

Story → Test → Defect

در این حالت، Traceability وجود دارد؛ حتی اگر یک جدول Excel به نام RTM نداشته باشیم.

RTM یک الزام خاص Scrum نیست؛ Traceability مهم است و RTM یکی از روش‌های مدیریت آن است.

12.3 یک مثال از Traceability در Sprint

فرض کنیم US-042 – Password Recovery دارای چهار Acceptance Criteria است و QA برای آن پنج Test Case طراحی می‌کند:

User Story	Test Case	Result
US-042	TC-101	Pass
US-042	TC-102	Pass
US-042	TC-103	Fail
US-042	TC-104	Pass
US-042	TC-105	Pass

در این مثال، TC-103 Fail شده است. QA پس از بررسی، یک Defect با شناسه BUG-078 ثبت می‌کند.

اکنون Traceability به شکل زیر است:

US-042 → TC-103 → BUG-078

این زنجیره در یک تیم Agile کاملاً کاربردی است.

12.4 RTM در Agile ممکن است حول User Story شکل بگیرد

در پروژه‌های سنتی ممکن است ساختار اصلی Traceability به شکل زیر باشد:

Requirement → Test Case

اما در Agile، ممکن است ساختار عملی‌تر این باشد:

User Story → Test Case

یا:

User Story → Acceptance Criteria → Test Case

این تفاوت مهم است؛ زیرا در Agile، User Story معمولاً یکی از مهم‌ترین Artefactهای بیان نیازمندی است.

بنابراین اگر بخواهیم برای یک تیم Agile RTM طراحی کنیم، الزاماً نیازی نیست ستونی با عنوان Requirement Document ID داشته باشیم. در برخی پروژه‌ها ممکن است Story ID شناسه اصلی Traceability باشد.

12.5 RTM و Definition of Done

Traceability می‌تواند در بررسی Definition of Done نیز کمک‌کننده باشد.

فرض کنیم تیم برای تکمیل یک User Story این موارد را لازم می‌داند:

• Development Completed
• Code Review
• Test Case Completed
• Tests Passed
• Critical Defects Closed

در این شرایط، Traceability می‌تواند وضعیت Story را از جنبه تست روشن‌تر کند:

US-042

↓

Test Cases

↓

Test Results

↓

Defects

این اطلاعات به تیم کمک می‌کند پیش از Done اعلام کردن Story، وضعیت تست آن را بررسی کند.

البته Definition of Done در هر تیم می‌تواند متفاوت باشد و Traceability تنها یکی از منابع اطلاعاتی برای ارزیابی آن است.

12.6 Traceability در Sprintهای بعدی

حالا فرض کنیم در Sprint بعدی همین قابلیت تغییر می‌کند.

Product Owner اعلام می‌کند:

لینک Password Recovery باید بعد از ۱۰ دقیقه منقضی شود.

این تغییر ممکن است روی Test Caseهای قبلی اثر بگذارد.

اگر Traceability داشته باشیم:

US-042

↓

Acceptance Criteria

↓

TC-101 تا TC-105

می‌توانیم Test Caseهای تحت تأثیر را سریع‌تر پیدا کنیم.

بنابراین Traceability در Agile برای Change Impact Analysis نیز مفید است.

12.7 RTM در Agile و مفهوم Lightweight Documentation

یکی از اصول مهم Agile، جلوگیری از مستندسازی غیرضروری است.

بنابراین ساختن یک RTM بسیار بزرگ که کسی آن را به‌روزرسانی نمی‌کند، با رویکرد Agile سازگار نیست.

بهتر است:

به اندازه‌ای Traceability ایجاد کنیم که برای مدیریت کیفیت و ریسک پروژه ارزش ایجاد کند.

مثلاً در یک پروژه ساده، این رابطه ممکن است کافی باشد:

Story → Test Case

اما در یک پروژه حساس، ممکن است Traceability گسترده‌تری ارزش داشته باشد:

Story → Acceptance Criteria → Test Case → Test Result → Defect

12.8 RTM در Agile و Automation Testing

در تیم‌هایی که Automation Testing دارند، Traceability می‌تواند یک مرحله جلوتر برود.

مثلاً:

US-042

↓

TC-103

↓

Automated Test: password_reset_expired_link

↓

Test Result

این ارتباط کمک می‌کند مشخص شود کدام User Story توسط کدام Automated Test پوشش داده شده است.

البته نحوه پیاده‌سازی چنین Traceabilityای به ابزارها و فرآیند تیم بستگی دارد.

12.9 آیا RTM در Agile با Waterfall متفاوت است؟

بهتر است بگوییم اصل Traceability یکسان است، اما Artefactها و روش پیاده‌سازی آن ممکن است متفاوت باشد.

Waterfall	Agile
Requirement Document	User Story / Backlog Item
Requirement ID	Story ID
Test Case	Test Case
Defect	Defect
RTM Document	روابط داخل ابزارها یا ماتریس سبک
Change Request	Backlog / Story Change

بنابراین می‌توانیم دو زنجیره متفاوت داشته باشیم:

Waterfall:

Requirement → Test Case → Defect

Agile:

User Story → Acceptance Criteria → Test Case → Defect

هر دو در نهایت یک هدف دارند:

قابل ردیابی کردن ارتباط بین نیاز کسب‌وکار و فعالیت‌های توسعه و تست. 🔗

یک نکته مهم

نباید تصور کنیم که چون تیم Agile است، دیگر نیازی به Traceability ندارد.

برعکس، در پروژه‌های Agile به دلیل تغییرات مداوم Requirementها، داشتن Traceability مناسب می‌تواند بسیار ارزشمند باشد.

تفاوت اصلی این است که Traceability باید با روح Agile سازگار باشد:

ساده، به‌روز و ارزش‌آفرین.

نه یک فایل عظیم که فقط برای Audit ساخته شده و در عمل کسی از آن استفاده نمی‌کند.

13. RTM در پروژه‌های بزرگ و حساس 🏢🔗

تا اینجا RTM را بیشتر در قالب یک پروژه معمولی نرم‌افزاری دیدیم؛ جایی که رابطه اصلی بین Requirement و Test Case بود.

اما هرچه پروژه بزرگ‌تر، پیچیده‌تر یا حساس‌تر شود، تعداد ارتباط‌هایی که باید قابل ردیابی باشند نیز بیشتر می‌شود.

در چنین پروژه‌هایی ممکن است یک جدول ساده با چند ستون دیگر برای مدیریت Traceability کافی نباشد.

13.1 چرا پروژه‌های بزرگ به Traceability بیشتری نیاز دارند؟

فرض کنید یک سیستم بانکی در حال توسعه است.

یک Requirement ممکن است به بخش‌های مختلفی متصل باشد:

Requirement

↓

Business Rule

↓

User Story

↓

Design

↓

Component

↓

API

↓

Test Case

↓

Test Result

↓

Defect

حالا تصور کنید این سیستم هزاران Requirement و ده‌ها هزار Test Case داشته باشد.

اگر ارتباط بین این Artefactها مشخص نباشد، پاسخ دادن به سؤال‌هایی مانند:

«اگر این Requirement تغییر کند، چه چیزهایی تحت تأثیر قرار می‌گیرند؟»

بسیار دشوار می‌شود.

13.2 RTM در پروژه‌های حساس

در برخی حوزه‌ها مانند موارد زیر، Traceability معمولاً اهمیت بیشتری پیدا می‌کند:

• Banking
• Healthcare
• Aerospace
• Automotive
• Defense
• سیستم‌های صنعتی و کنترل

علت فقط Testing نیست.

در چنین پروژه‌هایی ممکن است سازمان لازم داشته باشد نشان دهد:

هر Requirement چگونه طراحی، پیاده‌سازی و Verification شده است؟

بنابراین Traceability ممکن است از سطح Requirement تا شواهد اجرای تست ادامه پیدا کند.

مثلاً:

REQ-100

↓

Design-025

↓

Component-C17

↓

TC-501

↓

Test Result

↓

Evidence

13.3 Traceability و Compliance

فرض کنید یک سیستم دارای یک الزام قانونی یا استانداردی است.

ممکن است سازمان نیاز داشته باشد ثابت کند که:

Requirement قانونی

↓

Implementation

↓

Verification Evidence

در چنین شرایطی Traceability فقط یک ابزار QA نیست، بلکه می‌تواند بخشی از Quality Assurance و Compliance سازمان باشد.

13.4 Traceability Matrix چندسطحی

در پروژه‌های بزرگ ممکن است به جای یک RTM بسیار بزرگ، چند Matrix مختلف داشته باشیم.

Requirements ↔ Design

نشان می‌دهد هر Requirement در کدام بخش طراحی پوشش داده شده است.

Requirements ↔ Components

نشان می‌دهد هر Requirement با کدام Componentها ارتباط دارد.

Requirements ↔ Test Cases

نشان می‌دهد هر Requirement چگونه Verification یا Validation می‌شود.

Test Cases ↔ Defects

نشان می‌دهد Failureهای تست چه Defectهایی ایجاد کرده‌اند.

در نتیجه، به جای یک جدول غول‌پیکر، چند رابطه مشخص و قابل مدیریت خواهیم داشت.

13.5 یک مثال چندلایه

فرض کنیم:

REQ-200:

سیستم باید تراکنش پرداخت را در کمتر از ۳ ثانیه پردازش کند.

این Requirement ممکن است به موارد زیر متصل شود:

REQ-200

↓

Performance Requirement

↓

Payment Service

↓

API-POST /payment

↓

PT-015 – Load Test

↓

Test Result

↓

BUG-301

حالا اگر Performance Requirement تغییر کند، Traceability کمک می‌کند مسیر احتمالی تأثیر را پیدا کنیم.

13.6 یک RTM یا چند Matrix؟

اینجا یک سؤال مهم مطرح می‌شود:

آیا بهتر است تمام این ارتباط‌ها را در یک RTM قرار دهیم؟

معمولاً نه لزوماً.

اگر همه چیز را در یک جدول قرار دهیم، ممکن است جدولی بسیار بزرگ با ستون‌هایی مانند موارد زیر ایجاد شود:

Requirement | User Story | Design | Component | API | Test Scenario | Test Case | Result | Defect | Evidence

در یک پروژه کوچک شاید چنین ساختاری قابل مدیریت باشد؛ اما در پروژه‌های بزرگ خیلی سریع به جدولی پیچیده و دشوار برای نگهداری تبدیل می‌شود.

راهکار بهتر می‌تواند استفاده از Traceability Relationships بین Artefactها باشد.

مثلاً:

• Requirement ↔ Design
• Requirement ↔ Test
• Test ↔ Defect

سپس ابزار مدیریت پروژه یا Test Management می‌تواند این ارتباط‌ها را در زمان موردنیاز نمایش دهد.

13.7 RTM به‌عنوان یک Graph

در پروژه‌های پیچیده حتی می‌توان RTM را نه فقط به‌عنوان یک جدول، بلکه به‌عنوان یک Graph تصور کرد. 🕸️

مثلاً:

                 ┌── Design
                 │
Requirement ─────┼── Component
                 │
                 ├── Test Case ─── Test Result
                 │
                 └── Defect

در این نگاه، هر Artefact یک Node است و ارتباط بین آن‌ها یک Relationship.

این مدل برای پروژه‌های بسیار پیچیده می‌تواند دید بهتری نسبت به یک جدول سنتی ایجاد کند.

13.8 Traceability و Audit

یکی دیگر از کاربردهای مهم Traceability در پروژه‌های حساس، Auditability است.

فرض کنید Auditor سؤال کند:

«برای این Requirement چه شواهدی دارید که نشان دهد سیستم آن را برآورده کرده است؟»

تیم می‌تواند مسیر را دنبال کند:

Requirement → Test Case → Test Execution → Test Result → Evidence

این قابلیت باعث می‌شود Traceability برای Audit بسیار ارزشمند باشد.

13.9 اما Traceability بیش از حد هم خطرناک است

یک نکته مهم وجود دارد:

هرچه Traceability بیشتر باشد، الزاماً بهتر نیست.

اگر تیم برای هر Artefact و هر Relationship مستندسازی اجباری ایجاد کند، هزینه نگهداری به‌شدت افزایش پیدا می‌کند.

مثلاً اگر برای یک پروژه ساده بخواهیم این موارد را به هم متصل کنیم:

Requirement → Story → Design → Class → Method → API → Test Case → Test Script → Test Result → Defect → Evidence

ممکن است هزینه نگهداری این اطلاعات از ارزش واقعی آن بیشتر شود.

بنابراین باید بین این دو تعادل ایجاد شود:

Traceability Value

در برابر:

Traceability Cost

13.10 یک سؤال کلیدی برای طراحی RTM

قبل از اینکه ستون یا Relationship جدیدی به RTM اضافه کنیم، بهتر است بپرسیم:

«این ارتباط قرار است چه تصمیم یا فعالیتی را بهتر کند؟»

اگر پاسخ مشخصی نداریم، احتمالاً آن Relationship ضرورتی ندارد.

مثلاً:

Requirement ↔ Test Case

هدف:

بررسی Test Coverage

این Relationship ارزشمند است. ✅

Requirement ↔ Defect

هدف:

Impact Analysis و تحلیل کیفیت

این Relationship نیز در بسیاری از پروژه‌ها می‌تواند ارزشمند باشد. ✅

اما اگر یک Relationship فقط برای پر کردن یک ستون ایجاد شده باشد و هیچ‌کس از آن استفاده نکند:

❌ احتمالاً ارزش نگهداری ندارد.

جمع‌بندی

در پروژه‌های کوچک ممکن است RTM فقط چنین چیزی باشد:

Requirement ↔ Test Case

اما در پروژه‌های بزرگ‌تر ممکن است Traceability گسترده‌تر شود:

Requirement ↔ Design ↔ Component ↔ Test ↔ Defect ↔ Evidence

با این حال، هدف اصلی همیشه یکی است:

بتوانیم مسیر یک نیازمندی را در طول چرخه عمر محصول دنبال کنیم و اثر تغییرات یا وضعیت Verification آن را بهتر بفهمیم.

14. چگونه یک RTM استاندارد و حرفه‌ای طراحی کنیم؟ 📋

حالا که با مفهوم Traceability، انواع ارتباط‌ها، Coverage، Defect و Impact Analysis آشنا شدیم، وقت آن است که یک RTM را واقعاً طراحی کنیم.

اما قبل از باز کردن Excel یا ابزار Test Management، یک سؤال مهم‌تر وجود دارد:

قرار است این RTM چه مشکلی را حل کند؟

اگر پاسخ این سؤال مشخص نباشد، احتمال زیادی دارد که در نهایت یک جدول بسیار بزرگ بسازیم که پر از ستون است، اما در عمل کسی از آن استفاده نمی‌کند.

14.1 ابتدا هدف RTM را مشخص کنید

قبل از طراحی RTM، مشخص کنید Traceability دقیقاً برای چه هدفی موردنیاز است.

مثلاً اگر هدف، بررسی Test Coverage باشد، رابطه اصلی می‌تواند به شکل زیر باشد:

Requirement → Test Case

اگر هدف، Impact Analysis باشد، ممکن است بخواهیم ارتباط زیر را نیز دنبال کنیم:

Requirement → Component → Test Case

و اگر هدف، Defect Traceability باشد، این زنجیره اهمیت بیشتری پیدا می‌کند:

Requirement → Test Case → Defect

بنابراین اولین اصل این است:

RTM را بر اساس هدف طراحی کنید، نه بر اساس تعداد ستون‌هایی که می‌توان به جدول اضافه کرد.

14.2 Artefactهای موردنیاز را مشخص کنید

در مرحله بعد باید مشخص کنیم چه Artefactهایی در پروژه وجود دارند و کدام‌یک برای Traceability ارزشمند هستند.

برای مثال:

• Requirement
• User Story
• Acceptance Criteria
• Test Scenario
• Test Case
• Component
• Test Result
• Defect

قرار نیست الزاماً همه این Artefactها وارد RTM شوند.

فقط مواردی را انتخاب کنید که برای Traceability پروژه ارزش واقعی ایجاد می‌کنند.

14.3 Relationshipها را مشخص کنید 🔗

حالا باید مشخص کنیم دقیقاً چه ارتباط‌هایی را می‌خواهیم ردیابی کنیم.

برای مثال:

Requirement ↔ Test Case

برای بررسی Test Coverage.

Requirement ↔ Component

برای Impact Analysis.

Test Case ↔ Defect

برای Defect Traceability.

User Story ↔ Acceptance Criteria

برای بررسی ارتباط Story با معیارهای پذیرش.

14.4 شناسه‌های یکتا ایجاد کنید

هر Artefact بهتر است یک شناسه مشخص و یکتا داشته باشد.

REQ-001
REQ-002

TC-001
TC-002

BUG-001
BUG-002

US-001
US-002

این کار باعث می‌شود به جای نوشتن توضیحات طولانی، Relationshipها را با IDها مشخص کنیم.

برای مثال:

REQ-001 → TC-001, TC-002

14.5 RTM را با Requirementها شروع کنید

فرض کنیم سه Requirement داریم:

ID	Requirement
REQ-001	کاربر بتواند ثبت‌نام کند
REQ-002	کاربر بتواند Login کند
REQ-003	کاربر بتواند Password خود را بازیابی کند

در این مرحله هنوز Test Caseها را اضافه نکرده‌ایم.

14.6 Test Caseها را به Requirementها متصل کنید

حالا Test Caseها را به Requirementهای مربوط متصل می‌کنیم:

Requirement	Test Case
REQ-001	TC-001, TC-002
REQ-002	TC-003, TC-004
REQ-003	TC-005, TC-006

در این مرحله یک سؤال مهم قابل پاسخ است:

آیا برای تمام Requirementها حداقل یک Test Case داریم؟

اگر مثلاً رابطه زیر وجود داشته باشد:

REQ-003 → —

باید آن Requirement را بررسی کنیم تا مشخص شود آیا واقعاً بدون پوشش تست باقی مانده است یا خیر.

14.7 Coverage را بررسی کنید

حالا می‌توانیم Requirement Coverage را بررسی کنیم.

فرض کنید:

20 Requirement

داریم و:

18 Requirement

حداقل یک Test Case دارند.

در این صورت:

Requirement Coverage = 90%

اما این عدد به‌تنهایی معیار کافی برای ارزیابی کیفیت نیست.

باید بررسی کنیم:

دو Requirement بدون Coverage کدام‌اند؟

اگر این دو مورد مثلاً:

• UI Theme
• Critical Payment Rule

باشند، اهمیت آن‌ها یکسان نیست.

بنابراین Coverage باید در کنار Risk و Priority تحلیل شود.

14.8 در صورت نیاز Component را اضافه کنید

اگر پروژه پیچیده‌تر باشد، می‌توانیم Component را نیز وارد Traceability کنیم.

Requirement	Test Case	Component
REQ-001	TC-001	User Service
REQ-002	TC-003	Auth Service
REQ-003	TC-005	Password Service

حالا می‌توانیم سؤال دیگری را پاسخ دهیم:

این Requirement یا Test Case با کدام بخش سیستم ارتباط دارد؟

این اطلاعات هنگام تغییر یک Component می‌تواند برای Impact Analysis مفید باشد.

14.9 Test Result را اضافه کنید

در صورت نیاز می‌توانیم نتیجه اجرای Test Case را نیز در Traceability ثبت کنیم:

Requirement	Test Case	Component	Result
REQ-001	TC-001	User Service	Pass
REQ-001	TC-002	User Service	Pass
REQ-002	TC-003	Auth Service	Fail
REQ-003	TC-005	Password Service	Pass

اکنون علاوه بر Coverage، می‌توانیم وضعیت اجرای Test Caseها را نیز مشاهده کنیم.

14.10 Defect را اضافه کنید

اگر TC-003 با Fail مواجه شود، ممکن است یک Defect مانند BUG-015 ثبت شود.

Requirement	Test Case	Result	Defect
REQ-002	TC-003	Fail	BUG-015

در نتیجه مسیر کامل‌تر می‌شود:

REQ-002 → TC-003 → BUG-015

14.11 یک RTM حرفه‌ای چه شکلی می‌تواند باشد؟

برای یک پروژه متوسط، ممکن است ساختار زیر مناسب باشد:

Req ID	Requirement	User Story	Test Case	Component	Result	Defect
REQ-001	Registration	US-001	TC-001	User Service	Pass	—
REQ-001	Registration	US-001	TC-002	User Service	Pass	—
REQ-002	Login	US-002	TC-003	Auth Service	Fail	BUG-015
REQ-003	Password Recovery	US-003	TC-004	Password Service	Pass	—

این جدول می‌تواند برای یک پروژه متوسط مناسب باشد؛ اما در پروژه‌های بزرگ بهتر است همه این روابط الزاماً در یک جدول واحد قرار نگیرند.

14.12 RTM را بیش از حد بزرگ نکنید

یکی از اشتباهات رایج این است که تصور کنیم:

هرچه ستون‌های بیشتری داشته باشیم، RTM حرفه‌ای‌تر است.

در واقع ممکن است نتیجه کاملاً برعکس باشد.

یک RTM با ۲۰ ستون که هیچ‌کس آن را به‌روز نمی‌کند، از یک RTM ساده با ۵ ستون که همیشه دقیق و به‌روز است، ارزش کمتری دارد.

بنابراین:

RTM خوب، RTMی است که واقعاً استفاده و نگهداری شود.

14.13 یک روش عملی برای انتخاب ستون‌ها

برای هر ستون این سؤال را بپرسید:

اگر این ستون وجود نداشته باشد، چه تصمیم یا کاری سخت‌تر می‌شود؟

مثلاً:

Test Case ID

بدون آن نمی‌توانیم Coverage را به‌درستی بررسی کنیم.

✅ نگه داریم.

Defect ID

برای Traceability بین تست و Bug مفید است.

✅ در صورت نیاز نگه داریم.

Component

برای Impact Analysis می‌تواند ارزشمند باشد.

✅ در پروژه‌های مناسب نگه داریم.

اما اگر ستونی فقط به این دلیل اضافه شده باشد که «شاید یک روز لازم شود»:

❌ احتمالاً بهتر است حذف شود.

14.14 RTM را به‌روز نگه دارید

آخرین و شاید مهم‌ترین اصل این است:

RTM فقط زمانی ارزش دارد که اطلاعات آن قابل اعتماد و به‌روز باشد.

اگر Requirement تغییر کند اما RTM تغییر نکند، Traceability دیگر قابل اعتماد نیست.

اگر Test Case حذف شود اما Relationship آن باقی بماند، اطلاعات نادرستی ایجاد می‌شود.

اگر وضعیت Defect در Traceability به‌روز نشود، گزارش پروژه ممکن است وضعیت واقعی را نشان ندهد.

پس RTM باید همراه با پروژه تکامل پیدا کند.

چک‌لیست طراحی RTM ✅

قبل از نهایی کردن RTM، این موارد را بررسی کنید:

• هدف RTM مشخص شده است.
• Requirementها ID یکتا دارند.
• Test Caseها ID یکتا دارند.
• Relationshipهای موردنیاز مشخص شده‌اند.
• Requirementهای بدون Test Case شناسایی می‌شوند.
• Test Caseهای بدون Requirement قابل بررسی هستند.
• در صورت نیاز Defectها Trace می‌شوند.
• در صورت نیاز Componentها Trace می‌شوند.
• Coverage قابل محاسبه است.
• RTM با تغییرات پروژه به‌روزرسانی می‌شود.
• ستون‌های غیرضروری حذف شده‌اند.

15. RTM را با چه ابزارهایی می‌توان ساخت؟ 🛠️

حالا که ساختار RTM را می‌شناسیم، یک سؤال عملی مطرح می‌شود:

برای ساخت RTM حتماً به یک ابزار تخصصی نیاز داریم؟

پاسخ کوتاه: خیر.

RTM می‌تواند از یک جدول ساده Excel شروع شود و در پروژه‌های بزرگ‌تر، به‌صورت Relationship بین Artefactهای مختلف در ابزارهای تخصصی مدیریت Requirements و Testing پیاده‌سازی شود.

انتخاب ابزار بیشتر به اندازه پروژه، پیچیدگی Traceability، تعداد اعضای تیم و فرآیند سازمان بستگی دارد.

15.1 Excel؛ ساده‌ترین نقطه شروع 📊

یکی از رایج‌ترین روش‌ها برای ساخت RTM استفاده از Excel است.

مثلاً:

Requirement ID	Requirement	Test Case ID	Result	Defect
REQ-001	Login	TC-001	Pass	—
REQ-002	Password Recovery	TC-002	Fail	BUG-015
REQ-003	Logout	TC-003	Pass	—

برای پروژه‌های کوچک و متوسط، این روش می‌تواند کاملاً کافی باشد.

مزایای Excel

• ساده است.
• تقریباً همه اعضای تیم با آن آشنا هستند.
• سریع قابل ایجاد است.
• نیاز به ابزار تخصصی ندارد.
• برای پروژه‌های کوچک هزینه اضافی ایجاد نمی‌کند.

اما Excel محدودیت‌هایی نیز دارد.

با افزایش تعداد Requirementها و Test Caseها:

• نگهداری سخت‌تر می‌شود.
• احتمال خطای انسانی افزایش پیدا می‌کند.
• مدیریت Relationshipها دشوارتر می‌شود.
• کنترل Versionها پیچیده‌تر می‌شود.
• همکاری هم‌زمان ممکن است دشوارتر شود.

بنابراین Excel برای همه پروژه‌ها بهترین انتخاب نیست.

15.2 Jira و ابزارهای مدیریت کار

در تیم‌های Agile، ممکن است Requirementها به شکل Epic، Story یا Task در ابزار مدیریت پروژه ثبت شوند.

Test Caseها نیز می‌توانند از طریق افزونه‌ها یا ابزارهای مرتبط مدیریت شوند.

در این حالت Traceability ممکن است چیزی شبیه این باشد:

Epic → User Story → Test Case → Test Result → Defect

مزیت این روش این است که Traceability می‌تواند در همان محیطی قرار بگیرد که تیم برای مدیریت Sprint و Development استفاده می‌کند.

اما باید توجه داشت که Jira به‌تنهایی الزاماً یک ابزار کامل Test Management یا Requirements Management نیست و امکانات Traceability آن به نحوه پیکربندی و ابزارهای متصل به آن بستگی دارد.

15.3 ابزارهای Test Management

در تیم‌های QA حرفه‌ای، ممکن است Test Caseها در ابزارهای تخصصی Test Management نگهداری شوند.

در چنین محیطی می‌توان Relationshipهایی مانند:

Requirement → Test Case

Test Case → Test Result

Test Case → Defect

را مدیریت کرد.

این ابزارها معمولاً امکاناتی برای گزارش‌گیری و بررسی Coverage نیز ارائه می‌کنند.

15.4 ابزارهای Requirements Management

در پروژه‌های بزرگ‌تر، ممکن است تمرکز اصلی روی Requirements Management باشد.

در چنین محیط‌هایی Traceability می‌تواند بین Artefactهای مختلف ایجاد شود:

Requirement → Design → Implementation → Test

این نوع ابزارها معمولاً برای پروژه‌هایی که تعداد Requirementها بسیار زیاد است و کنترل تغییرات اهمیت بالایی دارد، مناسب‌تر هستند.

15.5 Azure DevOps

در تیم‌هایی که از Azure DevOps استفاده می‌کنند، Work Itemها می‌توانند برای نمایش بخشی از Traceability مورد استفاده قرار بگیرند.

برای مثال:

Epic → Feature → User Story → Task

و در کنار آن Test Caseها و Defectها نیز می‌توانند به Work Itemهای مرتبط متصل شوند.

در چنین ساختاری، به جای اینکه همه روابط را دستی در یک Excel وارد کنیم، بخشی از Traceability داخل خود سیستم نگهداری می‌شود.

15.6 آیا ابزار، RTM را خودکار می‌کند؟

تا حد زیادی می‌تواند، اما نه به این معنی که ابزار خودش تصمیم می‌گیرد چه چیزی باید به چه چیزی متصل باشد.

این قسمت بسیار مهم است.

ابزار می‌تواند Relationshipها را ثبت و نمایش دهد.

اما اینکه:

REQ-015 باید به TC-103 متصل باشد.

یک تصمیم فرآیندی و تستی است که باید توسط تیم تعیین شود.

بنابراین:

Tool ≠ Traceability Strategy

ابزار فقط اجرای Traceability را ساده‌تر می‌کند.

15.7 Excel یا ابزار تخصصی؟ 🤔

می‌توانیم یک مقایسه ساده داشته باشیم:

ویژگی	Excel	ابزار تخصصی
شروع کار	بسیار ساده	نیازمند Setup
هزینه	معمولاً پایین	ممکن است بالا باشد
پروژه کوچک	✅ مناسب	گاهی بیش از نیاز
پروژه بزرگ	⚠️ دشوارتر	✅ مناسب‌تر
Relationshipهای پیچیده	محدود	بهتر
گزارش‌گیری	دستی‌تر	معمولاً پیشرفته‌تر
همکاری تیمی	محدودتر	معمولاً بهتر
Automation	محدود	بیشتر
Audit / History	محدودتر	معمولاً بهتر

بنابراین نمی‌توان گفت:

«ابزار تخصصی همیشه بهتر است.»

بلکه باید گفت:

ابزاری بهتر است که متناسب با پیچیدگی Traceability پروژه باشد.

15.8 یک اشتباه رایج در انتخاب ابزار

گاهی تیم‌ها ابتدا ابزار را انتخاب می‌کنند و بعد سعی می‌کنند فرآیند Traceability را با قابلیت‌های ابزار تطبیق دهند.

بهتر است مسیر برعکس باشد:

1. هدف Traceability را مشخص کنیم.
2. Artefactهای موردنیاز را مشخص کنیم.
3. Relationshipها را مشخص کنیم.
4. حجم و پیچیدگی پروژه را بررسی کنیم.
5. سپس ابزار مناسب را انتخاب کنیم.

این رویکرد می‌تواند از بسیاری از هزینه‌های غیرضروری جلوگیری کند.

15.9 RTM دستی یا خودکار؟

در پروژه‌های کوچک، ممکن است یک QA Engineer بتواند RTM را به‌صورت دستی مدیریت کند.

اما در پروژه‌های بزرگ، بهتر است تا حد امکان Traceability از طریق ابزارها و Integrationها مدیریت شود.

مثلاً:

Requirement ایجاد شد

⬇️

Test Case مرتبط ایجاد شد

⬇️

Test اجرا شد

⬇️

Defect ثبت شد

⬇️

Defect به Test و Requirement مرتبط شد

هرچه این ارتباط‌ها بیشتر به‌صورت سیستماتیک ثبت شوند، احتمال خطای انسانی کمتر می‌شود.

15.10 آیا RTM باید حتماً یک فایل جدا باشد؟

خیر.

این یکی از مهم‌ترین نکات درباره RTM است.

RTM می‌تواند:

• یک Excel Sheet باشد.
• بخشی از یک Test Management Tool باشد.
• بخشی از یک Requirements Management System باشد.
• مجموعه‌ای از Relationshipها در یک ALM/DevOps Platform باشد.
• یا حتی ترکیبی از چند سیستم باشد.

آنچه RTM را به یک ابزار Traceability تبدیل می‌کند، نام فایل یا ابزار نیست؛ بلکه وجود قابلیت Traceability بین Artefactهای مرتبط است.

جمع‌بندی

اگر پروژه کوچک است:

Excel می‌تواند کاملاً کافی باشد.

اگر تیم Agile متوسط دارید:

Jira / Azure DevOps + ابزار Test Management می‌تواند گزینه مناسب‌تری باشد.

اگر پروژه Enterprise و حساس دارید:

ممکن است به Requirements Management، Test Management و Traceability یکپارچه نیاز داشته باشید.

پس بهتر است قبل از خرید یا انتخاب ابزار از خودمان بپرسیم:

«چه مقدار Traceability واقعاً نیاز داریم؟»

نه اینکه:

«کدام ابزار امکانات بیشتری دارد؟»

16. اشتباهات رایج در طراحی و استفاده از RTM ⚠️

RTM در ظاهر فقط یک جدول است؛ چند شناسه، چند ستون و چند رابطه.

اما ساختن یک جدول آسان است. ساختن Traceability قابل اعتماد دشوارتر است.

در پروژه‌های واقعی، ممکن است RTM کاملاً پر باشد، اما وقتی Requirement تغییر می‌کند یا یک Bug مهم پیدا می‌شود، تیم نتواند از آن استفاده کند.

چرا؟

چون مشکل معمولاً خود جدول نیست؛ نحوه طراحی و نگهداری Traceability است.

بیایید مهم‌ترین اشتباه‌ها را بررسی کنیم.

16.1 تبدیل RTM به یک جدول غول‌پیکر 📋

اولین اشتباه این است که تصور کنیم:

«هرچه اطلاعات بیشتری داخل RTM باشد، RTM حرفه‌ای‌تر است.»

در نتیجه ممکن است جدولی با ۲۰ یا ۳۰ ستون ساخته شود:

Requirement → Story → Criteria → Design → Component → API → Test Scenario → Test Case → Script → Result → Defect → Environment → Evidence → …

مشکل اینجاست که نگهداری چنین جدولی بسیار دشوار می‌شود.

بعد از مدتی:

• اطلاعات به‌روز نمی‌شوند.
• بعضی ستون‌ها خالی می‌مانند.
• Relationshipها اشتباه می‌شوند.
• تیم دیگر به RTM اعتماد نمی‌کند.

بنابراین:

RTM باید به اندازه‌ای پیچیده باشد که نیاز پروژه را پوشش دهد، نه بیشتر.

16.2 ساختن RTM فقط برای Audit

گاهی RTM فقط به این دلیل ساخته می‌شود که:

«ممکن است Auditor آن را بخواهد.»

در نتیجه یک جدول بزرگ ایجاد می‌شود، چند روز اطلاعات آن وارد می‌شود و سپس کسی دیگر آن را به‌روزرسانی نمی‌کند.

این بدترین حالت ممکن است.

چون Traceability باید در طول پروژه ارزش عملیاتی داشته باشد.

اگر RTM بتواند به QA کمک کند:

• Coverage را بررسی کند.
• Impact Analysis انجام دهد.
• Test Caseهای مرتبط را پیدا کند.
• Defectها را Trace کند.

آن‌وقت واقعاً ارزشمند است.

16.3 به‌روزرسانی نکردن RTM 🔄

فرض کنید Requirement تغییر کرده است.

اما RTM همچنان نسخه قبلی را نشان می‌دهد.

یا یک Test Case حذف شده ولی Relationship آن همچنان در RTM باقی مانده است.

در این شرایط RTM حتی می‌تواند گمراه‌کننده‌تر از نداشتن RTM باشد.

چون تیم تصور می‌کند اطلاعات موجود صحیح است.

پس:

Traceability قدیمی، Traceability قابل اعتماد نیست.

16.4 اتصال هر Test Case به یک Requirement

گاهی یک اشتباه دیگر رخ می‌دهد:

«هر Test Case باید حتماً فقط به یک Requirement متصل باشد.»

این الزام عمومی وجود ندارد.

ممکن است یک Test Case چند Requirement را پوشش دهد.

مثلاً:

TC-050: بررسی فرآیند Checkout

ممکن است همزمان چند Requirement را پوشش دهد:

REQ-020 – محاسبه مبلغ

REQ-021 – اعمال تخفیف

REQ-022 – محاسبه مالیات

در این حالت رابطه می‌تواند Many-to-Many باشد.

یعنی:

یک Requirement → چند Test Case

و:

یک Test Case → چند Requirement

16.5 فرض کردن اینکه هر Requirement فقط یک Test Case دارد

این هم اشتباه مشابهی است.

یک Requirement مهم ممکن است ده‌ها Test Case داشته باشد.

مثلاً Requirement مربوط به Login:

• Login با اطلاعات صحیح
• Password اشتباه
• Email اشتباه
• فیلدهای خالی
• Account Locked
• Session Timeout
• SQL Injection
• محدودیت تعداد تلاش‌ها

پس:

REQ-001 → TC-001 … TC-020

کاملاً طبیعی است.

تعداد Test Caseها باید بر اساس ریسک، پیچیدگی و شرایط قابل تست Requirement تعیین شود، نه بر اساس یک نسبت ثابت.

16.6 یکی دانستن Coverage با کیفیت تست

فرض کنید RTM نشان می‌دهد:

Requirement Coverage = 100%

آیا یعنی تست عالی بوده است؟

خیر. ❌

ممکن است برای هر Requirement فقط یک Test Case بسیار ساده نوشته شده باشد.

مثلاً:

REQ-001 → TC-001

Coverage داریم.

اما شاید هیچ تست Negative، Boundary یا Security برای آن Requirement وجود نداشته باشد.

بنابراین:

Requirement Coverage نشان می‌دهد Requirementها Trace شده‌اند؛ نه اینکه تست‌ها لزوماً کافی یا باکیفیت هستند.

16.7 ثبت نکردن Requirementهای Non-Functional

گاهی RTM فقط برای Functional Requirements استفاده می‌شود.

مثلاً:

• Login
• Registration
• Payment
• Search

اما Requirementهای Non-Functional نیز ممکن است نیاز به Traceability داشته باشند:

Performance

Security

Availability

Accessibility

Usability

مثلاً:

سیستم باید بتواند حداقل ۱۰۰۰ درخواست در دقیقه را پردازش کند.

این Requirement هم باید بتواند به Test مربوطه Trace شود:

NFR-015 → PT-023

بنابراین RTM نباید بدون دلیل فقط به Functional Requirements محدود شود.

16.8 نادیده گرفتن Requirementهای بدون Test

REQ-100 → —

برخی تیم‌ها این خانه خالی را نادیده می‌گیرند.

در حالی که این می‌تواند یک هشدار مهم باشد.

باید بررسی کنیم:

چرا این Requirement Test Case ندارد؟

ممکن است:

• تست هنوز طراحی نشده باشد.
• Requirement جدید باشد.
• Test Case در ابزار دیگری باشد.
• Requirement قابل تست نباشد.
• Traceability ناقص باشد.

خود خانه خالی مشکل قطعی نیست؛ بی‌توجهی به آن مشکل است.

16.9 نادیده گرفتن Test Caseهای بدون Requirement

همین بررسی باید در جهت مخالف نیز انجام شود.

مثلاً:

TC-500 → —

این Test Case باید بررسی شود.

ممکن است دلیل منطقی داشته باشد؛ مثلاً یک تست فنی یا Security Test باشد.

اما اگر هیچ هدف مشخصی نداشته باشد، شاید یک Test Case قدیمی یا غیرضروری باشد.

این موضوع به Test Case Maintenance نیز کمک می‌کند.

16.10 اشتباه گرفتن RTM با Test Case Repository

RTM محل نگهداری تمام جزئیات Test Case نیست.

Test Case معمولاً اطلاعاتی مانند:

• Preconditions
• Test Data
• Steps
• Expected Result
• Actual Result

دارد.

اما RTM بیشتر روی Relationship تمرکز می‌کند.

یعنی:

این Requirement با کدام Test Case ارتباط دارد؟

پس:

RTM جایگزین Test Case Management نیست.

16.11 استفاده از IDهای نامنظم

فرض کنید Requirementها این‌طور باشند:

REQ1
requirement-2
R-03
Need-004
REQ-5

این کار مدیریت Traceability را دشوار می‌کند.

بهتر است یک Convention مشخص داشته باشیم:

REQ-001
REQ-002
REQ-003

TC-001
TC-002
TC-003

BUG-001
BUG-002

در پروژه‌های بزرگ ممکن است Naming Convention پیچیده‌تری استفاده شود، اما Consistency از پیچیدگی مهم‌تر است.

16.12 دستی نگه داشتن همه Relationshipها در پروژه‌های بزرگ

در پروژه‌ای با:

50 Requirement

و:

100 Test Case

مدیریت دستی شاید امکان‌پذیر باشد.

اما تصور کنید:

5,000 Requirement

و:

30,000 Test Case

داریم.

در این مقیاس، مدیریت دستی Relationshipها بسیار پرریسک است.

در چنین شرایطی بهتر است از ابزارهای تخصصی و Integrationها استفاده شود تا Traceability تا حد امکان سیستماتیک باشد.

16.13 تصور اینکه RTM همه چیز را حل می‌کند

این شاید مهم‌ترین اشتباه باشد.

RTM نمی‌تواند:

• Requirement بد را خوب کند.
• Test Case ضعیف را قوی کند.
• Bug را خودش پیدا کند.
• Impact Analysis را به‌طور کامل خودکار انجام دهد.
• کیفیت نرم‌افزار را تضمین کند.

RTM یک ابزار Traceability است.

ارزش آن زمانی مشخص می‌شود که تیم QA و سایر اعضای پروژه بتوانند از اطلاعات آن برای تصمیم‌گیری استفاده کنند.

چک‌لیست RTM خوب ✅

یک RTM خوب معمولاً:

• ساده و قابل فهم است.
• هدف مشخصی دارد.
• Relationshipهای ضروری را پوشش می‌دهد.
• IDهای یکتا دارد.
• به‌روز نگه داشته می‌شود.
• Requirementهای بدون Coverage را مشخص می‌کند.
• Test Caseهای بدون ارتباط را قابل شناسایی می‌کند.
• در صورت نیاز Defectها را Trace می‌کند.
• با Risk و Priority پروژه هماهنگ است.
• از اطلاعات غیرضروری پر نشده است.

و مهم‌تر از همه:

تیم واقعاً از آن استفاده می‌کند.

یک جمله برای به خاطر سپردن

RTM خوب، بزرگ‌ترین RTM نیست؛ قابل اعتمادترین RTM است. 🔗

حالا تقریباً تمام مفاهیم اصلی RTM را داریم.

در بخش بعد می‌توانیم یک موضوع بسیار مهم را بررسی کنیم:

RTM در برابر Requirement Traceability Matrix، Traceability، Test Coverage و Traceability Matrix؛ آیا این اصطلاحات واقعاً یکی هستند؟

این بخش کمک می‌کند تفاوت اصطلاحاتی را که در مقالات و ابزارهای مختلف می‌بینیم دقیقاً مشخص کنیم.

17. تفاوت RTM، Traceability و Traceability Matrix چیست؟ 🔗

در مقالات، مستندات و ابزارهای تست، اصطلاحات مختلفی مانند RTM، Requirement Traceability، Traceability، Traceability Matrix و Requirement Traceability Matrix را می‌بینیم.

گاهی این اصطلاحات به جای یکدیگر استفاده می‌شوند و همین موضوع می‌تواند باعث سردرگمی شود. بنابراین بهتر است تفاوت آن‌ها را دقیق‌تر مشخص کنیم.

17.1 Traceability چیست؟

Traceability یک مفهوم کلی است و به قابلیت دنبال کردن ارتباط بین یک Artefact و Artefact مرتبط دیگر اشاره دارد.

برای مثال، می‌توانیم ارتباط‌های زیر را داشته باشیم:

• Requirement → Test Case
• Test Case → Defect
• Requirement → Component

بنابراین Traceability الزاماً فقط به رابطه بین Requirement و Test Case محدود نمی‌شود. هدف کلی آن این است که بتوانیم ارتباط بین بخش‌های مختلف پروژه را ردیابی و دنبال کنیم.

17.2 Requirements Traceability چیست؟

Requirements Traceability به قابلیت دنبال کردن یک Requirement در طول چرخه عمر آن اشاره دارد.

برای مثال، ممکن است مسیر زیر را داشته باشیم:

Requirement → Design → Implementation → Test → Result

در اینجا سؤال اصلی این است:

این Requirement در بخش‌های مختلف پروژه چه سرنوشتی پیدا کرده است؟

17.3 Requirement Traceability Matrix چیست؟

Requirement Traceability Matrix یا RTM یکی از روش‌های نمایش و مدیریت Requirements Traceability است.

RTM معمولاً یک ساختار جدولی یا ماتریسی است که ارتباط بین Requirementها و Artefactهای مرتبط را نمایش می‌دهد.

Requirement ID	Test Case ID
REQ-001	TC-001
REQ-002	TC-002
REQ-003	TC-003

بنابراین می‌توان گفت:

Traceability یک مفهوم است؛ RTM یکی از روش‌های پیاده‌سازی و نمایش آن است.

17.4 Traceability Matrix چیست؟

Traceability Matrix اصطلاحی گسترده‌تر است و به ماتریسی اشاره دارد که برای نمایش Relationship بین Artefactهای مرتبط استفاده می‌شود.

برای مثال:

• Requirement ↔ Test Case می‌تواند یک Traceability Matrix باشد.
• Requirement ↔ Design نیز می‌تواند یک Traceability Matrix باشد.
• Test Case ↔ Defect نیز می‌تواند برای نمایش Traceability استفاده شود.

بنابراین هر Traceability Matrix الزاماً RTM نیست. با این حال، در فضای Software Testing وقتی افراد از عبارت RTM استفاده می‌کنند، معمولاً منظورشان Requirements Traceability Matrix است.

17.5 یک مثال ساده برای تفکیک مفاهیم

فرض کنید پروژه ما روابط زیر را دارد:

REQ-001 → TC-001
REQ-002 → TC-002
TC-002 → BUG-015
REQ-002 → Login Component

این مجموعه روابط بخشی از Traceability پروژه را تشکیل می‌دهد.

اگر همین روابط را در قالب یک جدول برای Requirementها سازمان‌دهی کنیم، می‌توانیم RTM داشته باشیم:

Requirement ID	Test Case ID	Component	Defect
REQ-001	TC-001	User Service	—
REQ-002	TC-002	Auth Service	BUG-015

17.6 RTM و Test Coverage یکی نیستند

RTM و Test Coverage نیز گاهی با یکدیگر اشتباه گرفته می‌شوند، در حالی که دو مفهوم متفاوت هستند.

RTM: رابطه بین Requirementها و Artefactهای مرتبط را نشان می‌دهد.

Test Coverage: میزان پوشش Requirementها یا سایر موارد موردنظر توسط تست‌ها را اندازه‌گیری می‌کند.

RTM می‌تواند برای محاسبه یا بررسی Coverage مورد استفاده قرار گیرد، اما:

RTM خودش Test Coverage نیست.

برای مثال، ممکن است از روی RTM به 100٪ Requirement Coverage برسیم، اما این عدد به‌تنهایی به معنی 100٪ کیفیت تست یا نبودن ریسک در محصول نیست.

17.7 RTM و Test Case Management یکی نیستند

RTM به ما می‌گوید که یک Requirement با کدام Test Caseها ارتباط دارد:

REQ-001 → TC-001, TC-002

اما Test Case Management جزئیات خود Test Caseها را مدیریت می‌کند؛ برای مثال:

• Preconditions
• Test Data
• Test Steps
• Expected Result
• Actual Result
• Status

بنابراین RTM و Test Case Repository دو مفهوم متفاوت هستند، هرچند ممکن است هر دو در یک ابزار مدیریت تست قرار داشته باشند.

17.8 RTM و Requirements Management نیز یکی نیستند

Requirements Management یک فرآیند گسترده‌تر است و فعالیت‌های مختلفی را شامل می‌شود، از جمله:

• ایجاد Requirement
• تحلیل Requirement
• اولویت‌بندی
• تأیید Requirement
• Versioning
• مدیریت تغییرات
• Traceability

RTM فقط یکی از Artefactها یا روش‌هایی است که می‌تواند در فرآیند Requirements Management مورد استفاده قرار گیرد.

17.9 یک تصویر ذهنی ساده 🧠

اگر بخواهیم این مفاهیم را ساده کنار هم قرار دهیم:

Requirements Management
↓
Requirements Traceability
↓
RTM / Traceability Matrix
↓
Coverage / Impact Analysis / Change Management

در این مدل، Requirements Management یک فرآیند گسترده است، Requirements Traceability یکی از قابلیت‌های مهم آن محسوب می‌شود و RTM یا Traceability Matrix می‌تواند یکی از روش‌های مدیریت و نمایش این روابط باشد.

17.10 پس وقتی در یک ابزار عبارت Traceability را می‌بینیم…

فرض کنید در یک ابزار Test Management گزینه‌ای با نام Traceability وجود دارد.

نباید انتظار داشته باشیم که این بخش الزاماً یک فایل Excel شبیه RTM به ما نشان دهد.

ممکن است ابزار به جای یک جدول، یک Graph یا Relationship View نمایش دهد:

Requirement ↔ Test Case ↔ Test Run ↔ Defect

در واقع ابزار همان مفهوم Traceability را با یک شکل متفاوت نمایش می‌دهد.

نکته مهم

برای جلوگیری از سردرگمی، این جمله را به خاطر بسپارید:

RTM یا Requirement Traceability Matrix، یکی از رایج‌ترین روش‌های نمایش و مدیریت Requirement Traceability است؛ اما Traceability مفهومی گسترده‌تر از یک جدول RTM دارد.

به همین دلیل، اگر بعداً در ابزارهایی مانند Jira، Azure DevOps یا ابزارهای Test Management با مفهوم Traceability مواجه شدید، نباید تصور کنید که حتماً باید یک جدول Excel با ساختار RTM وجود داشته باشد.

جمع‌بندی بخش 17

اصطلاح	مفهوم
Traceability	قابلیت ردیابی ارتباط بین Artefactها
Requirements Traceability	ردیابی Requirement در طول چرخه عمر
Traceability Matrix	ماتریس برای نمایش Relationshipها
RTM	معمولاً Requirement Traceability Matrix
Test Coverage	میزان پوشش موردنظر توسط تست
Requirements Management	فرآیند گسترده مدیریت Requirementها

در نتیجه، اگر کسی بپرسد RTM چیست؟ می‌توانیم پاسخ دهیم:

RTM یا Requirement Traceability Matrix، ماتریسی برای ثبت و نمایش ارتباط بین Requirementها و Artefactهای مرتبط پروژه، به‌ویژه Test Caseها، است تا بتوان Coverage، تغییرات و اثرات آن‌ها را بهتر ردیابی و تحلیل کرد.

18. ساخت یک RTM واقعی با مثال عملی 📊

حالا وقت آن است که مفاهیمی را که تا اینجا یاد گرفتیم، در یک مثال عملی کنار هم قرار دهیم.

فرض کنید در حال تست یک فروشگاه اینترنتی هستیم. تیم Business چند Requirement برای بخش‌های Login و Checkout تعریف کرده است.

هدف ما این است که ببینیم چگونه می‌توان بین Requirementها، Test Caseها، Componentها، Test Resultها و Defectها Traceability ایجاد کرد.

18.1 مرحله اول: تعریف Requirementها

ID	Requirement
REQ-001	کاربر باید بتواند با Email و Password معتبر وارد سیستم شود.
REQ-002	پس از ورود موفق، کاربر باید به Dashboard هدایت شود.
REQ-003	کاربر باید بتواند محصول را به سبد خرید اضافه کند.
REQ-004	سیستم باید برای سفارش‌های بالاتر از ۵ میلیون تومان ۱۰٪ تخفیف اعمال کند.

از همین ابتدا برای هر Requirement یک ID یکتا داریم. این ID در ادامه به عنوان نقطه اتصال سایر Artefactها استفاده می‌شود.

18.2 مرحله دوم: طراحی Test Caseها 🧪

حالا QA بر اساس Requirementها Test Case طراحی می‌کند.

برای REQ-001 دو Test Case داریم:

• TC-001: Login با Email و Password صحیح
• TC-002: Login با Password اشتباه

برای REQ-002:

• TC-003: بررسی Redirect بعد از Login موفق

برای REQ-003:

• TC-004: اضافه کردن محصول به Cart

برای REQ-004 سه Test Case داریم:

• TC-005: سفارش کمتر از ۵ میلیون تومان
• TC-006: سفارش دقیقاً ۵ میلیون تومان
• TC-007: سفارش بیشتر از ۵ میلیون تومان

حالا اولین Traceability شکل گرفته است:

REQ-001 → TC-001, TC-002
REQ-002 → TC-003
REQ-003 → TC-004
REQ-004 → TC-005, TC-006, TC-007

18.3 مرحله سوم: اضافه کردن Component

فرض کنیم معماری سیستم شامل Componentهای زیر است:

• Authentication Service
• User Service
• Cart Service
• Discount Service
• Order Service

حالا می‌توانیم Requirementها را به Componentهای مرتبط متصل کنیم.

Requirement	Component
REQ-001	Authentication Service
REQ-002	Authentication Service, User Service
REQ-003	Cart Service
REQ-004	Discount Service, Order Service

این ارتباط برای Impact Analysis بسیار مفید است.

برای مثال، اگر Discount Service تغییر کند، می‌توانیم سریع‌تر Requirementها و Test Caseهای مرتبط را پیدا کنیم.

18.4 مرحله چهارم: اجرای Test Caseها

حالا Test Caseها اجرا می‌شوند. فرض کنیم نتایج به شکل زیر باشند:

Test Case	Result
TC-001	Pass
TC-002	Pass
TC-003	Pass
TC-004	Pass
TC-005	Pass
TC-006	Fail
TC-007	Pass

در اینجا یک نکته مهم داریم: TC-006 مربوط به Requirement مربوط به تخفیف است و Fail شده است.

این Test Case بررسی می‌کند که برای سفارش دقیقاً ۵ میلیون تومان چه اتفاقی می‌افتد؛ بنابراین یک Boundary Value مهم در این Requirement محسوب می‌شود.

18.5 مرحله پنجم: ثبت Defect 🐞

QA بررسی می‌کند و متوجه می‌شود سیستم برای سفارش دقیقاً ۵ میلیون تومان تخفیف اعمال نمی‌کند.

بنابراین یک Defect با شناسه BUG-001 ثبت می‌شود.

عنوان: Discount is not applied when order amount is exactly 5,000,000

اکنون Relationship جدیدی داریم:

TC-006 → BUG-001

و چون TC-006 به REQ-004 مربوط است، زنجیره کامل‌تر می‌شود:

REQ-004 → TC-006 → BUG-001

18.6 مرحله ششم: ساخت RTM

حالا می‌توانیم بخشی از اطلاعات را در یک جدول RTM ترکیب کنیم:

Req ID	Requirement	Test Case	Component	Result	Defect
REQ-001	Login با اطلاعات معتبر	TC-001	Authentication Service	Pass	—
REQ-001	Login با Password اشتباه	TC-002	Authentication Service	Pass	—
REQ-002	Redirect به Dashboard	TC-003	Auth / User Service	Pass	—
REQ-003	افزودن محصول به Cart	TC-004	Cart Service	Pass	—
REQ-004	اعمال تخفیف ۱۰٪	TC-005	Discount / Order Service	Pass	—
REQ-004	تخفیف برای مبلغ دقیقاً ۵M	TC-006	Discount / Order Service	Fail	BUG-001
REQ-004	تخفیف برای مبلغ بیشتر از ۵M	TC-007	Discount / Order Service	Pass	—

این جدول یک نمونه عملی از RTM است؛ اما باید توجه داشته باشیم که این فقط یکی از شکل‌های ممکن RTM است.

هیچ قانون عمومی وجود ندارد که بگوید RTM باید دقیقاً همین ستون‌ها را داشته باشد. ساختار آن باید بر اساس هدف Traceability و نیازهای پروژه تعیین شود.

18.7 حالا چه اطلاعاتی می‌توانیم از RTM استخراج کنیم؟

اینجاست که RTM ارزش واقعی خود را نشان می‌دهد. 🔍

آیا تمام Requirementها تست شده‌اند؟

بله. هر چهار Requirement حداقل یک Test Case مرتبط دارند. بنابراین از نظر Requirement-to-Test Traceability، همه Requirementها دارای پوشش تست هستند.

کدام Requirement مشکل دارد؟

REQ-004، زیرا یکی از Test Caseهای آن یعنی TC-006 Fail شده و یک Defect نیز برای آن ثبت شده است.

Bug مربوط به کدام Requirement است؟

با دنبال کردن Relationship می‌توانیم مسیر زیر را ببینیم:

BUG-001 ← TC-006 ← REQ-004

بنابراین می‌توانیم BUG-001 را به REQ-004 نسبت دهیم.

این Requirement به کدام Component مربوط است؟

REQ-004 → Discount Service / Order Service

بنابراین اگر این Componentها تغییر کنند، تیم QA می‌تواند بررسی کند که کدام Requirementها و Test Caseها تحت تأثیر قرار می‌گیرند.

18.8 حالا Requirement تغییر می‌کند 🔄

فرض کنید Business تصمیم می‌گیرد قانون تخفیف را تغییر دهد.

قبلاً:

بیشتر از ۵ میلیون تومان → ۱۰٪ تخفیف

اکنون:

۵ میلیون تومان و بیشتر → ۱۰٪ تخفیف

با استفاده از Traceability می‌توانیم سریعاً به Test Caseهای مرتبط برسیم:

REQ-004 → TC-005, TC-006, TC-007

در اینجا مشخص می‌شود که TC-006 دقیقاً همان Boundary مهمی است که باید بررسی شود.

بعد از اصلاح سیستم، TC-006 دوباره اجرا می‌شود و نتیجه آن:

TC-006 → Pass

سپس BUG-001 نیز پس از Verification موفق می‌تواند بسته شود.

18.9 RTM نهایی بعد از Fix

Req ID	Test Case	Result	Defect
REQ-001	TC-001	Pass	—
REQ-001	TC-002	Pass	—
REQ-002	TC-003	Pass	—
REQ-003	TC-004	Pass	—
REQ-004	TC-005	Pass	—
REQ-004	TC-006	Pass	BUG-001 – Closed
REQ-004	TC-007	Pass	—

حالا مسیر کامل را داریم:

Requirement → Test Case → Test Result → Failure → Defect → Fix → Retest → Pass

این زنجیره نشان می‌دهد که Traceability فقط برای ایجاد یک جدول نیست؛ بلکه می‌تواند مسیر یک نیازمندی را از تعریف تا تست، ثبت مشکل و Verification مجدد قابل ردیابی کند.

18.10 یک نکته مهم درباره ساختار واقعی RTM

در مثال بالا همه اطلاعات را در یک جدول قرار دادیم تا مفهوم کاملاً قابل فهم باشد.

اما در یک پروژه واقعی ممکن است این اطلاعات در چند ابزار مختلف قرار داشته باشند:

• Requirement Management: برای Requirementها
• Test Management: برای Test Caseها و Test Execution
• Issue / Bug Tracking: برای Defectها

Relationship بین این Artefactها می‌تواند از طریق ID یا Link مدیریت شود.

بنابراین RTM الزاماً به معنی «یک فایل Excel که همه اطلاعات پروژه داخل آن باشد» نیست. در یک محیط حرفه‌ای، RTM می‌تواند در واقع یک Traceability View از اطلاعاتی باشد که در چند سیستم مختلف قرار دارند.

18.11 یک مدل ساده برای به خاطر سپردن

اگر بخواهیم مسیر اصلی را در ساده‌ترین شکل ممکن به خاطر بسپاریم:

Requirement
↓
Test Case
↓
Test Result
↓
Pass / Fail
↓
Defect
↓
Fix
↓
Retest
↓
Pass

و در کنار آن:

Requirement → Component

این دو مسیر در کنار یکدیگر به تیم کمک می‌کنند پاسخ دهد:

• چه چیزی باید ساخته شود؟
• کجا پیاده‌سازی شده است؟
• چگونه تست شده است؟
• آیا تست موفق بوده است؟
• اگر تست شکست خورده، چه Defectی ایجاد شده است؟
• آیا پس از اصلاح دوباره تست شده است؟

این همان قدرت واقعی Traceability است. 🔗

جمع‌بندی بخش 18

در یک RTM ساده می‌توانیم داشته باشیم:

Requirement ↔ Test Case

در یک RTM گسترده‌تر:

Requirement ↔ Test Case ↔ Test Result ↔ Defect

و در پروژه‌های پیچیده‌تر:

Requirement ↔ Design ↔ Component ↔ Test ↔ Defect ↔ Evidence

اما همیشه باید به یک اصل برگردیم:

هر Relationship باید دلیلی داشته باشد و برای پروژه ارزش ایجاد کند.

19. پیدا کردن Coverage Gap با استفاده از RTM 🔍

یکی از کاربردهای مهم RTM این است که فقط نشان نمی‌دهد چه چیزهایی به یکدیگر متصل هستند؛ بلکه می‌تواند جاهایی را نیز مشخص کند که نباید خالی باشند.

فرض کنید تیم پروژه ۵۰ Requirement دارد. همه تصور می‌کنند تست‌ها آماده‌اند و پروژه وضعیت خوبی دارد؛ اما وقتی RTM را بررسی می‌کنیم، متوجه می‌شویم برای ۴ Requirement حتی یک Test Case نیز وجود ندارد.

اینجاست که مفهوم Coverage Gap اهمیت پیدا می‌کند.

19.1 Coverage Gap چیست؟

Coverage Gap به وضعیتی گفته می‌شود که بخشی از نیازمندی‌ها یا محدوده موردنظر پروژه، پوشش تستی کافی یا مورد انتظار را ندارد.

برای مثال:

REQ-001 → TC-001
REQ-002 → TC-002, TC-003
REQ-003 → —
REQ-004 → TC-004

در اینجا REQ-003 هیچ Test Case مرتبطی ندارد. بنابراین یک Traceability Gap یا Coverage Gap داریم که باید بررسی شود.

19.2 Orphan Requirement چیست؟

اگر یک Requirement هیچ ارتباطی با Test Case نداشته باشد، ممکن است به آن Orphan Requirement گفته شود.

مثلاً:

REQ-003 → هیچ Test Caseی ندارد

این وضعیت می‌تواند یک هشدار باشد، اما الزاماً به معنی Bug یا مشکل قطعی نیست.

• Requirement تازه ایجاد شده باشد.
• هنوز در Scope تست قرار نگرفته باشد.
• Test Caseها در حال طراحی باشند.
• Requirement از نوعی باشد که روش Verification متفاوتی دارد.
• Relationship مربوط به آن هنوز ثبت نشده باشد.

بنابراین:

Orphan بودن یک Requirement یک Signal است که باید بررسی شود، نه اینکه لزوماً یک Defect باشد.

19.3 یک مثال از Coverage Gap

Requirement	Test Case
REQ-001	TC-001
REQ-002	TC-002
REQ-003	—
REQ-004	TC-004
REQ-005	—

در نگاه اول ممکن است تصور کنیم فقط دو Requirement مشکل دارند. اما باید سؤال کنیم:

آیا REQ-003 و REQ-005 واقعاً باید تست شوند؟

اگر پاسخ بله باشد، دو Coverage Gap داریم. اگر روش Verification دیگری برای آن‌ها تعریف شده باشد، ممکن است نبود Test Case در RTM کاملاً منطقی باشد.

19.4 Requirement Coverage

فرض کنید 100 Requirement داریم و از این تعداد، 95 Requirement حداقل یک Test Case مرتبط دارند.

در این حالت:

Requirement Coverage = 95%

این عدد می‌تواند برای گزارش وضعیت Traceability مفید باشد، اما نباید آن را با کیفیت کلی تست اشتباه گرفت.

95٪ Coverage به معنی 95٪ کیفیت نرم‌افزار نیست.

این عدد فقط نشان می‌دهد چه تعداد Requirement حداقل یک ارتباط با Test Case دارند.

19.5 Coverage ظاهری؛ وقتی Traceability کافی نیست

فرض کنید RTM این رابطه را نشان می‌دهد:

REQ-001 → TC-001 ✅

در نگاه اول Requirement پوشش داده شده است. اما Requirement می‌گوید:

کاربر باید بتواند با Email و Password معتبر وارد سیستم شود و در صورت پنج بار ورود ناموفق، حساب کاربری برای مدت ۳۰ دقیقه Lock شود.

در حالی که TC-001 فقط Login موفق را بررسی می‌کند.

در این شرایط، RTM از نظر Traceability یک ارتباط معتبر دارد، اما ممکن است Test Coverage واقعی Requirement کامل نباشد.

بنابراین باید بین Traceability Coverage و Test Coverage تمایز قائل شویم.

19.6 Test Caseهای Orphan

این بررسی را می‌توانیم برعکس نیز انجام دهیم.

فرض کنید:

REQ-001 → TC-001
REQ-002 → TC-002
REQ-003 → —

اما یک Test Case با شناسه TC-999 داریم که به هیچ Requirementای متصل نیست.

TC-999 → هیچ Requirementی ندارد

این Test Case نیز باید بررسی شود. ممکن است:

• یک تست فنی باشد.
• یک تست Exploratory باشد.
• برای Non-Functional Testing استفاده شود.
• Requirement مربوطه حذف شده باشد.
• Relationship آن ثبت نشده باشد.
• Test Case قدیمی باشد.

بنابراین Orphan Test Case نیز یک Signal برای بررسی است و لزوماً به معنی Test Case اشتباه نیست.

19.7 Traceability در هر دو جهت 🔄

یک RTM مناسب فقط نباید بتواند از Requirement به Test Case حرکت کند؛ بهتر است بتوانیم Relationship را در جهت مخالف نیز دنبال کنیم.

Forward Traceability

از Requirement به سمت Test حرکت می‌کنیم:

Requirement → Test Case

سؤال اصلی:

آیا این Requirement تست شده است؟

Backward Traceability

از Test Case به سمت Requirement حرکت می‌کنیم:

Test Case → Requirement

سؤال اصلی:

این Test Case دقیقاً برای چه نیازی طراحی شده است؟

19.8 Bidirectional Traceability

وقتی بتوانیم Relationship را در هر دو جهت دنبال کنیم، به مفهوم Bidirectional Traceability می‌رسیم.

یعنی:

Requirement ↔ Test Case

برای مثال، از REQ-010 می‌توانیم به Test Caseهای TC-021، TC-022 و TC-023 برسیم و از TC-022 نیز بتوانیم به REQ-010 برگردیم.

این قابلیت برای مدیریت تغییرات، بررسی Coverage و نگهداری Test Suite ارزشمند است.

19.9 Coverage فقط برای Requirement نیست

همین مفهوم را می‌توان برای سایر Artefactها نیز به کار برد:

• Requirement → Design: آیا Requirement در Design پوشش داده شده است؟
• Requirement → Component: آیا مشخص است Requirement در کدام Component پیاده‌سازی شده است؟
• Requirement → Test: آیا Requirement تست یا Verification شده است؟
• Test → Defect: آیا Failureهای تست به Defectهای مربوطه Trace شده‌اند؟

بنابراین Coverage بسته به هدف پروژه می‌تواند معناهای متفاوتی داشته باشد.

19.10 Coverage Gap و Risk 🎯

همه Coverage Gapها اهمیت یکسانی ندارند.

فرض کنید REQ-010 مربوط به تغییر رنگ یک دکمه باشد و REQ-011 مربوط به محاسبه مبلغ یک تراکنش بانکی. اگر هر دو Test Case نداشته باشند، از نظر تعداد دو Coverage Gap داریم؛ اما از نظر Risk وضعیت کاملاً متفاوت است.

بنابراین بهتر است Coverage را همراه با موارد زیر تحلیل کنیم:

• Priority
• Risk
• Business Impact

19.11 RTM و Risk-Based Testing

در یک رویکرد Risk-Based Testing، ممکن است Requirementهای High-Risk به Coverage و سناریوهای تست بیشتری نیاز داشته باشند.

Requirement	Risk	Test Cases
REQ-001	Low	1
REQ-002	Medium	3
REQ-003	High	10

در اینجا تعداد Test Caseها عمداً برابر نیست؛ زیرا Coverage مناسب لزوماً به معنی Coverage یکسان نیست.

Requirementهای پرریسک ممکن است به سناریوهای بیشتری برای پوشش ریسک‌های مختلف نیاز داشته باشند.

19.12 Coverage Gap در زمان Release

فرض کنید Release بعدی نزدیک است و مدیر QA می‌پرسد:

آیا تمام Requirementهای این Release پوشش تستی دارند؟

با RTM می‌توان فهرستی از Gapها استخراج کرد:

Release 2.5

REQ-101 → Covered
REQ-102 → Covered
REQ-103 → Covered
REQ-104 → NOT COVERED
REQ-105 → NOT COVERED

حالا تیم می‌تواند درباره این موارد تصمیم بگیرد:

• برای Requirementهای بدون Coverage، Test Case طراحی شود.
• Requirement از Scope Release خارج شود.
• ریسک مربوطه به‌صورت آگاهانه پذیرفته شود.
• در صورت اهمیت بالا، Release متوقف یا به تعویق انداخته شود.

بنابراین RTM می‌تواند به تصمیم‌گیری درباره Release نیز کمک کند.

19.13 RTM یک ابزار تصمیم‌گیری است

ارزش واقعی RTM فقط در این نیست که یک جدول مرتب داشته باشیم. ارزش آن زمانی مشخص می‌شود که بتوانیم از آن برای پاسخ دادن به سؤال‌های مهم QA استفاده کنیم:

• کدام Requirement هنوز تست نشده است؟
• کدام Test Case هیچ Requirementی ندارد؟
• کدام Requirement فقط Coverage ظاهری دارد؟
• کدام Requirementهای High-Risk Coverage کافی ندارند؟
• کدام Requirementها بعد از تغییر، نیاز به Regression Testing دارند؟

این قابلیت، RTM را از یک جدول ساده به ابزاری برای Quality Decision Making تبدیل می‌کند.

جمع‌بندی

• Requirement بدون Test Case → Coverage Gap / Orphan Requirement
• Test Case بدون Requirement → Orphan Test Case
• Requirement با Coverage ناکافی → Potential Coverage Gap
• Requirement High-Risk بدون Coverage مناسب → Risk-related Testing Gap

با استفاده از Bidirectional Traceability نیز می‌توان Relationshipها را از هر دو طرف بررسی کرد:

Requirement ↔ Test Case

20. RTM در مصاحبه شغلی QA؛ چه چیزهایی باید بلد باشیم؟ 🎯

اگر برای موقعیت QA Engineer یا Software Tester آماده می‌شوید، RTM یکی از مفاهیمی است که ممکن است در مصاحبه درباره آن سؤال شود.

اما معمولاً مصاحبه‌گر فقط به دنبال یک تعریف حفظ‌شده نیست. هدف این است که مشخص شود آیا واقعاً متوجه شده‌اید Traceability چه مشکلی را حل می‌کند و چگونه می‌توان از آن در یک پروژه واقعی استفاده کرد.

20.1 سؤال: RTM چیست؟

یک پاسخ خوب و کوتاه:

RTM یا Requirement Traceability Matrix، ماتریسی است که ارتباط بین Requirementها و Artefactهای مرتبط، به‌خصوص Test Caseها، را نشان می‌دهد تا بتوانیم پوشش نیازمندی‌ها، وضعیت تست و در صورت نیاز Defectها و سایر ارتباط‌ها را ردیابی کنیم.

اگر بخواهید پاسخ را کمی حرفه‌ای‌تر کنید، می‌توانید اضافه کنید:

RTM کمک می‌کند بتوانیم یک Requirement را از زمان تعریف تا Verification و در صورت نیاز تا Defect و Retest دنبال کنیم.

20.2 سؤال: هدف اصلی RTM چیست؟

پاسخ:

هدف اصلی RTM ایجاد Traceability بین Requirementها و فعالیت‌ها یا Artefactهای مرتبط است تا مطمئن شویم Requirementها پوشش داده شده‌اند و بتوانیم Coverage، Impact Analysis و وضعیت تست را بهتر بررسی کنیم.

نکته مهم این است که نگویید:

«هدف RTM این است که Test Caseها را ذخیره کنیم.»

چون RTM یک Test Case Repository نیست.

20.3 سؤال: رایج‌ترین Relationship در RTM چیست؟

پاسخ:

رایج‌ترین Relationship، ارتباط بین Requirement و Test Case است.

برای مثال:

REQ-001 → TC-001, TC-002

اما بسته به پروژه Relationshipهای دیگری نیز ممکن است وجود داشته باشند:

• Requirement ↔ User Story
• Requirement ↔ Design
• Requirement ↔ Component
• Requirement ↔ Test Case
• Test Case ↔ Test Result
• Test Case ↔ Defect

20.4 سؤال: آیا RTM فقط Requirement و Test Case را شامل می‌شود؟

خیر.

RTM در ساده‌ترین شکل معمولاً Requirement و Test Case را به هم مرتبط می‌کند، اما Traceability می‌تواند بسته به نیاز پروژه به Component، Design، Test Result، Defect و سایر Artefactها نیز گسترش پیدا کند.

این پاسخ دقیق‌تر از این است که بگوییم «RTM فقط Requirement و Test Case است»، زیرا مفهوم Traceability گسترده‌تر از این رابطه است.

20.5 سؤال: Forward و Backward Traceability چیست؟

Forward Traceability

از Requirement به سمت Test می‌رویم:

Requirement → Test Case

سؤال اصلی:

آیا تمام Requirementها تست شده‌اند؟

Backward Traceability

از Test Case به سمت Requirement می‌رویم:

Test Case → Requirement

سؤال اصلی:

این Test Case برای کدام Requirement طراحی شده است؟

اگر هر دو جهت را داشته باشیم:

Bidirectional Traceability: Requirement ↔ Test Case

این مدل برای کنترل Coverage و جلوگیری از Test Caseهای بدون هدف بسیار مفید است.

20.6 سؤال: اگر Requirement هیچ Test Caseی نداشته باشد چه می‌کنید؟

پاسخ حرفه‌ای این نیست که فوراً بگویید «Requirement مشکل دارد».

بهتر است بگویید:

ابتدا بررسی می‌کنم که آیا Requirement واقعاً در Scope تست قرار دارد و آیا روش Verification دیگری برای آن تعریف شده است. اگر باید تست شود اما Test Case ندارد، آن را به عنوان یک Coverage Gap بررسی می‌کنم.

این پاسخ نشان می‌دهد که شما صرفاً جدول را پر نمی‌کنید؛ بلکه وضعیت را تحلیل می‌کنید.

20.7 سؤال: اگر Test Case هیچ Requirementی نداشته باشد چه؟

پاسخ:

بررسی می‌کنم Test Case برای چه هدفی ایجاد شده است. ممکن است یک تست فنی، Exploratory، Security یا Non-Functional باشد؛ یا ممکن است Relationship آن ثبت نشده یا Requirement مربوطه حذف شده باشد.

پس:

Orphan Test Case ≠ همیشه Test Case اشتباه

20.8 سؤال: آیا 100٪ Requirement Coverage یعنی نرم‌افزار کاملاً تست شده است؟

خیر. ❌

100٪ Requirement Coverage فقط نشان می‌دهد Requirementها حداقل یک ارتباط با Test Case دارند. این موضوع تضمین نمی‌کند که Test Caseها از نظر سناریوهای مثبت، منفی، Boundary، Security، Performance و سایر جنبه‌ها کافی باشند.

مثلاً:

REQ-001 → TC-001

از نظر Traceability Coverage پوشش داریم، اما ممکن است TC-001 فقط یک Happy Path را تست کند.

20.9 سؤال: آیا یک Requirement می‌تواند چند Test Case داشته باشد؟

بله. این حالت بسیار رایج است.

REQ-001
   ├── TC-001 Login موفق
   ├── TC-002 Password اشتباه
   ├── TC-003 Email اشتباه
   ├── TC-004 فیلد خالی
   └── TC-005 Account Locked

بنابراین رابطه One-to-Many کاملاً طبیعی است.

20.10 آیا یک Test Case می‌تواند چند Requirement را پوشش دهد؟

بله.

برای مثال یک Test Case مربوط به Checkout ممکن است همزمان چند Requirement را Verification کند:

TC-100
  → REQ-020
  → REQ-021
  → REQ-022

بنابراین Relationship می‌تواند Many-to-Many نیز باشد.

20.11 سؤال: RTM در Agile کاربرد دارد؟

بله. Traceability در Agile نیز کاربرد دارد، اما لزوماً به شکل یک فایل رسمی RTM نیست.

ممکن است ارتباط بین User Story، Acceptance Criteria، Test Case و Defect در ابزارهای مدیریت پروژه و Test Management نگهداری شود.

مثلاً:

US-042 → Acceptance Criteria → TC-103 → BUG-078

بنابراین:

Agile بودن پروژه به معنی حذف Traceability نیست.

20.12 سؤال: آیا RTM حتماً باید در Excel باشد؟

خیر.

RTM می‌تواند:

• در Excel پیاده‌سازی شود.
• در Test Management Tool مدیریت شود.
• در Requirements Management Tool قرار داشته باشد.
• از Relationshipهای بین Work Itemها در یک ALM یا DevOps Platform تشکیل شود.

نکته اصلی:

RTM یک مفهوم Traceability است، نه یک فرمت فایل خاص.

20.13 سؤال: اگر Requirement تغییر کند، RTM چه کمکی می‌کند؟

اینجا باید مفهوم Impact Analysis را وارد پاسخ کنید.

مثلاً:

REQ-015 تغییر کرده است.

از طریق Traceability می‌توانیم پیدا کنیم:

REQ-015
   → TC-101
   → TC-102
   → TC-103
   → Discount Component

سپس بررسی کنیم کدام Test Caseها باید:

• اصلاح شوند.
• دوباره اجرا شوند.
• در Regression Testing قرار بگیرند.

بنابراین:

RTM می‌تواند یکی از منابع مهم اطلاعات برای Impact Analysis باشد.

20.14 سؤال: آیا هر Test Case Fail شده باید یک Defect ایجاد کند؟

خیر.

وقتی Test Case Fail می‌شود، ابتدا باید علت Failure مشخص شود.

• Software Defect
• مشکل در Environment
• اشتباه در Test Data
• Configuration اشتباه
• Test Case قدیمی یا نادرست
• تغییر Requirement
• مشکل در Test Automation

بنابراین:

Fail ≠ Automatically Defect

ابتدا Investigation انجام می‌شود و سپس در صورت تأیید وجود نقص، Defect ثبت خواهد شد.

20.15 سؤال سناریویی 🎯

مصاحبه‌گر می‌گوید:

یک Requirement داریم که ۱۰ Test Case برای آن تعریف شده است. ۸ تست Pass و ۲ تست Fail شده‌اند. شما از RTM چه اطلاعاتی استخراج می‌کنید؟

یک پاسخ خوب:

ابتدا بررسی می‌کنم دو Test Case Fail شده کدام هستند و آیا برای آن‌ها Defect ثبت شده است. سپس Severity و Priority Defectها را بررسی می‌کنم و مشخص می‌کنم Requirement در چه وضعیتی قرار دارد. همچنین بررسی می‌کنم آیا Failureها به یک Component خاص مربوط هستند و آیا برای Release یا Regression Testing تأثیری دارند.

این پاسخ نشان می‌دهد شما RTM را صرفاً یک جدول نمی‌بینید، بلکه از آن برای تصمیم‌گیری QA استفاده می‌کنید.

20.16 سؤال سخت‌تر: آیا RTM برای هر پروژه ضروری است؟

پاسخ بهتر این است:

Traceability می‌تواند بسیار ارزشمند باشد، اما شکل و سطح آن باید متناسب با پروژه باشد.

در یک پروژه کوچک ممکن است:

Requirement → Test Case

کافی باشد.

در یک پروژه Enterprise ممکن است نیاز داشته باشیم:

Requirement → Design → Component → Test → Defect → Evidence

بنابراین نباید یک مدل یکسان را برای همه پروژه‌ها تحمیل کرد.

20.17 اگر در مصاحبه فقط یک نکته درباره RTM بخواهید بگویید…

این جمله را به خاطر بسپارید:

RTM به ما کمک می‌کند بدانیم هر Requirement کجا پوشش داده شده، چگونه Verification شده و در صورت نیاز چه Artefactها یا مشکلاتی به آن مرتبط هستند.

و اگر بخواهید یک مثال بزنید:

REQ-001 → TC-001 → Pass

یا:

REQ-002 → TC-005 → Fail → BUG-015

همین مثال ساده می‌تواند بخش بزرگی از مفهوم RTM را منتقل کند. 🔗

جمع‌بندی

برای مصاحبه QA بهتر است این مفاهیم را درباره RTM به‌خوبی بلد باشید:

• RTM چیست؟
• هدف RTM چیست؟
• Requirement ↔ Test Case
• Forward Traceability
• Backward Traceability
• Bidirectional Traceability
• Coverage Gap
• Orphan Requirement
• Requirement ↔ Defect
• Impact Analysis
• RTM در Agile
• RTM در Excel و ابزارهای تخصصی
• تفاوت Coverage با کیفیت تست
• رابطه Fail و Defect

اما یک موضوع مهم دیگر باقی می‌ماند:

آیا RTM در تست‌های مختلف مثل Functional، API، Performance، Security و Accessibility هم کاربرد دارد؟

در بخش بعد بررسی می‌کنیم که آیا Traceability فقط برای Functional Testing است یا می‌توان آن را به انواع مختلف Testing نیز گسترش داد. 🧪🔗

“`html

21. RTM در انواع مختلف تست؛ فقط برای Functional Testing نیست 🧪🔗

وقتی صحبت از RTM می‌شود، معمولاً اولین چیزی که به ذهن می‌رسد این است:

Requirement → Test Case

و Test Case هم معمولاً یک سناریوی Functional است.

اما Traceability محدود به Functional Testing نیست.

هر Requirementی که قابل Verification یا Validation باشد، می‌تواند با روش تست یا شواهد مناسب به Traceability متصل شود.

21.1 RTM در Functional Testing

این رایج‌ترین حالت است.

فرض کنیم Requirement داریم:

کاربر باید بتواند محصول را به سبد خرید اضافه کند.

Traceability:

REQ-101 → TC-201

و Test Case:

Add product to cart

پس:

Requirement → Functional Test Case

21.2 RTM در API Testing 🔌

فرض کنیم Requirement می‌گوید:

سیستم باید امکان دریافت اطلاعات پروفایل کاربر را فراهم کند.

این Requirement ممکن است به یک API متصل باشد:

GET /api/profile

و تست‌های API زیر برای آن طراحی شوند:

• Status Code
• Response Body
• Authentication
• Authorization
• Invalid Token
• Missing Parameters

بنابراین Traceability می‌تواند چنین باشد:

REQ-102

↓

Profile API

↓

API-TC-015

یعنی لازم نیست Test Case حتماً یک تست UI باشد.

21.3 RTM در Performance Testing ⚡

فرض کنیم Requirement زیر را داریم:

سیستم باید درخواست‌های Search را در شرایط عادی با Response Time کمتر از ۲ ثانیه پاسخ دهد.

این Requirement یک Non-Functional Requirement است.

بنابراین ممکن است Traceability به Performance Test متصل شود:

NFR-015 → Performance Test PT-010 → Test Result

مثلاً:

Average Response Time = 1.4s

پس:

NFR → Performance Test

یکی از کاربردهای مهم Traceability است.

21.4 RTM در Security Testing 🔐

فرض کنیم Requirement می‌گوید:

کاربر بدون احراز هویت نباید بتواند اطلاعات حساب سایر کاربران را مشاهده کند.

این Requirement می‌تواند به Security Testهایی متصل شود:

• SEC-TC-021: Access without authentication
• SEC-TC-022: Access another user’s data
• SEC-TC-023: Authorization bypass

در نتیجه:

REQ-SEC-005 → SEC-TC-021 → SEC-TC-022 → SEC-TC-023

اگر یکی از تست‌ها Fail شود، ممکن است Defect نیز ایجاد شود:

REQ-SEC-005 → SEC-TC-022 → BUG-301

21.5 RTM در Accessibility Testing ♿

Accessibility نیز می‌تواند Requirementهای قابل ردیابی داشته باشد.

مثلاً:

تمام قابلیت‌های اصلی سیستم باید با Keyboard قابل استفاده باشند.

یا:

عناصر Interactive باید دارای نام قابل تشخیص برای فناوری‌های کمکی باشند.

حالا می‌توانیم داشته باشیم:

NFR-020 → Accessibility Test → Test Result

این موضوع به‌خصوص در پروژه‌هایی که Accessibility Requirement رسمی دارند اهمیت پیدا می‌کند.

21.6 RTM در Compatibility Testing

فرض کنیم Requirement می‌گوید:

سیستم باید در Browserهای پشتیبانی‌شده عملکرد صحیح داشته باشد.

حالا ممکن است Test Caseها روی ترکیب‌های مختلف اجرا شوند:

• Chrome
• Firefox
• Edge
• Safari

و حتی:

• Windows
• macOS
• Android
• iOS

در نتیجه:

REQ-025 → Compatibility Test Cases → Browser / OS → Test Results

Traceability به ما کمک می‌کند بفهمیم کدام Requirement روی چه محیط‌هایی Verification شده است.

21.7 RTM در Mobile Testing 📱

در اپلیکیشن موبایل نیز می‌توان Traceability داشت.

مثلاً:

REQ-030: کاربر باید بتواند Push Notification دریافت کند.

این Requirement ممکن است به Test Caseهای مختلف متصل شود:

• Android
• iOS
• Permission Granted
• Permission Denied
• App in Background
• App Terminated

بنابراین یک Requirement ممکن است تعداد زیادی Test Case داشته باشد.

21.8 RTM در Regression Testing

یکی از کاربردهای مهم Traceability در Regression Testing است.

فرض کنید یک Requirement تغییر کرده:

REQ-040

با Traceability می‌توانیم Test Caseهای مرتبط را پیدا کنیم:

REQ-040 → TC-101 → TC-102 → TC-103

سپس بررسی می‌کنیم کدام Test Caseها باید دوباره اجرا شوند.

اگر Component نیز مشخص باشد:

REQ-040 → Payment Service

می‌توانیم دامنه Regression را بهتر تحلیل کنیم.

البته RTM به‌تنهایی تعیین نمی‌کند کل Regression Suite چیست؛ بلکه یکی از ورودی‌های تصمیم‌گیری است.

21.9 RTM در Exploratory Testing

اینجا موضوع کمی متفاوت می‌شود.

Exploratory Testing الزاماً از قبل Test Caseهای کاملاً تعریف‌شده ندارد.

بنابراین نمی‌توان همیشه انتظار داشت:

Requirement → Test Case

به شکل سنتی وجود داشته باشد.

ممکن است Traceability از Requirement به موارد دیگری برقرار شود:

Requirement → Test Charter → Session → Findings

مثلاً:

REQ-050 → Exploratory Charter EC-05 → Session S-12 → BUG-405

این مدل نشان می‌دهد Traceability لزوماً به معنی «Requirement به Test Case رسمی» نیست.

21.10 RTM در Automation Testing 🤖

در Automation Testing نیز Traceability می‌تواند وجود داشته باشد.

مثلاً:

REQ-060 → TC-201 → Automated Test: login_valid_credentials → Execution Result

این ارتباط به تیم کمک می‌کند بفهمد:

کدام Requirement توسط Automated Test پوشش داده شده است؟

در پروژه‌های بزرگ‌تر حتی می‌توان وضعیت Automation Coverage را نیز بررسی کرد.

Requirement	Test Case	Automation
REQ-001	TC-001	Automated
REQ-002	TC-002	Manual
REQ-003	TC-003	Automated

اما باید دقت کنیم:

Automation Coverage با Requirement Coverage یکی نیست.

ممکن است یک Requirement Coverage داشته باشد، اما Test آن Manual باشد.

21.11 RTM در Integration Testing

فرض کنیم Requirement می‌گوید:

پس از پرداخت موفق، سیستم باید وضعیت Order را به Paid تغییر دهد.

این Requirement به چند Component مربوط است:

Payment Service

و:

Order Service

بنابراین Traceability می‌تواند گسترده‌تر شود:

REQ-070 → Payment Service → Order Service → Integration Test IT-015

این نوع Traceability در معماری‌های پیچیده و Microservices می‌تواند بسیار مفید باشد.

21.12 آیا همه Testها باید در RTM باشند؟

نه لزوماً.

این یکی از مهم‌ترین نکات است.

هدف Traceability این نیست که:

«تمام فعالیت‌های QA را داخل یک جدول قرار دهیم.»

بلکه باید بر اساس هدف پروژه تصمیم بگیریم چه Relationshipهایی ارزش ردیابی دارند.

مثلاً در یک پروژه:

Functional Requirements → Functional Tests

ممکن است کافی باشد.

در پروژه دیگری:

Security Requirements → Security Tests

اهمیت بیشتری داشته باشد.

و در پروژه‌ای دیگر:

Performance Requirements → Performance Tests

باید حتماً Trace شوند.

21.13 یک RTM می‌تواند چند نوع Test را پوشش دهد

فرض کنیم یک Requirement داریم:

REQ-100: Checkout باید امن، سریع و قابل استفاده باشد.

این Requirement ممکن است به چند دسته تست متصل شود:

                     ┌── Functional Test
                     │
REQ-100 ─────────────┼── Security Test
                     │
                     ├── Performance Test
                     │
                     └── Accessibility Test

بنابراین Traceability می‌تواند یک تصویر چندبعدی از Verification Requirement ایجاد کند.

21.14 نکته مهم: Requirement باید قابل Verification باشد

برای اینکه بتوانیم Requirement را به Test متصل کنیم، Requirement باید تا حد مناسبی قابل تست یا Verification باشد.

مثلاً:

سیستم باید سریع باشد.

این Requirement برای Traceability مناسب نیست؛ چون «سریع» دقیق نیست.

اما:

Response Time سیستم برای 95٪ درخواست‌ها نباید بیشتر از 2 ثانیه باشد.

قابل اندازه‌گیری‌تر است و می‌توان Test مناسب برای آن طراحی کرد.

بنابراین کیفیت Requirement روی کیفیت Traceability نیز اثر می‌گذارد.

جمع‌بندی بخش 21

RTM محدود به Functional Testing نیست.

می‌توانیم Traceability را در حوزه‌های مختلف داشته باشیم:

نوع تست	نمونه Relationship
Functional	Requirement → Functional Test
API	Requirement → API Test
Performance	NFR → Performance Test
Security	Security Requirement → Security Test
Accessibility	Accessibility Requirement → Accessibility Test
Compatibility	Requirement → Compatibility Test
Integration	Requirement → Integration Test
Automation	Requirement → Automated Test
Exploratory	Requirement → Charter / Session

پس یک نکته کلیدی را به خاطر بسپاریم:

Traceability باید بین Requirement و روش Verification مناسب آن برقرار شود؛ نه اینکه همه Requirementها الزاماً فقط به Test Caseهای Functional متصل شوند.

در نتیجه، RTM می‌تواند از یک جدول ساده:

Requirement → Test Case

به یک شبکه بسیار غنی‌تر تبدیل شود:

Requirement → Design / Component → Test → Result → Defect → Evidence

و این همان جایی است که مفهوم Requirements Traceability از یک جدول ساده فراتر می‌رود. 🔗

22. مدیریت RTM در طول چرخه واقعی پروژه 🔄

تا اینجا RTM را از جنبه‌های مختلف بررسی کردیم؛ اما در یک پروژه واقعی، RTM یک جدول ثابت نیست که یک‌بار ساخته شود و برای همیشه همان‌طور باقی بماند.

Requirementها تغییر می‌کنند، Test Caseهای جدید اضافه می‌شوند، بعضی Test Caseها حذف یا اصلاح می‌شوند، Defect ایجاد می‌شود و بعد از رفع Defect دوباره تست انجام می‌شود.

بنابراین RTM باید همراه با پروژه تکامل پیدا کند.

بیایید این موضوع را با یک سناریوی واقعی‌تر دنبال کنیم.

22.1 روز اول پروژه؛ Requirementها ایجاد می‌شوند

فرض کنیم تیم در حال توسعه یک فروشگاه اینترنتی است.

سه Requirement اولیه داریم:

ID	Requirement
REQ-001	کاربر باید بتواند با Email و Password وارد شود.
REQ-002	کاربر باید بتواند محصولی را به سبد خرید اضافه کند.
REQ-003	کاربر باید بتواند سفارش خود را پرداخت کند.

در این مرحله هنوز Test Caseها طراحی نشده‌اند.

بنابراین RTM ممکن است این وضعیت را داشته باشد:

Requirement	Test Case
REQ-001	—
REQ-002	—
REQ-003	—

این وضعیت لزوماً مشکل نیست.

چون پروژه هنوز در مرحله تحلیل و طراحی تست قرار دارد.

22.2 مرحله طراحی Test Case 🧪

QA شروع به طراحی Test Caseها می‌کند.

برای Login:

• TC-001: Login موفق
• TC-002: Password اشتباه

برای Cart:

• TC-003: Add Product to Cart

برای Payment:

• TC-004: Payment موفق
• TC-005: Payment ناموفق

اکنون RTM تغییر می‌کند:

Requirement	Test Cases
REQ-001	TC-001, TC-002
REQ-002	TC-003
REQ-003	TC-004, TC-005

در این مرحله تیم می‌تواند Coverage اولیه را بررسی کند.

22.3 اجرای تست

حالا Build آماده شده و Test Caseها اجرا می‌شوند.

نتایج:

Test Case	Result
TC-001	Pass
TC-002	Pass
TC-003	Pass
TC-004	Fail
TC-005	Pass

یک Test Case Fail شده است:

TC-004

22.4 Failure بررسی می‌شود

QA نباید صرفاً به خاطر Fail شدن TC-004 بلافاصله نتیجه بگیرد که Defect داریم.

ابتدا باید بررسی شود.

ممکن است:

• Test Data اشتباه باشد.
• محیط مشکل داشته باشد.
• سرویس Payment در دسترس نباشد.
• Test Case اشتباه باشد.
• واقعاً Software Defect وجود داشته باشد.

فرض کنیم بعد از بررسی مشخص می‌شود مشکل از نرم‌افزار است.

پس:

BUG-001

ثبت می‌شود.

22.5 Traceability کامل‌تر می‌شود 🔗

اکنون Relationshipها داریم:

REQ-003

↓

TC-004

↓

BUG-001

بنابراین اگر مدیر پروژه بپرسد:

«مشکل Payment مربوط به کدام Requirement است؟»

می‌توانیم مسیر را دنبال کنیم.

22.6 Defect Fix می‌شود

تیم Development مشکل را اصلاح می‌کند.

QA دوباره TC-004 را اجرا می‌کند:

TC-004 → Pass

اما کار هنوز تمام نشده است.

چون تغییر در Payment ممکن است روی Test Caseهای دیگری نیز اثر گذاشته باشد.

اینجاست که Impact Analysis اهمیت پیدا می‌کند.

22.7 تغییر Requirement 🔄

فرض کنیم Business تصمیم می‌گیرد یک قانون جدید برای Payment اضافه کند:

اگر مبلغ سفارش بیشتر از ۱۰ میلیون تومان باشد، کاربر باید احراز هویت دومرحله‌ای انجام دهد.

Requirement جدید:

REQ-004

حالا QA باید بررسی کند چه Test Caseهایی لازم است.

مثلاً:

• TC-006: Payment برای مبلغ کمتر از ۱۰ میلیون
• TC-007: Payment برای مبلغ دقیقاً ۱۰ میلیون
• TC-008: Payment برای مبلغ بیشتر از ۱۰ میلیون با 2FA
• TC-009: Payment بیشتر از ۱۰ میلیون بدون 2FA

اکنون:

REQ-004 → TC-006, TC-007, TC-008, TC-009

22.8 تغییر Requirement قبلی

حالا فرض کنید Requirement قبلی نیز تغییر کند.

نسخه قدیمی:

کاربر باید بتواند سفارش خود را پرداخت کند.

نسخه جدید:

کاربر باید بتواند سفارش خود را با کارت بانکی یا کیف پول دیجیتال پرداخت کند.

در اینجا فقط ایجاد Test Case جدید کافی نیست.

باید بررسی کنیم:

چه چیزهایی تحت تأثیر این تغییر قرار گرفته‌اند؟

با استفاده از Traceability می‌توانیم پیدا کنیم:

REQ-003 → TC-004 → TC-005 → Payment Component

حالا باید بررسی کنیم آیا Test Caseهای فعلی کافی هستند یا خیر.

ممکن است Test Caseهای جدید ایجاد کنیم:

• TC-010: Payment با کارت بانکی
• TC-011: Payment با Wallet

22.9 RTM در زمان Regression

بعد از تغییر Payment، تیم تصمیم می‌گیرد Regression Testing انجام دهد.

RTM می‌تواند به تیم کمک کند Test Caseهای مرتبط را پیدا کند.

REQ-003
   ├── TC-004
   ├── TC-005
   ├── TC-010
   └── TC-011

همچنین اگر Component مشخص شده باشد:

Payment Component

می‌توان Test Caseهای دیگری را که به همان Component مربوط هستند نیز بررسی کرد.

اما یک نکته مهم:

RTM به‌تنهایی تعیین‌کننده کامل Regression Scope نیست.

تیم QA باید علاوه بر Traceability، مواردی مثل:

• Impact Analysis
• Risk
• Dependency
• Code Change
• Architecture

را نیز در نظر بگیرد.

22.10 نزدیک شدن به Release 🚀

حالا فرض کنیم Release 2.0 نزدیک است.

QA می‌خواهد وضعیت Coverage را بررسی کند.

Requirement	Test Coverage	Result
REQ-001	Covered	Pass
REQ-002	Covered	Pass
REQ-003	Covered	Pass
REQ-004	Covered	Pass

از نظر Requirement-to-Test Traceability، همه Requirementها Coverage دارند.

اما QA باید بررسی‌های بیشتری انجام دهد.

مثلاً:

• آیا همه Testها Pass شده‌اند؟
• آیا Defectهای Critical باز هستند؟
• آیا Requirementهای High-Risk تست شده‌اند؟
• آیا Regression انجام شده است؟
• آیا Requirement جدیدی بدون Test باقی مانده است؟

بنابراین:

RTM یکی از ورودی‌های تصمیم Release است، نه تنها معیار تصمیم‌گیری.

22.11 Requirement جدیدی در آخرین لحظه اضافه می‌شود 😰

فرض کنید یک روز قبل از Release، Business یک Requirement جدید اضافه می‌کند:

REQ-005

کاربر باید بتواند سفارش را لغو کند.

اما هنوز:

REQ-005 → هیچ Test Caseی ندارد.

RTM بلافاصله یک Gap را نشان می‌دهد.

تیم QA باید تصمیم بگیرد:

• Test Case طراحی شود؟
• تست این Requirement به Release بعد منتقل شود؟
• Requirement از Scope خارج شود؟
• Risk پذیرفته شود؟

این دقیقاً یکی از ارزش‌های مهم RTM است.

22.12 RTM بعد از Release هم تمام نمی‌شود

ممکن است تصور کنیم بعد از Release، RTM دیگر کاربردی ندارد.

اما در واقع می‌تواند برای موارد زیر همچنان مورد استفاده قرار گیرد:

• Maintenance
• Regression
• Change Requests
• Bug Fixes
• New Releases
• Impact Analysis

مثلاً سه ماه بعد Business می‌گوید:

«قانون تخفیف باید تغییر کند.»

تیم می‌تواند از Traceability قبلی استفاده کند و سریع‌تر متوجه شود:

کدام Requirement؟

کدام Component؟

کدام Test Case؟

کدام Defectهای قبلی؟

و:

کدام Regression Testها؟

22.13 چرخه عمر RTM

اگر کل فرایند را خلاصه کنیم:

Requirement Created
        ↓
Requirement Analyzed
        ↓
Test Cases Designed
        ↓
Traceability Created
        ↓
Test Execution
        ↓
Pass / Fail
        ↓
Defect
        ↓
Fix
        ↓
Retest
        ↓
Regression
        ↓
Release
        ↓
Requirement Change
        ↓
Impact Analysis
        ↓
Update Traceability

این چرخه ممکن است بارها در طول عمر محصول تکرار شود.

22.14 RTM یک سند Static نیست

این نکته را می‌توان به‌عنوان یکی از پیام‌های اصلی مقاله در نظر گرفت:

RTM یک Snapshot ثابت از پروژه نیست؛ باید بازتاب‌دهنده وضعیت فعلی Traceability باشد.

اگر Requirement تغییر کرده ولی RTM تغییر نکرده، RTM دیگر نمای دقیقی از پروژه ارائه نمی‌دهد.

اگر Test Case حذف شده ولی Relationship آن باقی مانده، Traceability اشتباه می‌شود.

اگر Defect بسته شده ولی وضعیت آن در سیستم به‌روز نشده، گزارش‌ها ممکن است نادرست باشند.

بنابراین:

RTM باید Maintenance شود.

22.15 چه کسی مسئول به‌روزرسانی RTM است؟

یک اشتباه رایج این است که تصور کنیم:

«RTM فقط وظیفه Tester است.»

در واقع بسته به ساختار پروژه، افراد مختلف می‌توانند در ایجاد و نگهداری Traceability نقش داشته باشند:

• Business Analyst
• Product Owner
• Developer
• QA Engineer
• QA Lead
• Requirements Engineer
• Test Manager

اما در پروژه‌های مختلف مسئولیت دقیق می‌تواند متفاوت باشد.

مهم این است که:

مالکیت Traceability باید مشخص باشد.

اگر هیچ‌کس مسئول آن نباشد، احتمالاً RTM بعد از مدتی منسوخ می‌شود.

22.16 بهترین روش برای نگهداری RTM

به جای اینکه در پایان پروژه یک نفر بنشیند و تمام Relationshipها را وارد کند، بهتر است Traceability از همان ابتدای چرخه توسعه ایجاد شود.

یعنی:

Requirement ایجاد شد → ID دریافت کرد

↓

Test طراحی شد → به Requirement متصل شد

↓

Test اجرا شد → Result ثبت شد

↓

Failure بررسی شد → در صورت نیاز Defect ایجاد شد

↓

Defect Fix شد → Retest ثبت شد

این روش بسیار بهتر از ساختن RTM در آخر پروژه است.

جمع‌بندی بخش 22

RTM در پروژه واقعی باید همراه با تغییرات پروژه حرکت کند:

Create → Link → Execute → Analyze → Update → Retest → Release

و با هر تغییر مهم، Traceability نیز باید دوباره بررسی شود.

هدف این نیست که در پایان پروژه یک جدول زیبا داشته باشیم.

هدف این است که در هر لحظه بتوانیم بفهمیم Requirementها چه وضعیتی دارند و چه چیزهایی به آن‌ها وابسته است. 🔗

23. چگونه یک RTM استاندارد و حرفه‌ای طراحی کنیم؟ 📊

تا اینجا دیدیم RTM چه کاربردهایی دارد، چه Relationshipهایی می‌تواند داشته باشد و چگونه در طول پروژه تغییر می‌کند.

حالا به یک سؤال عملی می‌رسیم:

اگر بخواهیم امروز برای یک پروژه واقعی RTM بسازیم، چه ستون‌هایی باید داشته باشد؟

پاسخ این است که یک قالب ثابت و اجباری برای تمام پروژه‌ها وجود ندارد.

RTM باید بر اساس هدف پروژه طراحی شود؛ اما می‌توانیم یک ساختار پایه داشته باشیم و در صورت نیاز آن را گسترش دهیم.

23.1 ابتدا هدف RTM را مشخص کنید 🎯

قبل از اینکه Excel را باز کنیم و شروع به ساختن ستون‌ها کنیم، باید مشخص کنیم RTM قرار است چه سؤالی را پاسخ دهد.

مثلاً:

آیا همه Requirementها تست شده‌اند؟

در این صورت شاید همین ساختار کافی باشد:

Requirement ID	Requirement	Test Case ID	Test Result
REQ-001	Login	TC-001	Pass

اما اگر سؤال ما این باشد:

اگر Requirement تغییر کند، چه بخش‌هایی تحت تأثیر قرار می‌گیرند؟

ممکن است به اطلاعات بیشتری نیاز داشته باشیم:

Requirement	Component	Test Case	Defect
REQ-001	Authentication	TC-001	—

پس:

اول هدف، بعد ساختار.

23.2 ستون‌های پایه RTM

برای یک RTM معمولی در پروژه QA، می‌توانیم از این ستون‌ها شروع کنیم:

ستون	کاربرد
Requirement ID	شناسه یکتا
Requirement	شرح نیازمندی
Test Case ID	Test Case مرتبط
Test Result	نتیجه آخرین اجرا
Defect ID	Defect مرتبط

مثلاً:

Req ID	Requirement	Test Case	Result	Defect
REQ-001	Login موفق	TC-001	Pass	—
REQ-002	Reset Password	TC-002	Fail	BUG-012
REQ-003	Add to Cart	TC-003	Pass	—

این ساختار برای بسیاری از پروژه‌های کوچک و متوسط کاملاً قابل استفاده است.

23.3 Requirement ID؛ مهم‌ترین نقطه اتصال 🔑

هر Requirement باید یک شناسه مشخص داشته باشد.

REQ-001
REQ-002
REQ-003

این ID مانند یک کلید عمل می‌کند.

مثلاً:

REQ-001

در Requirement Document وجود دارد.

همین ID می‌تواند در:

• RTM
• Test Case
• Defect
• Design
• User Story

مورد استفاده قرار گیرد.

بنابراین استفاده از IDهای یکتا بسیار مهم است.

23.4 آیا باید متن کامل Requirement را در RTM بنویسیم؟

لزومی ندارد.

در پروژه‌های بزرگ ممکن است فقط:

REQ-001

در RTM قرار گیرد و متن کامل Requirement در Requirements Management Tool نگهداری شود.

مثلاً:

Requirement ID	Test Case ID
REQ-001	TC-001
REQ-002	TC-002

این کار باعث می‌شود RTM ساده‌تر و قابل نگهداری‌تر باشد.

در Excel پروژه‌های کوچک، نگهداری متن Requirement نیز می‌تواند مفید باشد.

23.5 Test Case ID

Test Case نیز باید شناسه یکتا داشته باشد:

TC-001
TC-002
TC-003

این ID به RTM اجازه می‌دهد Requirement را به Test Case متصل کند.

مثلاً:

REQ-001 → TC-001

یا:

REQ-001 → TC-001, TC-002, TC-003

23.6 Test Result

در صورت نیاز می‌توان وضعیت اجرای Test را نیز در RTM نمایش داد.

مثلاً:

• Not Run
• Pass
• Fail
• Blocked
• Not Applicable

مثال:

Requirement	Test Case	Result
REQ-001	TC-001	Pass
REQ-002	TC-002	Fail
REQ-003	TC-003	Blocked

این ستون برای گزارش وضعیت Release می‌تواند مفید باشد.

اما باید توجه کنیم:

اگر ابزار Test Management شما همین اطلاعات را به‌صورت دقیق نگهداری می‌کند، الزاماً لازم نیست همان اطلاعات را دوباره به‌صورت دستی در یک Excel RTM وارد کنید.

23.7 Defect ID 🐞

اگر Test Case Fail شده باشد، در صورت تأیید وجود Defect می‌توان آن را به Defect مرتبط کرد.

مثلاً:

TC-002 → BUG-012

و در نتیجه:

REQ-002 → TC-002 → BUG-012

این Relationship برای Impact Analysis و بررسی وضعیت Requirement بسیار مفید است.

23.8 Component

اگر هدف RTM فقط Requirement Coverage باشد، Component ممکن است ضروری نباشد.

اما اگر بخواهیم Impact Analysis انجام دهیم، می‌تواند مفید باشد.

مثلاً:

Requirement	Component
REQ-001	Authentication
REQ-002	Payment
REQ-003	Cart

حالا اگر:

Payment Component

تغییر کند، می‌توانیم Requirementها و Test Caseهای مرتبط را راحت‌تر پیدا کنیم.

23.9 Priority و Risk 🎯

در پروژه‌های Risk-Based Testing، اضافه کردن این اطلاعات می‌تواند بسیار ارزشمند باشد.

Requirement	Priority	Risk	Test Cases
REQ-001	High	High	8
REQ-002	Medium	Medium	3
REQ-003	Low	Low	1

این اطلاعات کمک می‌کند Coverage را بهتر تفسیر کنیم.

مثلاً:

چرا یک Requirement فقط یک Test Case دارد؟

اگر Risk آن Low باشد، شاید کاملاً منطقی باشد.

اما اگر Risk آن High باشد، ممکن است نیاز به بررسی بیشتری داشته باشیم.

23.10 Requirement Type

گاهی اضافه کردن نوع Requirement نیز مفید است:

• Functional
• Performance
• Security
• Usability
• Accessibility
• Reliability

مثلاً:

ID	Type	Requirement
REQ-001	Functional	Login
NFR-001	Performance	Response Time < 2s
NFR-002	Security	Unauthorized access prevented

این کار کمک می‌کند بفهمیم Coverage فقط مربوط به Functional Testing نیست.

23.11 Version

در پروژه‌هایی که Requirementها مرتب تغییر می‌کنند، Version نیز می‌تواند اهمیت داشته باشد.

مثلاً:

REQ-010 v1.0

بعد:

REQ-010 v2.0

اگر Requirement تغییر کرده باشد، باید بدانیم Test Caseها برای کدام Version طراحی یا اجرا شده‌اند.

البته در ابزارهای حرفه‌ای، Version History ممکن است توسط خود سیستم مدیریت شود و نیازی به ستون دستی نباشد.

23.12 یک Template پیشنهادی برای پروژه متوسط

برای یک پروژه QA متوسط، می‌توانیم چنین ساختاری داشته باشیم:

Req ID	Type	Requirement	Priority	Risk	Component	Test Case ID	Test Result	Defect ID
REQ-001	Functional	Login	High	High	Auth	TC-001	Pass	—
REQ-001	Functional	Login	High	High	Auth	TC-002	Pass	—
REQ-002	Functional	Add to Cart	High	Medium	Cart	TC-003	Pass	—
NFR-001	Performance	Response < 2s	High	High	Search	PT-001	Fail	BUG-010

این قالب نسبتاً جامع است.

اما باز هم:

لازم نیست تمام پروژه‌ها دقیقاً همین ستون‌ها را داشته باشند.

23.13 یک RTM بیش از حد پیچیده چه شکلی می‌شود؟ 😵

فرض کنید چنین ستون‌هایی اضافه کنیم:

Requirement ID
Requirement
Requirement Version
Business Owner
Priority
Risk
Epic
Feature
User Story
Acceptance Criteria
Design Document
Architecture
Component
API
Database Table
Test Scenario
Test Case
Automation Script
Test Data
Environment
Browser
OS
Execution
Result
Defect
Severity
Priority
Release
Sprint
Build
Evidence
Tester
Reviewer
Approval
Date

آیا این RTM حرفه‌ای‌تر است؟

لزوماً نه.

ممکن است فقط یک Spreadsheet غیرقابل نگهداری ساخته باشیم.

23.14 اصل طلایی طراحی RTM

برای هر ستون از خودمان بپرسیم:

آیا این اطلاعات برای Traceability یا تصمیم‌گیری موردنیاز است؟

اگر پاسخ:

بله

باشد، ستون را نگه می‌داریم.

اگر:

خیر

باشد، احتمالاً نیازی به آن نداریم.

این اصل ساده جلوی بسیاری از RTMهای بیش از حد پیچیده را می‌گیرد.

23.15 RTM خوب باید قابل خواندن باشد 👀

فرض کنید مدیر QA در جلسه می‌پرسد:

«کدام Requirementهای High-Risk هنوز Coverage کامل ندارند؟»

اگر برای پاسخ به این سؤال مجبور باشیم ۲۰ ستون و چند هزار ردیف را بررسی کنیم، RTM طراحی خوبی ندارد.

یک RTM خوب باید بتواند اطلاعات مهم را سریع قابل مشاهده کند.

مثلاً با Filter:

Risk = High

و:

Coverage = Missing

به سرعت Gapها مشخص شوند.

23.16 یک RTM می‌تواند چند View داشته باشد

به‌جای اینکه همه اطلاعات را در یک جدول غول‌پیکر نمایش دهیم، می‌توانیم Viewهای مختلف داشته باشیم.

Coverage View

Requirement → Test Case

Defect View

Requirement → Test Case → Defect

Impact View

Requirement → Component → Test Case

Release View

Requirement → Test Result → Release Status

این رویکرد معمولاً خوانایی بیشتری دارد.

23.17 ساختار پیشنهادی نهایی

برای مقاله، می‌توانیم یک مدل ساده و حرفه‌ای پیشنهاد کنیم:

Requirement
     │
     ├────► Component
     │
     └────► Test Case
                │
                ▼
           Test Result
                │
                ▼
             Defect

و اطلاعاتی مثل:

Risk، Priority، Version و Release

را فقط زمانی اضافه کنیم که واقعاً برای تصمیم‌گیری یا Traceability پروژه لازم باشند.

جمع‌بندی بخش 23

یک RTM حرفه‌ای الزاماً بزرگ و پیچیده نیست.

بلکه باید:

• هدف مشخص داشته باشد.
• IDهای یکتا داشته باشد.
• Relationshipهای مهم را نمایش دهد.
• Coverage Gapها را قابل مشاهده کند.
• در صورت نیاز Defect و Component را Trace کند.
• با تغییرات پروژه به‌روز شود.
• از اطلاعات غیرضروری پر نشود.

و مهم‌تر از همه:

RTM باید برای تیم قابل استفاده باشد، نه فقط برای اینکه در مستندات پروژه وجود داشته باشد. 🔗

24. نمونه کامل RTM برای یک پروژه واقعی 📊

تا اینجا RTM را از نظر مفهومی بررسی کردیم. حالا بیایید یک نمونه نسبتاً واقعی بسازیم؛ نمونه‌ای که بتواند نشان دهد در یک پروژه QA، ارتباط بین Requirement، Component، Test Case، Test Result و Defect چگونه کنار هم قرار می‌گیرد.

فرض کنید تیم در حال توسعه یک فروشگاه اینترنتی است و قرار است نسخه جدید بخش خرید و پرداخت منتشر شود.

24.1 Requirementهای پروژه

ابتدا چند Requirement داریم:

ID	نوع	Requirement	Risk	Priority
REQ-001	Functional	کاربر باید بتواند با اطلاعات معتبر وارد حساب کاربری شود.	High	High
REQ-002	Functional	کاربر باید بتواند محصول را به سبد خرید اضافه کند.	Medium	High
REQ-003	Functional	کاربر باید بتواند سفارش خود را با کارت بانکی پرداخت کند.	High	Critical
REQ-004	Functional	سیستم باید مبلغ نهایی سفارش را صحیح محاسبه کند.	High	Critical
NFR-001	Performance	پاسخ API جستجو در 95٪ درخواست‌ها باید کمتر از 2 ثانیه باشد.	High	High
NFR-002	Security	کاربر نباید بتواند به اطلاعات سفارش کاربر دیگری دسترسی پیدا کند.	Critical	Critical

در همین مرحله یک نکته مهم مشخص می‌شود:

همه Requirementها Functional نیستند.

دو Requirement آخر Non-Functional هستند و همچنان می‌توانند در Traceability قرار بگیرند.

24.2 ارتباط Requirement با Component

فرض کنیم معماری سیستم شامل این Componentهاست:

• Authentication Service
• Cart Service
• Order Service
• Payment Service
• Search Service

حالا Relationship را ایجاد می‌کنیم:

Requirement	Component
REQ-001	Authentication Service
REQ-002	Cart Service
REQ-003	Payment Service
REQ-004	Order Service
NFR-001	Search Service
NFR-002	Order Service

حالا اگر Payment Service تغییر کند، می‌توانیم سریع‌تر Requirementهای مرتبط را پیدا کنیم.

این همان کاربرد Traceability در Impact Analysis است.

24.3 طراحی Test Caseها 🧪

حالا QA بر اساس Requirementها Test Case طراحی می‌کند.

برای Login:

• TC-001: Login با اطلاعات معتبر
• TC-002: Login با Password اشتباه

برای Cart:

• TC-003: Add Product to Cart

برای Payment:

• TC-004: Payment با کارت معتبر
• TC-005: Payment با کارت نامعتبر

برای Order Calculation:

• TC-006: محاسبه صحیح مبلغ سفارش
• TC-007: محاسبه Discount
• TC-008: محاسبه Tax

برای Performance:

• PT-001: Search API تحت Load مشخص

برای Security:

• SEC-001: دسترسی به سفارش متعلق به کاربر دیگر

24.4 حالا Relationship اصلی RTM را ایجاد کنیم

ارتباط Requirement و Test Case:

Requirement	Test Case
REQ-001	TC-001
REQ-001	TC-002
REQ-002	TC-003
REQ-003	TC-004
REQ-003	TC-005
REQ-004	TC-006
REQ-004	TC-007
REQ-004	TC-008
NFR-001	PT-001
NFR-002	SEC-001

حالا یک نکته مهم را می‌بینیم:

یک Requirement می‌تواند چند Test Case داشته باشد.

مثلاً:

REQ-004 → TC-006, TC-007, TC-008

و این کاملاً طبیعی است.

24.5 اجرای Testها

فرض کنیم Testها اجرا می‌شوند:

Test Case	Result
TC-001	Pass
TC-002	Pass
TC-003	Pass
TC-004	Pass
TC-005	Pass
TC-006	Pass
TC-007	Fail
TC-008	Pass
PT-001	Pass
SEC-001	Fail

دو Failure داریم:

TC-007

و:

SEC-001

24.6 بررسی Failureها

QA ابتدا Failure را بررسی می‌کند.

برای TC-007 مشخص می‌شود Discount برای برخی سفارش‌ها اشتباه محاسبه می‌شود.

بنابراین:

BUG-101

ثبت می‌شود.

برای SEC-001 نیز مشخص می‌شود کاربر در شرایط خاصی می‌تواند Order متعلق به کاربر دیگر را مشاهده کند.

این مشکل بسیار جدی‌تر است.

بنابراین:

BUG-102

ثبت می‌شود.

24.7 حالا Traceability بسیار جالب می‌شود 🔗

برای BUG-101:

REQ-004
    ↓
TC-007
    ↓
BUG-101

و برای BUG-102:

NFR-002
    ↓
SEC-001
    ↓
BUG-102

اکنون اگر مدیر QA بپرسد:

«BUG-102 مربوط به کدام Requirement است؟»

می‌توانیم Relationship را دنبال کنیم.

24.8 RTM کامل پروژه

حالا می‌توانیم اطلاعات را در یک جدول جامع‌تر ببینیم:

Req ID	Type	Risk	Component	Test Case	Result	Defect
REQ-001	Functional	High	Authentication	TC-001	Pass	—
REQ-001	Functional	High	Authentication	TC-002	Pass	—
REQ-002	Functional	Medium	Cart	TC-003	Pass	—
REQ-003	Functional	High	Payment	TC-004	Pass	—
REQ-003	Functional	High	Payment	TC-005	Pass	—
REQ-004	Functional	High	Order	TC-006	Pass	—
REQ-004	Functional	High	Order	TC-007	Fail	BUG-101
REQ-004	Functional	High	Order	TC-008	Pass	—
NFR-001	Performance	High	Search	PT-001	Pass	—
NFR-002	Security	Critical	Order	SEC-001	Fail	BUG-102

این نمونه نشان می‌دهد که RTM می‌تواند بسیار فراتر از:

Requirement → Test Case

باشد.

24.9 پیدا کردن Coverage Gap

حالا فرض کنیم Requirement دیگری اضافه شده:

REQ-005

کاربر باید بتواند سفارش خود را لغو کند.

اما هنوز Test Caseی برای آن ایجاد نشده است.

Requirement	Test Case
REQ-005	—

این یک Coverage Gap است.

QA می‌تواند آن را شناسایی کند و Test Caseهای لازم را طراحی کند:

• TC-009: Cancel Order
• TC-010: Cancel Order after Shipment
• TC-011: Cancel Order after Payment

24.10 بررسی Coverage

فرض کنیم در نهایت:

11 Requirement

داریم.

از این تعداد:

10 Requirement

حداقل یک Test Case یا Test مرتبط دارند.

پس Requirement Coverage ما:

10 / 11 = 90.9٪

اما این عدد به تنهایی کافی نیست.

چرا؟

چون ممکن است Requirementهای پوشش‌داده‌نشده از اهمیت بسیار بالایی برخوردار باشند.

24.11 Coverage و Risk را کنار هم ببینیم 🎯

فرض کنید:

REQ-005 → Coverage = 0%

Risk = Low

اما:

NFR-003 → Coverage = 0%

Risk = Critical

هر دو از نظر Coverage مشکل دارند.

اما NFR-003 بسیار مهم‌تر است.

پس تیم QA نباید فقط بگوید:

«دو Requirement بدون Coverage داریم.»

باید بگوید:

«یک Requirement Critical بدون Coverage داریم که قبل از Release باید تعیین تکلیف شود.»

این تفاوت بین گزارش ساده و تحلیل QA است.

24.12 حالا Requirement تغییر می‌کند

فرض کنیم Business Requirement مربوط به Payment را تغییر می‌دهد.

قبلاً:

کاربر باید بتواند با کارت بانکی پرداخت کند.

اکنون:

کاربر باید بتواند با کارت بانکی یا کیف پول دیجیتال پرداخت کند.

این تغییر روی:

REQ-003

اثر گذاشته است.

از RTM می‌فهمیم:

REQ-003
   ↓
TC-004
TC-005

و Component آن:

Payment Service

است.

بنابراین QA می‌تواند Impact Analysis را شروع کند.

Test Case جدید:

TC-012: Payment with Digital Wallet

و احتمالاً Test Caseهای دیگری نیز برای Failure و Edge Caseهای Wallet لازم خواهد بود.

24.13 Regression بعد از تغییر

بعد از تغییر Payment، تیم فقط TC-012 را اجرا نمی‌کند.

باید بررسی کند Test Caseهای قبلی نیز تحت تأثیر قرار گرفته‌اند یا خیر.

مثلاً:

• TC-004
• TC-005
• TC-012

و بسته به Impact ممکن است تست‌های دیگری نیز در Regression قرار بگیرند.

اینجا Traceability کمک می‌کند Testهای مرتبط را پیدا کنیم.

24.14 وضعیت نهایی بعد از Fix

فرض کنیم BUG-101 و BUG-102 اصلاح شده‌اند.

تست‌ها دوباره اجرا می‌شوند:

Test	Before	After
TC-007	Fail	Pass
SEC-001	Fail	Pass

بنابراین وضعیت نهایی:

BUG-101 → Closed

BUG-102 → Closed

و:

REQ-004 → Covered / Pass

NFR-002 → Covered / Pass

24.15 این RTM چه چیزی به ما می‌گوید؟

حالا اگر Release Manager سؤال کند:

«آیا Requirementهای مهم تست شده‌اند؟»

می‌توانیم پاسخ دهیم.

«بله، Requirementهای High و Critical دارای Trace به Test هستند و وضعیت اجرای آن‌ها مشخص است.»

اگر بپرسد:

«آیا Requirement امنیتی مشکل داشت؟»

می‌توانیم بگوییم:

«بله، SEC-001 ابتدا Fail شد، BUG-102 ثبت شد و پس از Fix مجدداً تست و Pass شد.»

اگر بپرسد:

«تغییر Payment روی چه چیزهایی اثر می‌گذارد؟»

می‌توانیم از Traceability استفاده کنیم:

REQ-003
   ↓
Payment Service
   ↓
TC-004 / TC-005 / TC-012

24.16 اما این جدول را بیش از حد بزرگ نکنیم

در این مثال عمداً اطلاعات زیادی را در یک جدول جمع کردیم تا مفهوم واضح باشد.

در پروژه واقعی ممکن است بهتر باشد این اطلاعات در چند View یا سیستم مختلف نگهداری شوند.

Requirement View

Requirement → Component

Test Coverage View

Requirement → Test Case

Defect View

Requirement → Test Case → Defect

Release View

Requirement → Test Result → Release

این روش معمولاً از یک Spreadsheet عظیم قابل استفاده‌تر است.

24.17 یک مدل نهایی برای RTM

اگر بخواهیم این مثال را در یک نمودار ساده خلاصه کنیم:

Requirement
     │
     ├──────────► Component
     │
     ▼
  Test Case
     │
     ▼
Test Execution
     │
     ├── Pass
     │
     └── Fail
           │
           ▼
         Defect
           │
           ▼
          Fix
           │
           ▼
         Retest

و در صورت تغییر Requirement:

Requirement Change
        │
        ▼
 Impact Analysis
        │
        ├── Component
        ├── Test Cases
        └── Regression

این در واقع تصویر کاربردی RTM در یک پروژه واقعی است. 🔗

جمع‌بندی

یک RTM حرفه‌ای می‌تواند به تیم QA کمک کند تا ارتباط بین این Artefactها را دنبال کند:

Requirement

↕️

Component

↕️

Test Case

↕️

Test Result

↕️

Defect

اما لازم نیست همه این Relationshipها همیشه در یک جدول قرار بگیرند.

میزان Traceability باید متناسب با پیچیدگی، ریسک و نیاز پروژه باشد.

و مهم‌تر از همه:

هدف RTM این نیست که تعداد زیادی Relationship ثبت کنیم؛ هدف این است که بتوانیم سؤال‌های مهم پروژه را با استفاده از Traceability پاسخ دهیم. 🎯

25. بهترین روش‌های استفاده از RTM در پروژه‌های واقعی 🎯

حالا که با ساختار RTM و کاربردهای مختلف آن آشنا شدیم، وقت آن است که از نگاه عملی‌تر به موضوع نگاه کنیم.

ساختن یک RTM کار سختی نیست.

سختی واقعی این است که RTM را طوری نگهداری کنیم که واقعاً برای تیم ارزش ایجاد کند.

یک فایل Excel با صدها ردیف، به‌خودی‌خود نشانه حرفه‌ای بودن نیست. حتی ممکن است اگر درست مدیریت نشود، بیشتر از اینکه کمک کند، دردسر ایجاد کند. 😅

25.1 RTM را از ابتدای پروژه ایجاد کنید

یکی از اشتباهات رایج این است که تیم در پایان پروژه به فکر RTM می‌افتد.

مثلاً نزدیک Release ناگهان گفته می‌شود:

«باید یک RTM هم آماده کنیم.»

در این شرایط معمولاً QA مجبور می‌شود Relationshipهای مختلف را از روی مستندات، Test Caseها و ابزارهای مختلف بازسازی کند.

نتیجه ممکن است:

• Relationshipهای ناقص
• Requirementهای جاافتاده
• Test Caseهای بدون Trace
• اطلاعات قدیمی
• Coverage اشتباه

باشد.

بهتر است Traceability از همان زمانی که Requirementها شکل می‌گیرند، به‌تدریج ایجاد شود.

25.2 برای Requirementها ID یکتا داشته باشید 🔑

به جای اینکه Relationshipها را بر اساس متن Requirement ایجاد کنیم، بهتر است از ID استفاده کنیم.

مثلاً:

REQ-001
REQ-002
REQ-003

این کار باعث می‌شود اگر متن Requirement تغییر کرد، هویت آن از بین نرود.

مثلاً:

REQ-003
نسخه 1:
پرداخت با کارت بانکی

نسخه 2:
پرداخت با کارت بانکی یا کیف پول دیجیتال

Requirement همچنان:

REQ-003

است.

25.3 Traceability را بیش از حد پیچیده نکنید

یکی از خطرهای RTM این است که تیم تصور کند هر چیزی باید به هر چیز دیگری متصل شود.

Requirement
→ User Story
→ Acceptance Criteria
→ Design
→ Component
→ API
→ Database
→ Test Scenario
→ Test Case
→ Automation Script
→ Test Run
→ Defect
→ Evidence

این سطح از Traceability ممکن است در یک پروژه Enterprise ضروری باشد، اما برای یک پروژه کوچک می‌تواند کاملاً غیرضروری باشد.

بنابراین:

Traceability باید به اندازه‌ای باشد که به پروژه کمک کند، نه اینکه خودش به یک پروژه تبدیل شود.

25.4 از RTM برای Impact Analysis استفاده کنید 🔍

یکی از ارزشمندترین کاربردهای RTM زمانی مشخص می‌شود که Requirement تغییر می‌کند.

مثلاً:

REQ-020

تغییر کرده است.

با Traceability می‌توانیم بررسی کنیم:

REQ-020
   ↓
Component
   ↓
Test Cases
   ↓
Defects

و مشخص کنیم چه چیزهایی احتمالاً باید بررسی یا اصلاح شوند.

این کار به QA کمک می‌کند Regression Testing را هدفمندتر برنامه‌ریزی کند.

25.5 فقط به Coverage درصدی نگاه نکنید

فرض کنید داشبورد پروژه نشان می‌دهد:

Requirement Coverage = 100%

این عدد در نگاه اول عالی است. 🎉

اما هنوز سؤال‌های مهمی وجود دارد:

• آیا Test Caseها کیفیت مناسبی دارند؟
• آیا Negative Scenarioها تست شده‌اند؟
• آیا Boundary Valueها بررسی شده‌اند؟
• آیا Security تست شده؟
• آیا Performance Requirementها Verification شده‌اند؟
• آیا Testها واقعاً اجرا شده‌اند؟
• آیا Testهای Fail شده Defect باز دارند؟

بنابراین:

Coverage Metric فقط یک Signal است، نه اثبات کیفیت.

25.6 Coverage را با Risk ترکیب کنید 🎯

فرض کنید:

REQ-001 → Coverage = 100%

اما Risk آن Low است.

در مقابل:

REQ-002 → Coverage = 80%

ولی Risk آن Critical است.

در چنین شرایطی، Requirement دوم احتمالاً اولویت بالاتری برای بررسی دارد.

پس یک QA حرفه‌ای فقط نمی‌پرسد:

«چند درصد Requirementها Coverage دارند؟»

بلکه می‌پرسد:

«کدام Requirementهای مهم و پرریسک Coverage کافی ندارند؟»

25.7 RTM را با Defect Management مرتبط کنید 🐞

اگر ابزار پروژه اجازه می‌دهد، ارتباط بین Requirement، Test و Defect را حفظ کنید.

مثلاً:

REQ-015
   ↓
TC-105
   ↓
BUG-203

حالا اگر BUG-203 دوباره باز شود، می‌دانیم دقیقاً کدام Requirement تحت تأثیر است.

این اطلاعات در:

• Regression
• Release Assessment
• Impact Analysis
• Risk Analysis

بسیار مفید است.

25.8 Relationshipهای قدیمی را پاک کنید

فرض کنید:

TC-101

قبلاً برای:

REQ-010

طراحی شده بود.

بعد Requirement تغییر کرده و Test Case دیگر به آن مربوط نیست.

اگر Relationship قدیمی همچنان باقی بماند، RTM اطلاعات نادرست نشان می‌دهد.

بنابراین باید Relationshipها نیز مانند Test Caseها Maintenance شوند.

25.9 Requirementهای حذف‌شده را هم مدیریت کنید

فرض کنیم:

REQ-025

از Scope خارج شده است.

نباید صرفاً آن را از RTM حذف کنیم و تمام.

باید بدانیم:

• چه Test Caseهایی به آن وابسته بودند؟
• آیا Defect مرتبطی وجود دارد؟
• آیا Test Caseها باید حذف یا Archive شوند؟
• آیا Requirement در Release قبلی استفاده شده بود؟

در سیستم‌های حرفه‌ای، History و Versioning می‌تواند برای این موضوع بسیار مفید باشد.

25.10 RTM را با Test Management Tool هماهنگ کنید

در پروژه‌های بزرگ، نگهداری دستی RTM در Excel می‌تواند مشکل‌ساز شود.

ممکن است Test Case در یک ابزار تغییر کند ولی Excel به‌روز نشود.

در نتیجه:

Tool A

می‌گوید:

TC-101 = Pass

اما Excel:

TC-101 = Not Run

این اختلاف اطلاعات می‌تواند مشکل‌ساز باشد.

بنابراین اگر ابزارهای مدیریت Requirement و Test امکان Traceability دارند، بهتر است تا حد امکان از همان سیستم به‌عنوان Source of Truth استفاده شود.

25.11 RTM را در Reviewها بررسی کنید

Traceability نباید فقط در زمان Release بررسی شود.

می‌توان آن را در نقاط مهم پروژه Review کرد:

• Requirement Review
• Test Design Review
• Sprint Review
• Regression Cycle
• Release Readiness Review

مثلاً در پایان هر Sprint می‌توان پرسید:

«آیا User Storyهای این Sprint Test Coverage دارند؟»

این کار باعث می‌شود Gapها زودتر کشف شوند.

25.12 RTM را به‌عنوان ابزار ارتباطی ببینید

RTM فقط برای QA نیست.

افراد مختلف می‌توانند از آن استفاده کنند:

Business Analyst

برای بررسی اینکه Requirementها به Test متصل هستند.

Developer

برای فهمیدن Impact تغییرات.

QA

برای بررسی Coverage.

QA Lead

برای ارزیابی Testing Status.

Product Owner

برای درک وضعیت Requirementها.

Release Manager

برای ارزیابی آمادگی Release.

بنابراین RTM می‌تواند یک زبان مشترک بین تیم‌های مختلف باشد.

25.13 از Automation برای Traceability استفاده کنید 🤖

در پروژه‌های بزرگ، بسیاری از Relationshipها را می‌توان به‌صورت خودکار مدیریت کرد.

Requirement ID
      ↓
Test Case ID
      ↓
Automated Test
      ↓
CI/CD Execution
      ↓
Test Result

در این حالت بعد از اجرای Pipeline می‌توان وضعیت تست‌ها را به Requirementهای مرتبط متصل کرد.

این رویکرد در تیم‌های مدرن QA می‌تواند بسیار ارزشمند باشد.

25.14 RTM را به Dashboard تبدیل کنید

RTM فقط یک جدول نیست.

از داده‌های Traceability می‌توان Metrics ساخت:

• Requirement Coverage
• Test Execution Status
• Pass Rate
• Failed Requirements
• Open Defects by Requirement
• High-Risk Requirements without Coverage

مثلاً:

Requirement Coverage      96%
Test Execution             91%
Pass Rate                  88%
Critical Defects            2
High-Risk Gaps              1

این اطلاعات برای QA Lead و مدیریت بسیار قابل استفاده‌تر از یک Excel چندصد ردیفی است.

25.15 چند اشتباه رایج که باید از آن‌ها دوری کنیم ❌

اشتباه اول: ساخت RTM در پایان پروژه

باعث اطلاعات ناقص و Traceability جعلی می‌شود.

اشتباه دوم: تصور اینکه 100٪ Coverage یعنی کیفیت 100٪

Coverage فقط یک شاخص است.

اشتباه سوم: قرار دادن همه چیز در یک جدول

RTM بیش از حد بزرگ، خوانایی و نگهداری را دشوار می‌کند.

اشتباه چهارم: به‌روزرسانی نکردن RTM

Requirement تغییر کرده اما RTM همان نسخه قبلی باقی مانده است.

اشتباه پنجم: نادیده گرفتن Non-Functional Requirements

Performance، Security، Accessibility و سایر NFRها نیز ممکن است نیاز به Traceability داشته باشند.

اشتباه ششم: فرض اینکه هر Fail یک Defect است

Failure ابتدا باید Investigation شود.

اشتباه هفتم: Traceability بدون هدف

اگر نمی‌دانیم چرا یک Relationship را ثبت می‌کنیم، احتمالاً باید درباره ضرورت آن سؤال کنیم.

25.16 مهم‌ترین اصل حرفه‌ای RTM

اگر بخواهیم تمام این بخش را در یک جمله خلاصه کنیم:

یک RTM خوب، بیشترین اطلاعات ممکن را جمع نمی‌کند؛ اطلاعات درست را برای پاسخ دادن به سؤال‌های درست پروژه فراهم می‌کند. 🎯

یعنی وقتی پروژه از ما می‌پرسد:

«آیا این Requirement تست شده؟»

بتوانیم پاسخ دهیم.

وقتی می‌پرسد:

«این تغییر روی چه تست‌هایی اثر دارد؟»

بتوانیم پاسخ دهیم.

و وقتی می‌پرسد:

«این Defect مربوط به کدام Requirement است؟»

بتوانیم مسیر را دنبال کنیم.

این همان ارزش واقعی Requirements Traceability است. 🔗

“`

جمع‌بندی

یک RTM حرفه‌ای می‌تواند به تیم QA کمک کند تا ارتباط بین این Artefactها را دنبال کند:

Requirement ↕️ Component ↕️ Test Case ↕️ Test Result ↕️ Defect

اما لازم نیست همه این Relationshipها همیشه در یک جدول قرار بگیرند.

میزان Traceability باید متناسب با پیچیدگی، ریسک و نیاز پروژه باشد.

و مهم‌تر از همه:

هدف RTM این نیست که تعداد زیادی Relationship ثبت کنیم؛ هدف این است که بتوانیم سؤال‌های مهم پروژه را با استفاده از Traceability پاسخ دهیم. 🎯