تست مبتنی بر زمینه چیست؟ مقایسه با استانداردها

یک تیم می‌گوید «استاندارد مشخص کرده چه تستی انجام دهیم» و تیم دیگر پاسخ می‌دهد «ما Context-Driven هستیم؛ پس Test Plan و مستندات لازم نیست». هر دو جمله بخشی از مسئله را حذف می‌کنند. استاندارد بدون شناخت ریسک نمی‌گوید کدام Failure برای این محصول مهم‌تر است؛ زمینه‌گرایی بدون Evidence نیز می‌تواند به تصمیم سلیقه‌ای و غیرقابل‌دفاع تبدیل شود.

تست مبتنی بر زمینه یا Context-Driven Testing از نیاز پروژه، ذی‌نفعان، ریسک و محدودیت واقعی شروع می‌کند. استانداردها می‌توانند زبان مشترک، فرایند، قالب Evidence یا الزام قراردادی بدهند. انتخاب حرفه‌ای معمولاً «یکی از این دو» نیست؛ ترکیب سه لایه است: تعهدهای غیرقابل‌چشم‌پوشی، کنترل‌های مشترک و راهبرد تست Tailorشده برای زمینه.

پاسخ کوتاه: از استاندارد به‌عنوان ورودی و Guardrail استفاده کنید، نه جایگزین قضاوت. از Context برای انتخاب هدف، عمق، تکنیک و Evidence استفاده کنید، نه بهانه‌ای برای حذف انضباط.

تست مبتنی بر زمینه (Context-Driven Testing) چیست؟

Context-Driven Testing یک تکنیک یا مدل چرخه عمر نیست؛ یک رویکرد به انتخاب و ارزیابی Practiceهاست. صفحه اصلی اصول Context-Driven Testing هفت اصل را مطرح می‌کند: ارزش Practice به زمینه وابسته است؛ Best Practice جهان‌شمول وجود ندارد؛ افراد و همکاری مهم‌اند؛ پروژه تغییر می‌کند؛ محصول باید مسئله واقعی را حل کند؛ تست کار فکری دشوار است؛ و قضاوت و مهارت در طول پروژه برای انتخاب کار مناسب لازم‌اند.

طبق توضیح تاریخچه همان منبع، این School در ۲۰۰۱ معرفی شد و بنیان‌گذاران بعداً دیدگاه‌های متفاوتی پیدا کردند؛ نویسنده صفحه ترجیح می‌دهد امروز از «رویکرد Context-Driven» سخن بگوید. پس با یک استاندارد رسمی یا Methodology دارای مراحل اجباری روبه‌رو نیستیم.

Context دقیقاً شامل چه چیزهایی است؟

زمینه فقط Agile بودن یا اندازه تیم نیست. حداقل این ابعاد باید دیده شوند:

• Mission تست و تصمیمی که باید پشتیبانی شود؛
• کاربران مستقیم، افراد متأثر و انتظار ذی‌نفعان؛
• مسئله کسب‌وکار و Journeyهای حیاتی؛
• معماری، Interfaceها و Failure Modeها؛
• کیفیت‌های مهم مانند امنیت، کارایی، قابلیت اطمینان و تعامل؛
• ریسک، اثر، برگشت‌پذیری و Exposure؛
• چرخه عمر، سرعت تغییر و Release Model؛
• Testability، Observability و امکان کنترل State؛
• داده، محیط، دستگاه، شبکه و وابستگی بیرونی؛
• مهارت، ظرفیت، استقلال و پراکندگی تیم؛
• قانون، قرارداد، استاندارد، سیاست و Retention قابل‌اعمال؛
• مخاطب Evidence، زمان تصمیم، بودجه و هزینه تأخیر.

شناخت این عوامل باید به انتخاب قابل‌ردیابی منجر شود. جمله «به Context بستگی دارد» بدون اینکه بگوییم کدام Context و چگونه بر تصمیم اثر گذاشت، پاسخ نیست.

تست مبتنی بر زمینه با تست اکتشافی یکی نیست

تست اکتشافی روشی است که یادگیری، طراحی و اجرا را در یک حلقه بازخورد نزدیک ترکیب می‌کند. CDT می‌تواند از آن استفاده کند، اما می‌تواند تست اسکریپت‌شده، تحلیل ایستا، اتوماسیون، مدل‌سازی رسمی یا ارزیابی مستقل هم انتخاب کند. در یک Context ایمنی‌حیاتی، مستندات گسترده و اجرای دقیق ممکن است کاملاً Context-Driven باشند. راهنمای تست اکتشافی ساختاریافته مرز Technique و رویکرد را روشن‌تر می‌کند.

«رویکرد استاندارد تست» یک چیز واحد نیست

اصطلاح Standard Approach معمولاً چند مفهوم متفاوت را مخلوط می‌کند:

1. استاندارد فرایند: چه فعالیت‌ها و Outcomeهایی برای اداره و اجرای تست لازم‌اند؛
2. استاندارد مستندات: چه Information Itemهایی می‌توانند Evidence را ساختار دهند؛
3. مدل کیفیت: چه ویژگی‌هایی برای تعریف و ارزیابی کیفیت مطرح‌اند؛
4. استاندارد حوزه یا مقررات: کنترل و Evidence اجباری برای یک صنعت یا قرارداد؛
5. روش داخلی: Definition of Done، Severity، CI Gate و Runbook سازمان؛
6. Body of Knowledge و گواهینامه: زبان و سرفصل یادگیری، نه Strategy آماده محصول.

این‌ها ممکن است با Waterfall، Agile، DevOps، اجرای دستی یا خودکار ترکیب شوند. قراردادن همه در ستون «سنتی و خشک» یک Straw Man می‌سازد و مانع Tailoring دقیق می‌شود.

ISO/IEC/IEEE ۲۹۱۱۹-۲ چه می‌گوید؟

ISO/IEC/IEEE 29119-2:2021 فرایندهای عمومی برای راهبری، مدیریت و اجرای تست تعریف می‌کند و دامنه آن را همه مدل‌های چرخه عمر نرم‌افزار می‌داند. یعنی خود Standard، معادل Waterfall یا طرح ثابت یک‌باره نیست.

ISO/IEC/IEEE ۲۹۱۱۹-۳ چه نقشی دارد؟

ISO/IEC/IEEE 29119-3:2021 قالب‌های مستندات خروجی فرایندهای Part ۲ را ارائه می‌کند و برای سازمان، پروژه یا فعالیت تست و همه مدل‌های چرخه عمر قابل‌استفاده است. قالب، الزام به Word سنگین نیست؛ Artifact می‌تواند در ابزار، کد، داشبورد یا مخزن Evidence باشد، اگر اطلاعات لازم، مالکیت و Retention را تأمین کند.

چرا IEEE ۸۲۹ مرجع جاری نیست؟

متن قدیمی این مقاله IEEE ۸۲۹ را نمونه جاری Documentation معرفی می‌کرد. صفحه رسمی IEEE 829-2008 وضعیت آن را Superseded اعلام می‌کند و خانواده ISO/IEC/IEEE ۲۹۱۱۹ را جانشین می‌داند. اگر قرارداد Legacy صریحاً ۸۲۹ را خواسته، همان تعهد را ثبت کنید؛ اما Policy جدید را بدون دلیل بر استاندارد کنارگذاشته‌شده بنا نکنید.

ISTQB استاندارد فرایند پروژه نیست

سرفصل ISTQB CTFL ۴.۰.۱ یک Body of Knowledge برای Foundation Level است و خود آن «وابستگی تست به Context» را یکی از اصول می‌داند. گواهینامه می‌تواند واژگان مشترک و حداقل دانش نظری را نشان دهد؛ Strategy، مهارت عملی یا شایستگی در محصول خاص را به‌تنهایی ثابت نمی‌کند.

سه لایه‌ای که باید از هم جدا شوند

لایه	پرسش	نمونه	امکان Tailoring
تعهد سخت	چه چیزی قانون، قرارداد یا Safety Policy الزام کرده؟	کنترل دسترسی، Evidence نگهداری‌شده، بازبین مستقل	فقط با مسیر مجاز Waiver؛ نه تصمیم سلیقه‌ای تیم
کنترل مشترک	برای همکاری و Traceability چه چیز باید ثابت باشد؟	Build ID، وضعیت نتیجه، Severity، Decision Record	شکل اجرا قابل‌تغییر؛ Outcome باید حفظ شود
راهبرد تطبیقی	با زمان و ریسک فعلی چه تستی بیشترین اطلاعات را می‌دهد؟	Charter، عمق Regression، Device Matrix، Canary	بالا؛ با Evidence و تغییر Context بازبینی می‌شود

Context-Driven بودن اجازه نمی‌دهد تعهد سخت را ناپدید کنید. استاندارد بودن نیز به این معنی نیست که همه جزئیات راهبرد در همه Releaseها ثابت بماند.

مقایسه درست: نقطه شروع و معیار انتخاب

محور	تأکید Context-Driven	کاربرد سالم استاندارد
نقطه شروع	Mission، ریسک و نیاز ذی‌نفع	تعهد و Outcome مشترک
انتخاب Practice	Fit-for-Purpose و قابل‌بازنگری	گزینه‌ها، حداقل‌ها و زبان مشترک
مستندات	متناسب با مصرف‌کننده و تصمیم	Information Item و Traceability لازم
تست اسکریپت‌شده	وقتی تکرار و Regression ارزش دارد	ساختار اجرا و Evidence قابل‌مقایسه
تست اکتشافی	برای Unknown، یادگیری و تطبیق سریع	قابل‌مدیریت با Charter، Note و گزارش
اندازه‌گیری	Metric معتبر برای پرسش زمینه	تعریف، مخرج و Status مشترک
تغییر	Strategy با Context به‌روز می‌شود	Change Control و ردپای Tailoring
صلاحیت	قضاوت، دامنه و تکنیک‌های متنوع	حداقل نقش، بازبینی و آموزش
ریسک افراط	سلیقه فردی و Evidence ناکافی	تیک‌زدن، مستندات بی‌مصرف و Compliance Theater

پنج دوگانه کاذب که باید کنار گذاشت

۱. Context-Driven یا مستند

سؤال درست «چقدر مستند؟» نیست؛ «چه کسی برای کدام تصمیم، چه Evidenceای را تا چه زمانی لازم دارد؟» است. Session Note، Trace، تست کدنویسی‌شده، Screenshot محدود، Risk Register و گزارش تکمیل همگی مستندند. حجم بیشتر، Evidence بهتر را تضمین نمی‌کند.

۲. Exploratory یا Scripted

Regression پایدار، محاسبه مالی و Contract API معمولاً از Script و اتوماسیون سود می‌برند. رفتار تازه، تعامل انسانی و Failure ناشناخته به Exploration نیاز دارند. یک Journey می‌تواند ابتدا اکتشافی باشد، سپس یافته پایدار آن به Check تکرارشونده تبدیل شود.

۳. Agile یا استاندارد

مانیفست Agile برای آیتم‌های سمت چپ ارزش بیشتری قائل است، اما ارزش آیتم‌های سمت راست را نفی نمی‌کند. Agile می‌تواند Evidence، Traceability و استاندارد داشته باشد؛ تفاوت در حلقه بازخورد، Batch و روش نگهداشت آن‌هاست.

۴. مهارت انسان یا فرایند

فرایند ضعیف نمی‌تواند با Heroics دائمی جبران شود و فرایند خوب نیز بدون قضاوت اجرا نمی‌شود. Checklist باید حافظه را پشتیبانی کند؛ تصمیم پیچیده را به تیک مکانیکی تقلیل ندهد. برای کنترل خطاهای قضاوت، راهنمای سوگیری شناختی در تست مکمل است.

۵. Compliance یا کشف ریسک

Conformance به الزام مشخص یک سؤال مهم است، اما همه ریسک محصول را پوشش نمی‌دهد. از طرف دیگر، کشف عیب جذاب بدون پوشش الزام نیز کافی نیست. Compliance Test و Risk Exploration باید دو خروجی روشن و قابل‌پیوند داشته باشند.

بوم Context؛ قبل از نوشتن Strategy

Mission و تصمیم:
محصول / Release / Journey:

ذی‌نفعان و افراد متأثر:
مسئله‌ای که محصول باید حل کند:
کیفیت‌های حیاتی و Trade-off:

ریسک‌های محصول و پروژه:
معماری، Interface و وابستگی:
داده، محیط، Locale، Device و شبکه:
Testability و Observability:

چرخه عمر و سرعت تغییر:
مهارت، ظرفیت و استقلال تیم:

تعهدهای قانونی / قراردادی / سیاستی:
Evidence موردنیاز، مخاطب و Retention:

بودجه، Deadline و هزینه تأخیر:
کنترل تولید، Rollback و برگشت‌پذیری:

موارد نامعلوم:
فرض‌ها، مالک و تاریخ بازبینی:

این بوم یک‌بار برای همیشه پر نمی‌شود. معماری، ترافیک، قرارداد، تیم یا وابستگی که تغییر کند، Strategy نیز باید بازبینی شود.

برای کامل‌تر دیدن کیفیت از مدل مرجع استفاده کنید

ISO/IEC 25010:2023 یک مدل Product Quality با ۹ ویژگی ارائه می‌کند و می‌تواند برای تعریف Requirement، هدف تست، معیار پذیرش و Measure استفاده شود. مدل نمی‌گوید همه ویژگی‌ها باید وزن یکسان داشته باشند؛ Context تعیین می‌کند کدام Quality Characteristic برای این محصول و Release حیاتی است.

از Context به استراتژی تست؛ هشت گام

گام ۱: تصمیم را نام‌گذاری کنید

آیا Evidence برای Merge، Release، پذیرش قراردادی، مهاجرت داده، خرید ابزار یا پاسخ Incident لازم است؟ Mission مبهم، خروجی مبهم می‌سازد.

گام ۲: تعهدهای سخت را جدا کنید

Clause، Policy، قرارداد PSP، Security Control، Retention و نیاز Audit را با مالک تفسیر ثبت کنید. تیم QA نباید از روی حدس حکم حقوقی بسازد.

گام ۳: ریسک‌ها را به زبان اثر بنویسید

Condition→Event→Impact بنویسید و Inherent، Current و Residual Risk را جدا کنید. راهنمای RBT برای ساخت Risk Register و نگاشت آن به Evidence کاربردی است.

گام ۴: برای هر ریسک تکنیک و Oracle انتخاب کنید

Boundary برای کران، Decision Table برای Rule، State Transition برای Workflow، Contract Test برای Interface، Performance Test برای Workload و Exploration برای Unknown. نام Technique بدون Test Condition و Oracle کافی نیست.

گام ۵: Evidence Contract بسازید

برای هر خروجی تعیین کنید: Artifact، منبع، نسخه، Status، مالک، دسترسی، Retention، مصرف‌کننده و تصمیم. Evidence می‌تواند خودکار باشد، اما معنای آن باید انسانی و قراردادی باشد.

گام ۶: Fast Feedback و Deep Evidence را لایه‌بندی کنید

Checkهای سریع در PR، Integration محدود، تست Journey، آزمون‌های کند زمان‌بندی‌شده و کنترل تولید را بر اساس سرعت و ریسک بچینید. مقاله Continuous Testing در CI/CD این معماری را عملی می‌کند.

گام ۷: Not Evaluated و ریسک باقی‌مانده را گزارش کنید

Pass بدون دامنه، اطلاعات ناقص است. مشخص کنید چه Platform، State، Data، Dependency یا Quality Characteristic ارزیابی نشده و چه کسی ریسک را پذیرفته است. قالب گزارش اختتامیه تست برای این تصمیم مناسب است.

گام ۸: Trigger بازبینی تعریف کنید

تغییر معماری، قرارداد، Dependency، حجم، Incident شدید، تیم، داده یا ابزار باید Strategy را دوباره باز کند. بازبینی صرفاً تقویمی کافی نیست.

حداقل استانداردسازی مفید برای بیشتر تیم‌ها

حتی تیم بسیار Context-Driven از چند قرارداد مشترک سود می‌برد:

• شناسه یکتای Build، Artifact، Commit و Environment؛
• تعریف Resultهای Pass، Fail، Blocked، Skipped، Not Run و Inconclusive؛
• Severity، Priority و اختیار پذیرش ریسک؛
• منبع Test Basis و نسخه آن؛
• Run Manifest شامل داده، Dependency و Config مؤثر؛
• قواعد Secret، PII، Screenshot، دسترسی و Retention؛
• پیوند Risk→Test→Evidence→Decision؛
• مالک، موعد و شاهد تکمیل Action Item؛
• سیاست Flaky، Retry و Quarantine؛
• Trigger بازبینی Strategy.

این حداقل‌ها «بهترین Practice جهان‌شمول» نیستند؛ نقطه شروع پیشنهادی‌اند که باید حذف، افزودن یا تغییر هر مورد آن با Context توضیح داده شود.

مثال ایرانی: Strategy پرداخت یک بازارگاه

سناریو فرضی است. بازارگاه سه PSP دارد، مبلغ در Backend ریال ذخیره می‌شود و UI تومان نمایش می‌دهد. بخشی از کاربران رقم فارسی وارد می‌کنند. کمپین ترافیک را ناگهان بالا می‌برد، SMS و PSP گاهی کند می‌شوند و تیم باید Evidence تسویه و بازپرداخت را برای مالی نگه دارد.

لایه تعهد سخت

• قرارداد Interface هر PSP و وضعیت‌های قابل‌قبول؛
• کنترل دسترسی و حفاظت از شناسه و داده تراکنش؛
• ردیابی مالی سفارش، پرداخت، کیف پول، بازپرداخت و تسویه؛
• Retention و اختیار مشاهده Evidence طبق سیاست سازمان و قرارداد؛
• مالک پذیرش ریسک مالی و Incident.

لایه استاندارد مشترک

• Contract Test نسخه‌دار و مجموعه Regression برای Idempotency؛
• شناسه Correlation میان درخواست، Callback، سفارش و Ledger؛
• Run Manifest شامل PSP، Currency Unit، Script رقم، Config و Build؛
• گزارش بسته نتایج، Not Evaluated، مغایرت و Decision Record؛
• Quality Gate برای خطای بحرانی و شرط Rollback.

لایه تطبیقی Context-Driven

• Charter برای Timeout پیش و پس از کسر وجه، Callback تکراری و خارج از ترتیب؛
• بررسی ریال/تومان، ارقام فارسی/لاتین، جداکننده و بازپرداخت جزئی؛
• Workload کمپین با Mix واقعی PSP و Stop Condition ایمن؛
• آزمون Failover، تأخیر SMS و قطع وابستگی بدون ایجاد تراکنش واقعی ناخواسته؛
• Canary، مانیتور مغایرت، Feature Flag و تطبیق دوره‌ای در تولید.

اتوماسیون برای Contract، Invariant و Regression تکراری مناسب است؛ Exploration برای Stateهای ناشناخته و تعامل وابستگی ارزش دارد. راهنمای اتوماسیون تست کمک می‌کند این مرز بر اساس ارزش و هزینه نگهداشت تعیین شود.

Tailoring Record؛ انحراف را قابل‌دفاع کنید

فیلد	پرسش
مرجع	کدام Standard، Policy، Template یا Practice؟
Applicability	چرا در این دامنه اعمال می‌شود یا نمی‌شود؟
Outcome لازم	چه کنترل یا اطلاعاتی نباید از دست برود؟
Tailoring	چه چیزی حذف، ادغام، سبک یا جایگزین شده است؟
دلیل	کدام Context و Trade-off تصمیم را توجیه می‌کند؟
ریسک	چه شکافی ایجاد می‌شود و کنترل جبرانی چیست؟
اختیار	چه کسی تغییر یا Waiver را تأیید کرده است؟
Evidence و انقضا	تصمیم کجا ثبت و چه زمانی بازبینی می‌شود؟

Tailoring پنهانی، استاندارد را به تئاتر تبدیل می‌کند. Tailoring ثبت‌شده، نشان می‌دهد تیم Outcome را فهمیده و آگاهانه شکل اجرای آن را تغییر داده است.

چه رویکردی برای چهار Context رایج مناسب است؟

MVP کم‌ریسک و برگشت‌پذیر

تمرکز بر Journey اصلی، Unit/Contract سریع، چند Charter کوتاه، Telemetry و Feedback کاربر. Evidence سبک است، اما Build و تصمیم باید مشخص بماند. «MVP» مجوز نادیده‌گرفتن امنیت یا داده شخصی نیست.

فروشگاه یا بازارگاه پرترافیک

Regression خودکار لایه‌ای، Performance/Resilience، Contract وابستگی، Device/Locale Matrix و Exploration کمپین لازم‌اند. Error Budget، Canary و Rollback بخشی از Strategy‌اند، نه جایگزین تست پیش از انتشار.

محصول با تعهد نظارتی یا ایمنی بالا

Traceability، استقلال، Validation، Evidence نگهداری‌شده و Change Control وزن بیشتری می‌گیرند. Context-Driven بودن یعنی این تعهدها را دقیق در Strategy وارد کنیم و فراتر از Checklist، Failureهای مخصوص محصول را هم جست‌وجو کنیم.

مهاجرت سامانه Legacy

Characterization Test، تطبیق داده، Parallel Run و Reconciliation استاندارد می‌شوند؛ Exploration روی رفتارهای ضمنی، داده آلوده، عملیات دستی و تفاوت کاربران قدیمی تمرکز می‌کند. Requirement ناقص باید به‌عنوان محدودیت ثبت شود.

معیارهای سالم برای رویکرد ترکیبی

• Risk Evidence Coverage: چه سهمی از ریسک‌های اولویت‌بالا Evidence معتبر دارد؟
• Evidence Freshness: چند Artifact به Build یا Contract قدیمی وصل است؟
• Decision Latency: از آماده‌شدن Build تا تصمیم قابل‌دفاع چقدر طول می‌کشد؟
• Not Evaluated: کدام شکاف‌ها تکرار می‌شوند و مالک ندارند؟
• Trace Gap: چند الزام یا ریسک بدون Test/Evidence/Decision است؟
• Exploration Yield: چه فرض یا ریسک تازه‌ای به مدل اضافه شد، نه فقط تعداد باگ؟
• Maintenance Cost: زمان نگهداشت، Flaky و تریاژ هر لایه چقدر است؟
• Residual-risk Outcome: رخداد تولید به کدام ریسک شناخته‌شده یا ناشناخته وصل بود؟

Pass Rate خام، تعداد Test Case و حجم سند درباره Fit Strategy چیزی نمی‌گویند. هر Metric باید تعریف، مخرج، منبع، تصمیم و Guardrail داشته باشد.

نشانه‌های افراط در هر دو سمت

Context-Driven نمایشی

• هر Tester روش شخصی دارد و Outcome مشترک نیست؛
• «به Context بستگی دارد» جای دلیل و Evidence را گرفته است؛
• جلسه اکتشافی Note، Coverage و Debrief ندارد؛
• الزام قراردادی به‌عنوان Bureaucracy حذف می‌شود؛
• نتیجه به یک متخصص غیرقابل‌جایگزین وابسته است.

Standards-Driven نمایشی

• Template کامل است اما تصمیم‌گیر آن را نمی‌خواند؛
• Traceability به Linkهای مرده و Evidence قدیمی ختم می‌شود؛
• تعداد Case به‌جای Risk Coverage گزارش می‌شود؛
• Deviation واقعی پنهان و Audit فقط نمایشی است؛
• Process ثابت با تغییر معماری و محصول به‌روز نمی‌شود.

اگر از شما خواسته می‌شود Evidence را تحریف کنید یا تعهد سخت را بدون اختیار کنار بگذارید، موضوع فقط انتخاب Method نیست؛ مسیر اخلاق حرفه‌ای QA لازم است.

برنامه ۳۰ روزه برای ساخت Strategy متناسب

1. هفته اول: یک Journey را انتخاب، بوم Context را پر و تعهدها را از Preference جدا کنید.
2. هفته دوم: پنج ریسک اول، Technique، Oracle و Evidence Contract را تعریف کنید.
3. هفته سوم: یک Run کامل با لایه‌های Scripted، Exploratory و Production Control اجرا کنید.
4. هفته چهارم: Tailoring Record، هزینه، شکاف Evidence و تصمیم واقعی را مرور کنید.

خروجی Pilot باید یک Strategy کوتاه و زنده باشد، نه اعلام پذیرش یک مکتب. اگر Practice انتخابی تصمیم را بهتر نکرد، آن را تغییر دهید.

جمع‌بندی

تست مبتنی بر زمینه و استانداردهای تست دشمن هم نیستند، اما نقطه شروع متفاوتی دارند. CDT از مسئله، Stakeholder، ریسک و محدودیت شروع می‌کند؛ Standard می‌تواند Outcome، زبان و Evidence مشترک فراهم کند. رویکرد بالغ، تعهد سخت را حفظ، کنترل مشترک را سبک و قابل‌اجرا، و Strategy را با تغییر Context به‌روز می‌کند.

به‌جای پرسش «CDT یا Standard؟» بپرسید: کدام تصمیم، کدام ریسک، کدام تعهد و کدام Evidence؟ پاسخ همین چهار پرسش تعیین می‌کند چه چیزی باید ثابت بماند، چه چیزی Tailor شود و چه چیزی ارزش ادامه‌دادن ندارد. برای مرور مبانی هدف و سطح تست نیز راهنمای تست نرم‌افزار چیست نقطه شروع مناسبی است.

سؤالات متداول تست مبتنی بر زمینه

۱. آیا Context-Driven Testing همان تست اکتشافی است؟

خیر. CDT رویکرد انتخاب Practice بر اساس Context است؛ Exploratory Testing یک شیوه طراحی و اجرای تست است. یک Strategy زمینه‌محور می‌تواند تست اکتشافی، اسکریپت‌شده، خودکار، رسمی یا مستقل را کنار هم داشته باشد.

۲. آیا تست مبتنی بر زمینه مخالف استانداردهاست؟

CDT با شروع از Best Practice مستقل از Context مخالف است. Standard می‌تواند الزام، زبان یا گزینه مفید باشد. تیم باید Applicability، Outcome، Tailoring و ریسک انحراف را ثبت کند؛ نه اینکه Standard را کورکورانه اجرا یا کامل حذف کند.

۳. آیا CDT در پروژه‌های رگولاتوری یا ایمنی‌حیاتی قابل‌استفاده است؟

بله، اگر الزامات قابل‌اعمال به‌عنوان بخش اصلی Context و خطوط قرمز Strategy وارد شوند. در چنین محصولی Traceability، استقلال، Retention و کنترل تغییر بیشتر می‌شود؛ هم‌زمان Exploration برای ریسک‌های خاص محصول همچنان ارزش دارد.

۴. آیا Context-Driven بودن یعنی مستندسازی کمتر؟

نه لزوماً. یعنی مستندسازی متناسب با مصرف‌کننده، تصمیم و تعهد. یک Context ممکن است Note سبک بخواهد و دیگری Evidence چندساله. مسئله ارزش و کفایت اطلاعات است، نه حداقل یا حداکثر حجم.

۵. تیم کوچک از کجا شروع کند؟

یک Journey حیاتی، پنج ریسک، سه تعهد مشترک و یک Evidence Contract انتخاب کنید. Build ID، Result States، Risk Decision و Not Evaluated را ثابت نگه دارید؛ سپس Regression سریع و Charterهای اکتشافی را بر اساس ریسک توسعه دهید.