تست مبتنی بر ریسک چیست؟ RBT با ماتریس و مثال

سه ساعت تا تصمیم انتشار مانده است. تیم ۲۴۰ تست دارد، اما فقط ۹۰ تست را می‌تواند اجرا کند. آیا باید ۹۰ تست سریع‌تر را انتخاب کند؟ تست‌های همیشه‌سبز را اجرا کند تا درصد Pass بالا برود؟ یا همه تست‌ها را نصفه‌ونیمه پوشش دهد؟ تست مبتنی بر ریسک برای همین تصمیم ساخته شده است: ابتدا مشخص می‌کند کدام شکست برای چه کسی، با چه احتمالی و چه اثری مهم است؛ سپس نوع، عمق، ترتیب و شواهد تست را متناسب با آن تنظیم می‌کند.

Risk-Based Testing یا RBT یک نوع تست مانند Performance یا Security نیست. یک رویکرد مدیریتی و تحلیلی است که ریسک‌های کیفیت محصول را به Test Strategy، Test Condition، تکنیک، پوشش، ترتیب اجرا و گزارش ریسک باقی‌مانده وصل می‌کند. خروجی خوب RBT یک Heatmap رنگی نیست؛ زنجیره‌ای قابل‌ردگیری از ریسک → اقدام کاهش → تست → شواهد → تصمیم است.

تست مبتنی بر ریسک چیست؟

در RBT، شناسایی، ارزیابی، پایش و کاهش ریسک، محرک فعالیت‌های تست است. ریسک‌های با سطح بالاتر معمولاً زودتر بررسی می‌شوند و شواهد عمیق‌تر، متنوع‌تر یا طولانی‌تری می‌گیرند. هدف، «پیداکردن همه باگ‌ها» نیست؛ هدف، کاهش عدم‌قطعیت درباره مهم‌ترین شکست‌ها و رساندن ریسک باقی‌مانده به سطحی است که صاحب اختیار آگاهانه می‌پذیرد.

این تعریف با سرفصل جاری ISTQB CTFL 4.0.1 و فصل RBT در ISTQB CTAL Test Management 3.0 هم‌راستاست. استاندارد منتشرشده ISO/IEC/IEEE 29119-2:2021 نیز فرایندهای عمومی حاکمیت، مدیریت و اجرای تست را برای مدل‌های مختلف چرخه عمر تعریف می‌کند.

RBT چه تصمیم‌هایی را تغییر می‌دهد؟

• کدام Test itemها داخل Scope یا خارج از Scope باشند؛
• کدام Test level و Test type برای هر ریسک مناسب باشد؛
• کدام تکنیک و معیار Coverage استفاده شود؛
• تست چه زمانی و با چه ترتیبی شروع شود؛
• چه مهارت، استقلال، محیط و داده‌ای لازم باشد؛
• چه مقدار تلاش و تکرار به هر ناحیه اختصاص یابد؛
• چه شواهدی برای Exit و تصمیم انتشار کافی یا ناکافی باشد.

RBT با Test Prioritization چه فرقی دارد؟

اولویت‌بندی Test Case فقط یکی از خروجی‌های RBT است. یک RBT کامل پیش از اجرا آغاز می‌شود: ریسک می‌تواند معماری را وارد Review کند، تست امنیتی یا Performance جدید بسازد، نیاز به Service virtualization را آشکار کند یا طراحی Feature را تغییر دهد. اگر فقط ترتیب یک Regression suite ثابت را عوض کنیم، بخشی از RBT را اجرا کرده‌ایم، نه کل چرخه را.

این مقاله با راهنمای پیاده‌سازی چه مرزی دارد؟

این صفحه مرجع مفهومی «تست مبتنی بر ریسک چیست» و آموزش مدل تصمیم با یک مثال کامل است. برای تسهیل کارگاه، بلوغ سازمانی و استقرار گسترده‌تر، راهنمای جداگانه پیاده‌سازی تست مبتنی بر ریسک ادامه همین خوشه محتوایی است؛ بنابراین دو صفحه نباید عنوان و هدف یکسان داشته باشند.

چهار مفهوم که معمولاً با هم اشتباه می‌شوند

مفهوم	پرسش اصلی	نمونه	اثر بر تست
Product/Quality Risk	اگر محصول کیفیت موردانتظار را نداشته باشد چه آسیبی رخ می‌دهد؟	بازپرداخت دوبار ثبت و موجودی کیف پول کم شود	محرک مستقیم RBT
Project Risk	چه چیزی تحویل یا فعالیت تست را تهدید می‌کند؟	Sandbox درگاه دیر آماده شود	بر برنامه، محیط و امکان شواهد اثر دارد
Issue	چه مشکل یا مانعی اکنون واقعاً رخ داده است؟	Sandbox امروز در دسترس نیست	نیاز به اقدام فوری و بازبرنامه‌ریزی
Defect Severity	نقص مشاهده‌شده چه اثر بالقوه‌ای دارد؟	باگ دوباره‌پرداخت Critical	اولویت Triage/Fix؛ فقط بعد از کشف Defect
Test Priority	کدام تست با توجه به ریسک، وابستگی و زمان زودتر اجرا شود؟	Idempotency قبل از ظاهر Notification	ترتیب اجرا
Release Risk	با شواهد فعلی، چه عدم‌قطعیت و مواجهه‌ای باقی مانده است؟	PSP دوم تست نشده و Rollback دستی است	ورودی توصیه و تصمیم انتشار

Product Risk و Project Risk را در یک ستون نریزید

کمبود تستر، تأخیر محیط و تغییر Scope ریسک پروژه‌اند؛ خطای محاسبه مبلغ، پاسخ کند و مجوز ناقص ریسک محصول‌اند. ریسک پروژه ممکن است Residual Product Risk را بالا ببرد—مثلاً نبود محیط باعث تست‌نشدن Failover شود—اما نوع مالک، پاسخ و گزارش آن متفاوت است. مخلوط‌کردن این دو، Heatmap را شلوغ و اقدام را مبهم می‌کند.

ریسک، باگ حدس‌زده‌شده نیست

ریسک درباره یک رویداد نامطمئن و اثر نامطلوب است. «محاسبه مبلغ غلط است» اگر شواهد قطعی داریم یک Defect/Issue است؛ «به‌دلیل تبدیل ریال و تومان، ممکن است مبلغ بازپرداخت ده برابر ثبت شود و زیان مالی ایجاد کند» یک Risk statement است. با کشف باگ، رجیستر را به Defect پیوند دهید و ارزیابی را به‌روز کنید.

مدل RBT: از تحلیل ریسک تا کنترل ریسک

مدل عملی چهار فعالیت دارد که ترتیبی به نظر می‌رسند اما می‌توانند هم‌پوشانی داشته باشند:

1. Risk Identification: کشف و بیان ریسک‌های کیفیت؛
2. Risk Assessment: دسته‌بندی، سنجش Likelihood و Impact و تعیین سطح؛
3. Risk Mitigation: انتخاب تست یا اقدام دیگری برای کاهش/کنترل؛
4. Risk Monitoring: رصد شواهد، تغییرات، ریسک نوظهور و اثربخشی اقدام.

Inherent، Current و Residual Risk

• Inherent Risk: سطح ریسک پیش از درنظرگرفتن کنترل‌های مشخص؛
• Current Risk: سطح با کنترل‌های موجود در وضعیت فعلی؛
• Residual Risk: ریسکی که پس از اقدامات و با شواهد موجود باقی می‌ماند.

تیم باید در رجیستر بنویسد کدام نوع را امتیاز می‌دهد. در غیر این صورت یک نفر احتمال را قبل از Idempotency و دیگری بعد از آن می‌سنجد و اختلاف ظاهری ایجاد می‌شود. «Test Pass» به‌تنهایی Residual Risk را عددی کم نمی‌کند؛ نشان می‌دهد در دامنه، محیط، داده و Oracle مشخص شکست دیده نشده است. اصلاح طراحی، رفع Defect و کنترل عملیاتی می‌توانند سطح ریسک را تغییر دهند.

پاسخ به ریسک همیشه تست بیشتر نیست

پاسخ	معنا	نمونه در محصول پرداخت
Avoid	حذف فعالیت یا طراحی مولد ریسک	حذف عملیات خودکار پرخطر تا آماده‌شدن کنترل
Reduce/Mitigate	کاهش Likelihood یا Impact	Idempotency key، Limit و تست همزمانی
Transfer/Share	انتقال بخشی از پیامد/مسئولیت با قرارداد	SLA و جبران با ارائه‌دهنده سرویس—بدون حذف مسئولیت خود تیم
Accept	پذیرش آگاهانه در محدوده اختیار	Risk owner با دلیل، تاریخ انقضا و Contingency
Contingency	آمادگی برای وقوع	Feature flag، Reconciliation و Runbook بازگردانی

ISO ۳۱۰۰۰ فرایند مدیریت ریسک را به حاکمیت و تصمیم سازمانی وصل می‌کند؛ صفحه رسمی ISO 31000:2018—که در ۲۰۲۳ تأیید شده—بر شناسایی، تحلیل، ارزیابی، درمان، پایش و ارتباط ریسک تأکید دارد. RBT باید با سازوکار Risk management سازمان سازگار باشد، نه یک جزیره QA.

چگونه ریسک‌های کیفیت را شناسایی کنیم؟

ریسک را با ساختار Condition→Event→Impact بنویسید

با توجه به شرایط/علت/تغییر مشخص، ممکن است رویداد یا Failure رخ دهد، در نتیجه اثر معین برای کاربر، کسب‌وکار یا سیستم ایجاد شود.

نمونه ضعیف: «ریسک بازپرداخت بالاست.»
نمونه بهتر: «با توجه به Retry خودکار Callback و نبود کلید Idempotency مشترک، ممکن است یک درخواست بازپرداخت دوبار اعمال شود؛ در نتیجه موجودی فروشنده نادرست، زیان مالی و Reconciliation دستی ایجاد شود.»

از کجا ریسک پیدا کنیم؟

• هدف کسب‌وکار، Journeyهای پرتکرار و دارایی‌های حساس؛
• Acceptance Criteria، مثال‌های مبهم و نیازمندی‌های متناقض؛
• معماری، Interface، Queue، Cache، Migration و نقاط Single failure؛
• Diff، فناوری جدید، پیچیدگی، Change frequency و Ownership مبهم؛
• Incident، Escaped defect، Ticket پشتیبانی و شکایت کاربر؛
• Telemetry، Error budget، نرخ Retry، Reconciliation و داده مالی؛
• Threat model، Privacy review و الزامات قراردادی/سازمانی؛
• دانش Product، توسعه، QA، SRE، Security، Support و کاربران متأثر.

کارگاه ۴۵دقیقه‌ای شناسایی ریسک

1. ۵ دقیقه: Scope، تغییر، هدف و فرض‌های جلسه؛
2. ۸ دقیقه: نوشتن مستقل ریسک‌ها برای کاهش Anchoring؛
3. ۱۰ دقیقه: ادغام موارد هم‌ریشه و تفکیک Product/Project/Issue؛
4. ۱۰ دقیقه: تکمیل Condition، Event و Impact؛
5. ۸ دقیقه: امتیازدهی با شاهد و ثبت اختلاف؛
6. ۴ دقیقه: مالک، اقدام بعدی، Unknownها و زمان بازبینی.

Product، توسعه، QA و عملیات حداقل گروه پایه‌اند؛ برای پرداخت/داده، Security، مالی، حقوقی یا پشتیبانی را در صورت ارتباط اضافه کنید. اجماع اجباری خطرناک است: اگر دو خبره درباره Likelihood اختلاف دارند، بازه یا هر دو برآورد و علت اختلاف را ثبت کنید. اختلاف خودش یک سیگنال عدم‌قطعیت است.

دسته‌بندی با مدل کیفیت، نه چک‌لیست کور

مدل ISO/IEC 25010:2023 نه ویژگی کیفیت و زیرمشخصه‌هایشان را به‌عنوان مرجع ارزیابی محصول تعریف می‌کند. از آن برای تحریک گفتگو درباره Functional suitability، Performance efficiency، Compatibility، Interaction capability، Reliability، Security، Maintainability، Flexibility و Safety استفاده کنید؛ اما فقط موارد مرتبط با Context را وارد رجیستر کنید.

Likelihood و Impact را چگونه امتیاز دهیم؟

اول Scale را تعریف کنید، بعد امتیاز دهید

Likelihood	تعریف نمونه برای یک Release	شاهد نمونه
۱ — Rare	سناریو فقط با ترکیب بسیار نامعمول و کنترل‌های قوی ممکن است	هیچ رخداد مشابه؛ مسیر محدود و آزموده
۲ — Unlikely	ممکن اما بعید؛ پیش‌شرط‌های متعدد دارد	یک مورد تاریخی دور یا تغییر کوچک
۳ — Possible	در شرایط معمول Release قابل‌وقوع است	تغییر متوسط، مسیر مشابه سابقه Defect دارد
۴ — Likely	بدون کنترل اضافی انتظار وقوع معقول است	تغییر پرتکرار، Incident/Retryهای اخیر
۵ — Almost certain	در اکثر سناریوهای مرتبط یا به‌صورت تکراری رخ می‌دهد	Issue فعال یا شکست‌های مکرر—که شاید دیگر Risk صرف نباشد

Impact	تعریف نمونه	معیارهای بومی‌سازی
۱ — Negligible	اثر ناچیز، بازیابی فوری، بدون داده حساس	کاربر/تراکنش محدود، Workaround روشن
۲ — Minor	اختلال محدود یا اصطکاک قابل‌تحمل	پشتیبانی کم، بازیابی ساده
۳ — Major	Journey مهم مختل یا گروه معنادار متأثر	زیان/تأخیر قابل‌توجه، Workaround پرهزینه
۴ — Severe	خدمت اصلی یا داده حساس به‌شدت متأثر	دامنه زیاد، بازیابی دشوار، آسیب اعتماد
۵ — Catastrophic	پیامد مالی/ایمنی/حقوقی/داده‌ای غیرقابل‌قبول	حدها را Risk owner و سیاست سازمان تعریف کند

این جدول فقط نمونه است. حد مالی، دامنه کاربر، حساسیت داده، مدت اختلال و Recovery باید برای سازمان شما عدد یا تعریف شود. Impact را می‌توان در چند بُعد ثبت کرد و بالاترین بُعد موجه یا Policy مصوب را به‌کار برد؛ میانگین‌گیری ممکن است یک پیامد فاجعه‌بار را پنهان کند.

فرمول ۱ تا ۲۵ چه معنایی دارد؟

یک ماتریس ساده می‌تواند Risk rank = Likelihood rank × Impact rank بسازد و رتبه‌ها را مثلاً به Low/Medium/High/Critical نگاشت کند. اما اگر ۱ تا ۵ برچسب‌های کیفی/ترتیبی باشند، ۴ واقعاً «دو برابر ۲» نیست. حاصل‌ضرب ۲۰ نه ۲۰٪ احتمال است، نه ۲۰ میلیون زیان و نه اندازه علمی ریسک. NIST در یک نمونه رسمی توضیح می‌دهد که Scaleهای کیفی Interval واقعی نیستند و ترکیب آن‌ها لزوماً میانگین یا حساب سخت‌گیرانه نیست؛ نگاه کنید به نمونه Risk Assessment مبتنی بر SP ۸۰۰-۳۰.

یک قرارداد ماتریس نمونه

• ۱ تا ۴: Low؛
• ۵ تا ۹: Medium؛
• ۱۰ تا ۱۵: High؛
• ۱۶ تا ۲۵: Critical؛
• هر Impact=۵ دست‌کم Review اجباری می‌خواهد، حتی اگر Likelihood پایین باشد؛
• در امتیاز برابر، Impact، عدم‌قطعیت، تغییر جدید و نبود Recovery tie-breaker هستند.

این مرزها قانون جهانی نیستند. پیش از دیدن فهرست ریسک‌های همان Release تصویبشان کنید تا تیم پس از مشاهده نتیجه، رنگ‌ها را برای رسیدن به تصمیم مطلوب جابه‌جا نکند.

چه زمانی ارزیابی کمی معتبرتر است؟

وقتی داده کافی و قابل‌مقایسه دارید—مثلاً نرخ واقعی Failure در تعداد مشخص تراکنش و توزیع زیان معتبر—می‌توان Expected loss یا مدل احتمالاتی ساخت. فرمول P × Loss با داده آماری با حاصل‌ضرب رتبه‌های ۱ تا ۵ یکسان نیست. عدم‌قطعیت، بازه و فرض‌ها را گزارش کنید؛ دقت اعشاری نباید جای داده ضعیف را بگیرد.

برای ریسک امنیتی، چارچوب OWASP Risk Rating Methodology عوامل Threat actor، Vulnerability، Technical impact و Business impact را باز می‌کند و خودش بر بومی‌سازی مدل تأکید دارد. آن را بی‌تغییر به همه ریسک‌های کیفیت تعمیم ندهید.

مثال کامل Risk Register: بازپرداخت فروشگاه ایرانی

Release شامل بازپرداخت کیف پول، Callback درگاه، Notification و گزارش مالی است. امتیازها Current Risk و مبتنی بر Scale نمونه بالا هستند.

ID / Risk statement خلاصه	L	I	Rank	سطح	مالک	اقدام/شاهد اصلی
R-۰۱: Retry Callback بدون Idempotency باعث بازپرداخت دوباره و زیان مالی شود	۴	۵	۲۰	Critical	Payments	Design review، تست همزمانی/Retry، Reconciliation
R-۰۲: تبدیل تومان/ریال یا Rounding مبلغ بازپرداخت را نادرست کند	۳	۵	۱۵	High	Finance/Product	Decision table، BVA، Property و Oracle مستقل
R-۰۳: Agent پشتیبانی برای سفارش خارج از Scope بازپرداخت بزند	۲	۵	۱۰	High	IAM/Product	Role×Action×Owner، API negative، Audit log
R-۰۴: قطع SMS وضعیت موفق را به کاربر نرساند و تماس پشتیبانی بالا رود	۴	۲	۸	Medium	Notification	Fallback UI، Queue retry، تست Failure dependency
R-۰۵: رقم فارسی/نیم‌فاصله جست‌وجوی تراکنش را خراب کند	۳	۲	۶	Medium	Merchant UI	Unicode partitions و Browser/RTL matrix
R-۰۶: Event تحلیلی صفحه موفق ارسال نشود	۲	۱	۲	Low	Growth	Contract/event check و مانیتورینگ

فیلدهای حداقل Risk Register

• ID پایدار، عنوان و Risk statement کامل؛
• Product/Project/Issue، Test item و Quality characteristic؛
• Inherent یا Current بودن امتیاز، Likelihood، Impact، Level و دلیل؛
• شواهد، فرض‌ها، Unknownها و تاریخ ارزیابی؛
• Risk owner و Action owner—این دو ممکن است متفاوت باشند؛
• Response، Test conditions، کنترل‌های غیرتستی و Contingency؛
• Defect/Test/Requirement/Telemetry links؛
• وضعیت، Target residual risk، Review date و Acceptance authority.

Risk owner چه کسی است؟

QA تسهیل‌گر تحلیل و مالک شواهد تست می‌تواند باشد، اما نباید به‌تنهایی Impact مالی یا پذیرش ریسک کسب‌وکار را امضا کند. Risk owner کسی است که اختیار و پاسخ‌گویی برای Treatment/Acceptance دارد؛ Action owner فعالیت مشخص را انجام می‌دهد؛ Release authority تصمیم نهایی را با توجه به چند ریسک و محدودیت می‌گیرد.

چگونه Risk را به Test Strategy نگاشت کنیم؟

پس از امتیازدهی، برای هر ریسک یک یا چند Test condition تعریف کنید. سپس Test level، Test type، تکنیک، Coverage، Oracle، داده، محیط و زمان را انتخاب کنید. این تصمیم‌ها در Test Plan و برنامه‌ریزی تست ثبت می‌شوند؛ خود رجیستر جای Test Plan نیست.

ریسک	زودترین اقدام	تکنیک/نوع تست	Coverage/Oracle نمونه	محیط/داده
R-۰۱ دوباره‌پرداخت	Review طراحی Idempotency و State model	State transition، Integration، Concurrency، Fault injection	هر Event order/Retry کلیدی؛ Ledger مستقل و Side-effect count	Queue/DB واقعی کنترل‌شده، PSP stub با Retry
R-۰۲ مبلغ غلط	مثال‌سازی Rule مالی	Decision table، BVA، Property-based	Currency/fee/tax/refund rules؛ جمع مستقل حسابداری	ریال/تومان، حدها، رقم فارسی، مبلغ بزرگ
R-۰۳ مجوز	Role/action workshop و Threat review	API authorization، Negative، Audit	هر Role×Action×Resource owner؛ deny-by-default	Tenant و نقش ایزوله، Log قابل‌همبستگی
R-04 SMS	تعریف UX بدون SMS	Dependency failure، Queue retry، Recovery	State در UI منبع حقیقت؛ no duplicate message	Stub timeout/error، Clock کنترل‌شده
R-05 Unicode	تعریف Normalization	Equivalence partition، Compatibility، Exploratory	فارسی/عربی/لاتین/نیم‌فاصله/RTL	DB collation و Browserهای پشتیبانی‌شده

اهرم‌های «شدت تست»

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

• شروع زودتر با Review، مثال و Static analysis؛
• استفاده از Test levelها و Test typeهای مکمل؛
• تکنیک نظام‌مندتر و معیار Coverage قوی‌تر؛
• تستر باتجربه‌تر یا استقلال بیشتر؛
• داده متنوع‌تر، حجم/توالی/همزمانی بیشتر؛
• محیط با Fidelity بالاتر و Dependency failure واقعی‌تر؛
• تکرار، Duration، Platform matrix یا Automation frequency بیشتر؛
• Review تست، Evidence سخت‌گیرانه‌تر و Regression گسترده‌تر.

«دو برابر Risk score = دو برابر Test case» رابطه معتبری نیست. گاهی یک تغییر طراحی یا یک Oracle مستقل بیشتر از صد تست مشابه ریسک را کاهش می‌دهد. برای تبدیل Scope به Effort/Duration از راهنمای تخمین تست نرم‌افزار استفاده کنید و عدم‌قطعیت را جدا نگه دارید.

Depth-first یا Breadth-first؟

• Depth-first: ابتدا شواهد عمیق برای Criticalها؛ مناسب وقتی یک Failure حیاتی می‌تواند Release را فوراً متوقف کند.
• Breadth-first: ابتدا حداقل یک تست/Probe برای همه Risk itemها؛ مناسب وقتی تیم به نمای کلی زودهنگام نیاز دارد.
• ترکیبی: Smoke پهناگرا برای آشکارکردن Blockerهای عمومی، سپس عمق روی Critical/High و دوباره یک دور پوشش باقی‌مانده.

تست اکتشافی برای Unknown unknownها و تغییرات پرابهام ارزشمند است. Charter را به ریسک، ناحیه، زمان و Evidence وصل کنید؛ راهنمای تست اکتشافی ساختاریافته قالب Session و گزارش را توضیح می‌دهد.

اجرای ریسک‌محور، پایش و کنترل

Test caseها چگونه اولویت می‌گیرند؟

Risk level تنها عامل نیست. ترتیب عملی باید این عوامل را هم ببیند:

• ریسک‌های پوشش‌داده‌شده و قدرت Test condition؛
• وابستگی و توان آشکارکردن Blocker محیط/Build؛
• زمان اجرا و Time-to-information؛
• تازگی تغییر و سابقه Failure/Flaky؛
• نیاز به Setup داده یا Window سرویس ثالث؛
• توان تست در پوشش هم‌زمان چند ریسک؛
• قابلیت تشخیص علت با Evidence موجود.

در شروع Cycle، Baseline شامل Risk register version، Test scope، Build، Environment، Data، Oracle و Coverage target را ثابت کنید. تغییر Risk level یا اضافه‌شدن ریسک مجاز است، اما تاریخچه را بازنویسی نکنید. مدیریت Run، Attempt و Closure در راهنمای چرخه اجرای تست آمده است.

وضعیت ریسک را از نتیجه تست جدا کنید

Test result	برداشت مجاز درباره ریسک	برداشت غیرمجاز
Passed	در دامنه و شرایط مشخص، Failure مشاهده نشد	ریسک صفر یا Feature قطعاً سالم است
Failed	شاهدی علیه انتظار داریم؛ نیاز به Triage	حتماً Product defect است
Blocked	شاهد موردنیاز تولید نشده؛ Unknown باقی است	چون اجرا نشد، ریسک پایین است
Inconclusive	Oracle/Evidence برای داوری کافی نیست	معادل Passed یا Failed
Not run	عدم‌قطعیت برنامه‌ریزی‌شده یا ناخواسته باقی است	قابل حذف از گزارش Release است
Flaky/Quarantined	سیگنال غیرقابل‌اعتماد و احتمالاً ریسک در Test system	با Rerun سبز، شواهد کامل است

چه زمانی Risk register به‌روز شود؟

• تغییر نیازمندی، معماری، Dependency، داده یا Deployment؛
• یافتن Defect شدید یا الگوی چند Defect هم‌ریشه؛
• Blocked شدن تست مهم یا کاهش Fidelity محیط؛
• تغییر حجم/گروه کاربر/Exposure Feature؛
• Incident، Telemetry غیرعادی یا بازخورد پشتیبانی؛
• اضافه‌شدن کنترل، Fix یا Contingency معتبر؛
• پیش از Release decision و پس از Production learning.

پوشش ریسک و متریک‌های RBT

یک درصد کلی نسازید مگر تعریفش روشن باشد

اگر Risk scoreها رتبه ترتیبی‌اند، جمع‌کردن آن‌ها و ساخت «۸۷٪ Risk coverage» ظاهری دقیق اما گمراه‌کننده می‌سازد. گزارش بهتر، به تفکیک سطح است:

• Critical: ۳ از ۳ Risk item دارای Evidence کامل؛ ۰ Defect باز؛
• High: ۴ از ۵ دارای Evidence کامل؛ ۱ مورد Blocked؛
• Medium: ۶ از ۹ بررسی‌شده؛ ۳ مورد Not run با دلیل؛
• Low: Smoke برای ۷ از ۱۲؛ بقیه خارج از Timebox؛

اگر Coverage درصدی لازم است، Definition را ثبت کنید؛ مثلاً «تعداد Risk itemهای درون Scope که همه Test conditionهای اجباری‌شان نتیجه قابل‌داوری دارد ÷ کل Risk itemهای همان سطح». Passed/Failed هر دو می‌توانند Evidence باشند؛ Blocked/Inconclusive/Not-run شواهد کامل نیستند. این درصد درباره کیفیت محصول نیست، درباره تکمیل شواهد تعریف‌شده است.

متریک‌های سالم

• درصد Critical/Highهای دارای Risk statement، مالک و Evidence link؛
• زمان تا اولین Evidence برای ریسک‌های Critical؛
• Defectهای High/Critical یافته‌شده در یک‌سوم اول اجرا؛
• تعداد ریسک‌های جدید کشف‌شده در Review/Test/Production؛
• Risk itemهای Blocked یا Unknown و سن آن‌ها؛
• ریسک‌های پذیرفته‌شده بدون مالک/انقضا؛
• Escaped incident به تفکیک «ریسک شناخته‌شده اما ناکافی» و «ریسک ازدست‌رفته»؛
• آیا تست‌های حذف‌شده واقعاً سطح پایین‌تری از تست‌های اجراشده داشتند؟

برای تعریف Denominator، Baseline و پرهیز از KPIهای قابل‌بازی، راهنمای متریک‌های تست نرم‌افزار را کنار RBT به‌کار ببرید.

گزارش Residual Risk و تصمیم انتشار

QA شواهد و توصیه می‌دهد؛ صاحب اختیار کسب‌وکار/محصول تصمیم می‌گیرد. گزارش Release باید هم ریسک شناخته‌شده و هم نبود شواهد را نشان دهد. «۹۶٪ تست‌ها Pass شد» بدون اینکه چهار درصد باقی‌مانده چه ریسکی پوشش می‌دادند، اطلاعات تصمیم نیست.

قالب Residual Risk Memo

Decision scope: Release/Build/Feature/Traffic و زمان
Baseline: نسخه Risk register، Test plan، Environment و Data
Critical/High evidence: پوشش به تفکیک Risk ID، نتیجه و محدودیت
Open defects: اثر، Workaround، Owner و SLA
Unknowns: Blocked/Not-run/Inconclusive، علت و Exposure
Changed risk: امتیاز قبلی/فعلی و شاهد تغییر
Controls/Contingency: Flag، Limit، Monitor، Reconciliation، Rollback
Recommendation: Go / Conditional Go / No-Go / Extend evidence
Acceptance: Decision owner، دلیل، زمان و Review/expiry

مثال توصیه مشروط

R-۰۱ و R-۰۲ با تست‌های طراحی‌شده Pass و Reconciliation مستقل تأیید شده‌اند. R-۰۳ یک Defect مجوز High باز دارد؛ بنابراین انتشار عمومی توصیه نمی‌شود. گزینه مشروط: Feature برای نقش پشتیبانی غیرفعال، فقط Refund خودکار با سقف محدود فعال، Alert و Reconciliation ساعتی برقرار و Fix تا ۲۴ ساعت. تصمیم و پذیرش این Residual Risk باید با Product/Finance owner باشد.

قالب‌های Status، Completion و Release Readiness و مرز «توصیه» با «تصمیم» در راهنمای گزارش تست تصمیم‌محور توضیح داده شده‌اند.

RBT در Agile، Scrum و CI/CD

RBT یک کارگاه یک‌باره ابتدای پروژه نیست

در توسعه تکرارشونده، Risk analysis سبک می‌تواند در Discovery/Refinement برای Storyهای مهم، هنگام طراحی، در Planning و پس از تغییر معنی‌دار انجام شود. لازم نیست برای هر Story جلسه سنگین بسازید. یک Risk note سه‌خطی برای تغییر کوچک و یک Workshop رسمی برای تغییر پرداخت، مهاجرت یا مجوز، هر دو RBT هستند اگر تصمیم تست را واقعاً تغییر دهند.

Change-based risk در Pull Request

Pipeline می‌تواند سیگنال‌هایی مانند Component حیاتی، تغییر Schema، مجوز، Money type، Dependency، Migration یا Failure history را به Test selection بدهد. اما مدل خودکار باید قابل‌توضیح باشد و راه Override ممیزی‌پذیر داشته باشد. «فایل تغییر نکرده» مساوی «ریسک ندارد» نیست؛ تغییر Contract یا Configuration می‌تواند مصرف‌کننده دیگری را بشکند.

یک چرخه بازخورد نمونه

1. Pre-commit: Unit/Static برای Ruleهای سریع مرتبط؛
2. PR: تست‌های Changed-component و Critical contracts؛
3. Merge: Breadth-first smoke و Integration کلیدی؛
4. Nightly: Depth، ترکیبات داده، Performance و Failure paths؛
5. Pre-release: Residual risk review و شواهد محیط هدف؛
6. Production: Monitor، Canary و Incident learning برای به‌روزرسانی Risk register.

این لایه‌بندی در مراحل مختلف چرخه حیات تست نرم‌افزار (STLC) قابل‌انطباق است؛ RBT وابسته به Waterfall یا Agile خاصی نیست.

تکنیک‌های سبک و سنگین RBT

رویکرد	ویژگی	مناسب برای	محدودیت
Lightweight workshop + matrix	Likelihood/Impact کیفی، Stakeholder محدود، Registry کوچک	محصول وب/موبایل غیر Safety-critical، Iteration کوتاه	سوگیری و دقت محدود؛ نیازمند تعریف Scale
PRAM/PRISMA/SST	روش‌های ساختاریافته سبک با ورودی نیازمندی/ذی‌نفع	تیم‌هایی که Traceability و فرایند تکرارپذیرتر می‌خواهند	باید با Context و نسخه منبع تطبیق شود
FMEA/FMECA	Failure mode، علت، اثر و گاهی Detection/Criticality	Component/Process با Failure modeهای مشخص	RPN می‌تواند رتبه‌های متفاوت را هم‌عدد کند
Fault Tree Analysis	Top event و ترکیب علل منطقی	Failure بحرانی با وابستگی علّی پیچیده	ساخت و نگهداری تخصصی
Hazard analysis	تمرکز بر Hazard، Safety و کنترل	سامانه‌های Safety-critical و regulated	نیازمند استاندارد دامنه و متخصص
Cost of exposure	Likelihood، زیان و هزینه Test/control	وقتی داده مالی/آماری معتبر موجود است	با رتبه‌های حدسی نباید Quantitative نامیده شود

رنگی‌بودن ماتریس به معنای Lightweight و فرمول‌داشتن به معنای علمی‌بودن نیست. Formality، دامنه Stakeholder، کیفیت داده، Traceability، مقررات و پیامد شکست روش مناسب را تعیین می‌کنند.

خطاها و سوگیری‌های رایج

همه‌چیز High است

Scale تعریف نشده یا Stakeholder می‌خواهد حوزه خودش را محافظت کند. Impact boundary، Evidence و تعداد محدود Critical را تعریف کنید؛ اما سقف مصنوعی «فقط پنج ریسک High» هم نسازید. اگر همه واقعاً High هستند، شاید Scope Release بیش از ظرفیت کنترل است.

Unknown به Low تبدیل می‌شود

نبود Incident یا داده، شاهد احتمال پایین نیست. برای Component جدید، تیم بی‌تجربه یا Telemetry ناقص، Confidence/Uncertainty را جدا ثبت و Discovery test یا Spike برنامه‌ریزی کنید.

Highest-paid-person’s opinion

امتیازدهی آشکار گروهی باعث Anchoring می‌شود. ابتدا مستقل رأی دهید، سپس اختلاف را با داده و فرض بررسی کنید. Minority concern را حذف نکنید؛ ممکن است نماینده گروه کاربری کم‌صدا باشد.

Availability و Recency bias

آخرین Incident همه امتیازها را می‌بلعد. داده چند Release، Support، Change map و Risk taxonomy را کنار تجربه تازه بگذارید. در عین حال Incident جدید را صرفاً به نام «سوگیری» نادیده نگیرید.

Rare but catastrophic در ماتریس گم می‌شود

یک Likelihood پایین و Impact فاجعه‌بار ممکن است Score متوسط بگیرد. Policy جدا برای Safety، داده حساس، زیان بزرگ یا الزام قراردادی داشته باشید؛ Impact=۵ می‌تواند Review/Gate خاص ایجاد کند.

Low riskها برای همیشه تست نمی‌شوند

Breadth-first smoke، نمونه‌برداری چرخشی و Exploratory timebox مانع ناحیه کور می‌شوند. Low امروز می‌تواند با Usage، Dependency یا تغییر معماری فردا High شود.

Pass rate به‌جای Residual risk

صد تست کم‌ارزش سبز می‌تواند یک تست Critical اجرا‌نشده را پنهان کند. گزارش را بر Risk ID و Evidence اجباری بنا کنید، نه تعداد خام Case.

ملاحظات RBT برای تیم‌های ایرانی

ریال، تومان، تقویم و Unicode

Risk statementهای مالی باید واحد پول، قواعد Rounding، سقف، Timezone، تقویم و نمایش را صریح کنند. رقم فارسی/عربی، نیم‌فاصله، نام‌های طولانی و راست‌به‌چپ فقط «حالت لبه UI» نیستند؛ بسته به Journey می‌توانند Impact مالی، دسترس‌پذیری یا پشتیبانی داشته باشند.

درگاه، پیامک و سرویس ثالث

احتمال Failure را فقط از SLA فروشنده تخمین نزنید. Timeout، پاسخ دیرهنگام، Callback تکراری/خارج از ترتیب، قطعی شبکه، Rate limit و تفاوت Sandbox/واقعی را در Scenario بیاورید. Transfer قراردادی، ریسک تجربه کاربر و Reconciliation خود شما را صفر نمی‌کند.

دسترسی ابزار و زیرساخت

محدودیت IP، تحریم، پرداخت License، قطع Registry یا نبود Device/Cloud باید به‌عنوان Project risk ثبت شود؛ سپس اثرش بر Product evidence روشن گردد. گزینه Self-hosted، Cache Artifact، Runner داخلی و مسیر جایگزین را پیش از Release حیاتی آزمایش کنید.

قانون و قرارداد

QA نباید از روی یک مقاله ادعای Compliance بدهد. الزام دقیق را از حقوقی/امنیت/قرارداد و نسخه معتبر منبع بگیرد، آن را به Control و Testable evidence نگاشت کند و Residual risk را به صاحب اختیار گزارش دهد.

برنامه ۳۰روزه شروع RBT

هفته اول: قرارداد واژگان و Scale

• Product/Project/Issue/Defect/Residual را تعریف کنید.
• Likelihood و Impact را با مثال‌های محصول خودتان کالیبره کنید.
• Risk statement و Registry حداقلی را تصویب کنید.

هفته دوم: Pilot روی یک Journey

• یک Journey مهم مثل بازپرداخت انتخاب کنید.
• کارگاه ۴۵دقیقه‌ای با چهار تا هفت Stakeholder برگزار کنید.
• ۵ تا ۱۲ ریسک را به Test condition و Evidence نگاشت کنید.

هفته سوم: اجرا و Residual report

• Depth/Breadth strategy و Baseline Cycle را ثبت کنید.
• نتایج را بر Risk ID گزارش و Unknownها را برجسته کنید.
• یک Release memo با Recommendation و Acceptance owner بسازید.

هفته چهارم: Retrospective و Scale

• ریسک‌های ازدست‌رفته، False alarm و کیفیت Scale را مرور کنید.
• بررسی کنید آیا Defectهای پرریسک زودتر پیدا شدند و Skipها واقعاً کم‌ریسک‌تر بودند.
• Template را سبک‌تر کنید و فقط به Journey بعدی گسترش دهید.

چک‌لیست نهایی تست مبتنی بر ریسک

• Scope، هدف و Decision horizon مشخص است.
• Product risk از Project risk و Issue جدا شده است.
• هر ریسک Condition، Event و Impact قابل‌فهم دارد.
• Stakeholderهای فنی، کسب‌وکاری و متأثر نمایندگی شده‌اند.
• Likelihood/Impact Scale تعریف و شاهد امتیاز ثبت شده است.
• معلوم است امتیاز Inherent، Current یا Residual است.
• رتبه‌های ۱ تا ۵ به‌عنوان داده دقیق آماری تفسیر نشده‌اند.
• هر Critical/High مالک، Treatment، Test condition و Evidence دارد.
• Test level/type/technique/coverage/oracle متناسب انتخاب شده است.
• Blocked، Not-run، Inconclusive و Flaky به‌عنوان Unknown گزارش می‌شوند.
• Risk register با تغییر، Defect و Production learning به‌روز می‌شود.
• Residual risk، Contingency و Acceptance authority در Release memo آمده‌اند.

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

تست مبتنی بر ریسک یا RBT دقیقاً چیست؟

رویکردی است که شناسایی، ارزیابی، پایش و کاهش ریسک‌های کیفیت محصول را محرک Scope، نوع، تکنیک، عمق، ترتیب و گزارش تست قرار می‌دهد. RBT یک Test type مستقل نیست و می‌تواند تست کارکردی، امنیت، Performance، Review، Static analysis و Exploratory را متناسب با ریسک ترکیب کند.

آیا Risk score همیشه از ضرب احتمال در اثر به دست می‌آید؟

نه به یک معنا. با داده آماری معتبر می‌توان محاسبه کمی ساخت؛ اما Scaleهای رایج ۱ تا ۵ معمولاً رتبه‌های کیفی‌اند. حاصل‌ضرب آن‌ها فقط Rank نیمه‌کمی در قرارداد همان ماتریس است و نباید احتمال واقعی، زیان یا فاصله علمی تلقی شود. Definition، Evidence و عدم‌قطعیت از خود عدد مهم‌ترند.

تفاوت Product Risk و Project Risk چیست؟

Product risk به کیفیت محصول و پیامد Failure مربوط است؛ مانند مبلغ غلط، مجوز ناقص یا پاسخ کند. Project risk توان تحویل یا تست را تهدید می‌کند؛ مانند تأخیر محیط، کمبود مهارت یا Dependency فروشنده. RBT مستقیماً روی Product/Quality risk تمرکز دارد، اما Project risk باید جدا مدیریت شود چون می‌تواند شواهد و ریسک باقی‌مانده را تغییر دهد.

آیا با Pass شدن تست، ریسک صفر می‌شود؟

خیر. Pass فقط می‌گوید در دامنه، داده، محیط و Oracle مشخص Failure مشاهده نشده است. مسیرهای تست‌نشده، محدودیت مدل، منفی کاذب و تغییر Production باقی می‌مانند. Residual risk با ترکیب Evidence، کنترل‌ها، Defectهای باز، Unknownها و Exposure ارزیابی و توسط صاحب اختیار پذیرفته یا رد می‌شود.

در زمان خیلی کم، Depth-first بهتر است یا Breadth-first؟

اگر یک Failure حیاتی به‌تنهایی Release را متوقف می‌کند، ابتدا Depth-first روی آن منطقی است. اگر تیم باید سریع سلامت کلی Build و همه Risk areaها را ببیند، Breadth-first مناسب‌تر است. معمولاً ترکیب Smoke پهناگرا، عمق روی Critical/High و سپس نمونه‌برداری از باقی نواحی بهترین Information flow را می‌دهد.

جمع‌بندی: RBT یعنی مدیریت شواهد، نه رنگ‌آمیزی ریسک

تست مبتنی بر ریسک وقتی ارزش دارد که تصمیم را تغییر دهد. Risk statement روشن، Scale تعریف‌شده، Stakeholder متنوع، نگاشت به Test condition، Evidence قابل‌ردگیری و گزارش Residual risk اجزای ضروری‌اند. ماتریس یک ابزار گفتگوست، نه ماشین حقیقت؛ درصد Pass یک نتیجه اجرایی است، نه میزان ایمنی؛ و QA مالک همه ریسک‌های کسب‌وکار نیست، بلکه سازنده و مترجم شواهد تصمیم است.