وقتی صحبت از تست نرمافزار میشود، معمولاً ذهن ما به سمت Test Case، Test Execution و Bug Reporting میرود؛ اما بخش مهمی از کار Tester خیلی قبلتر از اجرای اولین تست شروع میشود.
یک تستر حرفهای باید بداند نرمافزار دقیقاً قرار است چه رفتاری داشته باشد و این رفتار مورد انتظار از کجا مشخص میشود. یکی از منابع مهمی که میتواند پاسخ این سؤال را در اختیار تیم قرار دهد، FRD یا Functional Requirements Document است.
FRD سندی است که نیازمندیها و رفتارهای عملکردی مورد انتظار سیستم را مستند میکند. اما برای یک Tester، شناخت FRD فقط به معنی دانستن تعریف این سند نیست؛ مهمتر از آن، توانایی خواندن، تحلیل و تبدیل نیازمندیها به سناریوهای قابل تست است.
در این مقاله میخواهیم FRD را از دید یک تستر بررسی کنیم؛ از اینکه FRD چیست و معمولاً چه بخشهایی دارد، تا نحوه تحلیل نیازمندیها ، شناسایی ابهامها، استخراج Test Scenario و Test Case، ارتباط با Acceptance Criteria و Requirement Traceability و در نهایت Workflow واقعی Tester از دریافت FRD تا اجرای تست.
همچنین بررسی میکنیم که FRD در پروژههای Agile و Scrum چه جایگاهی دارد و چرا حتی در پروژههایی که سندی با عنوان FRD وجود ندارد، مهارت Requirement Analysis همچنان برای Tester اهمیت زیادی دارد.
هدف این مقاله این نیست که یک قالب خاص از FRD را حفظ کنید؛ بلکه میخواهیم یاد بگیریم چگونه وقتی با یک Requirement یا سند نیازمندی مواجه میشویم، از خودمان سؤالهای درست بپرسیم و آن را به یک ورودی مؤثر برای فعالیتهای Testing و QA تبدیل کنیم.
۱. FRD چیست؟
FRD مخفف Functional Requirements Document است که میتوان آن را سند نیازمندیهای عملکردی ترجمه کرد.
اگر بخواهیم خیلی ساده بگوییم، FRD سندی است که مشخص میکند:
سیستم باید چه قابلیتهایی داشته باشد و در مقابل ورودیها و شرایط مختلف، چه رفتار عملکردی از خود نشان دهد.
برای مثال، فرض کنید قرار است یک سیستم فروشگاه اینترنتی ساخته شود. یکی از قابلیتهای آن، ورود کاربران است. در FRD ممکن است رفتار این قابلیت بهصورت زیر مشخص شود:
- کاربر شماره موبایل خود را وارد میکند.
- سیستم شماره موبایل را بررسی میکند.
- یک کد تأیید برای کاربر ارسال میشود.
- کاربر کد تأیید را وارد میکند.
- اگر کد صحیح باشد، کاربر وارد حساب خود میشود.
- اگر کد اشتباه باشد، سیستم پیام خطای مناسب نمایش میدهد.
در واقع FRD تلاش میکند رفتار مورد انتظار سیستم را پیش از پیادهسازی، به شکلی مشخص و قابل فهم مستند کند.
چرا به FRD نیاز داریم؟
در یک پروژه نرمافزاری افراد مختلفی با یک قابلیت درگیر هستند. برای مثال، Business Analyst ممکن است نیازمندی را تحلیل و مستند کند، Developer آن را پیادهسازی کند و Tester عملکرد پیادهسازیشده را بررسی کند.
اگر هرکدام از این افراد برداشت متفاوتی از رفتار مورد انتظار سیستم داشته باشند، احتمال بروز خطا و اختلاف در مراحل بعدی افزایش پیدا میکند.
FRD میتواند بهعنوان یک مرجع مشترک کمک کند تا تیم درک یکسانی از این سؤال داشته باشد:
«قرار است سیستم از نظر عملکردی دقیقاً چه کاری انجام دهد؟»
بنابراین FRD فقط یک سند برای Developer نیست. Tester نیز برای طراحی و اجرای تست به درک مشخصی از رفتار مورد انتظار سیستم نیاز دارد.
یک نکته مهم درباره FRD
نباید تصور کنیم که همه شرکتها یا پروژهها دقیقاً از یک قالب ثابت برای FRD استفاده میکنند.
ساختار، میزان جزئیات و حتی نام این سند ممکن است از سازمانی به سازمان دیگر متفاوت باشد. در بعضی پروژهها نیازمندیهای عملکردی در قالب سندی با عنوان FRD مستند میشوند و در برخی دیگر ممکن است همین اطلاعات در اسناد یا ابزارهای دیگری مانند SRS، User Story و Acceptance Criteria قرار داشته باشند.
بنابراین چیزی که اهمیت دارد، صرفاً نام FRD یا قالب ظاهری آن نیست؛ بلکه این است که نیازمندیهای عملکردی و رفتار مورد انتظار سیستم به شکلی واضح و قابل فهم مشخص شده باشند.
از دید Tester نیز این نکته مهم است که بداند FRD تنها منبع اطلاعاتی برای طراحی تست نیست و بسته به پروژه ممکن است لازم باشد از منابع دیگری مانند Acceptance Criteria، User Story، SRS و Business Rules نیز استفاده کند.
در ادامه ابتدا بررسی میکنیم که یک FRD معمولاً شامل چه بخشهایی است و چه اطلاعاتی میتواند در اختیار Tester قرار دهد.
۲. FRD معمولاً شامل چه بخشهایی است؟
حالا که با مفهوم کلی FRD آشنا شدیم، سؤال بعدی این است:
داخل یک FRD چه اطلاعاتی قرار میگیرد؟
پاسخ این سؤال یک قالب کاملاً ثابت ندارد. شرکتها و پروژههای مختلف ممکن است ساختارهای متفاوتی برای FRD داشته باشند، اما معمولاً این سند اطلاعاتی را شامل میشود که به تیم کمک میکند قابلیتهای سیستم و رفتار مورد انتظار آنها را بهتر درک کند.
برای مثال، یک FRD میتواند شامل بخشهای زیر باشد.
۲.۱. معرفی و هدف سند
در ابتدای سند معمولاً مشخص میشود که FRD مربوط به چه محصول یا پروژهای است و با چه هدفی تهیه شده است.
مثلاً:
هدف این سند، مشخص کردن نیازمندیهای عملکردی سیستم فروشگاه اینترنتی است.
این بخش بیشتر برای ایجاد یک دید کلی نسبت به سند استفاده میشود.
۲.۲. محدوده سیستم
در این قسمت مشخص میشود که FRD چه بخشهایی از سیستم را پوشش میدهد و چه بخشهایی خارج از محدوده آن هستند.
مثلاً اگر پروژه مربوط به یک فروشگاه اینترنتی باشد، قابلیتهای زیر ممکن است در محدوده قرار داشته باشند:
- ثبتنام و ورود کاربر
- جستوجوی محصول
- سبد خرید
- ثبت سفارش
- پرداخت
در مقابل، ممکن است سیستم حسابداری شرکت خارج از محدوده این FRD باشد.
برای Tester، دانستن Scope اهمیت زیادی دارد؛ چون کمک میکند درک کند چه قابلیتهایی در محدوده بررسی قرار دارند و چه مواردی خارج از این محدوده هستند.
۲.۳. Functional Requirements
این بخش معمولاً یکی از مهمترین قسمتهای FRD است.
در این قسمت مشخص میشود که سیستم چه قابلیتها و عملکردهایی باید داشته باشد.
مثلاً:
سیستم باید به کاربر اجازه دهد محصول را به سبد خرید اضافه کند.
یا:
سیستم باید امکان حذف محصول از سبد خرید را برای کاربر فراهم کند.
هر Functional Requirement میتواند یک شناسه مشخص داشته باشد، مانند:
- FR-001: ورود کاربر
- FR-002: جستوجوی محصول
- FR-003: افزودن محصول به سبد خرید
- FR-004: حذف محصول از سبد خرید
وجود شناسه برای Tester بسیار مفید است، زیرا امکان برقراری ارتباط بین Requirement و موارد تست مانند Test Scenario و Test Case را سادهتر میکند.
۲.۴. Business Rules
گاهی برای مشخص کردن رفتار سیستم، توضیح یک قابلیت بهتنهایی کافی نیست و باید قوانین کسبوکار نیز مشخص شوند.
مثلاً:
- کاربر نمیتواند بیشتر از تعداد موجودی محصول سفارش دهد.
- اگر مبلغ سفارش بیشتر از ۵ میلیون تومان باشد، هزینه ارسال رایگان است.
این قوانین میتوانند مستقیماً روی طراحی تست تأثیر بگذارند.
برای مثال، در مورد قانون دوم Tester فقط مبلغ ۵ میلیون تومان را بررسی نمیکند؛ بلکه احتمالاً شرایط مختلفی مانند موارد زیر را نیز در نظر میگیرد:
- کمتر از ۵ میلیون
- دقیقاً ۵ میلیون
- بیشتر از ۵ میلیون
بنابراین Business Ruleها میتوانند منبع مهمی برای شناسایی شرایط تست و Boundary باشند.
۲.۵. ورودیها و خروجیها
در برخی FRDها مشخص میشود که یک قابلیت چه Inputهایی دریافت میکند و چه Outputهایی ایجاد میکند.
مثلاً برای ورود کاربر:
Input:
- شماره موبایل
- کد تأیید
Output:
- ورود موفق به حساب کاربری
- یا نمایش پیام خطا
این اطلاعات برای Tester اهمیت زیادی دارند، زیرا به او کمک میکنند شرایط ورودی و Expected Result را بهتر مشخص کند.
۲.۶. رفتار سیستم در شرایط مختلف
یک Requirement مناسب فقط مسیر موفقیتآمیز را توصیف نمیکند؛ بلکه در صورت نیاز باید رفتار سیستم در شرایط مختلف نیز مشخص شود.
مثلاً:
اگر کد تأیید اشتباه باشد، سیستم باید پیام خطای مناسب نمایش دهد.
یا:
اگر موجودی محصول کافی نباشد، سیستم نباید اجازه ثبت سفارش را بدهد.
این بخش برای Tester اهمیت ویژهای دارد، زیرا رفتار سیستم در شرایط غیرعادی و خطا میتواند مستقیماً به Negative Scenarioهای تست تبدیل شود.
Tester هنگام مطالعه Requirement میتواند سؤالهایی مانند این مطرح کند:
- اگر ورودی نامعتبر باشد چه اتفاقی میافتد؟
- اگر داده موردنیاز وجود نداشته باشد چه؟
- اگر یکی از شرایط لازم برقرار نباشد چه؟
پاسخ این سؤالها میتواند به شناسایی سناریوهایی کمک کند که در مسیر اصلی عملکرد سیستم دیده نمیشوند.
۲.۷. محدودیتها و شرایط خاص
ممکن است برای بعضی قابلیتها محدودیتهایی وجود داشته باشد.
مثلاً:
- کاربر حداکثر میتواند ۱۰ عدد از یک محصول را به سبد خرید اضافه کند.
- کد تأیید فقط ۲ دقیقه اعتبار دارد.
چنین محدودیتهایی برای Tester اهمیت زیادی دارند، زیرا معمولاً فرصت مناسبی برای طراحی Boundary Test ایجاد میکنند.
برای مثال، اگر حداکثر تعداد مجاز ۱۰ باشد، مقادیر ۹، ۱۰ و ۱۱ میتوانند برای بررسی Boundary مورد توجه قرار گیرند.
۲.۸. وابستگیها و تعامل با سایر بخشها
بعضی قابلیتها به بخشهای دیگر سیستم یا حتی سیستمهای خارجی وابسته هستند.
برای مثال، فرآیند ثبت سفارش ممکن است با بخشهای زیر در ارتباط باشد:
سبد خرید → سیستم موجودی → سیستم پرداخت → سیستم ارسال
مشخص شدن این وابستگیها به Tester کمک میکند جریان کامل قابلیت را بهتر درک کند و شرایطی را که ممکن است یک وابستگی در دسترس نباشد، شناسایی کند.
برای مثال:
اگر سرویس پرداخت در دسترس نباشد، رفتار مورد انتظار سیستم چیست؟
اگر این رفتار مشخص نشده باشد، موضوع میتواند برای Requirement Clarification مطرح شود.
نکته مهم برای Tester
Tester نباید FRD را صرفاً بخواند تا متوجه شود:
«سیستم چه کاری انجام میدهد؟»
بلکه باید آن را از زاویه قابلیت تست و کیفیت Requirement نیز بررسی کند.
هنگام مطالعه FRD میتوان سؤالهایی مانند این را مطرح کرد:
- آیا Requirement واضح است؟
- آیا اطلاعات کافی برای درک رفتار سیستم وجود دارد؟
- آیا شرایط خطا مشخص شده است؟
- آیا محدودیتها و Boundaryها مشخص هستند؟
- آیا رفتار سیستم در شرایط مختلف تعریف شده است؟
- آیا Requirement قابل تست است؟
- آیا بین Requirementهای مختلف تناقضی وجود دارد؟
- آیا وابستگیهای مهم مشخص شدهاند؟
به همین دلیل، FRD میتواند حتی پیش از شروع Test Execution، به یکی از ورودیهای مهم فعالیتهای QA تبدیل شود.
در بخش بعدی، سراغ یکی از سؤالهای مهم میرویم:
FRD چه تفاوتی با BRD و SRS دارد؟
۳. تفاوت FRD با BRD و SRS چیست؟
وقتی با FRD آشنا میشویم، معمولاً خیلی زود با دو اصطلاح دیگر نیز مواجه میشویم:
هر سه میتوانند با نیازمندیهای یک پروژه نرمافزاری مرتبط باشند، اما هدف، سطح جزئیات و نحوه استفاده از آنها لزوماً یکسان نیست.
برای یک درک اولیه میتوان این سه مفهوم را بهصورت زیر در نظر گرفت:
BRD → کسبوکار چه میخواهد؟
FRD → سیستم از نظر عملکردی چه کاری باید انجام دهد؟
SRS → نیازمندیها و مشخصات نرمافزار چگونه باید بهصورت ساختاریافته تعریف شوند؟
البته این تقسیمبندی یک قانون جهانی نیست. در پروژههای واقعی، مرز بین این اسناد میتواند بر اساس سازمان، متدولوژی توسعه و روش مستندسازی متفاوت باشد.
۳.۱. BRD چیست؟
BRD مخفف Business Requirements Document است؛ یعنی سند نیازمندیهای کسبوکار.
تمرکز BRD بیشتر روی هدف، مسئله و نیاز کسبوکار است، نه جزئیات رفتار نرمافزار.
برای مثال، فرض کنید یک فروشگاه اینترنتی قصد دارد امکان خرید آنلاین محصولات را فراهم کند.
در BRD ممکن است چنین نیازی مطرح شود:
«کسبوکار باید امکان خرید آنلاین محصولات را برای مشتریان فراهم کند.»
در این سطح هنوز وارد جزئیاتی مانند نحوه انتخاب محصول، اعتبارسنجی موجودی یا پیام خطای سیستم نشدهایم.
۳.۲. FRD چه چیزی را مشخص میکند؟
FRD یک گام به سمت رفتار عملکردی سیستم میآید.
برای همان مثال، ممکن است در FRD مشخص شود:
کاربر باید بتواند محصول را به سبد خرید اضافه کند.
سپس جزئیات عملکردی بیشتری مشخص شود، مانند:
- محصول باید موجود باشد.
- کاربر باید بتواند تعداد موردنظر را انتخاب کند.
- تعداد انتخابشده نباید از موجودی بیشتر باشد.
- در صورت موفقیت، محصول باید در سبد خرید نمایش داده شود.
- در صورت کافی نبودن موجودی، سیستم باید رفتار مشخصی داشته باشد.
در اینجا دیگر درباره نحوه عملکرد مورد انتظار سیستم صحبت میکنیم.
۳.۳. SRS چیست؟
SRS مخفف Software Requirements Specification است.
SRS معمولاً برای مستندسازی ساختاریافته نیازمندیها و مشخصات نرمافزار استفاده میشود و میتواند بر اساس پروژه شامل اطلاعات مختلفی باشد؛ از جمله:
- نیازمندیهای عملکردی
- نیازمندیهای غیرعملکردی
- رابطهای سیستم
- محدودیتها
- قواعد و مشخصات مرتبط با نرمافزار
بنابراین بهتر است SRS را صرفاً «نسخه فنیتر FRD» در نظر نگیریم.
در برخی سازمانها FRD بخشی از اطلاعات موردنیاز SRS را پوشش میدهد، در برخی پروژهها ممکن است این اسناد همپوشانی زیادی داشته باشند و در برخی دیگر اصلاً از FRD بهعنوان یک سند مستقل استفاده نشود.
پس رابطه دقیق FRD و SRS به ساختار مستندسازی همان پروژه بستگی دارد.
۳.۴. یک مثال ساده برای درک تفاوت
فرض کنیم میخواهیم قابلیت خرید آنلاین را برای یک فروشگاه ایجاد کنیم.
میتوان تفاوت این اسناد را بهصورت ساده اینگونه تصور کرد:
BRD:
مشتری باید بتواند محصولات را بهصورت آنلاین خریداری کند.
⬇️
FRD:
کاربر باید بتواند محصول را به سبد خرید اضافه کند، تعداد محصول را مشخص کند و سفارش خود را ثبت کند.
⬇️
SRS:
نیازمندیها و مشخصات نرمافزار مربوط به این قابلیت بهصورت ساختاریافته مستند میشوند؛ از جمله رفتارهای مورد انتظار، ورودیها و خروجیها، رابطها، محدودیتها و سایر مشخصات مرتبط.
در نتیجه میتوان برای درک اولیه این مسیر را در ذهن داشت:
Business Need → Functional Behavior → Software Specification
اما در پروژه واقعی ممکن است این مرزبندی دقیقاً به همین شکل اجرا نشود.
۳.۵. این تفاوت برای Tester چه اهمیتی دارد؟
برای Tester، دانستن تفاوت این اسناد فقط یک موضوع تئوری نیست.
وقتی تستر بداند هر سند معمولاً چه نوع اطلاعاتی را در اختیار او قرار میدهد، راحتتر میتواند منبع مناسب برای پاسخ به سؤال خود را پیدا کند.
مثلاً اگر سؤال این باشد:
«چرا این قابلیت باید وجود داشته باشد؟»
احتمالاً باید سراغ Business Requirement یا مستندات محصول رفت.
اگر سؤال این باشد:
«این قابلیت از نظر عملکردی چگونه باید رفتار کند؟»
FRD میتواند منبع مناسبی باشد.
و اگر سؤال این باشد:
«نیازمندیها و مشخصات نرمافزار چگونه بهصورت ساختاریافته تعریف شدهاند؟»
ممکن است SRS یا سایر مستندات نیازمندی نرمافزار پاسخ را ارائه کنند.
بنابراین برای Tester، مهمتر از حفظ کردن نام اسناد این است که بداند:
هر سند چه هدفی دارد و برای پیدا کردن چه نوع اطلاعاتی باید به آن مراجعه کند.
در بخش بعدی، به موضوعی میرسیم که مستقیماً به فعالیت Tester مربوط میشود:
۴. چرا FRD برای تست نرمافزار اهمیت دارد؟ 🔍
ممکن است در نگاه اول تصور کنیم FRD بیشتر برای Business Analyst و Developer اهمیت دارد و Tester فقط زمانی به آن نیاز پیدا میکند که نرمافزار برای تست آماده شده باشد.
اما Tester میتواند خیلی زودتر از مرحله اجرای تست از FRD استفاده کند؛ زیرا برای اینکه بتوانیم مشخص کنیم نرمافزار درست کار میکند یا نه، ابتدا باید بدانیم رفتار مورد انتظار چیست.
FRD میتواند یکی از منابع اصلی برای درک این رفتار مورد انتظار باشد و به Tester کمک کند از مرحله بررسی Requirement تا طراحی و اجرای تست، مسیر مشخصتری داشته باشد.
۴.۱. FRD به Tester میگوید چه چیزی باید تست شود
فرض کنید در FRD نوشته شده است:
سیستم باید به کاربر اجازه دهد محصول را به سبد خرید اضافه کند.
Tester با خواندن این Requirement متوجه میشود که یکی از قابلیتهایی که باید بررسی شود، افزودن محصول به سبد خرید است.
اما تست نباید فقط به یک مسیر موفق محدود شود. Tester باید بررسی کند این قابلیت در شرایط مختلف چه رفتاری دارد؛ برای مثال:
- محصول موجود باشد.
- محصول ناموجود باشد.
- تعداد انتخابشده بیشتر از موجودی باشد.
- محصول قبلاً در سبد خرید وجود داشته باشد.
- کاربر مهمان باشد یا وارد حساب خود شده باشد.
بنابراین FRD میتواند نقطه شروعی برای شناسایی Test Scenarioهای مختلف باشد.
۴.۲. FRD به Tester میگوید نتیجه مورد انتظار چیست
یکی از مهمترین مفاهیم در تست نرمافزار، Expected Result است.
فرض کنید Tester محصولی را به سبد خرید اضافه میکند و محصول در سبد نمایش داده میشود. آیا تست موفق بوده است؟
برای پاسخ به این سؤال باید بدانیم سیستم دقیقاً چه رفتاری باید داشته باشد.
مثلاً اگر FRD مشخص کرده باشد:
پس از اضافه شدن محصول، سیستم باید نام محصول، تعداد و قیمت آن را در سبد خرید نمایش دهد.
حالا Tester معیار مشخصی برای مقایسه رفتار واقعی با رفتار مورد انتظار دارد:
FRD → Expected Behavior
Software → Actual Behavior
تست با مقایسه این دو، مشخص میکند که رفتار پیادهسازیشده با Requirement سازگار است یا خیر.
۴.۳. FRD به طراحی Test Case کمک میکند
Tester میتواند اطلاعات موجود در FRD را به شرایط مختلف تست و سپس به Test Case تبدیل کند.
برای مثال، Requirement زیر را در نظر بگیرید:
کاربر نمیتواند بیشتر از موجودی محصول سفارش دهد.
از همین Requirement میتوان شرایط مختلفی برای تست استخراج کرد:
| موجودی | تعداد درخواستی | نتیجه مورد انتظار |
|---|---|---|
| 10 | 5 | سفارش مجاز باشد |
| 10 | 10 | سفارش مجاز باشد |
| 10 | 11 | سفارش مجاز نباشد |
در این مثال، Tester فقط مسیر موفق را بررسی نمیکند؛ بلکه شرایط مرزی و حالت نامعتبر را نیز در نظر میگیرد.
۴.۴. FRD به پیدا کردن Requirementهای ناقص کمک میکند
یکی از ارزشمندترین کاربردهای FRD برای Tester این است که تستر میتواند خود Requirement را نیز بررسی کند.
فرض کنید در FRD نوشته شده است:
کاربر باید بتواند رمز عبور خود را تغییر دهد.
در نگاه اول Requirement قابل فهم است، اما Tester ممکن است سؤالهایی مانند این موارد مطرح کند:
- حداقل طول رمز جدید چقدر است؟
- آیا رمز قبلی باید وارد شود؟
- اگر رمز جدید با رمز قبلی یکسان باشد چه اتفاقی میافتد؟
- اگر کاربر اطلاعات اشتباه وارد کند چه میشود؟
- آیا محدودیتی برای تعداد تلاشهای ناموفق وجود دارد؟
اگر پاسخ این سؤالها مشخص نباشد، ممکن است Requirement برای پیادهسازی و تست به اندازه کافی دقیق نباشد.
۴.۵. FRD به جلوگیری از تست بر اساس حدس و فرض کمک میکند
گاهی Tester با رفتاری مواجه میشود که در مستندات مشخص نشده است.
مثلاً:
اگر کاربر محصولی را که موجودی آن صفر است به سبد خرید اضافه کند، چه اتفاقی باید بیفتد؟
اگر Requirement درباره این وضعیت چیزی نگفته باشد، Tester نباید صرفاً بر اساس حدس شخصی تصمیم بگیرد که چه رفتاری درست است.
بهتر است موضوع با فرد یا تیم مسئول Requirement، مانند Business Analyst یا Product Owner، شفاف شود.
تجربه Tester برای کشف سناریوهای احتمالی و پرسیدن سؤالهای درست بسیار مهم است، اما تصمیم درباره رفتار مورد انتظار نباید صرفاً بر اساس حدس Tester باشد.
۴.۶. FRD میتواند به Traceability کمک کند
در پروژههای بزرگ، لازم است بتوانیم ارتباط بین Requirementها و Test Caseها را مشخص کنیم.
برای مثال:
FR-001: ورود کاربر
- TC-001: ورود با اطلاعات صحیح
- TC-002: ورود با رمز اشتباه
- TC-003: ورود با کاربر نامعتبر
- TC-004: ورود با فیلد خالی
این ارتباط کمک میکند بررسی کنیم آیا برای Requirementهای موردنظر تست مناسب وجود دارد یا خیر.
همچنین اگر Requirement تغییر کند، Traceability کمک میکند سریعتر تشخیص دهیم کدام Test Caseها باید بازبینی یا اصلاح شوند.
۴.۷. FRD میتواند قبل از نوشته شدن کد به Tester کمک کند
یکی از ویژگیهای رویکردهای مدرن تست نرمافزار این است که فعالیتهای QA الزاماً بعد از توسعه شروع نمیشوند.
اگر FRD قبل از پیادهسازی در اختیار Tester قرار بگیرد، او میتواند از همان مرحله:
- Requirementها را Review کند.
- ابهامها و تناقضها را شناسایی کند.
- سناریوهای مثبت و منفی را بررسی کند.
- شرایط مرزی را مشخص کند.
- سؤالهای لازم را از تیم مطرح کند.
در نتیجه، ممکن است یک مشکل قبل از اینکه حتی کدی برای آن نوشته شود شناسایی و اصلاح شود. این موضوع با مفهوم Shift Left Testing ارتباط مستقیم دارد.
۴.۸. بنابراین FRD برای Tester فقط یک «سند مرجع» نیست
اگر بخواهیم کاربرد FRD برای Tester را خلاصه کنیم، میتوانیم به این موارد اشاره کنیم:
- درک رفتار مورد انتظار
- شناسایی Test Scenario
- کمک به طراحی Test Case
- تعیین Expected Result
- کشف ابهام و نقص Requirement
- ایجاد Traceability
- شروع فعالیتهای QA پیش از اجرای نرمافزار
بنابراین Tester حرفهای فقط منتظر آماده شدن نرمافزار نمیماند تا تست را شروع کند؛ بلکه از مرحله Requirement Review تلاش میکند ریسکهای کیفیت را زودتر شناسایی و از ورود خطا به مراحل بعدی جلوگیری کند.
۵. تستر چگونه باید یک FRD را بخواند؟ 🔍
خواندن FRD برای Tester فقط به این معنی نیست که سند را از ابتدا تا انتها مطالعه کند و در پایان بگوید:
«خب، فهمیدم این قابلیت چه کاری انجام میدهد.»
نگاه Tester تحلیلیتر است. او هنگام مطالعه FRD باید تلاش کند رفتار مورد انتظار سیستم را استخراج کند و همزمان به دنبال ابهامها، حالتهای خاص، تناقضها و مواردی باشد که ممکن است باعث ایجاد مشکل در پیادهسازی یا پوشش تست شوند.
به بیان ساده، Tester هنگام خواندن FRD باید دو سؤال را همزمان دنبال کند:
سیستم قرار است چه کاری انجام دهد؟
و
چطور میتوانم مطمئن شوم که درست انجام میدهد؟
۵.۱. ابتدا یک دید کلی از قابلیت پیدا کنید
قبل از اینکه مستقیماً سراغ Test Case بروید، بهتر است ابتدا کل قابلیت و ارتباط آن با سایر بخشهای سیستم را درک کنید.
فرض کنید FRD مربوط به قابلیت ثبت سفارش است. پیش از طراحی تست باید بدانید این فرآیند چه مراحلی دارد:
انتخاب محصول → سبد خرید → اطلاعات ارسال → روش پرداخت → پرداخت → ثبت سفارش
اگر Tester فقط یک بخش کوچک از FRD را بررسی کند، ممکن است وابستگیها و ارتباط آن قابلیت با سایر بخشهای سیستم را نبیند.
بنابراین اولین قدم، ایجاد یک تصویر کلی از جریان عملکرد سیستم است.
۵.۲. Requirementها را به رفتارهای قابل تست تبدیل کنید
بعد از درک کلی قابلیت، باید Requirementها را از زاویه تست بررسی کنید.
مثلاً:
سیستم باید به کاربر اجازه دهد یک محصول را به سبد خرید اضافه کند.
حالا Tester میتواند این Requirement را به شرایط قابل بررسی تبدیل کند:
- محصول موجود → امکان افزودن
- محصول ناموجود → عدم امکان افزودن
- تعداد معتبر → افزودن موفق
- تعداد بیشتر از موجودی → نمایش خطا
در واقع Tester تلاش میکند یک Requirement کلی را به مجموعهای از شرایط قابل بررسی تبدیل کند.
۵.۳. به کلمات مبهم حساس باشید ⚠️
یکی از مهمترین مهارتهای Tester هنگام Review کردن FRD، تشخیص Ambiguity یا ابهام است.
مثلاً فرض کنید در FRD نوشته شده است:
«سیستم باید بهسرعت صفحه را نمایش دهد.»
کلمه «بهسرعت» معیار دقیقی ارائه نمیکند. یک نفر ممکن است منظورش کمتر از یک ثانیه باشد و فرد دیگری سه ثانیه را قابل قبول بداند.
بنابراین Tester باید بپرسد:
«بهسرعت دقیقاً یعنی چه مقدار زمان؟»
اگر Requirement مشخص کند:
صفحه باید حداکثر طی ۲ ثانیه نمایش داده شود.
حالا معیار مشخصتری برای ارزیابی وجود دارد.
البته این مثال به Non-functional Requirement نزدیک میشود و نشان میدهد همه نیازمندیهای یک پروژه الزاماً در FRD قرار نمیگیرند. نکته مهم این است که Tester باید نسبت به معیارهای مبهم و غیرقابل اندازهگیری حساس باشد.
۵.۴. شرایط مثبت و منفی را بررسی کنید
گاهی Requirement فقط مسیر موفق را توضیح میدهد.
کاربر میتواند با وارد کردن شماره موبایل و رمز عبور وارد سیستم شود.
Tester نباید فقط این سناریو را در نظر بگیرد:
اطلاعات صحیح → ورود موفق
بلکه باید شرایط دیگری را نیز بررسی کند:
- شماره موبایل اشتباه باشد.
- رمز عبور اشتباه باشد.
- یکی از فیلدها خالی باشد.
- شماره موبایل فرمت نامعتبر داشته باشد.
- کاربر وجود نداشته باشد.
- حساب کاربر غیرفعال باشد.
این سؤالها به شناسایی Negative Scenarioها و رفتار سیستم در شرایط نامعتبر کمک میکنند.
۵.۵. Boundaryها را پیدا کنید
محدودیتهایی که در FRD مشخص شدهاند معمولاً فرصت مناسبی برای طراحی تستهای Boundary فراهم میکنند.
مثلاً:
کاربر میتواند حداکثر ۵ محصول از یک کالا سفارش دهد.
در این حالت Tester میتواند مقادیر اطراف مرز را بررسی کند:
۴ → ۵ → ۶
- یک مقدار کمتر از حد مجاز
- دقیقاً برابر با حد مجاز
- یک مقدار بیشتر از حد مجاز
این نوع نگاه کمک میکند Test Caseها فقط به مقادیر معمول محدود نشوند.
۵.۶. ورودی و خروجی را بررسی کنید
برای هر قابلیت، Tester باید تا حد امکان مشخص کند:
Input چیست؟
و:
Expected Output چیست؟
مثلاً:
کاربر مبلغ سفارش را وارد میکند و سیستم هزینه ارسال را محاسبه میکند.
در اینجا Tester باید بداند:
- چه ورودیهایی مجاز هستند؟
- چه ورودیهایی غیرمجاز هستند؟
- نتیجه محاسبه چگونه باید باشد؟
- در صورت ورود مقدار نامعتبر چه اتفاقی میافتد؟
هرچه Input و Expected Output دقیقتر باشند، طراحی تست نیز قابل اتکاتر خواهد بود.
۵.۷. Dependencyها را فراموش نکنید
بعضی قابلیتها مستقل نیستند و به سایر اجزای سیستم یا سرویسهای خارجی وابستگی دارند.
مثلاً ثبت سفارش ممکن است به این بخشها وابسته باشد:
Product Inventory → Shopping Cart → Payment → Order Management
در چنین شرایطی Tester باید بررسی کند که در صورت در دسترس نبودن یکی از این اجزا، رفتار مورد انتظار سیستم چیست.
مثلاً:
اگر سرویس پرداخت در دسترس نباشد، آیا سفارش ایجاد میشود یا خیر؟
اگر این رفتار در Requirement مشخص نشده باشد، موضوع باید برای شفافسازی مطرح شود.
۵.۸. Requirementهای مرتبط را با هم بررسی کنید
گاهی هر Requirement بهتنهایی منطقی به نظر میرسد، اما وقتی چند Requirement را کنار هم قرار میدهیم، ممکن است تناقض ایجاد شود.
FR-01:
کاربر میتواند حداکثر ۱۰ محصول سفارش دهد.
FR-02:
کاربران VIP میتوانند تا ۲۰ محصول سفارش دهند.
حالا یک سؤال مهم ایجاد میشود:
آیا محدودیت FR-01 برای کاربران VIP هم اعمال میشود؟
اگر این موضوع مشخص نشده باشد، Tester میتواند آن را بهعنوان یک ابهام در Requirement مطرح کند.
بنابراین Review کردن FRD فقط بررسی تکتک Requirementها نیست؛ ارتباط و سازگاری Requirementها با یکدیگر نیز اهمیت دارد.
۵.۹. در نهایت بپرسید: «آیا این Requirement قابل تست است؟»
یکی از مهمترین سؤالهایی که Tester هنگام مطالعه FRD باید از خود بپرسد این است:
«آیا میتوانم بر اساس این Requirement یک نتیجه مشخص برای Pass یا Fail تعیین کنم؟»
مثلاً:
❌ مبهم:
سیستم باید عملکرد خوبی داشته باشد.
در مقابل:
✅ قابل تستتر:
سیستم باید نتیجه جستوجو را حداکثر طی ۲ ثانیه نمایش دهد.
در مثال دوم، معیار مشخصتری برای ارزیابی وجود دارد.
البته قابل تست بودن همیشه به معنی وجود یک عدد یا معیار ساده نیست؛ مهم این است که شرایط، رفتار مورد انتظار و معیار ارزیابی به اندازه کافی مشخص باشند.
یک روش ساده برای خواندن FRD از دید Tester
میتوان کل فرآیند مطالعه FRD را به یک الگوی ساده تبدیل کرد:
- قابلیت چیست؟
- رفتار مورد انتظار چیست؟
- ورودیها چیست؟
- خروجی مورد انتظار چیست؟
- شرایط مثبت چیست؟
- شرایط منفی چیست؟
- محدودیتها و Boundaryها چیست؟
- وابستگیها چیست؟
- آیا Requirement ابهام یا تناقض دارد؟
- آیا میتوان آن را بهصورت قابل اتکا تست کرد؟
اگر Tester بتواند با چنین نگاهی FRD را بررسی کند، دیگر صرفاً خواننده سند نیست؛ بلکه از همان مرحله Requirement Review وارد فرآیند تضمین کیفیت میشود.
در بخش بعدی، یک قدم عملیتر برمیداریم و بررسی میکنیم که چگونه میتوان یک Requirement موجود در FRD را به Test Scenario تبدیل کرد.
۶. چگونه Requirementهای موجود در FRD را به Test Scenario تبدیل کنیم؟ 🧪
تا اینجا دیدیم که Tester هنگام خواندن FRD فقط به دنبال فهمیدن قابلیتهای سیستم نیست؛ بلکه باید بتواند از اطلاعات موجود در آن، شرایط مختلفی را که باید تست شوند استخراج کند.
اما این کار دقیقاً چگونه انجام میشود؟ برای درک بهتر، یک Requirement ساده را مرحلهبهمرحله بررسی کنیم.
یک Requirement ساده
فرض کنید در FRD مربوط به یک فروشگاه اینترنتی نوشته شده است:
FR-003: کاربر باید بتواند محصول موجود را به سبد خرید اضافه کند.
در نگاه اول شاید به نظر برسد که فقط یک تست لازم است: محصول را به سبد خرید اضافه کنیم و بررسی کنیم که آیا اضافه میشود یا خیر.
اما از دید Tester، همین Requirement میتواند سؤالهای بیشتری ایجاد کند.
۶.۱. ابتدا رفتار اصلی را شناسایی کنیم
اولین سؤال این است:
اگر همه شرایط درست باشند، چه اتفاقی باید بیفتد؟
در این مثال:
محصول موجود + تعداد معتبر → محصول با موفقیت به سبد خرید اضافه شود.
این همان Happy Path یا سناریوی اصلی است.
بنابراین یک Test Scenario میتواند این باشد:
بررسی امکان افزودن یک محصول موجود به سبد خرید
۶.۲. شرایط نامعتبر را بررسی کنیم
Tester نباید فقط مسیر موفق را بررسی کند. باید بپرسد:
اگر شرایط ایدهآل نباشد، سیستم چه رفتاری باید داشته باشد؟
مثلاً:
- محصول موجود نباشد.
- تعداد انتخابشده بیشتر از موجودی باشد.
- تعداد واردشده صفر باشد.
- تعداد مقدار منفی داشته باشد.
- محصول دیگر در سیستم فعال نباشد.
از این موارد میتوان Test Scenarioهای دیگری ایجاد کرد:
- بررسی عدم امکان افزودن محصول ناموجود به سبد خرید
- بررسی رفتار سیستم هنگام انتخاب تعداد بیشتر از موجودی
- بررسی افزودن محصول با تعداد نامعتبر
در این مرحله هنوز وارد جزئیات Test Case نشدهایم؛ فقط مشخص کردهایم چه شرایطی باید بررسی شوند.
۶.۳. شرایط مرزی را بررسی کنیم
حالا فرض کنید در FRD نوشته شده است:
کاربر میتواند حداکثر ۱۰ عدد از یک محصول را به سبد خرید اضافه کند.
این Requirement یک فرصت مناسب برای طراحی تستهای Boundary ایجاد میکند.
Tester میتواند سناریوهایی مانند اینها را در نظر بگیرد:
- افزودن ۹ عدد محصول
- افزودن دقیقاً ۱۰ عدد محصول
- تلاش برای افزودن ۱۱ عدد محصول
در نتیجه Test Scenarioها میتوانند شامل موارد زیر باشند:
- بررسی افزودن محصول با تعداد کمتر از حداکثر مجاز
- بررسی افزودن محصول با دقیقاً حداکثر تعداد مجاز
- بررسی عدم امکان افزودن محصول بیشتر از حد مجاز
۶.۴. وضعیتهای مختلف سیستم را در نظر بگیریم
گاهی یک Requirement در شرایط مختلف رفتار متفاوتی دارد.
مثلاً:
کاربر باید بتواند محصول را به سبد خرید اضافه کند.
اما ممکن است سیستم دو نوع کاربر داشته باشد:
- کاربر واردشده
- کاربر مهمان
در این حالت Tester باید بررسی کند که آیا هر دو نوع کاربر اجازه انجام این کار را دارند یا رفتار آنها متفاوت است.
اگر رفتار سیستم در این وضعیتها متفاوت باشد، برای هر وضعیت باید سناریوی مناسب تعریف شود.
۶.۵. Test Scenario با Test Case یکی نیست
این تفاوت برای درک فرآیند تست بسیار مهم است.
Test Scenario بیشتر مشخص میکند:
چه چیزی را باید تست کنیم؟
مثلاً:
بررسی افزودن محصول موجود به سبد خرید.
اما Test Case جزئیات اجرای این تست را مشخص میکند.
مثلاً:
- وارد صفحه محصول شوید.
- یک محصول موجود را انتخاب کنید.
- تعداد را روی ۱ قرار دهید.
- روی «افزودن به سبد خرید» کلیک کنید.
- سبد خرید را باز کنید.
- بررسی کنید محصول در سبد نمایش داده شود.
بنابراین میتوان گفت:
Requirement → Test Scenario → Test Case
Requirement میگوید سیستم چه کاری باید انجام دهد، Test Scenario مشخص میکند چه چیزی را باید بررسی کنیم و Test Case توضیح میدهد چگونه آن را بررسی کنیم.
۶.۶. یک Requirement میتواند چندین Test Scenario داشته باشد
ممکن است در FRD فقط یک Requirement نوشته شده باشد:
کاربر باید بتواند محصول را به سبد خرید اضافه کند.
اما Tester میتواند از آن چندین Scenario استخراج کند:
| نوع | Test Scenario |
|---|---|
| مثبت | افزودن محصول موجود |
| منفی | افزودن محصول ناموجود |
| منفی | افزودن تعداد بیشتر از موجودی |
| Boundary | افزودن حداکثر تعداد مجاز |
| Boundary | تلاش برای افزودن بیشتر از حد مجاز |
| اعتبارسنجی | وارد کردن تعداد صفر |
| اعتبارسنجی | وارد کردن تعداد منفی |
البته تعداد واقعی Test Scenarioها به جزئیات Requirement، قوانین کسبوکار و ریسکهای مرتبط با قابلیت بستگی دارد.
۶.۷. اینجا نقش تحلیلگرانه Tester مشخص میشود
نکته مهم این است که Tester نباید فقط Requirement را به Test Case تبدیل کند.
اگر در FRD نوشته شده باشد:
«کاربر میتواند محصول را به سبد خرید اضافه کند.»
یک Tester باتجربه ممکن است بلافاصله سؤالهایی مانند این مطرح کند:
- چه محصولی؟
- اگر محصول موجود نباشد چه؟
- حداکثر تعداد چقدر است؟
- کاربر مهمان هم میتواند؟
- اگر محصول قبلاً در سبد باشد چه؟
- اگر سرویس موجودی در دسترس نباشد چه؟
بعضی از این سؤالها ممکن است پاسخشان در FRD وجود داشته باشد و بعضی دیگر نه. اگر پاسخ مشخص نباشد، موضوع میتواند به Requirement Clarification یا اصلاح مستندات نیاز داشته باشد.
بنابراین تبدیل Requirement به Test Scenario فقط یک فعالیت مکانیکی نیست؛ نیازمند تحلیل و پرسیدن سؤالهای درست است.
یک فرمول ساده برای Tester
برای هر Requirement میتوان از این الگو استفاده کرد:
Requirement
↓
Happy Path
↓
Negative Scenarios
↓
Boundary Conditions
↓
Alternative Flows
↓
Error Conditions
↓
Dependencies
↓
Test Scenarios
این رویکرد کمک میکند Tester از یک Requirement ساده، پوشش تست مناسبتری ایجاد کند و در عین حال مواردی را که نیاز به شفافسازی دارند، زودتر شناسایی کند.
در بخش بعدی، به یکی از مهمترین مهارتهای Tester در کار با FRD میرسیم: چگونه ابهامها و Requirementهای ناقص را در FRD پیدا کنیم؟
۷. چگونه ابهامها و Requirementهای ناقص را در FRD پیدا کنیم؟ 🔎
یکی از مهمترین کارهایی که Tester هنگام بررسی FRD انجام میدهد، فقط پیدا کردن مواردی که باید تست شوند نیست؛ بلکه باید بررسی کند آیا Requirementها بهاندازه کافی واضح، کامل و قابل تست هستند یا خیر.
فرض کنید در FRD نوشته شده است:
کاربر باید بتواند سفارش خود را سریع ثبت کند.
در نگاه اول مفهوم جمله مشخص است، اما Tester باید بپرسد:
«سریع دقیقاً یعنی چقدر؟»
اگر معیار مشخصی وجود نداشته باشد، افراد مختلف ممکن است برداشت متفاوتی از Requirement داشته باشند و Tester نیز نمیتواند بهصورت دقیق مشخص کند که نتیجه تست قابل قبول است یا خیر.
۷.۱. Requirement مبهم چیست؟
Requirement مبهم Requirementی است که میتواند برای افراد مختلف برداشتهای متفاوتی ایجاد کند.
مثلاً:
سیستم باید رمز عبور قوی دریافت کند.
عبارت «قوی» معیار مشخصی ندارد. ممکن است یک نفر حداقل ۸ کاراکتر را کافی بداند و فرد دیگری انتظار داشته باشد رمز عبور شامل حروف بزرگ، حروف کوچک، عدد و کاراکتر خاص باشد.
اگر Requirement به شکل دقیقتری تعریف شود، مثلاً:
رمز عبور باید حداقل ۸ کاراکتر داشته باشد و شامل حداقل یک حرف، یک عدد و یک کاراکتر خاص باشد.
حالا Tester میتواند شرایط مختلف را با معیار مشخصی بررسی کند.
۷.۲. به کلمات مبهم حساس باشید ⚠️
هنگام مطالعه FRD، بعضی عبارتها میتوانند نشانهای باشند که Requirement نیاز به بررسی بیشتری دارد؛ مانند:
- سریع
- آسان
- مناسب
- کافی
- در اسرع وقت
- بهطور مناسب
- در صورت نیاز
- اطلاعات معتبر
البته وجود این کلمات بهتنهایی به معنی اشتباه بودن Requirement نیست. نکته مهم این است که Tester بررسی کند آیا این عبارتها تعریف یا معیار مشخصی دارند یا خیر.
برای مثال، «کاربر مجاز» میتواند یک عبارت کاملاً قابل قبول باشد، اگر در Requirement دیگری یا مستندات مرتبط مشخص شده باشد که چه کسی کاربر مجاز محسوب میشود.
۷.۳. Requirement ناقص را پیدا کنیم
گاهی Requirement مبهم نیست، اما اطلاعات کافی برای مشخص کردن رفتار سیستم در شرایط مختلف را ندارد.
کاربر میتواند سفارش خود را لغو کند.
این جمله از نظر کلی قابل فهم است، اما سؤالهای مهمی ایجاد میکند:
- آیا سفارش در حال آمادهسازی قابل لغو است؟
- آیا سفارش ارسالشده قابل لغو است؟
- آیا سفارش پرداختنشده قابل لغو است؟
- در صورت لغو سفارش، مبلغ چگونه بازگردانده میشود؟
- آیا لغو سفارش محدودیت زمانی دارد؟
اگر پاسخ این سؤالها روی رفتار سیستم تأثیر میگذارد و در هیچ Requirement یا منبع معتبر دیگری مشخص نشده باشد، Tester میتواند این موضوع را برای شفافسازی Requirement مطرح کند.
۷.۴. شرایط مرزی تعریفنشده را پیدا کنیم
محدودیتهای عددی معمولاً محل مناسبی برای پیدا کردن سؤالهای تکمیلی هستند.
کاربر میتواند حداکثر ۱۰ محصول سفارش دهد.
در اینجا Tester میتواند علاوه بر مقدار ۱۰، درباره رفتار سیستم در شرایطی مانند موارد زیر سؤال کند:
- مقدار ۹
- مقدار ۱۰
- مقدار ۱۱
- مقدار صفر
- مقدار منفی
- یک مقدار بسیار بزرگ
ممکن است برخی از این رفتارها از قبل در Requirementهای دیگر مشخص شده باشند؛ اما اگر تعیین تکلیف نشده باشند، Tester میتواند آنها را بهعنوان موارد نیازمند شفافسازی مطرح کند.
۷.۵. تناقض بین Requirementها را پیدا کنیم
گاهی هر Requirement بهتنهایی منطقی به نظر میرسد، اما وقتی چند Requirement را کنار هم قرار میدهیم، متوجه تناقض میشویم.
FR-01:
همه کاربران میتوانند سفارش خود را لغو کنند.
FR-02:
سفارشهای ارسالشده قابل لغو نیستند.
در اینجا مشخص نیست کدام Requirement باید در شرایط موردنظر اعمال شود. Tester میتواند این تناقض را در مرحله Requirement Review مطرح کند تا رفتار مورد انتظار مشخص شود.
۷.۶. Requirementهای غیرقابل تست را شناسایی کنیم
یکی از سؤالهای مهم Tester این است:
«آیا میتوانم بر اساس این Requirement یک نتیجه مشخص برای Pass یا Fail تعیین کنم؟»
برای مثال:
❌ مبهم: سیستم باید تجربه کاربری خوبی داشته باشد.
✅ قابل تستتر: پس از ثبت موفق سفارش، سیستم باید شماره سفارش را به کاربر نمایش دهد.
در مثال دوم، رفتار مورد انتظار مشخصتر است و Tester میتواند نتیجه تست را ارزیابی کند.
البته قابل تست بودن همیشه به معنی داشتن یک مقدار عددی نیست. مهم این است که رفتار مورد انتظار و معیار ارزیابی نتیجه به اندازه کافی مشخص باشند.
۷.۷. Tester نباید Requirement را از خودش حدس بزند
اگر FRD درباره یک وضعیت خاص توضیحی نداده باشد، Tester نباید صرفاً بر اساس تجربه شخصی تصمیم بگیرد که رفتار درست سیستم چیست.
برای مثال، اگر مشخص نشده باشد که سفارش ارسالشده قابل لغو است یا خیر، Tester نباید خودش این تصمیم را بگیرد. بهتر است موضوع با فرد یا تیم مسئول Requirement، مانند Business Analyst، Product Owner یا تیم Product، شفاف شود.
تجربه Tester در اینجا بسیار ارزشمند است؛ اما این تجربه بیشتر برای کشف سؤالها و سناریوهای احتمالی استفاده میشود، نه تعیین خودسرانه رفتار مورد انتظار.
۷.۸. یک چک ساده برای پیدا کردن ابهامها
هنگام بررسی هر Requirement میتوان چند سؤال ساده مطرح کرد:
- چه چیزی؟ دقیقاً چه قابلیت یا رفتاری باید وجود داشته باشد؟
- چه کسی؟ چه کاربری میتواند از آن استفاده کند؟
- چه زمانی؟ این رفتار در چه شرایطی باید اتفاق بیفتد؟
- با چه ورودی؟ چه دادههایی وارد سیستم میشوند؟
- چه خروجی؟ نتیجه مورد انتظار چیست؟
- اگر خطا رخ دهد چه؟ رفتار سیستم در شرایط نامعتبر چیست؟
- محدودیت چیست؟ حداقل، حداکثر یا سایر محدودیتها چیست؟
- چطور تست کنیم؟ آیا میتوان نتیجه مشخصی برای Pass یا Fail تعیین کرد؟
اگر پاسخ یکی از این سؤالها مشخص نباشد، ممکن است Requirement به شفافسازی یا تکمیل نیاز داشته باشد.
در نتیجه، Tester هنگام Review کردن FRD فقط به دنبال پیدا کردن تستهای آینده نیست؛ بلکه تلاش میکند قبل از شروع Development، ریسکهای ناشی از Requirementهای مبهم، ناقص، متناقض یا غیرقابل تست را شناسایی کند.
حالا که Requirementها و مشکلات احتمالی آنها را بررسی کردیم، مرحله بعد این است که ببینیم چگونه میتوان Requirementهای مشخصشده در FRD را به تستهای قابل اجرا تبدیل کرد.
۸. چگونه FRD را به Test Case تبدیل کنیم؟ 🧪
تا اینجا دیدیم که Tester میتواند با بررسی FRD، رفتار مورد انتظار سیستم را درک کند، ابهامها را شناسایی کند و Test Scenarioهای مختلف را استخراج کند.
در مرحله بعد، این Scenarioها میتوانند به Test Caseهای قابل اجرا تبدیل شوند.
اگر بخواهیم مسیر را بهصورت ساده ببینیم:
FRD → Requirement → Test Scenario → Test Case → Test Execution
در این زنجیره، FRD یکی از منابع اصلی برای درک رفتار مورد انتظار است و Test Case مشخص میکند که آن رفتار چگونه بررسی شود و چه نتیجهای انتظار داریم.
۸.۱. با یک Requirement شروع کنیم
فرض کنید در FRD یک فروشگاه اینترنتی نوشته شده است:
FR-003: کاربر باید بتواند یک محصول موجود را به سبد خرید اضافه کند.
از این Requirement میتوان ابتدا یک Test Scenario اصلی استخراج کرد:
Test Scenario: بررسی امکان افزودن محصول موجود به سبد خرید.
سپس میتوان این Scenario را با جزئیات بیشتر به یک یا چند Test Case تبدیل کرد.
۸.۲. Test Case چه اطلاعاتی دارد؟
ساختار Test Case به ابزار و روش کاری تیم بستگی دارد، اما معمولاً میتواند شامل اطلاعاتی مانند موارد زیر باشد:
- Test Case ID
- عنوان Test Case
- Preconditions
- Test Steps
- Test Data
- Expected Result
- Actual Result
- Status
هدف این اطلاعات این است که مشخص شود تست تحت چه شرایطی، با چه دادهای و چگونه اجرا شود و چه نتیجهای مورد انتظار است.
۸.۳. یک Test Case ساده
برای Requirement قبلی میتوان Test Case زیر را طراحی کرد:
- Test Case ID: TC-003
- عنوان: افزودن محصول موجود به سبد خرید
- Precondition: محصول موردنظر فعال و دارای موجودی است.
- Test Steps:
- وارد صفحه محصول شوید.
- محصول موردنظر را انتخاب کنید.
- تعداد را روی ۱ قرار دهید.
- روی گزینه «افزودن به سبد خرید» کلیک کنید.
- وارد سبد خرید شوید.
- Expected Result: محصول باید با تعداد ۱ و قیمت صحیح در سبد خرید نمایش داده شود.
پس از اجرای Test Case، Tester میتواند Actual Result را با Expected Result مقایسه کند و وضعیت تست را مشخص کند.
۸.۴. یک Requirement معمولاً فقط یک Test Case ندارد
وجود یک Requirement به این معنی نیست که فقط یک Test Case برای آن کافی است. تعداد تستها به شرایط، قوانین کسبوکار، ریسک و رفتارهای مشخصشده در Requirement بستگی دارد.
| Test Case | سناریو |
|---|---|
| TC-001 | افزودن محصول موجود |
| TC-002 | تلاش برای افزودن محصول ناموجود |
| TC-003 | افزودن تعداد بیشتر از موجودی |
| TC-004 | افزودن حداکثر تعداد مجاز |
| TC-005 | وارد کردن تعداد صفر |
| TC-006 | وارد کردن تعداد منفی |
البته مواردی مانند تعداد صفر یا مقدار منفی فقط زمانی باید بهعنوان Test Case در نظر گرفته شوند که از منطق محصول، قوانین کسبوکار، رفتار مورد انتظار یا رویکرد تست تیم پشتیبانی شوند.
۸.۵. Expected Result باید بر اساس Requirement مشخص شود
یکی از نکات مهم هنگام طراحی Test Case این است که Tester نباید Expected Result را صرفاً بر اساس حدس شخصی تعیین کند.
فرض کنید Requirement فقط میگوید:
سیستم باید امکان لغو سفارش را فراهم کند.
از این جمله بهتنهایی نمیتوان نتیجه گرفت که بعد از لغو سفارش، مبلغ باید فوراً بازگردانده شود، سفارش حذف شود یا فقط وضعیت آن به Cancelled تغییر کند.
این جزئیات باید در Requirement، Acceptance Criteria یا منبع معتبر دیگری مشخص شده باشند.
بنابراین:
Expected Result باید تا حد امکان از رفتار مورد انتظار مستندشده استخراج شود، نه از فرض Tester.
۸.۶. از FRD برای ایجاد Traceability استفاده کنیم
یکی از کاربردهای مهم Requirementهای دارای شناسه، ایجاد ارتباط بین Requirementها و Test Caseهاست.
برای مثال:
- FR-001: کاربر میتواند وارد سیستم شود.
→ TC-001، TC-002، TC-003 - FR-002: کاربر میتواند محصول را جستوجو کند.
→ TC-004، TC-005 - FR-003: کاربر میتواند محصول را به سبد خرید اضافه کند.
→ TC-006، TC-007، TC-008
این ارتباط بخشی از مفهوم Requirement Traceability است و کمک میکند مشخص شود Requirementهای مهم چگونه تحت پوشش تست قرار گرفتهاند.
همچنین اگر یک Requirement تغییر کند، Traceability کمک میکند سریعتر مشخص کنیم کدام Test Caseها باید بازبینی یا اصلاح شوند.
۸.۷. تغییر FRD چه تأثیری روی Test Case دارد؟
Requirementها در پروژههای واقعی ممکن است تغییر کنند.
فرض کنید ابتدا در FRD نوشته شده است:
کاربر میتواند حداکثر ۱۰ عدد از یک محصول سفارش دهد.
بعداً این Requirement به ۵ عدد تغییر میکند.
در این شرایط Tester باید بررسی کند:
- کدام Test Caseها تحت تأثیر قرار گرفتهاند؟
- آیا Test Data باید تغییر کند؟
- آیا Expected Resultها باید اصلاح شوند؟
- آیا Test Scenario جدیدی لازم است؟
- آیا برخی تستها باید دوباره اجرا شوند؟
این مثال نشان میدهد که Traceability فقط برای گزارشگیری نیست؛ بلکه در مدیریت تغییرات Requirement نیز کاربرد دارد.
۸.۸. تعداد Test Case معیار کافی برای پوشش تست نیست
فرض کنید برای Requirement زیر فقط یک Test Case نوشتهایم:
کاربر میتواند سفارش خود را لغو کند.
اگر فقط «لغو موفق سفارش» را تست کنیم، ممکن است بسیاری از رفتارهای مهم را بررسی نکرده باشیم.
- لغو سفارش در وضعیت Pending
- لغو سفارش در وضعیت Processing
- لغو سفارش ارسالشده
- لغو سفارش قبلاً لغوشده
- لغو سفارش توسط کاربر غیرمجاز
اگر FRD یا سایر منابع معتبر Requirement این شرایط را مشخص کرده باشند، باید در طراحی تست مورد توجه قرار گیرند.
بنابراین تعداد Test Caseها بهتنهایی معیار مناسبی برای سنجش کیفیت تست نیست؛ مهمتر از تعداد، پوشش رفتارهای مورد انتظار، شرایط مهم و ریسکهای مرتبط با Requirement است.
۸.۹. مسیر FRD تا اجرای تست
اکنون میتوانیم ارتباط بین FRD و فعالیتهای تست را به شکل زیر خلاصه کنیم:
FRD
↓
درک Requirement
↓
شناسایی شرایط مختلف
↓
Test Scenario
↓
Test Case
↓
Test Execution
↓
مقایسه Actual Result با Expected Result
↓
Pass / Fail
این زنجیره نشان میدهد که FRD فقط یک سند برای مطالعه نیست؛ بلکه میتواند یکی از ورودیهای اصلی برای تحلیل تست، طراحی Test Case و ایجاد Traceability باشد.
اما یک سؤال مهم باقی میماند: اگر خود FRD اشتباه، ناقص یا مبهم باشد، چه تأثیری بر تست خواهد داشت؟ در بخش بعدی این موضوع را بررسی میکنیم.
۹. وقتی FRD مشکل دارد، چه اتفاقی برای تست میافتد؟ ⚠️
تا اینجا دیدیم که FRD میتواند به Tester کمک کند تا رفتار مورد انتظار سیستم را درک کند، Test Scenario و Test Case طراحی کند و ارتباط بین Requirementها و تستها را برقرار کند.
اما یک نکته مهم وجود دارد:
اگر Requirement از ابتدا اشتباه، ناقص یا مبهم باشد، حتی یک فرآیند تست دقیق نیز ممکن است به نتیجه درستی نرسد.
در چنین شرایطی ممکن است Tester نرمافزار را کاملاً مطابق Requirement موجود بررسی کند، اما خود Requirement با نیاز واقعی محصول یا تصمیم کسبوکار مطابقت نداشته باشد.
۹.۱. Requirement مبهم میتواند باعث اختلاف بین Tester و Developer شود
فرض کنید در FRD نوشته شده است:
کاربر باید بتواند سفارش خود را لغو کند.
Developer ممکن است این Requirement را اینطور تفسیر کند که سفارش فقط تا قبل از ارسال قابل لغو است.
اما Tester ممکن است انتظار داشته باشد که سفارش حتی پس از ارسال نیز قابل لغو باشد.
در نتیجه Tester ممکن است یک Defect ثبت کند و Developer پاسخ دهد:
«این Bug نیست؛ قرار نبوده سفارش ارسالشده قابل لغو باشد.»
در چنین شرایطی ممکن است مشکل اصلی نه در تست و نه در پیادهسازی باشد؛ بلکه رفتار مورد انتظار از ابتدا به اندازه کافی مشخص نشده باشد.
۹.۲. Requirement ناقص میتواند باعث Test Coverage ناقص شود
فرض کنید FRD فقط نوشته باشد:
کاربر میتواند رمز عبور خود را تغییر دهد.
اگر هیچ جزئیات دیگری وجود نداشته باشد، ممکن است Tester فقط سناریوی موفق را در نظر بگیرد:
رمز قبلی صحیح + رمز جدید معتبر → تغییر موفق رمز عبور
اما اگر رفتارهایی مانند موارد زیر بخشی از نیازمندی محصول باشند، باید برای آنها نیز تعیین تکلیف شود:
- حداقل طول رمز عبور
- الزامات مربوط به پیچیدگی رمز
- یکسان بودن رمز جدید با رمز قبلی
- ورود رمز فعلی بهصورت اشتباه
- تلاشهای ناموفق متعدد
اگر این موارد در Requirement یا منابع معتبر مرتبط مشخص نشده باشند، Tester ممکن است اصلاً نداند که باید چه رفتارهایی را بررسی کند.
بنابراین Requirement ناقص میتواند مستقیماً روی Test Coverage تأثیر بگذارد.
۹.۳. Requirement اشتباه میتواند باعث False Positive یا False Bug شود
فرض کنید در FRD به اشتباه نوشته شده است:
حداکثر تعداد قابل سفارش برای هر محصول ۱۰ عدد است.
Tester بر اساس همین Requirement تلاش میکند ۱۱ محصول سفارش دهد و انتظار دارد سیستم خطا نمایش دهد.
اما بعداً مشخص میشود که محدودیت واقعی ۲۰ عدد بوده و عدد ۱۰ در FRD اشتباه ثبت شده است.
در این حالت Tester رفتار سیستم را مطابق Requirement موجود بررسی کرده است، اما نتیجه به دست آمده ممکن است از دید محصول Bug واقعی نباشد.
این مثال نشان میدهد که باید بین این دو موضوع تفاوت قائل شویم:
- Software Defect: نرمافزار برخلاف رفتار مورد انتظار مشخصشده عمل میکند.
- Requirement Defect: خود Requirement دارای مشکل، ابهام یا اطلاعات نادرست است.
روش ثبت و مدیریت این موارد به فرآیند هر تیم بستگی دارد.
۹.۴. تغییر Requirement میتواند تستهای قبلی را تحت تأثیر قرار دهد
Requirementها در پروژههای واقعی همیشه ثابت نمیمانند.
مثلاً ابتدا گفته شده است:
کاربر میتواند حداکثر ۵ محصول سفارش دهد.
بعداً این مقدار به ۱۰ تغییر میکند.
این تغییر ممکن است روی موارد مختلفی تأثیر بگذارد:
- Test Scenarioها
- Test Caseها
- Test Data
- Expected Resultها
- Regression Testها
به همین دلیل، Tester باید تغییرات مهم Requirement را دنبال کند و بررسی کند که آیا تستهای موجود هنوز معتبر هستند یا نیاز به اصلاح یا اجرای مجدد دارند.
۹.۵. آیا هر مشکل در FRD یک Software Bug است؟
خیر.
اگر Tester متوجه شود که یک Requirement مبهم یا ناقص است، الزاماً نباید آن را بهعنوان Software Bug ثبت کند.
ممکن است موضوع نیازمند یکی از این اقدامات باشد:
- Requirement Clarification
- گفتوگو با Business Analyst
- بررسی با Product Owner یا تیم Product
- اصلاح مستندات
- ثبت یک Issue یا Task برای پیگیری
روش دقیق مدیریت این موارد به فرآیند تیم بستگی دارد. نکته مهم این است که مشکل Requirement در همان مرحلهای که شناسایی شده، به شکل مناسبی پیگیری شود.
۹.۶. هرچه مشکل Requirement زودتر پیدا شود، بهتر است
فرض کنید یک ابهام در Requirement Review شناسایی شود. ممکن است با یک گفتوگوی کوتاه، رفتار مورد انتظار مشخص شود.
اما اگر همان ابهام تا مراحل بعدی باقی بماند، ممکن است این مسیر را طی کند:
Requirement مبهم
↓
Design
↓
Development
↓
Test Case
↓
Test Execution
↓
Defect Report
↓
بررسی و اصلاح
در این حالت، اصلاح یک ابهام ساده میتواند هزینه و زمان بیشتری نسبت به زمانی که همان موضوع در ابتدای مسیر شناسایی میشد، داشته باشد.
این موضوع یکی از دلایل اهمیت Shift Left Testing است؛ یعنی توجه به کیفیت و شناسایی ریسکها از مراحل ابتدایی چرخه توسعه، نه فقط هنگام اجرای تست.
۹.۷. کیفیت تست به کیفیت Requirement نیز وابسته است
اگر بخواهیم نتیجه این بخش را در یک جمله خلاصه کنیم:
Tester فقط کیفیت اجرای تست را کنترل نمیکند؛ کیفیت اطلاعاتی که تست بر اساس آن طراحی میشود نیز اهمیت دارد.
یک Test Case بسیار دقیق که بر اساس Requirement اشتباه طراحی شده باشد، لزوماً تست خوبی برای محصول واقعی نیست.
به همین دلیل، بررسی Requirementها یکی از فعالیتهایی است که میتواند به Tester کمک کند قبل از رسیدن مشکل به مرحله Development یا Testing، آن را شناسایی کند.
حالا که تأثیر Requirementهای ضعیف بر تست را دیدیم، باید دقیقتر بررسی کنیم که Tester در Requirement Review چه نقشی دارد و چگونه باید این بررسی را انجام دهد.
۱۰. نقش Tester در بررسی و Review کردن FRD 🔍
یکی از نکات مهم درباره FRD این است که Tester نباید اولین بار زمانی آن را مطالعه کند که نرمافزار آماده تست شده است.
اگر Tester از مرحله بررسی Requirement درگیر شود، میتواند قبل از شروع Development، ابهامها و ریسکهای مربوط به تست را شناسایی و برای شفافسازی آنها با تیم همکاری کند.
۱۰.۱. Requirement Review چیست؟
Requirement Review فرآیندی است که در آن اعضای مرتبط تیم، Requirementها را بررسی میکنند تا مشکلاتی مانند موارد زیر شناسایی شوند:
- ابهام
- ناقص بودن اطلاعات
- تناقض بین Requirementها
- غیرقابل تست بودن
- ناسازگاری با سایر نیازمندیها
- مشخص نبودن شرایط خطا یا حالتهای خاص
هدف این مرحله اجرای تست نرمافزار نیست؛ بلکه این است که مطمئن شویم چیزی که قرار است ساخته شود، به اندازه کافی واضح و قابل ارزیابی تعریف شده است.
۱۰.۲. چرا Tester باید در Requirement Review حضور داشته باشد؟
فرض کنید در FRD نوشته شده است:
کاربر میتواند سفارش خود را لغو کند.
ممکن است برای نویسنده Requirement این جمله کاملاً واضح باشد، اما Tester میتواند سؤالهایی مانند این مطرح کند:
- در چه وضعیتهایی سفارش قابل لغو است؟
- آیا سفارش ارسالشده هم قابل لغو است؟
- آیا سفارش پرداختنشده قابل لغو است؟
- اگر لغو سفارش با خطا مواجه شود چه اتفاقی میافتد؟
- آیا مبلغ سفارش باید بازگردانده شود؟
- اگر سفارش شامل چند محصول باشد، لغو چگونه انجام میشود؟
این سؤالها نشان میدهند که Tester Requirement را از زاویه قابلیت تست و رفتارهای قابل بررسی تحلیل میکند.
۱۰.۳. Tester چه چیزهایی را در FRD بررسی میکند؟
میتوان بررسی Tester را در چند محور اصلی خلاصه کرد:
- وضوح: آیا Requirement برای افراد مختلف یک معنی دارد؟
- کامل بودن: آیا اطلاعات لازم برای درک رفتار سیستم وجود دارد؟
- قابلیت تست: آیا میتوان بر اساس Requirement نتیجه Pass یا Fail را ارزیابی کرد؟
- سازگاری: آیا Requirement با سایر Requirementها تناقض ندارد؟
- شرایط خطا: آیا رفتار سیستم در حالتهای نامعتبر مشخص شده است؟
- Boundaryها: آیا محدودیتها و مقادیر مرزی تعیین تکلیف شدهاند؟
- وابستگیها: آیا وابستگی به سایر بخشهای سیستم یا سرویسها مشخص است؟
این بررسی به Tester کمک میکند قبل از طراحی Test Case، مشکلات احتمالی Requirement را شناسایی کند.
۱۰.۴. Tester لزوماً مسئول بازنویسی FRD نیست
نقش Tester در Requirement Review بیشتر شناسایی مسئله، ارزیابی قابلیت تست و مطرح کردن سؤال درست است.
برای مثال، Tester میتواند بگوید:
«در این Requirement مشخص نشده اگر موجودی محصول کمتر از تعداد درخواستی باشد چه اتفاقی باید بیفتد.»
یا:
«عبارت “زمان کوتاه” معیار مشخصی ندارد. آیا میتوان مقدار یا معیار قابل اندازهگیری تعیین کرد؟»
بعد از مطرح شدن موضوع، فرد یا تیم مسئول Requirement باید رفتار مورد انتظار را مشخص کند. بنابراین Tester نباید بدون هماهنگی، تصمیم محصول را به جای صاحب Requirement اتخاذ کند.
۱۰.۵. یک مثال واقعیتر از Requirement Review
فرض کنید FRD مربوط به یک سیستم بانکی نوشته شده است:
کاربر میتواند مبلغ موردنظر خود را انتقال دهد.
Tester هنگام Review ممکن است سؤالهایی مانند این مطرح کند:
- حداقل مبلغ انتقال چقدر است؟
- حداکثر مبلغ انتقال چقدر است؟
- اگر موجودی کافی نباشد چه اتفاقی میافتد؟
- اگر حساب مقصد وجود نداشته باشد چه؟
- اگر حساب مبدأ مسدود باشد چه؟
- اگر ارتباط با سرویس بانکی قطع شود چه؟
- اگر یک درخواست انتقال دوبار ارسال شود چه اتفاقی میافتد؟
همه این موارد لزوماً نباید در یک FRD واحد نوشته شوند؛ ممکن است برخی در اسناد یا منابع دیگری مشخص شده باشند. نکته مهم این است که اگر این موارد بر رفتار مورد انتظار سیستم تأثیر میگذارند، باید در جایی معتبر تعیین تکلیف شده باشند.
۱۰.۶. Requirement Review چگونه به Shift Left کمک میکند؟
فرض کنید یک Requirement ناقص قبل از شروع Development شناسایی شود.
تیم میتواند ابتدا رفتار مورد انتظار را شفاف کند و سپس Developer بر اساس نسخه اصلاحشده کار را شروع کند.
در این حالت، ممکن است از همان ابتدا از ایجاد یک خطای پیادهسازی جلوگیری شود.
بنابراین میتوان این مسیر را در نظر گرفت:
Requirement Review
↓
شفافسازی Requirement
↓
Development
↓
Testing
به جای اینکه مشکل تا مرحله تست باقی بماند و بعد به شکل یک Defect یا اختلاف تفسیری ظاهر شود.
۱۰.۷. آیا Tester باید در نوشتن FRD هم مشارکت کند؟
این موضوع به ساختار تیم و تعریف نقشها بستگی دارد.
معمولاً مسئول اصلی تعریف نیازمندیهای کسبوکار یا محصول شخص یا تیم دیگری است؛ مانند Business Analyst، Product Owner یا تیم Product. با این حال، Tester میتواند در بررسی، اصلاح و شفافسازی Requirementها مشارکت داشته باشد.
بهصورت ساده میتوان نقشها را اینگونه تصور کرد:
- Business / Product: چه مسئله یا نیازی باید حل شود؟
- Analysis: نیازمندی چگونه تحلیل و مستند شود؟
- Development: راهکار چگونه پیادهسازی شود؟
- Testing: آیا رفتار پیادهسازیشده مطابق رفتار مورد انتظار است و آیا Requirement برای تست کافی و قابل ارزیابی است؟
البته در تیمهای مختلف این مرزبندی میتواند متفاوت باشد و ممکن است برخی از این مسئولیتها بین چند نقش تقسیم شوند.
۱۰.۸. یک Tester خوب فقط Bug پیدا نمیکند
یکی از مهمترین پیامهای این مقاله همین نکته است.
اگر Tester فقط بعد از ساخته شدن نرمافزار Bug پیدا کند، بخشی از نقش خود را انجام داده است. اما اگر بتواند قبل از Development یک Requirement مبهم را شناسایی و برای شفافسازی آن سؤال مناسبی مطرح کند، ممکن است از ایجاد یک مشکل در مراحل بعدی جلوگیری شود.
به همین دلیل، آشنایی با FRD برای Tester فقط یادگیری یک سند مستنداتی نیست؛ بلکه به تقویت یک نگاه Quality-oriented کمک میکند؛ نگاهی که در آن Tester فقط به دنبال پیدا کردن خطا در محصول نیست، بلکه تلاش میکند ریسکهای کیفیت را از مراحل ابتدایی شناسایی کند.
در بخش بعدی، سراغ یکی از اسناد و مفاهیم بسیار نزدیک به FRD میرویم و بررسی میکنیم که Acceptance Criteria چه تفاوتی با FRD دارد و این دو چگونه میتوانند در فرآیند تست در کنار یکدیگر استفاده شوند.
۱۱. تفاوت FRD و Acceptance Criteria چیست؟ 🧩
وقتی Tester با FRD کار میکند، احتمالاً با مفهوم دیگری به نام Acceptance Criteria یا معیارهای پذیرش نیز مواجه میشود.
ممکن است در ابتدا این دو مفهوم شبیه به هم به نظر برسند؛ چون هر دو درباره رفتار مورد انتظار سیستم صحبت میکنند. اما معمولاً سطح و هدف آنها متفاوت است.
به زبان ساده میتوان گفت:
FRD مشخص میکند یک قابلیت از نظر عملکردی چه رفتاری باید داشته باشد.
Acceptance Criteria مشخص میکند چه شرایطی باید برقرار باشد تا آن قابلیت قابل قبول تلقی شود.
البته در پروژههای مختلف ممکن است این دو مفهوم تا حدی روی یکدیگر قرار بگیرند. همچنین Acceptance Criteria میتواند بخشی از مستندات Requirement باشد.
۱۱.۱. یک مثال ساده
فرض کنید قابلیت موردنظر این است:
کاربر باید بتواند رمز عبور خود را تغییر دهد.
در FRD ممکن است جزئیات عملکردی این قابلیت مشخص شود:
- کاربر رمز عبور فعلی را وارد میکند.
- کاربر رمز عبور جدید را وارد میکند.
- سیستم اعتبار رمز جدید را بررسی میکند.
- در صورت معتبر بودن، رمز عبور تغییر میکند.
- در صورت نامعتبر بودن، پیام مناسب نمایش داده میشود.
اما Acceptance Criteria میتواند شرایط قابل قبول بودن این رفتار را مشخص کند:
- Given: کاربر وارد حساب خود شده است.
When: رمز عبور فعلی و رمز عبور جدید معتبر را وارد میکند.
Then: سیستم باید رمز عبور را با موفقیت تغییر دهد. - Given: کاربر رمز عبور فعلی اشتباهی وارد کرده است.
When: درخواست تغییر رمز را ارسال میکند.
Then: سیستم نباید رمز عبور را تغییر دهد و باید پیام خطای مناسب نمایش دهد.
۱۱.۲. تفاوت را سادهتر کنیم
فرض کنیم FRD درباره قابلیت افزودن محصول به سبد خرید نوشته است:
کاربر میتواند محصول را به سبد خرید اضافه کند و سیستم باید تعداد و قیمت محصول را در سبد نمایش دهد.
حالا Acceptance Criteria میتواند شرایط مشخصتری را تعریف کند:
- اگر محصول موجود باشد و کاربر تعداد معتبر وارد کند، محصول باید به سبد اضافه شود.
- اگر تعداد واردشده بیشتر از موجودی باشد، سیستم نباید محصول را اضافه کند و باید پیام مناسب نمایش دهد.
- پس از افزودن موفق محصول، تعداد و قیمت صحیح باید در سبد نمایش داده شود.
در اینجا Acceptance Criteria کمک میکند مشخص شود چه شرایطی باید برقرار باشد تا قابلیت از دید محصول قابل قبول باشد.
۱۱.۳. چرا این تفاوت برای Tester مهم است؟
Tester ممکن است در یک پروژه با هر دو منبع مواجه شود. FRD رفتار عملکردی را توضیح میدهد و Acceptance Criteria شرایط پذیرش را مشخص میکند. Tester میتواند از ترکیب این اطلاعات برای طراحی تست استفاده کند.
برای مثال:
Requirement / FRD
↓
«کاربر میتواند محصول را به سبد خرید اضافه کند.»
Acceptance Criteria
↓
«اگر محصول موجود باشد، محصول باید با موفقیت به سبد اضافه شود.»
Test Scenario
↓
«بررسی افزودن محصول موجود به سبد خرید»
Test Case
↓
مراحل دقیق اجرای تست
این ارتباط به Tester کمک میکند از یک نیازمندی کلی به یک تست قابل اجرا برسد.
۱۱.۴. Acceptance Criteria همیشه جایگزین FRD نیست
این نکته مهم است که تصور نکنیم:
«اگر Acceptance Criteria داریم، دیگر به FRD نیاز نداریم.»
در برخی تیمها، مخصوصاً تیمهای Agile، ممکن است نیازمندیها بیشتر با User Story و Acceptance Criteria مدیریت شوند و اصلاً سندی با عنوان FRD وجود نداشته باشد.
در پروژههای دیگر ممکن است FRD وجود داشته باشد و Acceptance Criteria نیز برای قابلیتهای مختلف در کنار آن استفاده شود.
بنابراین باید به روش مستندسازی همان پروژه توجه کرد.
۱۱.۵. از دید Tester، مهمترین موضوع چیست؟
برای Tester نام سند در درجه دوم اهمیت قرار دارد. چیزی که واقعاً مهم است این است که بتواند پاسخ این سؤالها را پیدا کند:
- سیستم چه کاری باید انجام دهد؟
- در چه شرایطی؟
- چه نتیجهای قابل قبول است؟
- در شرایط خطا چه اتفاقی باید بیفتد؟
اگر این اطلاعات در FRD، Acceptance Criteria، User Story یا ترکیبی از چند سند قرار داشته باشند، Tester باید بتواند آنها را پیدا و به تست قابل اجرا تبدیل کند.
ارتباط FRD، Acceptance Criteria و Test Case
میتوانیم رابطه این مفاهیم را به شکل ساده اینطور ببینیم:
FRD
↓
رفتار عملکردی سیستم
Acceptance Criteria
↓
شرایط پذیرش قابلیت
Test Scenario
↓
چه چیزی باید بررسی شود؟
Test Case
↓
چگونه آن را بررسی کنیم؟
البته این زنجیره در همه تیمها دقیقاً به همین شکل اجرا نمیشود، اما برای درک ارتباط این مفاهیم، مدل مناسبی است.
۱۲. یک مثال کامل؛ از FRD تا Test Case 🧪
تا اینجا مفاهیم مختلفی را بررسی کردیم؛ اما برای اینکه ارتباط بین آنها کاملاً روشن شود، بهتر است همه چیز را در قالب یک مثال واقعی کنار هم قرار دهیم.
فرض کنیم قرار است برای یک فروشگاه اینترنتی قابلیت «ورود کاربر با شماره موبایل» طراحی و پیادهسازی شود.
۱۲.۱. بخشی از FRD
فرض کنیم در FRD این قابلیت به شکل زیر تعریف شده است:
FR-001: ورود کاربر با شماره موبایل
سیستم باید امکان ورود کاربران با استفاده از شماره موبایل و کد تأیید را فراهم کند.
- کاربر شماره موبایل خود را وارد میکند.
- سیستم معتبر بودن شماره موبایل را بررسی میکند.
- در صورت معتبر بودن شماره، کد تأیید برای کاربر ارسال میشود.
- کاربر کد تأیید را وارد میکند.
- در صورت صحیح بودن کد، کاربر وارد حساب خود میشود.
- در صورت اشتباه بودن کد، سیستم باید پیام خطای مناسب نمایش دهد.
- کد تأیید پس از ۲ دقیقه منقضی میشود.
- کاربر حداکثر میتواند ۵ بار کد اشتباه وارد کند.
حالا ببینیم Tester با این اطلاعات چه کاری انجام میدهد.
۱۲.۲. ابتدا Requirement را تحلیل میکنیم
Tester با خواندن این Requirement متوجه میشود که چند رفتار مختلف وجود دارد.
مسیر اصلی:
شماره معتبر → ارسال کد → کد صحیح → ورود موفق
اما فقط همین مسیر کافی نیست. چند سؤال مهم هم باید بررسی شوند:
- اگر شماره موبایل نامعتبر باشد چه؟
- اگر شماره خالی باشد چه؟
- اگر کد اشتباه باشد چه؟
- اگر کد منقضی شده باشد چه؟
- اگر کاربر ۵ بار کد اشتباه وارد کند چه؟
- اگر شماره متعلق به کاربر ثبتنشده باشد چه؟
- اگر ارسال کد با مشکل مواجه شود چه؟
بعضی از این موارد در FRD مشخص شدهاند و بعضی ممکن است نیاز به شفافسازی داشته باشند.
۱۲.۳. استخراج Test Scenario
حالا میتوانیم از Requirement چند Test Scenario استخراج کنیم:
سناریوهای مثبت:
- ورود با شماره موبایل معتبر و کد صحیح
- ورود موفق در محدوده زمانی اعتبار کد
سناریوهای منفی:
- ورود با شماره موبایل نامعتبر
- ورود با کد تأیید اشتباه
- ورود با کد تأیید منقضیشده
سناریوهای Boundary:
- وارد کردن کد اشتباه برای چهارمین بار
- وارد کردن کد اشتباه برای پنجمین بار
- وارد کردن کد اشتباه برای ششمین بار
این مرحله هنوز Test Case نیست. در اینجا فقط مشخص کردهایم چه شرایطی باید بررسی شوند.
۱۲.۴. تبدیل یک Scenario به Test Case
حالا سناریوی زیر را انتخاب میکنیم:
ورود با شماره موبایل معتبر و کد تأیید صحیح
Test Case ID: TC-001
عنوان: ورود موفق کاربر با شماره موبایل و کد صحیح
Precondition: کاربر دارای حساب کاربری معتبر است.
Test Steps:
- وارد صفحه ورود شوید.
- شماره موبایل معتبر کاربر را وارد کنید.
- روی گزینه دریافت کد تأیید کلیک کنید.
- کد ارسالشده را وارد کنید.
- گزینه ورود را انتخاب کنید.
Expected Result: کاربر باید با موفقیت وارد حساب کاربری خود شود.
۱۲.۵. یک Negative Test Case
سناریو:
ورود با کد تأیید اشتباه
Test Case ID: TC-002
عنوان: جلوگیری از ورود با کد تأیید اشتباه
Precondition: شماره موبایل معتبر است و کد تأیید برای کاربر ارسال شده است.
Test Steps:
- شماره موبایل معتبر را وارد کنید.
- کد تأیید دریافت کنید.
- کد اشتباه وارد کنید.
- روی گزینه ورود کلیک کنید.
Expected Result: کاربر نباید وارد حساب شود و سیستم باید پیام خطای مناسب نمایش دهد.
۱۲.۶. حالا Boundary Testing
در FRD گفته شده:
کاربر حداکثر میتواند ۵ بار کد اشتباه وارد کند.
اینجا Tester باید به مقادیر مرزی توجه کند:
| تعداد تلاش اشتباه | انتظار |
|---|---|
| ۴ | کاربر همچنان بتواند تلاش کند. |
| ۵ | رفتار تعریفشده برای پنجمین تلاش اعمال شود. |
| ۶ | کاربر نباید بتواند طبق همان جریان قبلی ادامه دهد. |
نکته مهم این است که FRD باید دقیقاً مشخص کند بعد از پنجمین تلاش چه اتفاقی میافتد.
مثلاً:
حساب کاربر به مدت ۱۰ دقیقه موقتاً مسدود میشود.
اگر چنین جزئیاتی مشخص نشده باشد، Tester باید قبل از اجرای تست درباره آن سؤال کند.
۱۲.۷. بررسی Expiration
در Requirement گفته شده:
کد تأیید پس از ۲ دقیقه منقضی میشود.
این Requirement یک Boundary دیگر ایجاد میکند. Tester میتواند شرایط زیر را بررسی کند:
- استفاده از کد قبل از ۲ دقیقه
- استفاده از کد در مرز ۲ دقیقه
- استفاده از کد بعد از ۲ دقیقه
اما یک سؤال مهم وجود دارد:
دقیقاً در لحظه ۲ دقیقه، کد معتبر است یا منقضی شده؟
این موضوع ممکن است از نظر تست بسیار مهم باشد و باید در Requirement یا Acceptance Criteria مشخص شود.
۱۲.۸. یک Requirement ناقص را هم پیدا کردیم
فرض کنید بعد از بررسی FRD متوجه شویم مشخص نشده:
اگر شماره موبایل متعلق به هیچ کاربری نباشد چه اتفاقی میافتد؟
آیا سیستم باید خطا نمایش دهد؟ کاربر را به صفحه ثبتنام هدایت کند؟ یا کد ارسال شود و حساب جدید ایجاد شود؟
Tester نباید خودش یکی از این گزینهها را انتخاب کند؛ این موضوع باید شفافسازی شود.
این دقیقاً یکی از نقشهای مهم Tester در Requirement Review است.
۱۲.۹. Traceability
حالا میتوانیم ارتباط Requirement با Test Caseها را نیز مشخص کنیم:
FR-001: ورود کاربر با شماره موبایل
- TC-001: ورود با کد صحیح
- TC-002: ورود با کد اشتباه
- TC-003: کد منقضیشده
- TC-004: پنجمین تلاش ناموفق
- TC-005: تلاش بعد از محدودیت
این ارتباط به تیم کمک میکند مطمئن شود Requirement موردنظر واقعاً پوشش تست دارد.
۱۲.۱۰. چیزی که از این مثال باید یاد بگیریم
این مثال نشان میدهد Tester قرار نیست صرفاً جمله موجود در FRD را به یک Test Case تبدیل کند.
مسیر واقعی بیشتر شبیه این است:
FRD
↓
درک Requirement
↓
پرسیدن سؤالهای لازم
↓
شناسایی شرایط مختلف
↓
Test Scenario
↓
Test Case
↓
Test Execution
و در بعضی موارد حتی ممکن است مسیر در همان ابتدا متوقف شود:
FRD
↓
Requirement مبهم
↓
Clarification
↓
اصلاح Requirement
↓
Test Design
این دقیقاً یکی از دلایلی است که میگوییم Tester از مرحله Requirement میتواند در کیفیت محصول نقش داشته باشد، نه اینکه فقط بعد از آماده شدن نرمافزار به دنبال Bug بگردد.
۱۳. FRD در Agile و Scrum چه جایگاهی دارد؟ 🔄
تا اینجا بیشتر درباره FRD در یک رویکرد نسبتاً سنتی صحبت کردیم؛ جایی که ممکن است نیازمندیها در قالب یک سند نسبتاً جامع مستند شوند.
اما وقتی وارد Agile و Scrum میشویم، ممکن است این سؤال پیش بیاید:
اگر در Agile از User Story و Acceptance Criteria استفاده میکنیم، پس FRD چه میشود؟
پاسخ کوتاه این است:
Agile لزوماً FRD را حذف یا ممنوع نمیکند؛ اما معمولاً مستندسازی را متناسب با نیاز تیم، اندازه قابلیت و میزان تغییرپذیری Requirementها انجام میدهد.
بنابراین شکل مستندسازی Requirementها میتواند با پروژههای سنتی متفاوت باشد، بدون اینکه نیاز به Requirementهای واضح و قابل تست از بین برود.
۱۳.۱. در Scrum لزوماً یک FRD بزرگ نداریم
فرض کنید در یک پروژه سنتی، قبل از شروع Development یک سند نسبتاً جامع تهیه میشود که قابلیتهای مختلف سیستم را توضیح میدهد.
اما در یک تیم Scrum ممکن است یک قابلیت به شکل یک User Story در Product Backlog ثبت شود:
بهعنوان یک کاربر، میخواهم بتوانم محصول را به سبد خرید اضافه کنم تا بتوانم خرید خود را انجام دهم.
سپس برای این User Story، Acceptance Criteria تعریف میشود؛ برای مثال:
- محصول موجود باید به سبد اضافه شود.
- تعداد محصول نباید از موجودی بیشتر باشد.
- پس از افزودن موفق، محصول باید در سبد نمایش داده شود.
در چنین حالتی، بخش مهمی از اطلاعات موردنیاز برای درک و تست قابلیت میتواند در همین User Story و Acceptance Criteria قرار داشته باشد.
۱۳.۲. آیا User Story همان FRD است؟
خیر. این دو مفهوم را نباید یکی در نظر گرفت.
User Story معمولاً یک نیاز یا قابلیت را از دید کاربر بیان میکند و در Agile بهعنوان یک واحد کاری نسبتاً کوچک استفاده میشود.
مثلاً:
بهعنوان مشتری، میخواهم بتوانم سفارش خود را لغو کنم تا در صورت تغییر تصمیم، خرید را ادامه ندهم.
اما برای پیادهسازی و تست این قابلیت، ممکن است جزئیات بیشتری لازم باشد:
- چه زمانی لغو سفارش مجاز است؟
- چه وضعیتهایی از سفارش قابل لغو هستند؟
- در صورت لغو چه اتفاقی برای سفارش میافتد؟
- چه پیامی به کاربر نمایش داده میشود؟
- چه محدودیتهایی وجود دارد؟
این اطلاعات ممکن است در Acceptance Criteria، Business Rules، مستندات محصول یا سایر منابع قرار داشته باشند. بنابراین User Story را نباید معادل یک FRD کامل در نظر گرفت.
۱۳.۳. پس در Agile اطلاعات موردنیاز Tester کجا قرار دارد؟
در یک پروژه Agile ممکن است اطلاعات موردنیاز Tester در چند منبع مختلف قرار داشته باشد:
User Story
↓
Acceptance Criteria
↓
Business Rules
↓
Product / Design Documentation
↓
API Documentation یا سایر مستندات فنی
بنابراین Tester در یک تیم Agile نباید الزاماً منتظر یک فایل با نام FRD باشد.
آنچه اهمیت دارد این است که بتواند پاسخ سؤال اصلی را پیدا کند:
رفتار مورد انتظار این قابلیت چیست؟
۱۳.۴. نقش Tester در Agile
در Agile، Tester بهتر است از ابتدای چرخه توسعه درگیر شود؛ نه اینکه فقط بعد از آماده شدن Feature وارد فرآیند شود.
برای مثال، در زمان Backlog Refinement یا جلسات مربوط به بررسی User Story، Tester میتواند سؤالهایی مانند اینها مطرح کند:
- اگر کاربر سفارش ارسالشده را لغو کند چه اتفاقی میافتد؟
- اگر موجودی محصول صفر باشد چه؟
- حداکثر تعداد قابل سفارش چقدر است؟
- اگر پرداخت موفق شود اما ثبت سفارش با خطا مواجه شود چه؟
این سؤالها کمک میکنند قبل از شروع Development، رفتار مورد انتظار روشنتر شود.
۱۳.۵. آیا در Agile دیگر Requirement Review نداریم؟
چرا، داریم؛ فقط ممکن است شکل آن متفاوت باشد.
در یک پروژه سنتی ممکن است Tester یک سند FRD چند ده صفحهای را Review کند. در Scrum ممکن است همین بررسی روی یک User Story و Acceptance Criteria در Backlog Refinement انجام شود.
هدف در هر دو حالت مشابه است:
پیدا کردن ابهامها و مشخص کردن رفتار مورد انتظار قبل از پیادهسازی.
بنابراین Agile نیاز به Requirementهای واضح و قابل تست را از بین نمیبرد؛ بلکه نحوه تعریف، مدیریت و تکامل آنها را تغییر میدهد.
۱۳.۶. یک مقایسه ساده
| رویکرد سنتی | Agile / Scrum |
|---|---|
| ممکن است FRD جامع وجود داشته باشد. | ممکن است User Story و Acceptance Criteria منبع اصلی باشند. |
| Requirementها ممکن است در سندهای رسمی متمرکز باشند. | اطلاعات ممکن است در چند Artifact مختلف قرار داشته باشند. |
| Requirement Review ممکن است بهصورت بررسی یک سند انجام شود. | بررسی Requirement میتواند در Backlog Refinement انجام شود. |
| Test Design بر اساس Requirementهای مستندشده انجام میشود. | Test Design میتواند بر اساس Story، Criteria و سایر منابع انجام شود. |
این جدول فقط یک مدل ساده برای درک تفاوت است و نباید آن را بهعنوان یک قانون ثابت در تمام پروژهها در نظر گرفت. در پروژههای Agile نیز ممکن است FRD یا سایر مستندات رسمی وجود داشته باشند.
۱۳.۷. نکته مهم برای Tester
اگر در یک پروژه Agile کار میکنید و سندی به نام FRD وجود ندارد، نباید نتیجه بگیرید:
«پس Requirement نداریم.»
بلکه باید ببینید Requirementها کجا و چگونه مستند شدهاند.
- User Story
- Acceptance Criteria
- Product Backlog
- Wiki
- مستندات محصول
- Business Rules
- API Documentation
وظیفه Tester این است که منبع معتبر رفتار مورد انتظار را پیدا کند و بتواند بر اساس آن تست طراحی کند.
در نتیجه، نبود FRD بهتنهایی نشانه ضعف فرآیند نیست؛ همانطور که وجود یک FRD جامع نیز بهتنهایی تضمینکننده کیفیت Requirementها نیست.
جمعبندی این بخش
FRD یک قالب یا الزام جهانی برای همه پروژهها نیست. در برخی پروژهها میتواند سند اصلی Functional Requirements باشد و در برخی تیمهای Agile، اطلاعات موردنیاز ممکن است در User Story، Acceptance Criteria و سایر مستندات توزیع شده باشد.
اما یک اصل تغییر نمیکند:
قبل از اینکه بتوانیم نرمافزار را درست تست کنیم، باید بدانیم رفتار مورد انتظار آن چیست.
و این دقیقاً همان نقطهای است که مهارت Tester در Requirement Analysis اهمیت پیدا میکند.
۱۴. اشتباهات رایج در کار با FRD از نگاه Tester ⚠️
داشتن FRD بهتنهایی تضمین نمیکند که فرآیند تست بهدرستی انجام شود. مهم این است که Tester چگونه FRD را بخواند، تحلیل کند و از اطلاعات آن استفاده کند.
چند اشتباه در این مرحله میتواند باعث شود بخشی از مشکلات سیستم اصلاً وارد فرآیند تست نشوند یا تستها بر اساس برداشت نادرست طراحی شوند.
۱۴.۱. فقط Happy Path را تست کنیم
یکی از رایجترین اشتباهات این است که Tester فقط مسیر موفق را از روی FRD استخراج کند.
کاربر اطلاعات صحیح را وارد میکند و با موفقیت وارد سیستم میشود.
این تست لازم است، اما کافی نیست. باید شرایط دیگری نیز بررسی شوند:
- اطلاعات اشتباه
- فیلدهای خالی
- فرمت نامعتبر
- کاربر غیرفعال
- محدودیت تعداد تلاش
- خطای سرویس وابسته
بنابراین هنگام مطالعه FRD همیشه باید پرسید:
اگر همه چیز طبق انتظار پیش نرود، سیستم چه رفتاری باید داشته باشد؟
۱۴.۲. فرض کردن Requirementهای نوشتهنشده
گاهی Tester بر اساس تجربه قبلی خودش تصمیم میگیرد سیستم باید چه رفتاری داشته باشد.
مثلاً:
«به نظر من بعد از سه بار ورود اشتباه، حساب باید قفل شود.»
اما اگر چنین چیزی در Requirement مشخص نشده باشد، Tester نباید آن را بهعنوان Expected Result قطعی در نظر بگیرد.
تجربه Tester برای کشف سؤال و شناسایی ریسک بسیار ارزشمند است، اما جای Requirement را نمیگیرد.
۱۴.۳. نادیده گرفتن ابهامها
گاهی Tester متوجه یک عبارت مبهم میشود اما آن را نادیده میگیرد.
مثلاً:
«سیستم باید پاسخ را سریع نمایش دهد.»
اگر این موضوع شفاف نشود، Tester ممکن است بعداً با Developer یا سایر اعضای تیم درباره اینکه «سریع» دقیقاً به چه معناست اختلاف پیدا کند.
بهتر است ابهام در همان مرحله Requirement Review مطرح و معیار قابل اندازهگیری آن مشخص شود.
۱۴.۴. تصور اینکه FRD همیشه کامل است
وجود یک سند رسمی به این معنی نیست که همه چیز در آن درست و کامل است.
ممکن است FRD:
- ناقص باشد؛
- قدیمی شده باشد؛
- با نسخه فعلی محصول هماهنگ نباشد؛
- شامل Requirementهای متناقض باشد؛
- یا برخی سناریوها را پوشش نداده باشد.
Tester باید FRD را منبع اطلاعاتی قابل بررسی بداند، نه سندی که بدون تحلیل باید پذیرفته شود.
۱۴.۵. نادیده گرفتن تغییرات Requirement
فرض کنید محدودیت یک قابلیت از ۱۰ به ۲۰ تغییر کرده است.
اگر Tester این تغییر را متوجه نشود، ممکن است Test Caseهای قدیمی را اجرا کند و به نتیجه اشتباه برسد.
به همین دلیل باید مشخص باشد:
کدام Test Caseها به کدام Requirement وابسته هستند؟
اینجاست که Traceability اهمیت پیدا میکند.
۱۴.۶. طراحی Test Case قبل از شفاف شدن Requirement
گاهی Tester بلافاصله بعد از دریافت FRD شروع به نوشتن Test Case میکند؛ اما اگر Requirement هنوز ابهام داشته باشد، ممکن است تعداد زیادی Test Case بر اساس یک برداشت اشتباه ایجاد شود.
ترتیب منطقیتر این است:
Requirement Review
↓
Clarification
↓
Test Scenario
↓
Test Case
این کار از دوبارهکاری جلوگیری میکند.
۱۴.۷. بررسی جداگانه Requirementها بدون توجه به ارتباط آنها
گاهی دو Requirement بهصورت جداگانه کاملاً منطقی هستند، اما در کنار هم تناقض ایجاد میکنند.
مثلاً:
FR-01: کاربر میتواند سفارش را لغو کند.
FR-02: سفارش پس از ارسال قابل تغییر نیست.
اگر مشخص نشده باشد که «لغو» جزو تغییر محسوب میشود یا خیر، Tester با یک ابهام مواجه است.
بنابراین علاوه بر بررسی تکتک Requirementها، باید ارتباط و سازگاری بین Requirementها نیز بررسی شود.
۱۴.۸. تمرکز فقط روی Functional Flow
FRD معمولاً تمرکز زیادی روی رفتارهای عملکردی دارد، اما Tester نباید تصور کند کیفیت نرمافزار فقط با بررسی Functional Requirements مشخص میشود.
ممکن است موضوعاتی مانند موارد زیر نیز برای محصول مهم باشند:
- Performance
- Security
- Usability
- Reliability
- Compatibility
البته این موارد لزوماً قرار نیست داخل FRD تعریف شوند و ممکن است در Non-functional Requirements یا اسناد دیگری مستند شده باشند.
بنابراین Tester باید بداند:
FRD فقط یکی از منابع اطلاعاتی موردنیاز برای تست است، نه تمام اطلاعات موردنیاز برای ارزیابی کیفیت نرمافزار.
۱۴.۹. تصور اینکه تعداد Test Case بیشتر یعنی تست بهتر
ممکن است یک Requirement فقط ۵ Test Case داشته باشد و Requirement دیگری ۵۰ Test Case. این تعداد بهتنهایی نشان نمیدهد کدام تست بهتر است.
معیار مهمتر این است که آیا رفتارهای مهم، شرایط مرزی، حالتهای خطا و ریسکهای واقعی سیستم پوشش داده شدهاند یا خیر.
هدف Tester نباید تولید بیشترین تعداد Test Case باشد؛ بلکه باید پوشش مناسب و معنادار ایجاد کند.
۱۴.۱۰. فراموش کردن اینکه Requirementها تغییر میکنند
در بسیاری از پروژهها Requirementها در طول زمان تغییر میکنند. ممکن است Feature جدیدی اضافه شود، یک محدودیت تغییر کند یا رفتار یک قابلیت اصلاح شود.
بنابراین Tester نباید FRD یا هر منبع دیگری از Requirement را سندی ثابت بداند که فقط یکبار خوانده میشود.
هر تغییر مهم در Requirement میتواند باعث شود نیاز باشد:
- Test Scenarioها بازبینی شوند.
- Test Caseها اصلاح شوند.
- Test Data تغییر کند.
- Regression Testها دوباره اجرا شوند.
مهمترین نکته 🎯
اگر بخواهیم تمام این اشتباهات را در یک جمله خلاصه کنیم:
بزرگترین اشتباه Tester این است که FRD را فقط بخواند، بدون اینکه آن را تحلیل کند.
یک Tester خوب هنگام خواندن FRD دائماً سؤال میپرسد:
- چه چیزی باید اتفاق بیفتد؟
- چه زمانی باید اتفاق بیفتد؟
- چه زمانی نباید اتفاق بیفتد؟
- اگر ورودی اشتباه باشد چه؟
- اگر محدودیت رعایت نشود چه؟
- آیا این Requirement قابل تست است؟
- آیا چیزی در آن مبهم یا ناقص است؟
- آیا با Requirement دیگری تناقض دارد؟
این نوع نگاه است که FRD را از یک سند مستنداتی ساده به یک منبع ارزشمند برای فعالیتهای QA و Testing تبدیل میکند.
در بخش بعدی، یک چکلیست کاربردی برای بررسی FRD از دید Tester تهیه میکنیم تا بتوانید هنگام Review یک سند واقعی، مرحلهبهمرحله از آن استفاده کنید.
۱۵. چکلیست بررسی FRD از نگاه Tester ✅
تا اینجا دیدیم که Tester چگونه میتواند یک FRD را بخواند، Requirementها را تحلیل کند، ابهامها را شناسایی کند و از آنها Test Scenario و Test Case استخراج کند.
اما در یک پروژه واقعی، داشتن یک Checklist میتواند این فرآیند را منظمتر کند و کمک کند نکات مهم هنگام Requirement Review فراموش نشوند.
چکلیست زیر یک چارچوب عملی برای بررسی FRD از دید Tester است. لازم نیست در هر پروژه تمام موارد با یک میزان اهمیت بررسی شوند؛ نوع محصول، ریسکها و شرایط پروژه تعیین میکنند کدام موارد اهمیت بیشتری دارند.
۱۵.۱. بررسی کلی FRD
قبل از ورود به جزئیات Requirementها، ابتدا باید تصویر کلی قابلیت را درک کنید:
- هدف قابلیت مشخص است.
- کاربر یا نقش استفادهکننده از قابلیت مشخص است.
- جریان کلی عملکرد قابل درک است.
- ارتباط قابلیت با سایر بخشهای سیستم مشخص است.
- اصطلاحات تخصصی استفادهشده قابل فهم هستند.
- نسخه یا وضعیت فعلی Requirement مشخص است.
در این مرحله هنوز لازم نیست Test Case طراحی کنید. هدف این است که ابتدا بدانید چه چیزی قرار است ساخته شود، برای چه کسی و با چه هدفی.
۱۵.۲. بررسی هر Requirement
برای هر Requirement میتوانید سؤالهای زیر را بررسی کنید:
- Requirement واضح و قابل فهم است.
- فقط یک برداشت منطقی از آن وجود دارد.
- رفتار مورد انتظار سیستم مشخص است.
- Actor یا کاربر مربوطه مشخص است.
- شرایط اجرای Requirement مشخص است.
- ورودیهای موردنیاز مشخص هستند.
- خروجی مورد انتظار مشخص است.
- محدودیتها و قوانین مرتبط مشخص هستند.
- رفتار سیستم در شرایط خطا مشخص است.
- Requirement قابل تست است.
اگر برای یکی از این موارد پاسخ مشخصی ندارید، ممکن است Requirement به Clarification نیاز داشته باشد.
۱۵.۳. بررسی Positive و Negative Scenarioها
برای هر قابلیت ابتدا از خودتان بپرسید:
اگر همه چیز طبق انتظار پیش برود، چه اتفاقی باید بیفتد؟
این سؤال به شناسایی Happy Path کمک میکند.
سپس شرایطی را بررسی کنید که در آن ورودی یا وضعیت سیستم مطابق حالت عادی نیست:
- اگر ورودی نامعتبر باشد چه؟
- اگر یک شرط لازم برقرار نباشد چه؟
- اگر کاربر مجاز نباشد چه؟
- اگر عملیات قبلاً انجام شده باشد چه؟
- اگر سرویس وابسته در دسترس نباشد چه؟
- اگر یک خطای غیرمنتظره رخ دهد چه؟
این سؤالها به شناسایی Negative Scenarioها و شرایط استثنایی کمک میکنند.
۱۵.۴. بررسی Boundaryها و محدودیتها
هرجا در Requirement یک حد، بازه یا محدودیت مشخص شده است، باید به مقادیر مرزی توجه کنید.
مثلاً اگر گفته شده باشد:
حداقل سن کاربر ۱۸ سال است.
مقادیر اطراف مرز میتوانند اهمیت زیادی داشته باشند:
۱۷ → ۱۸ → ۱۹
یا اگر حداکثر مبلغ انتقال ۱۰ میلیون تومان باشد:
۹,۹۹۹,۹۹۹ → ۱۰,۰۰۰,۰۰۰ → ۱۰,۰۰۰,۰۰۱
همچنین باید بررسی شود که Requirement درباره رفتار دقیق سیستم در این نقاط مرزی شفاف است یا خیر.
۱۵.۵. بررسی ابهامها
به عبارتهایی که تعریف دقیق و قابل اندازهگیری ندارند حساس باشید؛ برای مثال:
- سریع
- مناسب
- کافی
- معمولاً
- بهزودی
- در صورت نیاز
- کاربر مجاز
- اطلاعات معتبر
سؤال اصلی این است:
آیا برای این عبارت یک تعریف دقیق و قابل تست وجود دارد؟
اگر پاسخ منفی است، بهتر است موضوع قبل از طراحی تست یا اجرای آن شفاف شود.
۱۵.۶. بررسی تناقض بین Requirementها
Requirementها را فقط بهصورت جداگانه بررسی نکنید. گاهی هر Requirement بهتنهایی منطقی است، اما ترکیب آنها باعث ایجاد تناقض میشود.
مثلاً:
FR-01: کاربر میتواند سفارش را لغو کند.
FR-02: سفارش پس از ارسال قابل تغییر نیست.
در اینجا باید مشخص شود که آیا «لغو سفارش» نیز جزو «تغییر» محسوب میشود یا خیر.
- Requirementها با یکدیگر سازگار هستند.
- قوانین کسبوکار با یکدیگر تناقض ندارند.
- شرایط استثنا و اولویت قوانین مشخص است.
۱۵.۷. بررسی Dependencyها
برای هر قابلیت بررسی کنید آیا اجرای آن به بخش دیگری از سیستم یا یک سرویس خارجی وابسته است یا خیر.
مثلاً یک قابلیت ثبت سفارش ممکن است به Payment Service و Inventory Service وابسته باشد.
در چنین شرایطی باید مشخص باشد اگر سرویس وابسته در دسترس نباشد، Timeout شود یا خطا برگرداند، سیستم چه رفتاری باید داشته باشد.
۱۵.۸. بررسی Traceability
در نهایت باید بتوانید ارتباط بین Requirement و تست را مشخص کنید:
Requirement → Test Scenario → Test Case
- برای Requirementهای مهم Test Scenario مرتبط وجود دارد.
- Test Caseهای مناسب برای Scenarioها طراحی شدهاند.
- شرایط مثبت و منفی در صورت نیاز پوشش داده شدهاند.
- Boundaryها و محدودیتهای مهم بررسی شدهاند.
- تغییرات Requirement قابل ردیابی هستند.
این ارتباط به ایجاد Requirement Traceability کمک میکند و در بخشهای بعدی مقاله بیشتر به آن میپردازیم.
۱۵.۹. چکلیست سریع برای استفاده روزمره
اگر بخواهیم تمام موارد بالا را به یک نسخه سریع تبدیل کنیم، میتوانید هنگام Review هر FRD این ۱۰ سؤال را از خودتان بپرسید:
- هدف قابلیت چیست؟
- چه کسی از آن استفاده میکند؟
- رفتار مورد انتظار چیست؟
- ورودی و خروجی چیست؟
- Happy Path چیست؟
- Negative Scenarioها چیستند؟
- Boundaryها و محدودیتها چیستند؟
- چه Dependencyهایی وجود دارد؟
- آیا Requirement مبهم، ناقص یا متناقض است؟
- آیا میتوان بر اساس آن Test Case قابل اجرا طراحی کرد؟
اگر پاسخ این سؤالها مشخص باشد، بخش مهمی از تحلیل Requirement از دید Tester انجام شده است.
۱۵.۱۰. Checklist جایگزین تحلیل Tester نیست
این Checklist قرار نیست جایگزین تجربه، تحلیل ریسک و دانش دامنه شود.
ممکن است در یک سیستم بانکی، موضوعاتی مانند Security و Transaction Integrity اهمیت بیشتری داشته باشند و در یک فروشگاه اینترنتی، Inventory و Payment ریسکهای مهمتری ایجاد کنند.
بنابراین بهتر است Checklist را یک چارچوب ذهنی برای Requirement Review بدانیم، نه یک فرم ثابت که بدون تحلیل فقط تیک زده شود.
در بخش بعدی بررسی میکنیم که آیا Tester لازم است تمام صفحات یک FRD را با یک میزان جزئیات مطالعه کند یا میتواند برای بررسی یک سند بزرگ، رویکرد هدفمندتری داشته باشد.
۱۶. آیا Tester باید کل FRD را بخواند؟ 🤔
وقتی یک Tester برای اولین بار با یک FRD نسبتاً طولانی مواجه میشود، ممکن است این سؤال برایش پیش بیاید:
آیا باید تمام سند را از ابتدا تا انتها با جزئیات بخوانم؟
پاسخ این است: نه لزوماً.
Tester باید درک مناسبی از FRD داشته باشد، اما لازم نیست تمام بخشهای سند را با یک سطح از جزئیات مطالعه کند. در پروژههای واقعی، رویکرد مؤثرتر این است که ابتدا تصویر کلی را به دست بیاورد و سپس روی بخشهایی تمرکز کند که برای Test Analysis و Quality اهمیت بیشتری دارند.
۱۶.۱. ابتدا یک مرور کلی انجام دهید
در اولین مرحله، سند را سریع مرور کنید و به دنبال پاسخ این سؤالها باشید:
- FRD مربوط به چه محصول یا قابلیتی است؟
- هدف قابلیت چیست؟
- کاربران یا نقشهای درگیر چه کسانی هستند؟
- کدام بخشهای سیستم تحت تأثیر قرار میگیرند؟
- جریان کلی عملکرد چگونه است؟
- Requirementهای اصلی کداماند؟
هدف این مرحله ایجاد یک Mental Model از قابلیت است؛ یعنی قبل از ورود به جزئیات، بدانید سیستم در سطح کلی قرار است چگونه کار کند.
۱۶.۲. سپس بخشهای مهم برای تست را عمیقتر بررسی کنید
بعد از ایجاد تصویر کلی، روی بخشهایی تمرکز کنید که مستقیماً روی طراحی و اجرای تست تأثیر میگذارند.
- Functional Requirements: رفتار اصلی سیستم
- Business Rules: قوانین و محدودیتهای کسبوکار
- Input / Output: دادههای ورودی و خروجی
- Error Handling: رفتار سیستم در شرایط خطا
- Constraints: محدودیتها و Boundaryها
- Dependencies: ارتباط با سایر بخشها یا سرویسها
- Exceptions: شرایط استثنایی و مسیرهای غیرعادی
البته این موارد در همه FRDها با همین عنوانها وجود ندارند و ممکن است اطلاعات موردنیاز در بخشهای مختلف سند قرار گرفته باشد.
۱۶.۳. جریانهای اصلی را برای خودتان ترسیم کنید
اگر قابلیت پیچیده است، خواندن متن بهتنهایی ممکن است برای درک ارتباط بین بخشها کافی نباشد. میتوانید جریان اصلی را بهصورت ساده برای خودتان ترسیم کنید.
Login → Authentication → Dashboard
یا در یک فروشگاه اینترنتی:
Product → Cart → Payment → Order
این کار کمک میکند نقاط حساس، Dependencyها و بخشهایی را که احتمالاً نیاز به تست بیشتری دارند سریعتر شناسایی کنید.
۱۶.۴. FRD را با نگاه «چه چیزی میتواند خراب شود؟» بخوانید
یکی از تفاوتهای مهم بین خواندن FRD توسط یک کاربر عادی و یک Tester، نوع سؤالاتی است که هنگام مطالعه مطرح میشود.
کاربر ممکن است بخواند:
کاربر میتواند سفارش خود را لغو کند.
اما Tester احتمالاً سؤالهای بیشتری مطرح میکند:
- در چه وضعیتی لغو سفارش مجاز است؟
- چه کاربری اجازه لغو دارد؟
- آیا محدودیت زمانی وجود دارد؟
- اگر سفارش قبلاً لغو شده باشد چه؟
- اگر عملیات لغو ناموفق باشد چه؟
- اگر ارتباط با Server قطع شود چه؟
بنابراین Tester هنگام مطالعه Requirement فقط به مسیر اصلی فکر نمیکند؛ بلکه به دنبال Risk، حالتهای مرزی و شرایطی است که ممکن است رفتار سیستم را تغییر دهند.
۱۶.۵. ابهامها را همان لحظه ثبت کنید
اگر در حین مطالعه به عبارتی رسیدید که واضح نیست، بهتر است آن را همان لحظه ثبت کنید تا در Requirement Review یا Refinement مطرح شود.
مثلاً:
«سیستم باید در مدت کوتاهی پاسخ دهد.»
سؤال:
Clarification Needed: «مدت کوتاه» دقیقاً چه مقدار زمانی است؟
یا:
«کاربر مجاز میتواند سفارش را لغو کند.»
سؤال:
Clarification Needed: چه کاربری مجاز محسوب میشود و بر چه اساسی؟
۱۶.۶. هنگام خواندن FRD بلافاصله Test Case ننویسید
یکی از اشتباهات رایج این است که Tester هنگام مطالعه هر Requirement بلافاصله شروع به نوشتن Test Case کند.
بهتر است ابتدا این مسیر را طی کنید:
Understand → Analyze → Clarify → Identify Scenarios → Design Test Cases
ممکن است در مرحله تحلیل متوجه شوید Requirement ناقص است، یک سؤال مهم وجود دارد یا حتی نیازمندی باید تغییر کند. در چنین شرایطی طراحی Test Case قبل از شفاف شدن Requirement باعث دوبارهکاری میشود.
۱۶.۷. یک روش عملی برای FRDهای بزرگ
اگر FRD مثلاً ۱۰۰ صفحه باشد، میتوانید بررسی آن را به چند مرحله تقسیم کنید:
- Overview: شناخت محصول، Feature و هدف آن
- Requirements: بررسی Requirementهای مرتبط
- Business Rules: شناخت قوانین و محدودیتها
- Exceptions: بررسی شرایط خطا و استثنا
- Dependencies: بررسی ارتباط با سایر بخشها و سرویسها
- Test Analysis: تبدیل اطلاعات به Test Scenario و Test Case
این رویکرد هدفمند معمولاً از خواندن خطبهخط یک سند بزرگ بدون توجه به Scope و هدف تست، کارآمدتر است.
۱۶.۸. آیا بخشهای غیرمرتبط را میتوان نادیده گرفت؟
نه بهصورت کامل.
ممکن است بخشی از FRD مستقیماً Test Case ایجاد نکند، اما برای درک Context، Dependency یا تأثیر یک Requirement لازم باشد.
بنابراین بهتر است بهجای این ذهنیت که:
«این بخش Test Case ندارد، پس لازم نیست بخوانمش.»
از خودتان بپرسید:
«آیا دانستن این اطلاعات برای درک رفتار سیستم، ریسکها یا محدوده تست لازم است؟»
این نگاه باعث میشود هم از مطالعه غیرضروری جلوگیری کنید و هم اطلاعات مهم را از دست ندهید.
۱۶.۹. هدف نهایی چیست؟
در پایان مطالعه FRD، هدف این نیست که بتوانید تمام محتوای سند را از حفظ توضیح دهید.
هدف این است که بتوانید بگویید:
- قابلیت قرار است چه کاری انجام دهد.
- چه شرایطی روی رفتار آن تأثیر میگذارند.
- چه سناریوهایی باید بررسی شوند.
- چه ریسکها و حالتهای خطایی وجود دارند.
- کدام Requirementها مبهم یا ناقص هستند.
- برای طراحی تست چه اطلاعات بیشتری لازم است.
این تفاوت بین خواندن Requirement و تحلیل Requirement از دید تست است.
در بخش بعدی، سراغ Requirement Traceability میرویم و بررسی میکنیم چگونه ارتباط بین Requirement، Test Scenario، Test Case و Defect را حفظ کنیم.
۱۷. ارتباط FRD با Requirement Traceability 🔗
یکی از موضوعات مهم در پروژههای واقعی این است که بتوانیم مشخص کنیم هر Requirement چگونه به فعالیتهای تست مرتبط است.
فرض کنید یک پروژه شامل صدها Requirement و صدها Test Case باشد. اگر بین این موارد ارتباط مشخصی وجود نداشته باشد، خیلی زود سؤالهایی مطرح میشود:
- آیا این Requirement تست شده است؟
- اگر Requirement تغییر کند، کدام Test Caseها تحت تأثیر قرار میگیرند؟
- اگر یک Test Case Fail شود، مربوط به کدام Requirement است؟
اینجاست که مفهوم Requirement Traceability اهمیت پیدا میکند.
۱۷.۱. Requirement Traceability چیست؟
به زبان ساده، Requirement Traceability یعنی بتوانیم ارتباط یک Requirement را با مراحل مختلف تحلیل، طراحی، توسعه و تست دنبال کنیم.
برای مثال، ارتباط یک Requirement میتواند به شکل زیر باشد:
FR-003
↓
Test Scenario
↓
Test Case
↓
Test Execution
↓
Defect
البته Traceability میتواند بسته به فرآیند و ابزارهای پروژه، شکلهای مختلفی داشته باشد.
۱۷.۲. یک مثال ساده
فرض کنید در FRD نوشته شده است:
FR-005: کاربر باید بتواند رمز عبور خود را تغییر دهد.
حالا Tester میتواند برای این Requirement چند Test Scenario تعریف کند:
- تغییر موفق رمز عبور با اطلاعات صحیح
- تلاش برای تغییر رمز با رمز فعلی اشتباه
- استفاده از رمز جدید نامعتبر
- استفاده از رمز جدید یکسان با رمز قبلی، در صورت وجود چنین محدودیتی
سپس این Scenarioها به Test Caseهای مشخص تبدیل میشوند:
FR-005
↳ TS-01: تغییر موفق رمز
↳ TS-02: رمز فعلی اشتباه
↳ TS-03: رمز جدید نامعتبر
↳ TS-04: رمز جدید تکراری
در این حالت میتوانیم مسیر Requirement تا تست را بهصورت قابلردگیری مشاهده کنیم.
۱۷.۳. Traceability فقط ارتباط Requirement و Test Case نیست
در پروژههای بزرگتر، Traceability میتواند ارتباطهای بیشتری را نیز پوشش دهد.
Requirement
↓
Design
↓
Development
↓
Test Case
↓
Test Result
↓
Defect
این ارتباط باعث میشود بتوانیم مسیر یک Requirement را از زمان تعریف تا زمان ارزیابی کیفیت آن دنبال کنیم.
۱۷.۴. چرا Traceability برای Tester مهم است؟
یکی از مهمترین کاربردهای Traceability در زمان تغییر Requirement مشخص میشود.
فرض کنید Requirement زیر تغییر کند:
حداکثر تعداد محصول قابل سفارش از ۱۰ عدد به ۵ عدد کاهش پیدا کرده است.
اگر Traceability مناسبی داشته باشیم، میتوانیم سریع مشخص کنیم کدام تستها به این Requirement وابسته هستند.
FR-007
↓
TC-021
TC-022
TC-023
در نتیجه Tester میداند که این Test Caseها باید بازبینی و در صورت نیاز اصلاح شوند.
بدون Traceability، پیدا کردن موارد تحت تأثیر تغییر میتواند زمانبر و مستعد خطا باشد.
۱۷.۵. Traceability و Requirementهای بدون پوشش تست
فرض کنید FRD شامل ۵۰ Requirement است و بعد از طراحی تست متوجه شویم فقط ۴۵ Requirement حداقل یک Test Case مرتبط دارند.
این موضوع میتواند یک هشدار برای بررسی بیشتر باشد.
البته نداشتن Test Case مستقیم برای یک Requirement همیشه به معنی نقص نیست. ممکن است Requirement:
- خارج از Scope تست باشد.
- از طریق Test Case دیگری پوشش داده شده باشد.
- به شکل غیرمستقیم توسط تستهای دیگر بررسی شود.
بنابراین هدف Traceability صرفاً رسیدن به یک عدد مشخص نیست؛ بلکه باید بتوانیم وضعیت پوشش و دلیل آن را درک کنیم.
۱۷.۶. Traceability برای Defectها
Traceability میتواند ارتباط Defect با Test Case و Requirement را نیز مشخص کند.
مثلاً:
Bug-104
↓
TC-023
↓
FR-007
با این ارتباط میتوان سریعتر مشخص کرد Defect مربوط به کدام Requirement است و در صورت تغییر آن Requirement، چه موارد دیگری ممکن است تحت تأثیر قرار بگیرند.
۱۷.۷. Requirement Traceability Matrix چیست؟
برای مدیریت Traceability میتوان از Requirement Traceability Matrix (RTM) استفاده کرد.
| Requirement | Test Scenario | Test Case | Status |
|---|---|---|---|
| FR-001 | ورود موفق | TC-001 | Pass |
| FR-001 | رمز اشتباه | TC-002 | Pass |
| FR-002 | افزودن محصول | TC-003 | Pass |
| FR-002 | محصول ناموجود | TC-004 | Fail |
| FR-003 | لغو سفارش | TC-005 | Not Run |
ساختار RTM بسته به پروژه میتواند متفاوت باشد و ستونهای دیگری مانند Priority، Defect ID یا Test Execution نیز به آن اضافه شوند.
هدف اصلی این ماتریس این است که پوشش Requirementها و وضعیت تست آنها قابل مشاهده و قابل پیگیری باشد.
۱۷.۸. آیا همه پروژهها به RTM رسمی نیاز دارند؟
خیر.
در یک پروژه کوچک ممکن است ایجاد یک فایل یا جدول رسمی RTM ارزش زیادی نداشته باشد. در مقابل، پروژههای بزرگ یا حساس ممکن است به Traceability دقیقتری نیاز داشته باشند.
همچنین ابزارهای مدیریت تست و مدیریت پروژه میتوانند ارتباط بین Requirement، Test و Defect را بهصورت داخلی نگهداری کنند.
بنابراین نکته مهم داشتن فایلی با نام RTM نیست؛ بلکه وجود Traceability قابل اتکا است.
۱۷.۹. سه سؤال مهم برای Tester
از دید Tester میتوان اهمیت Traceability را در سه سؤال خلاصه کرد:
- هر Requirement چگونه تست شده است؟
- هر Test Case مربوط به کدام Requirement است؟
- اگر یک Requirement تغییر کند، کدام تستها تحت تأثیر قرار میگیرند؟
اگر بتوانیم به این سؤالها پاسخ دهیم، کنترل بهتری روی Test Coverage، Impact Analysis و مدیریت تغییرات خواهیم داشت.
در بخش بعدی، این مفاهیم را از حالت تئوری خارج میکنیم و یک Workflow عملی برای Tester از لحظه دریافت FRD تا پایان تست طراحی میکنیم.
۱۸. Workflow پیشنهادی Tester از دریافت FRD تا پایان تست 🔄
حالا میتوانیم مفاهیمی مانند FRD، Requirement Analysis، Test Scenario، Test Case و Traceability را در قالب یک فرآیند کاری کنار هم قرار دهیم.
فرض کنید Tester یک FRD جدید دریافت کرده و قرار است قابلیت مربوط به آن را تست کند. در این شرایط، بهتر است کار با نوشتن فوری Test Case شروع نشود؛ بلکه ابتدا Requirement باید درک و تحلیل شود.
مرحله ۱: درک هدف قابلیت 🎯
ابتدا باید بدانید این قابلیت چه مشکلی را برای کاربر یا کسبوکار حل میکند.
مثلاً:
«سیستم باید امکان لغو سفارش را برای کاربران فراهم کند.»
در این مرحله هنوز وارد جزئیات Test Case نمیشویم؛ هدف ایجاد یک تصویر کلی از قابلیت است.
مرحله ۲: درک جریان کلی قابلیت 🔄
حالا جریان اصلی عملکرد را بررسی کنید.
مشاهده سفارش
↓
انتخاب لغو سفارش
↓
نمایش تأییدیه
↓
تأیید لغو
↓
تغییر وضعیت سفارش
↓
نمایش نتیجه
این تصویر کلی کمک میکند نقاط مهم جریان و ارتباط بین بخشهای مختلف سیستم را بهتر درک کنید.
مرحله ۳: تحلیل Requirementها 🔍
حالا Requirementهای مرتبط با قابلیت را بررسی کنید و برای هرکدام سؤالهایی مانند این موارد مطرح کنید:
- رفتار مورد انتظار سیستم چیست؟
- چه کسی مجاز به انجام این عملیات است؟
- Precondition چیست؟
- ورودی و خروجی چیست؟
- چه محدودیتهایی وجود دارد؟
- سیستم در شرایط خطا چه رفتاری باید داشته باشد؟
- آیا قابلیت به سرویس یا بخش دیگری وابسته است؟
مرحله ۴: شناسایی ابهامها و سؤالات ❓
اگر Requirement مبهم یا ناقص است، نباید بر اساس حدس خودتان رفتار مورد انتظار را تعیین کنید.
مثلاً:
«کاربر میتواند سفارش را لغو کند.»
سؤالهای احتمالی:
- آیا سفارش ارسالشده نیز قابل لغو است؟
- آیا برای لغو سفارش محدودیت زمانی وجود دارد؟
- آیا همه کاربران اجازه لغو سفارش را دارند؟
- اگر عملیات لغو با خطا مواجه شود چه اتفاقی میافتد؟
این موارد باید برای Clarification ثبت شوند.
مرحله ۵: Requirement Review یا Refinement با تیم 👥
سؤالها و ابهامهای شناساییشده باید با افراد مرتبط بررسی شوند. بسته به ساختار پروژه، این افراد میتوانند شامل Business Analyst، Product Owner، Developer، UX/UI Designer یا سایر اعضای تیم باشند.
هدف این مرحله پیدا کردن ایراد در کار یک فرد خاص نیست؛ هدف این است که رفتار مورد انتظار سیستم قبل از پیادهسازی یا تست روشن باشد.
مرحله ۶: شناسایی Test Scenarioها 🧪
بعد از شفاف شدن Requirementها، میتوان Test Scenarioهای مهم را استخراج کرد.
Positive:
- لغو سفارش در وضعیت مجاز
Negative:
- لغو سفارش در وضعیت غیرمجاز
- تلاش کاربر غیرمجاز برای لغو سفارش
Boundary / Special Conditions:
- لغو سفارش در آخرین لحظه مجاز
- تلاش برای لغو بعد از پایان مهلت
Error:
- خطای سرویس هنگام انجام عملیات لغو
سناریوهای واقعی باید بر اساس Requirementها، Business Rules و ریسکهای همان محصول تعیین شوند.
مرحله ۷: طراحی Test Case 📝
حالا Test Scenarioها را به Test Caseهای قابل اجرا تبدیل کنید.
- Precondition
- Test Data
- Test Steps
- Expected Result
در پایان این مرحله باید بتوانید بهوضوح مشخص کنید:
چه کاری انجام میدهم و چه نتیجهای انتظار دارم؟
مرحله ۸: ایجاد Traceability 🔗
Test Caseها را به Requirement مربوط متصل کنید.
FR-012
↓
TS-001
↓
TC-001 / TC-002 / TC-003
این ارتباط در ادامه برای بررسی پوشش تست، مدیریت تغییرات و تحلیل تأثیر Requirementها بسیار مفید خواهد بود.
مرحله ۹: اجرای Test Caseها ▶️
بعد از آماده شدن Build یا Feature، Test Caseها اجرا میشوند و نتیجه هرکدام مشخص میشود:
Pass یا Fail
اگر تست Fail شود، Tester باید ابتدا مشخص کند علت واقعی چیست. برای مثال ممکن است مشکل از:
- نرمافزار
- Test Data
- Environment
- تغییر Requirement
- Dependency
باشد.
مرحله ۱۰: ثبت و پیگیری Defect 🐞
اگر مشخص شد مشکل واقعاً مربوط به نرمافزار است، باید Defect ثبت شود.
یک Defect مناسب معمولاً شامل اطلاعاتی مانند موارد زیر است:
- Title
- Preconditions
- Steps to Reproduce
- Expected Result
- Actual Result
- Severity / Priority در صورت نیاز
- Environment
- Evidence
در صورت امکان، Defect نیز باید به Test Case و Requirement مرتبط شود تا Traceability حفظ شود.
مرحله ۱۱: Retest و Regression Testing 🔁
بعد از اصلاح Defect توسط Developer، Tester باید Retest انجام دهد؛ یعنی بررسی کند آیا همان مشکل برطرف شده است یا خیر.
اما بررسی نباید همیشه به همان Defect محدود شود. بسته به نوع تغییر، باید مشخص شود آیا اصلاح انجامشده روی بخشهای دیگر سیستم نیز تأثیر گذاشته است یا خیر.
اینجاست که Regression Testing اهمیت پیدا میکند.
مرحله ۱۲: مدیریت تغییرات Requirement 🔄
Requirement ممکن است حتی بعد از شروع Development یا Test نیز تغییر کند.
مثلاً ابتدا گفته شده است:
سفارش تا ۳۰ دقیقه بعد از ثبت قابل لغو است.
سپس این مقدار به ۱۵ دقیقه تغییر میکند.
Tester باید بررسی کند:
- کدام Requirement تغییر کرده است؟
- کدام Test Scenarioها تحت تأثیر قرار گرفتهاند؟
- کدام Test Caseها باید اصلاح شوند؟
- آیا Test Case جدیدی لازم است؟
- کدام Regression Testها باید دوباره اجرا شوند؟
وجود Traceability در این مرحله باعث میشود تحلیل تأثیر تغییر بسیار سریعتر و دقیقتر انجام شود.
کل Workflow در یک نگاه 🧭
FRD دریافت میشود
↓
درک قابلیت
↓
تحلیل Requirement
↓
شناسایی ابهامها
↓
Requirement Review / Clarification
↓
Test Scenario Design
↓
Test Case Design
↓
Traceability
↓
Test Execution
↓
Defect Reporting
↓
Retest
↓
Regression Testing
↓
Test Completion
این Workflow نشان میدهد که ارتباط Tester با FRD به خواندن سند و نوشتن Test Case محدود نمیشود. Tester از مرحله درک Requirement شروع میکند، ابهامها و ریسکها را بررسی میکند، سناریوهای تست را طراحی میکند و در نهایت رفتار واقعی سیستم را در برابر رفتار مورد انتظار ارزیابی میکند.
در نتیجه، نقش Tester میتواند خیلی زودتر از مرحله اجرای تست آغاز شود؛ یعنی از زمانی که رفتار مورد انتظار محصول در حال تعریف و بررسی است.
۱۹. جمعبندی؛ FRD برای Tester دقیقاً چه اهمیتی دارد؟ 🎯
اگر بخواهیم تمام مطالب این مقاله را در یک تصویر ساده خلاصه کنیم، باید به نقطه شروع برگردیم:
قبل از اینکه نرمافزار ساخته شود، باید بدانیم قرار است چه چیزی ساخته شود.
FRD یکی از اسنادی است که میتواند رفتارهای عملکردی مورد انتظار سیستم را مستند کند؛ اما برای Tester، FRD صرفاً یک سند برای مطالعه نیست.
FRD را از زاویه Tester ببینید 🔍
وقتی یک Tester با FRD مواجه میشود، نباید فقط بپرسد:
«سیستم قرار است چه کاری انجام دهد؟»
بلکه باید سؤالهای بیشتری مطرح کند:
- آیا Requirement واضح و بدون ابهام است؟
- آیا اطلاعات موردنیاز برای درک رفتار سیستم کامل است؟
- آیا Requirement قابل تست است؟
- شرایط مثبت و منفی مشخص شدهاند؟
- Boundaryها و محدودیتها مشخص هستند؟
- رفتار سیستم در شرایط خطا مشخص است؟
- آیا Requirementها با یکدیگر تناقض ندارند؟
- آیا میتوان بر اساس آن Test Scenario و Test Case طراحی کرد؟
این نوع نگاه باعث میشود FRD از یک سند صرفاً مستنداتی به یکی از ورودیهای مهم فعالیتهای QA و Testing تبدیل شود.
مسیر FRD تا تست 🧪
در طول مقاله دیدیم که یک Requirement میتواند مسیر زیر را طی کند:
FRD
↓
Requirement Analysis
↓
Requirement Review / Clarification
↓
Test Scenario
↓
Test Case
↓
Test Execution
↓
Defect
↓
Retest & Regression
این مسیر نشان میدهد که ارتباط Tester با Requirement خیلی زودتر از مرحله اجرای تست آغاز میشود.
برای یک Tester تازهکار چه چیزی اهمیت بیشتری دارد؟ 🌱
اگر تازه وارد دنیای Software Testing شدهاید، ممکن است در ابتدا تصور کنید:
«Developer نرمافزار را میسازد و Tester آن را تست میکند.»
اما در یک تیم حرفهای، نقش Tester میتواند خیلی زودتر آغاز شود.
Tester ممکن است هنگام بررسی Requirement متوجه شود که:
- یک رفتار مشخص نشده است.
- یک Requirement مبهم است.
- یک سناریوی خطا فراموش شده است.
- دو Requirement با یکدیگر تناقض دارند.
- یک Boundary یا محدودیت تعریف نشده است.
- Requirement قابل تست نیست.
اگر چنین مشکلاتی پیش از Development شناسایی شوند، ممکن است اصلاً به Bug نرمافزاری تبدیل نشوند.
این موضوع یکی از تفاوتهای مهم میان تمرکز صرف بر Bug Finding و نگاه گستردهتر Quality Assurance است.
آیا باید FRD را حفظ کنیم؟ ❌
خیر.
هدف از یادگیری FRD این نیست که تعریف آن یا ساختار یک قالب خاص را حفظ کنید.
مهارت مهمتر این است که وقتی یک سند یا منبع Requirement در اختیار شما قرار گرفت، بتوانید:
آن را بخوانید → تحلیل کنید → سؤال بپرسید → ابهامها را پیدا کنید → سناریوهای تست را استخراج کنید → Test Case طراحی کنید.
حتی اگر در پروژه بعدی سندی با نام FRD وجود نداشته باشد، این مهارت همچنان برای شما کاربرد دارد.
ممکن است Requirementها در قالبهای مختلفی مانند موارد زیر ارائه شوند:
- User Story
- Acceptance Criteria
- Product Documentation
- Business Rules
- سایر مستندات و منابع مرتبط با محصول
بنابراین چیزی که باید یاد بگیرید تحلیل Requirement است، نه صرفاً شناخت نام یک سند.
مهمترین چیزی که باید به خاطر بسپارید 🧠
اگر بخواهیم کل مقاله را در یک جمله خلاصه کنیم:
Tester نباید منتظر بماند تا نرمافزار ساخته شود و بعد به دنبال مشکل بگردد؛ بلکه باید از همان زمانی که رفتار مورد انتظار سیستم تعریف میشود، به کیفیت و قابلیت تست آن فکر کند.
FRD یکی از نقاطی است که این نگاه میتواند از آنجا آغاز شود.
بنابراین اگر میخواهید از یک Tester صرفاً اجرایی به یک QA حرفهایتر و تحلیلگر Requirement تبدیل شوید، توانایی خواندن و تحلیل اسنادی مانند FRD میتواند مهارت ارزشمندی برای شما باشد.
مسیر ذهنی Tester هنگام تحلیل Requirement 🧩
Requirement چیست؟
↓
قرار است چه رفتاری اتفاق بیفتد؟
↓
چه شرایطی میتواند وجود داشته باشد؟
↓
چه چیزهایی ممکن است اشتباه شود؟
↓
آیا Requirement کامل، واضح و قابل تست است؟
↓
چه Test Scenarioهایی لازم داریم؟
↓
چه Test Caseهایی باید طراحی کنیم؟
↓
آیا محصول واقعاً مطابق رفتار مورد انتظار عمل میکند؟
این همان نقطهای است که Requirement Analysis و Software Testing به یکدیگر متصل میشوند.
منابع 📚
- ISO/IEC/IEEE 29148 – Requirements Engineering
- ISTQB – International Software Testing Qualifications Board
- Scrum.org – What is Scrum?
سوالات متداول درباره FRD برای Tester ❓
FRD یا Functional Requirements Document سندی برای مستندسازی نیازمندیها و رفتارهای عملکردی مورد انتظار سیستم است. این سند میتواند به Tester کمک کند بفهمد سیستم چه کاری باید انجام دهد و بر اساس آن Test Scenario و Test Case طراحی کند.
Tester باید دید کلی نسبت به FRD داشته باشد، اما لازم نیست تمام بخشهای یک سند طولانی را با یک سطح از جزئیات مطالعه کند. بهتر است ابتدا تصویر کلی قابلیت را درک کند و سپس روی Requirementها، Business Rules، ورودی و خروجیها، شرایط خطا، محدودیتها و Dependencyهای مرتبط با تست تمرکز کند.
خیر. FRD معمولاً بر نیازمندیها و رفتارهای عملکردی سیستم تمرکز دارد، در حالی که SRS میتواند دامنه گستردهتری از نیازمندیهای نرمافزار را پوشش دهد. ساختار و مرزبندی این اسناد نیز ممکن است در پروژههای مختلف متفاوت باشد.
نه همیشه. در برخی پروژههای Agile ممکن است بخش زیادی از اطلاعات موردنیاز برای تست در User Story و Acceptance Criteria قرار داشته باشد و سندی با عنوان FRD وجود نداشته باشد. اما در پروژههای دیگر FRD و Acceptance Criteria میتوانند در کنار یکدیگر استفاده شوند.
فرآیند معمول این است که Tester ابتدا Requirement را درک و تحلیل میکند، ابهامها را شناسایی و در صورت نیاز شفافسازی میکند، سپس Test Scenarioها را استخراج کرده و آنها را به Test Caseهای قابل اجرا تبدیل میکند.
FRD عمدتاً بر رفتارهای عملکردی تمرکز دارد، اما Tester برای ارزیابی کامل کیفیت محصول ممکن است به منابع دیگری مانند Non-functional Requirements نیز نیاز داشته باشد. موضوعاتی مانند Performance، Security، Usability و Compatibility ممکن است در اسناد دیگری تعریف شده باشند.
Requirement Traceability کمک میکند ارتباط بین Requirement، Test Scenario، Test Case، Test Result و در صورت نیاز Defect قابل پیگیری باشد. این ارتباط برای بررسی Test Coverage و مدیریت تأثیر تغییرات Requirement بسیار مفید است.
نبود سندی با نام FRD لزوماً به معنی نبود Requirement نیست. Tester باید منبع معتبر رفتار مورد انتظار را پیدا کند؛ این اطلاعات ممکن است در User Story، Acceptance Criteria، Product Documentation، Business Rules، Wiki یا سایر مستندات پروژه وجود داشته باشد.
مهمترین مهارت، صرفاً خواندن FRD نیست؛ بلکه تحلیل Requirement است. Tester باید بتواند ابهامها، تناقضها، شرایط مرزی، حالتهای خطا و ریسکهای مهم را شناسایی کند و Requirement را به سناریوهای قابل تست تبدیل کند.
