تیستن جامعه مهندسین تست نرم‌افزار ایران
نوشته های مرتبط
ماتریس ردیابی(Traceability Matrix-TM) چیست؟
یک ماتریس ردیابی سندیست که هر مستند دو سویه‌ای که نیازمند رابطه چند به چند است را مرتبط می‌کند. هدف این مستند بررسی تکمیل بودن این ارتباطات است، تا بدین ترتیب مشخص شود، هر سند با چه اسنادی مرتبط است، و اسناد فاقد ارتباط کدام هستند. با این روش چیزی از قلم نخواهد افتاد و می‌توان بعدا برای اسناد بی ارتباط تعیین تکلیف نمود.
در صنعت نرم‌افزار از این ماتریس معمولا برای ردیابی نیازمندی‌ها و نیز بررسی برآورده شدن نیازمندی‌های جاری پروژه استفاده می‌شود.
ماتریس ردیابی نیازمندی‌ها(Requirements Traceability Matrix-RTM) چیست؟
ماتریس ردیابی نیازمندی‌ها یا RTM تمام نیازمندی‌های ارائه شده توسط تیم مشتری یا تیم توسعه نرم‌افزار و ارتباط آنها را در غالب یک سند ثبت کرده در پایان Lifecycle تحویل می‌دهد.
به عبارت دیگر، این محصول، سندیست که نیازمندی‌های کاربری را با Test Caseها مرتبط کرده و نگاشت می‌کند. هدف اصلی ماتریس ردیابی نیازمندی این است که ببینید همه Test Caseها پوشش داده شده‌اند، بنابراین با انجام تست، نباید بررسی هیچ Functionality از دست برود.
چرا RTM مهم است؟
دستورالعمل اصلی هر تستر باید درک نیازمندی مشتری و حصول اطمینان از این موضوع باشد که محصول خروجی بدون ایراد خواهد بود. برای دستیابی به این هدف، هر QA باید نیازمندی‌ها را کاملا درک کرده و Test Caseهای مثبت(Positive) و منفی(Negative) را ایجاد کند.
این بدان معنیست، نیازمندی‌های نرم‌افزاری که توسط مشتری ارائه می‌شود، باید به سناریوهای مختلف تقسیم شده و Test Caseهای بیشتری را تست کند. هر یک از این موارد باید به صورت جداگانه اجرا شوند.
سوالی که در اینجا بوجود می‌آید، چگونگی حصول اطمینان از این است که آیا نیازمندی‌ها با در نظر گرفتن تمام سناریوهای/ Test Caseهای ممکن تست شده‌اند یا خیر؟ چگونه می‌توان اطمینان حاصل کرد که هیچ نیازمندی از چرخه تست خارج نمی‌شود؟
یک راه ساده این است که نیازمندی را به Test Scenarioها و Test Caseهای متناظر آن مرتبط کرده و متصل نماییم. چنین چیزی “ماتریس ردیابی نیازمندی‌ها” یا Requirements Traceability Matrix-RTM نامیده می‌شود.
ماتریس ردیابی، معمولا یک برگه است که حاوی الزامات با همه سناریوهای تست احتمالی، Test Caseها و وضعیت(Status) فعلی(یعنی آنها Pass شده‌اند یا Fail). این به تیم تست کمک می‌کند تا سطح فعالیت‌های تست انجام شده برای یک محصول خاص را درک کنند.
کدام پارامترها برای قرارگیری در RTM نیاز هستند
- Requirement ID
- نوع نیازمندی شرح آن
- Test Caseها با وضعیت‌‌شان(Status)
در بالای یک نمونه ماتریس ردیابی نیازمندی ارائه شده است.
اما در یک پروژه تست نرم‌افزار معمول، ماتریس ردیابی بیشتر از این پارامترها را در خود خواهد گنجاند.
همان طور که در بالا نشان داده شده، یک ماتریس ردیابی احتمالی می‌تواند:
- پوشش نیازمندی(Requirement Coverage) را در تعداد Test Caseها نشان دهد
- وضعیت طراحی و همچنین وضعیت اجرای برای هر Test Case خاص
- در صورتیکه هر تست پذیرش کاربر(User Acceptance Test) توسط کاربر انجام شود، وضعیت UAT نیز می‌تواند در همان ماتریس ثبت شود
- نقص‌های مرتبط و وضعیت فعلی نیز می‌تواند در همان ماتریس ذکر شود
این نوع ماتریس می‌تواند یک مجموعه برای تمام فعالیت‌های تست ارائه دهد.
می‌توان این کار در یک شیت اکسل جداگانه انجام داد. علاوه بر این تیم تست می‌تواند برای ردیابی نیازمندی‌هاب موجود از ابزارهای مدیریت تست(Test Management Tools) استفاده نماید.
انواع ماتریس ردیابی تست(Traceability Test Matrix)
در مهندسی نرم‌افزار، ماتریس ردیابی می‌تواند به سه کامپوننت اصلی تقسیم شود:
- ردیابی به جلو(Forward Traceability): این ماتریس برای بررسی اینکه آیا پروژه در جهت مورد نظر و برای محصول مناسب پیشرفت می‌کند یا خیر، استفاده می‌شود. این ماتریس اطمینان حاصل می‌کند که هر نیازمندی برای محصول انجام شده و تحت تست قرار گرفته است. این ماتریس نیازمندی‌ها را Test Caseها نگاشت می‌کند.
- ردیابی بازگشتی یا رو به عقب(Backward or Reverse Traceability): برای اطمینان از اینکه آیا محصول فعلی در مسیر درست باقی می‌ماند، استفاده می‌شود. هدف پشت پرده این نوع ردیابی این است که تأیید کنیم محدوده پروژه با افزودن کد، عناصر طراحی، تست یا کار دیگری که در نیازمندی درج نشده است گسترش نمی‌یابد. این ماتریس Test Caseها را به نیازمندی‌ها نگاشت می‌کند.
- ردیابی دو طرفه/رو به جلو و عقب(Bi-Directional Traceability/Forward Backward): این ماتریس ردیابی، تضمین می‌کند که تمام نیازمندی‌ها توسط Test Caseها پوشش(Cover) داده می‌شوند. این ماتریس تأثیر یک تغییر در نیازمندی‌های متاثر شده بوسیله نقص در یک محصول و بالعکس را تحلیل می‌کند.
چگونه RTM را درست کنیم؟
بیایید مفهوم ماتریس ردیابی نیازمندی را از طریق پروژه بانکی بررسی کنیم.
بر اساس Business Requirement Document-BRD و Technical Requirement Document-TRD، تسترها شروع به نوشتن Test Case می‌کنند.
فرض کنید، جدول زیر، Business Requirement Document-BRD برای پروژه بانکی است.
در اینجا سناریو این است که مشتری باید قادر به ورود به وب سایت بانکداری با رمز عبور و user#id صحیح باشد. در حالی که مدیر باید قادر به ورود به وب سایت از طریق صفحه Login مشتری باشد.
جدول زیر Technical Requirement Document-TRD ماست.
توجه داشته باشید: تیم‌های QA مطالب مورد نیاز برای BRD و TRD را مستند نمی‌کنند. همچنین برخی از شرکت ها از Function Requirement Documents-FRD استفاده می‌کنند که شبیه به TRD است، اما فرآیند ایجاد ماتریس ردیابی به همان شکل باقی می‌ماند.
بیایید پیش برویم و RTM را در تست ایجاد کنیم.
مرحله ۱: Test Case مثالی ما به صورت زیر است
“تأیید ورود به سیستم: زمانی که ID و رمز عبور درست وارد می‌شود، باید با موفقیت وارد سیستم شوید”
مرحله ۲: شناسایی نیازهای فنی(Technical Requirement) که این Test Case آنرا ممیزی می‌کند. برای Test Case ما، نیازمندی فنی T94 است که تایید شده است.
مرحله ۳: به این نیازمندی فنی(T94) در این Test Case دقت کنید.
مرحله ۴: شناسایی Business Requirement که برای این TR(نیازمندی فنی-T94) تعریف شده است
مرحله ۵: به این نیازمندی کسب و کاری(BR-Business Requirement) در این Test Case دقت کنید.
Software Testing Figure 19-9
مرحله ۶: مراحل بالا را برای همه Test Caseها انجام دهید. بعدا ۳ ستون اول از Test Suite خود را استخراج کنید. RTM برای تست آماده است!
Software Testing Figure 19-10
مزایای RTM
- پوشش ۱۰۰% تست را تایید می‌کند
- هر گونه گم شدن Requirement یا تناقضات سندی را برجسته می‌کند
- وضعیت نواقص یا اجرای کلی را با تمرکز بر نیازمندی‌های کسب و کاری(Business Requirement) نشان می‌دهد
- در تحلیل یا برآورد تاثیر بر کار تیم QA(با توجه به بازنگری و یا دوباره کاری روی Test Caseها) کمک می‌کند
این مطلب بخشی از دوره آموزشی رایگان تست نرم‌افزار بود، که می‌توانید تمامی مطالب این دوره رایگان را در اینجا مشاهده نمایید.
