ماتریس ردیابی نیازمندی (Requirements Traceability Matrix یا RTM) جدولی است که هر نیازمندی را به تستها، نتیجهها و باگهای مرتبط وصل میکند. با ماتریس ردیابی نیازمندی میفهمید کدام نیازمندی تست شده، کدام نه، و هر تغییر روی کدام تستها اثر دارد. در این راهنما انواع RTM، ستونهای لازم و یک نمونه کامل را مرور میکنیم.
اگر تازه با مفاهیم تست آشنا میشوید، اول راهنمای تست نرمافزار چیست را بخوانید.
ماتریس ردیابی نیازمندی چیست
ردیابی یعنی بتوانید از یک نقطه به نقطه دیگر برسید. از نیازمندی به تست، از تست به نتیجه و از نتیجه به باگ. RTM این ارتباطها را در یک نما جمع میکند.
اجزای اصلی
- نیازمندی: چیزی که سیستم باید انجام دهد یا ویژگیای که باید داشته باشد.
- تستکیس: بررسیای که نشان میدهد نیازمندی برآورده شده است یا نه.
- نتیجه اجرا: وضعیت آخرین اجرای هر تستکیس.
- باگ: نقصهایی که هنگام تست آن نیازمندی پیدا شدهاند.
چه مسئلهای را حل میکند
- شکاف پوشش: نیازمندیهایی که هیچ تستی ندارند، فوراً دیده میشوند.
- تستهای بیصاحب: تستهایی که به هیچ نیازمندی فعلی وصل نیستند، شناسایی میشوند.
- تحلیل اثر تغییر: وقتی نیازمندی تغییر میکند، تستهای مرتبط مشخصاند.
- تصمیم انتشار: وضعیت هر نیازمندی پیش از انتشار روشن است.
- ممیزی و قرارداد: در پروژههای قراردادی یا حوزههای تحت نظارت، شواهد تست قابل ارائه است.
انواع ماتریس ردیابی
جهت ردیابی سه حالت رایج دارد:
| نوع | جهت ردیابی | به چه سؤالی پاسخ میدهد |
|---|---|---|
| ردیابی رو به جلو (Forward) | از نیازمندی به تست | آیا هر نیازمندی تست دارد |
| ردیابی رو به عقب (Backward) | از تست به نیازمندی | آیا هر تست به نیازمندی معتبری وصل است |
| ردیابی دوطرفه (Bidirectional) | هر دو جهت | پوشش کامل است و تست اضافه وجود ندارد |
بیشتر تیمها به ماتریس دوطرفه نیاز دارند. ردیابی رو به جلو شکاف پوشش را نشان میدهد. ردیابی رو به عقب تستهای منسوخ را پیدا میکند.
سطح جزئیات
RTM میتواند در سطوح مختلف ساخته شود:
- سطح نیازمندی کسبوکار: برای گزارش به مدیران و ذینفعان.
- سطح داستان کاربری یا نیازمندی عملکردی: رایجترین سطح برای تیمهای چابک.
- سطح معیار پذیرش: دقیقترین سطح؛ هر معیار پذیرش به تستکیس خود وصل میشود.
سطحی را انتخاب کنید که بتوانید نگهداریاش کنید. ماتریس خیلی ریز که بهروز نمیماند، از ماتریس سادهتر اما دقیق کمارزشتر است.
ستونهای اصلی ماتریس
یک RTM کاربردی معمولاً این ستونها را دارد:
- شناسه نیازمندی: مثلاً REQ-12 یا شماره داستان کاربری در Jira.
- شرح کوتاه نیازمندی: یک خط، کافی برای شناسایی.
- اولویت یا ریسک نیازمندی: برای تمرکز روی موارد مهمتر.
- شناسه تستکیسها: یک یا چند تستکیس مرتبط.
- نوع تست: دستی یا خودکار، عملکردی یا غیرعملکردی.
- وضعیت آخرین اجرا: پاس، شکست، مسدود یا اجرا نشده.
- شناسه باگهای مرتبط: با وضعیت فعلی هر باگ.
- نسخه یا بیلد: نتیجه روی کدام نسخه ثبت شده است.
- یادداشت: توضیح شکاف یا ریسک باقیمانده.
ستونهای اضافه مثل مالک نیازمندی یا تاریخ آخرین تغییر هم مفیدند. اما ستونها را فقط به اندازه نیاز واقعی اضافه کنید.
نمونه ماتریس ردیابی نیازمندی
فرض کنید در حال تست ماژول ورود و حساب کاربری یک فروشگاه آنلاین هستید:
| شناسه نیازمندی | شرح | اولویت | تستکیسها | وضعیت آخرین اجرا | باگها | یادداشت |
|---|---|---|---|---|---|---|
| REQ-01 | ورود با ایمیل و رمز عبور | بالا | C101، C102، C103 | پاس | — | پوشش کامل |
| REQ-02 | قفل حساب بعد از پنج تلاش ناموفق | بالا | C104، C105 | شکست | BUG-231 (باز) | مانع انتشار |
| REQ-03 | بازیابی رمز عبور با ایمیل | بالا | C106 | مسدود | — | سرویس ایمیل محیط تست در دسترس نیست |
| REQ-04 | ورود با کد یکبارمصرف پیامکی | متوسط | C107، C108 | پاس | BUG-219 (بسته) | پس از رفع، تست مجدد پاس شد |
| REQ-05 | خروج خودکار بعد از ۳۰ دقیقه عدم فعالیت | متوسط | — | اجرا نشده | — | تستکیس نوشته نشده؛ شکاف پوشش |
| REQ-06 | نمایش تاریخچه ورودهای اخیر | پایین | C109 | پاس | — | — |
خواندن این نمونه
- REQ-02 یک باگ باز دارد و روی نیازمندی با اولویت بالاست. این مورد باید در گزارش انتشار برجسته شود.
- REQ-03 مسدود است. مشکل از محیط است، نه از محصول. اما تا رفع آن، وضعیت نیازمندی نامعلوم است.
- REQ-05 هیچ تستی ندارد. این همان شکافی است که RTM برای پیدا کردنش ساخته میشود.
از روی همین جدول، پوشش تست نیازمندیها هم محاسبه میشود. پنج نیازمندی از شش مورد حداقل یک تست دارند.
ساختن RTM گامبهگام
- فهرست نیازمندیها را جمع کنید: از سند نیازمندی، داستانهای کاربری یا بکلاگ محصول. هر نیازمندی باید شناسه یکتا داشته باشد.
- نیازمندیهای مبهم را روشن کنید: نیازمندیای که قابل تست نیست، باید پیش از ادامه با مالک محصول بازنویسی شود.
- تستکیسها را طراحی و وصل کنید: برای هر نیازمندی، تستکیسهای مثبت و منفی بنویسید. شیوه نوشتن را در راهنمای نوشتن تستکیس ببینید.
- ردیابی رو به عقب را بررسی کنید: تستهایی که به هیچ نیازمندی وصل نیستند را بررسی کنید. یا نیازمندی گمشده را پیدا کنید، یا تست را حذف کنید.
- نتیجه اجراها را وارد کنید: بعد از هر اجرا، ستون وضعیت بهروز شود.
- باگها را وصل کنید: هر باگ به تستکیس و از طریق آن به نیازمندی مرتبط شود.
- مالک و زمان بهروزرسانی را تعیین کنید: بدون مالک، ماتریس بعد از چند هفته کهنه میشود.
نیازمندی قابل تست چه ویژگیهایی دارد
گام دوم معمولاً از همه مهمتر است. نیازمندیای مثل «سیستم باید سریع باشد» قابل تست نیست. چون معیار روشنی برای پاس یا شکست ندارد. نیازمندی قابل تست این ویژگیها را دارد:
- مشخص: دقیقاً میگوید چه چیزی باید اتفاق بیفتد.
- قابل اندازهگیری: عدد، شرط یا نتیجه قابل مشاهده دارد؛ مثلاً «صفحه نتایج در کمتر از دو ثانیه بارگذاری شود».
- بدون تناقض: با نیازمندیهای دیگر در تضاد نیست.
- مستقل از راهحل: رفتار را توصیف میکند، نه جزئیات پیادهسازی را.
هر ابهامی که در این مرحله روشن شود، بعداً یک باگ یا یک بحث طولانی کمتر است.
RTM در تیمهای چابک
در تیمهای چابک سند نیازمندی بزرگ و ثابتی وجود ندارد. نیازمندیها در قالب داستان کاربری و در طول اسپرینتها شکل میگیرند. این به معنی بینیازی از ردیابی نیست. فقط شکل آن سبکتر میشود.
- هر داستان کاربری شناسهای در ابزار بکلاگ دارد. همین شناسه نقش شناسه نیازمندی را بازی میکند.
- معیارهای پذیرش هر داستان، پایه طراحی تستکیسها هستند.
- اتصال تست به داستان هنگام نوشتن تست انجام میشود، نه در پایان پروژه.
- در بازبینی اسپرینت، وضعیت تست داستانها بخشی از تعریف «انجامشده» است.
به این ترتیب ماتریس بهصورت تدریجی ساخته میشود. در پایان هر اسپرینت هم یک نمای بهروز از پوشش در دسترس است.
نمونه ردیابی رو به عقب
ردیابی رو به عقب از سمت تستها شروع میشود. مثلاً در همان ماژول ورود:
| تستکیس | نیازمندی مرتبط | نتیجه بررسی |
|---|---|---|
| C101 | REQ-01 | معتبر |
| C110 | — | به نیازمندی فعلی وصل نیست؛ مربوط به ورود با شبکه اجتماعی است که از محصول حذف شده |
| C111 | REQ-02 | معتبر، اما شرط پنج تلاش را با سه تلاش بررسی میکند؛ باید اصلاح شود |
این بررسی دو نتیجه دارد. تست C110 از مجموعه حذف یا بایگانی میشود. تست C111 با نیازمندی فعلی هماهنگ میشود.
جایگاه RTM در مستندات تست
محل نگهداری RTM، مالک آن و زمان بهروزرسانیاش را در طرح تست مشخص کنید. در گزارش پایان تست هم خلاصهای از آن بیاورید.
استفاده عملی از ماتریس
ماتریس فقط برای ممیزی نیست. در کار روزمره هم کاربرد مستقیم دارد.
پیدا کردن شکاف پوشش
ماتریس را بر اساس ستون تستکیس فیلتر کنید و ردیفهای خالی را ببینید. این ردیفها کار بعدی طراحی تست هستند. نیازمندیهای با اولویت بالا را اول پوشش دهید.
تحلیل اثر تغییر
وقتی یک نیازمندی تغییر میکند، تستکیسهای مرتبطش را از ماتریس پیدا کنید. این تستها باید بهروز و دوباره اجرا شوند. تستهای نیازمندیهای وابسته هم نامزد تست رگرسیون هستند.
تصمیم انتشار
پیش از انتشار، ماتریس را بر اساس وضعیت مرتب کنید. هر نیازمندی با اولویت بالا که شکست خورده، مسدود است یا تست ندارد، باید در جلسه تصمیم انتشار بررسی شود.
ردیابی نیازمندیهای غیرعملکردی
نیازمندیهایی مثل زمان پاسخ، تحمل بار یا الزامات امنیتی هم باید در ماتریس بیایند. تست آنها معمولاً با ابزار و محیط جداگانه انجام میشود. به همین دلیل گاهی از ماتریس جا میمانند. برای این نیازمندیها، ستون نوع تست را دقیق پر کنید و نتیجه گزارش ابزار را به ردیف مربوط پیوند دهید.
گفتگو با ذینفعان
مدیر محصول معمولاً به زبان نیازمندی فکر میکند، نه تستکیس. RTM گزارش تست را به زبان او ترجمه میکند. بهجای «۸۵ تست پاس شد» میگویید «از ۲۰ نیازمندی، ۱۷ مورد کامل تأیید شده است».
اشتباهات رایج
- ماتریس دستی و کهنه: اگر بهروزرسانی ماتریس کار جداگانهای باشد، بهزودی فراموش میشود. ارتباطها را جایی ثبت کنید که بخشی از کار روزمره است.
- یک تست برای یک نیازمندی پیچیده: وجود یک تست به معنی پوشش کامل نیست. حالتهای منفی و مرزی هم لازماند.
- شمارش بهجای تحلیل: عدد پوشش بالا با تستهای سطحی گمراهکننده است.
- بیتوجهی به نیازمندیهای غیرعملکردی: کارایی، امنیت و دسترسپذیری هم نیازمندیاند و باید ردیابی شوند.
- نبود شناسه یکتا: بدون شناسه، اتصال پایدار بین نیازمندی و تست ممکن نیست.
اگر تیم شما هنوز در صفحهگسترده کار میکند، مقاله مقایسه ابزارهای مدیریت تست کمک میکند گزینهها را بسنجید.
در TestRail هر تستکیس فیلد References دارد که شناسه نیازمندی یا داستان کاربری Jira در آن ثبت میشود. با اتصال به Jira، این ارجاعها قابل کلیکاند و از سمت Jira هم میتوان تستها و نتیجههای مرتبط را دید. گزارشهای پوشش بر اساس ارجاعها نشان میدهند کدام نیازمندی تست دارد و آخرین نتیجه آن چیست. به این ترتیب ماتریس ردیابی از کار روزمره ساخته میشود، نه با بهروزرسانی دستی یک فایل جدا. برای آشنایی با ساختار کلی این امکانات، صفحه پلتفرم TestRail را ببینید.
جمعبندی
ماتریس ردیابی نیازمندی هر نیازمندی را به تستها، نتیجهها و باگهایش وصل میکند. با آن شکاف پوشش، اثر تغییرات و آمادگی انتشار روشن میشود. سطح جزئیات را متناسب با توان نگهداری انتخاب کنید و برای ماتریس مالک مشخص بگذارید. بهترین ماتریس، ماتریسی است که از کار روزمره تیم بهروز میشود. برای مرور مفاهیم پایه، به راهنمای تست نرمافزار برگردید.