نیازمندی «کاربر باید شماره موبایل معتبر وارد کند» ظاهراً روشن است، اما برای تست کافی نیست. منظور از معتبر چیست؟ ارقام فارسی پذیرفته میشوند؟ شماره با +98 چطور؟ اگر شماره قبلاً ثبت شده باشد چه اتفاقی میافتد؟ چه پیامی نمایش داده میشود و چند بار میتوان کد تأیید خواست؟ هر سؤال بیپاسخ میتواند بعداً به باگ، دوبارهکاری یا اختلاف میان تیمها تبدیل شود.
تحلیل نیازمندیها در STLC نخستین مرحله تبدیل ایده کسبوکار به پوشش تست قابلاعتماد است. در این راهنما یاد میگیرید تستر چه اسنادی را بررسی کند، چه سؤالهایی بپرسد، Testability و ریسک را چگونه بسنجد و چه خروجیهایی پیش از Test Planning آماده کند.
فهرست مطالب
تحلیل نیازمندیها در STLC چیست؟
Requirement Analysis در چرخه حیات تست، فرایند بررسی نیازها، قواعد، طراحی و زمینه محصول برای شناسایی رفتار قابل تست، ابهام، تناقض، ریسک، وابستگی و نیازهای محیط/داده است. هدف این نیست که تستر فقط سند را «بخواند»؛ باید آن را به سؤال، مثال، مدل و شرایط تست تبدیل کند.
این مرحله بخشی از چرخه حیات تست نرمافزار (STLC) است و همزمان با کشف و Refinement انجام میشود. یافتهها به Product Owner، BA، Designer و Developer بازمیگردند تا پیش از کدنویسی یا در اولین فرصت تصمیم گرفته شوند.
تحلیل نیازمندی یک فعالیت تست استاتیک نیز هست: بدون اجرای نرمافزار میتوان نقصهای سند، منطق و مثال را پیدا کرد. همچنین Verification را تقویت میکند چون معیار ساخت روشنتر میشود و Validation را بهتر میکند چون تیم درباره نیاز واقعی کاربر سؤال میپرسد.
ورودیها و خروجیهای مرحله تحلیل نیازمندی
ورودیهای رایج
- Business Requirement و Product Goal؛
- User Story، Use Case و Acceptance Criteria؛
- SRS، BRD و مستند قوانین کسبوکار؛
- Wireframe، Prototype و Design System؛
- قرارداد API، مدل داده و نمودار معماری؛
- قوانین امنیت، حریم خصوصی و دسترسی؛
- لاگ، تیکت پشتیبانی و باگهای نسخه قبلی؛
- آمار استفاده و بازخورد کاربر؛
- Constraintهای فنی، زمانی و عملیاتی.
خروجیهای قابل تحویل
- فهرست ابهامها و سؤالها با مالک و وضعیت تصمیم؛
- نیازمندیها و معیارهای پذیرش اصلاحشده؛
- Test Condition و سناریوهای سطحبالا؛
- فهرست ریسک محصول و اولویت اولیه؛
- ماتریس ردیابی نیازمندی (RTM) اولیه؛
- نیاز محیط، حساب، داده، ابزار، Mock و دسترسی؛
- فرضها، محدودیتها و موارد خارج از دامنه؛
- ارزیابی Testability و Automation Feasibility؛
- ورودی روشن برای برنامهریزی تست در فاز دوم STLC.
یک نیازمندی قابل تست چه ویژگیهایی دارد؟
صفحه مرجع NIST درباره Verification نیازمندیها ویژگیهایی مانند کاملبودن، سازگاری، درستی، اولویت، ردیابیپذیری، بدون ابهامبودن، قابلفهمبودن و قابلراستیآزماییبودن را مطرح میکند. در عمل، چک زیر کمککننده است:
روشن و بدون ابهام
عبارتهایی مانند «سریع»، «مناسب»، «کاربرپسند»، «در اسرع وقت» و «شماره معتبر» باید معیار اندازهگیری یا مثال داشته باشند.
کامل
عامل، پیششرط، اقدام، داده، رفتار موفق، خطا، محدودیت و خروجی لازم مشخصاند. وابستگی به سرویس دیگر یا تصمیم کسبوکار حذف نشده است.
سازگار
با Story دیگر، طراحی، قرارداد API، Policy و اصطلاحات محصول تناقض ندارد. مثلاً یک سند مبلغ را ریال و UI آن را تومان نداند بدون تعریف تبدیل.
قابل اندازهگیری و آزمون
باید بتوان برای آن نتیجه Pass/Fail یا شواهد پذیرش تعریف کرد. «صفحه باید سریع باشد» قابل تست نیست؛ «صدک ۹۵ زمان پاسخ در بار مشخص کمتر از X باشد» قابل تست است—عدد X باید از هدف محصول بیاید.
قابل ردیابی
شناسه و منبع دارد و میتوان طراحی، کد، تست و عیب مرتبط را به آن وصل کرد. این ویژگی تحلیل اثر تغییر را سادهتر میکند.
ضروری و اولویتدار
ارزش، ریسک و اولویت آن روشن است. همه خواستهها الزام قطعی نیستند؛ بعضی فرض، محدودیت یا پیشنهادند.
امکانپذیر
از نظر فناوری، زمان، داده، قانون و عملیات قابل اجرا است. Testability نیز باید در طراحی لحاظ شود.
انواع نیازمندی که تستر باید ببیند
| نوع | مثال | پرسش تستر |
|---|---|---|
| عملکردی | کاربر میتواند سفارش را لغو کند | در چه Statusهایی؟ نتیجه مالی چیست؟ |
| غیرکارکردی | سیستم در اوج بار پاسخگو باشد | چه بار، چه Metric و چه آستانهای؟ |
| کسبوکار | تخفیف برای گروه خاص | عضویت گروه چگونه تعیین و بهروز میشود؟ |
| داده | نگهداری سوابق سفارش | چه مدت، با چه دسترسی و Masking؟ |
| رابط و یکپارچگی | ارسال وضعیت به سرویس بیرونی | Timeout، Retry، Idempotency و خطا؟ |
| عملیاتی | بازیابی پس از اختلال | RTO/RPO و Runbook چیست؟ |
| تجربه و دسترسپذیری | فرم برای همه قابل استفاده باشد | Keyboard، Screen Reader، خطا و Focus؟ |
| محلیسازی | رابط فارسی | RTL، ارقام، تقویم، تومان/ریال و Timezone؟ |
چارچوب پرسشهای تستر در Requirement Analysis
۱. کاربر و مجوز
- Actor اصلی و فرعی چه کسانیاند؟
- کاربر مهمان، ثبتنامشده، مدیر یا پشتیبان چه تفاوتی دارد؟
- اگر فرد بدون مجوز URL یا API را مستقیم فراخوانی کند چه میشود؟
- مالک داده چگونه احراز میشود؟
۲. هدف و مسیر موفق
- کاربر با انجام این قابلیت چه نتیجهای میخواهد؟
- پیششرط شروع چیست؟
- Success دقیقاً با چه وضعیت، پیام یا تغییر دادهای تعریف میشود؟
- پس از موفقیت، مرحله بعد چیست؟
۳. داده و اعتبارسنجی
- نوع، طول، فرمت، واحد، دقت و بازه هر فیلد چیست؟
- مقدار خالی، Null، تکراری و خارج از بازه چه رفتاری دارد؟
- اعداد فارسی/انگلیسی، فاصله و کاراکتر ویژه پذیرفته میشوند؟
- اعتبارسنجی در Client، Server یا هر دو انجام میشود؟
- پیام خطا به کاربر چه میگوید و داده نامعتبر ذخیره میشود؟
برای استخراج دادههای نماینده و مرزی، از تقسیمبندی همارزی و تحلیل مقدار مرزی استفاده کنید.
۴. وضعیت و چرخه عمر
- شیء از چه Stateهایی عبور میکند؟
- کدام انتقالها مجاز یا ممنوعاند؟
- لغو، برگشت، انقضا و تکرار چه اثری دارند؟
- دو اقدام همزمان چگونه مدیریت میشوند؟
اگر نتیجه به State قبلی وابسته است، مدل انتقال حالت بسازید.
۵. قواعد و ترکیب شرطها
- اگر چند شرط همزمان برقرار باشد کدام اولویت دارد؟
- استثناهای قانون چیست؟
- شرطهای «و/یا» دقیقاند؟
- قانون بر داده قدیمی چگونه اعمال میشود؟
برای قواعد چندشرطی، جدول تصمیم تناقض و ترکیب جاافتاده را آشکار میکند.
۶. خطا و بازیابی
- اگر API Timeout، پاسخ نامعتبر یا خطای ۵xx بدهد چه میشود؟
- Retry چند بار و با چه فاصلهای انجام میشود؟
- عملیات تکراری Idempotent است؟
- کاربر میتواند ادامه دهد یا باید از ابتدا شروع کند؟
- وضعیت نیمهکاره و داده ناسازگار چگونه پاکسازی میشوند؟
۷. کارایی، امنیت و عملیات
- بار هدف، زمان پاسخ و ظرفیت مورد انتظار چیست؟
- چه دادهای حساس است و کجا Mask/Encrypt میشود؟
- Log و Audit چه اطلاعاتی دارند و چه کسی دسترسی دارد؟
- Alert، Monitoring، Backup و بازیابی چگونهاند؟
- رفتار در شبکه ضعیف، Device کمقدرت یا فضای کم چیست؟
۸. رابط و تجربه فارسی
- چیدمان RTL و ترکیب متن فارسی/انگلیسی درست است؟
- تاریخ شمسی یا میلادی و Timezone چگونه نمایش/ذخیره میشوند؟
- مبلغ ریال است یا تومان و جداکننده هزارگان چیست؟
- شماره موبایل، کد ملی و کد پستی چه فرمتهایی دارند؟
- پیام خطا واضح، محترمانه و مرتبط با فیلد است؟
تکنیکهای مؤثر تحلیل نیازمندی برای تستر
Three Amigos
نماینده Product/Business، Development و Testing پیش از پیادهسازی مثالها و ابهامها را مرور میکنند. هدف جلسه بزرگ نیست؛ ایجاد درک مشترک و کشف فرضهای متفاوت است.
Example Mapping
Story را به Rule، Example، Question و Scope تقسیم کنید. مثالهای Concrete خیلی سریعتر از عبارت کلی اختلاف برداشت را نشان میدهند.
بازبینی و چکلیست
نیازمندی را مستقل بخوانید و یافته را با مکان، معیار و اثر ثبت کنید. چکلیست را از باگهای واقعی محصول تغذیه کنید؛ چکلیست عمومی بهتنهایی کافی نیست.
مدلسازی جریان و حالت
Flowchart، State Diagram، Sequence Diagram و Data Flow مسیر پنهان، Loop، انتقال نامعتبر و وابستگی سرویسها را آشکار میکنند.
جدول تصمیم و Pairwise
برای قواعد چندشرطی جدول تصمیم و برای ترکیب زیاد تنظیمات، Pairwise کمک میکند فضای تست کنترل شود.
Prototype و Review طراحی
رابط یا نمونه تعاملی، ابهام اصطلاح، ترتیب گام، پیام خطا و نیاز دسترسپذیری را پیش از کدنویسی نشان میدهد.
Risk Workshop
تیم احتمال و اثر شکست را از دید مالی، امنیت، کاربر، عملیات و اعتبار بررسی میکند. ریسک، عمق تست و اولویت داده/محیط را تعیین میکند.
تحلیل ریسک و Testability
ریسک محصول را چگونه ثبت کنیم؟
| ریسک | احتمال | اثر | نشانه/علت | پوشش پیشنهادی |
|---|---|---|---|---|
| ثبت سفارش تکراری | متوسط | زیاد | Callback و Retry | Integration، Idempotency، Concurrency |
| مبلغ اشتباه | متوسط | بحرانی | ریال/تومان و تخفیف | Unit، API، مرز و جدول تصمیم |
| از دسترفتن فرم | زیاد | متوسط | شبکه موبایل | Recovery و Exploratory |
ریسک فقط «احتمال باگ» نیست؛ اثر شکست نیز مهم است. یک مسیر کماحتمال با پیامد امنیتی یا مالی ممکن است بالاترین اولویت را بگیرد.
پرسشهای Testability
- آیا میتوان State و نتیجه را مشاهده و اندازهگیری کرد؟
- آیا داده تست را مستقل ساخت و پاک کرد؟
- آیا سرویس بیرونی Sandbox، Mock یا Contract دارد؟
- آیا Log، Trace ID و Metric برای Debug وجود دارد؟
- آیا زمان و وابستگی تصادفی قابلکنترلاند؟
- آیا Feature Flag و Rollback فراهم است؟
- آیا Selector یا Test ID پایدار برای UI داریم؟
اگر پاسخ منفی است، Testability Requirement را پیش از توسعه ثبت کنید؛ منتظر مرحله اجرا نمانید.
مثال عملی: تحلیل نیازمندی Checkout
نیازمندی اولیه: «کاربر آدرس را انتخاب میکند، روش ارسال را تعیین میکند و سفارش را پرداخت میکند.»
ابهامهای کشفشده
- اگر کالا برای شهر انتخابی قابل ارسال نباشد چه میشود؟
- هزینه ارسال پیش یا پس از تخفیف محاسبه میشود؟
- اگر موجودی در همین فاصله تمام شود چه رخ میدهد؟
- آدرس بدون کد پستی یا با ارقام فارسی پذیرفته میشود؟
- درگاه در Timeout چه Stateی به سفارش میدهد؟
- بازگشت دوباره Callback باعث نهاییسازی تکراری میشود؟
- کاربر با Refresh یا Back چه تجربهای دارد؟
- مبلغ نمایشدادهشده تومان و مبلغ درگاه ریال است؛ تبدیل کجا Verify میشود؟
معیار پذیرش اصلاحشده نمونه
- سیستم فقط روشهای ارسال قابلاستفاده برای شهر و اقلام سبد را نمایش میدهد.
- پیش از انتقال به درگاه، موجودی و مبلغ نهایی Server-side دوباره بررسی میشوند.
- هر سفارش تنها یک پرداخت موفق فعال دارد و Callback تکراری نتیجه را دوباره اعمال نمیکند.
- اگر وضعیت پرداخت نامشخص باشد، سفارش به «در انتظار تعیین وضعیت» میرود و کاربر پیام قابلفهم میبیند.
- مبالغ در UI با برچسب تومان نمایش و پیش از ارسال به درگاه با قاعده ثبتشده تبدیل میشوند.
- در خطای اعتبارسنجی آدرس، داده واردشده باقی میماند و Focus به خطای مرتبط منتقل میشود.
خروجی تست
تیم ریسک مبلغ و سفارش تکراری را بحرانی ثبت میکند، Sandbox و Callback قابلشبیهسازی میخواهد، تستهای Unit برای محاسبه، Contract برای درگاه، Integration برای State سفارش و چند E2E برای مسیر کاربر تعریف میکند. این خروجی مستقیم وارد Test Plan و طراحی تست میشود.
Requirement Traceability Matrix چیست؟
RTM ارتباط نیازمندی با ریسک، سناریو، تستکیس، نتیجه و عیب را نشان میدهد. یک قالب ساده:
| Req ID | نیازمندی | ریسک | Test Condition | سطح | وضعیت |
|---|---|---|---|---|---|
| CHK-01 | محاسبه مبلغ نهایی | بحرانی | تخفیف، ارسال، تبدیل واحد | Unit/API | طراحیشده |
| CHK-02 | Idempotent Callback | بحرانی | Callback تکراری و همزمان | Integration | نیاز به Mock |
RTM نباید سند سنگین و دستی باشد؛ حتی ارتباط شناسه Story با تست در ابزار مدیریت یا نام Test Suite میتواند ردیابی لازم را ایجاد کند. هدف، فهم پوشش و اثر تغییر است.
معیار خروج از مرحله تحلیل نیازمندی
- هدف و کاربر/Actor مشخصاند.
- معیارهای پذیرش قابلتست و مثالدارند.
- ابهام بحرانی بدون مالک و تصمیم باقی نمانده است.
- ریسکهای اصلی و اولویت آنها ثبت شدهاند.
- نیازهای عملکردی و غیرکارکردی شناسایی شدهاند.
- وابستگی، محیط، داده، دسترسی و Mock لازم روشناند.
- Test Conditionهای سطحبالا و Traceability اولیه وجود دارد.
- موارد خارج از دامنه و فرضها ثبت شدهاند.
- مانع Testability به Backlog یا معیار پذیرش اضافه شده است.
اشتباهات رایج تسترها در تحلیل نیازمندی
- منتظرماندن برای Build به جای حضور در Refinement؛
- پرسیدن سؤال بدون ثبت تصمیم و مالک؛
- تمرکز فقط بر Happy Path؛
- نادیدهگرفتن غیرکارکردی، عملیات و امنیت؛
- فرضکردن رفتار به جای شفافسازی؛
- پذیرش عباراتی مانند «سریع» و «معتبر» بدون معیار؛
- نوشتن Test Case پیش از فهم Rule و Risk؛
- استفاده از اسناد قدیمی بدون کنترل نسخه؛
- نادیدهگرفتن باگها و تیکتهای واقعی نسخه قبلی؛
- تحمیل سلیقه شخصی به جای نیاز و شواهد کاربر.
چکلیست تحلیل نیازمندی برای تستر
- هدف، Actor و ارزش کسبوکار روشن است.
- پیششرط، Trigger، مسیر موفق و خروجی مشخصاند.
- خطا، لغو، Timeout، Retry و بازیابی تعریف شدهاند.
- نوع، فرمت، واحد، مرز و Null هر داده روشن است.
- Stateها و انتقالهای مجاز/ممنوع مشخصاند.
- قواعد چندشرطی مثال و اولویت دارند.
- مجوز، حریم خصوصی، Log و Audit دیده شدهاند.
- کارایی، ظرفیت، دسترسپذیری و سازگاری معیار دارند.
- RTL، ارقام، تقویم، Timezone و تومان/ریال بررسی شدهاند.
- وابستگی، Sandbox، Mock، داده و محیط قابلتأمیناند.
- نیازمندی به تست و ریسک قابلردیابی است.
- سؤال باز مالک، موعد و وضعیت تصمیم دارد.
سوالات متداول
آیا تحلیل نیازمندی فقط وظیفه BA است؟
خیر. BA و Product نقش اصلی در تعریف نیاز دارند، اما تستر از زاویه خطا، مرز، ریسک و قابلیت تست بازخورد میدهد؛ توسعهدهنده و طراحی نیز امکانپذیری و تجربه را بررسی میکنند.
اگر مستندات کامل نباشند تستر چه کند؟
با مثال و سؤال، رفتار را با ذینفعان روشن و تصمیم را در Story، Acceptance Criteria یا Decision Log ثبت کند. نبود سند بزرگ مانع تحلیل نیست؛ نبود تصمیم قابلردیابی مانع است.
آیا همه نیازمندیها باید تست شوند؟
همه نیازمندیهای پذیرفتهشده باید وضعیت و ریسک روشن داشته باشند، اما عمق تست یکسان نیست. پوشش بر اساس احتمال و اثر شکست، الزام قانونی و اهمیت کسبوکار اولویتبندی میشود.
تفاوت Test Condition و Test Case چیست؟
Test Condition موضوع یا رفتار قابلبررسی در سطح بالاست؛ Test Case داده، پیششرط، مراحل و نتیجه مشخص برای اجرای آن شرط را تعریف میکند.
چگونه نیازمندی غیرکارکردی را قابل تست کنیم؟
Metric، بار/زمینه، آستانه، بازه زمانی و روش اندازهگیری را مشخص کنید. مثلاً «سریع» را به زمان پاسخ در بار تعریفشده و صدک مشخص تبدیل کنید؛ عدد باید از هدف محصول و ظرفیت بیاید.
جمعبندی
تحلیل نیازمندی برای تستر یعنی پیش از نوشتن Test Case، رفتار، ریسک و قابلیت مشاهده سیستم را بفهمد. سؤال خوب، مثال Concrete، مدل جریان، جدول تصمیم و RTM کمک میکنند ابهام پیش از تکثیر در طراحی و کد پیدا شود. خروجی موفق این مرحله فقط سند بیشتر نیست؛ معیار پذیرش روشن، ریسک اولویتدار و شرایط تستی است که تیم میتواند بر اساس آن برنامهریزی و تصمیمگیری کند.
