مدیریت تست

تست اکتشافی و Scripted؛ از Uncertainty تا Evidence

انتشار در تاریخ توسط محمد عسکری

پرسش «تست اکتشافی بهتر است یا تست اسکریپت‌محور؟» از ابتدا یک متغیر مهم را پنهان می‌کند: برای کدام تصمیم، ریسک، سیستم، Oracle و مرحله یادگیری؟ یک رویه از پیش نوشته‌شده می‌تواند مبهم، منقضی یا کاملاً انسانی باشد؛ یک Session اکتشافی نیز می‌تواند Charter، مدل پوشش، یادداشت زمان‌دار، ابزار و Evidence دقیق داشته باشد. این دو نه دو تیم رقیب‌اند و نه دو انتهای ساده نظم و خلاقیت.

در این راهنما یک Test Approach Allocation Record می‌سازیم: سؤال و Claim را پین می‌کنیم، سطح عدم‌قطعیت و Consequence را می‌سنجیم، میزان آزادی طراحی/داده/ترتیب/Oracle/توقف را آگاهانه تخصیص می‌دهیم، روش‌های ازپیش‌تعریف‌شده و تطبیقی را در یک Portfolio قرار می‌دهیم و Evidence را برای تصمیم و یادگیری بعدی نگه می‌داریم.

پاسخ کوتاه: Exploratory یا Scripted؟

  • اگر سؤال، Subject، State، Data، Oracle و تکرار پایدارند، بخش بیشتری را از پیش تعریف یا خودکار کنید.
  • اگر عدم‌قطعیت، تغییر، تعامل ناشناخته یا مدل ناقص است، آزادی تطبیق و یادگیری حین اجرا را افزایش دهید.
  • اگر Consequence بالاست، فقط Script اضافه نکنید؛ Evidence قابل بازبینی، استقلال مناسب، پوشش Risk و Exploration برای Unknownها لازم است.
  • برای Regression تکراری، check پایدار مفید است؛ اما هر دور باید freshness، relevance، Oracle و blind spot آن بازبینی شود.
  • برای Feature جدید، Charter اکتشافی می‌تواند مدل بسازد؛ یافته مهم سپس به مثال، check، monitor یا control پایدار تبدیل می‌شود.
  • Automation و Manual محور دیگری‌اند: هم رویه ازپیش‌تعریف‌شده و هم Exploration می‌توانند از ابزار استفاده کنند.
  • پوشش را با Risk/Model/State/Rule/Interface/Data/Platform بسنجید، نه فقط درصد Test Case اجراشده.
  • هر رویکرد باید Evidence، Unknown، محدودیت، مالک تصمیم و مسیر اصلاح داشته باشد.

تعریف دقیق: ازپیش‌تعریف‌شده و تطبیقی دو برچسب مطلق نیستند

ISTQB CTFL 4.0.1 Exploratory Testing را طراحی، اجرا و ارزیابی هم‌زمانِ تست در حین یادگیری از Test Object توضیح می‌دهد و می‌گوید می‌تواند از تکنیک‌های دیگر نیز استفاده کند. Session-based testing با Timebox، Charter، Coverage item، Session sheet و Debrief یکی از روش‌های ساختاردهی است. ما این تعریف را به‌عنوان یک vocabulary معتبر استفاده می‌کنیم، نه قانون انحصاری یا الزام Certification.

مفهومتعریف عملیاتی این مقالهبرداشت نادرست
Predefined procedureبخشی از Design/Data/Sequence/Oracle/Expected outcome پیش از اجرا ثبت شده استهمیشه دقیق، کامل یا دستی است
Exploratory testingیادگیری بر انتخاب Test بعدی اثر می‌گذارد و Design/Execution/Evaluation در هم تنیده‌اندتصادفی، بی‌هدف یا بدون مستندات است
Session-based managementساختار مدیریت یک کار اکتشافی با Mission/Timebox/Notes/Debriefهر Exploration باید دقیقاً ۹۰ دقیقه باشد
Automated checkکنترل ماشینیِ bounded claim با Oracle و Evidence تعریف‌شدهتمام Automated Testing یا ضد Exploration است
Ad hocدر کاربرد روزمره برچسبی مبهم؛ باید skill/mission/evidence را توصیف کردهر کار بدون Test Case الزاماً بی‌مهارت است

مالکیت محتوایی این راهنما

این مقاله مالک Question/Risk → Uncertainty/Consequence → Degrees of Freedom → Predefined/Adaptive Allocation → Procedure/Charter/Oracle/Coverage → Execution/Evidence → Finding/Conversion → Review/Rebalance است. برای اجرای کامل Charter/Session/Debrief به راهنمای تست اکتشافی ساختاریافته، برای انتخاب Manual/Automation و ROI به مقایسه تست دستی و خودکار و برای Portfolio کلان به سند استراتژی تست تصمیم‌محور مراجعه کنید.

Test Approach Allocation Record چیست؟

AllocationID: TAA-SYN-001
Version / Status / ReviewAt: v1 / PILOT / 2026-09-01
Product / Build / Risk: Fake Checkout / BUILD-SYN-17 / RISK-DUPLICATE
DecisionNeed: آیا rollout آزمایشی مجاز است؟
Question: timeout-after-commit و retry چه state قابل مشاهده‌ای می‌سازند؟
Known / Unknown: idempotency rule known / late callback interaction unknown
Consequence / Reversibility: HIGH-SYN / rollback possible
ChangeRate / RepeatFrequency: medium / every release
OracleStability: invariant stable; UI copy evolving
DegreesOfFreedom:
  mission=fixed, stateModel=fixed, data=partly_generated,
  sequence=adaptive, oracle=mixed, stop=risk_budget, notes=required
PredefinedEvidence: contract checks + duplicate-event invariant
AdaptiveEvidence: chartered timeout/retry/reorder exploration
ConversionRule: stable finding → regression check/monitor/control candidate
Owner / DecisionAuthority: Test-A / Release-Risk-B
ClaimLimit: no proof of absence, quality, safety or correct release

مرحله صفر: Decision و Evidence Question را پین کنید

«تست صفحه پرداخت» Scope نیست. Product/Service، Requirement/Risk/Claim، Build/Commit/Config، Environment، Data، User/System state، Decision need، Deadline source، صاحب اختیار و Not-claimed را ثبت کنید. Approach فقط وقتی قابل دفاع است که معلوم باشد چه تصمیمی به چه اطلاعاتی نیاز دارد.

EvidenceQuestionID / Version
ProductGoalOrRisk / Claim / Source
Subject: artifact|component|service|system|journey
Build / Commit / Config / Environment / Dependencies
PopulationOrCases / State / Data / Locale / Platform
Question / CompetingExplanations / Unknowns
DecisionNeed / DecisionOwner / Due / Consequence
EvidenceMinimum / Freshness / ClaimLimit

مرحله یک: عدم‌قطعیت را طبقه‌بندی کنید

  • Problem uncertainty: هنوز نمی‌دانیم چه Outcome/Need مهم است.
  • Rule uncertainty: رفتار مورد انتظار یا Source authority مبهم/متعارض است.
  • System uncertainty: State، dependency، timing، concurrency یا failure behavior کامل نیست.
  • Test uncertainty: Oracle، coverage model، environment یا data مناسب را نمی‌دانیم.
  • Change uncertainty: Subject، requirement یا architecture سریع تغییر می‌کند.
  • Evidence uncertainty: نتیجه، provenance، freshness یا رابطه آن با Claim نامطمئن است.
  • Outcome uncertainty: رفتار کاربر/Production و اثر بلندمدت هنوز قابل مشاهده نیست.

عدم‌قطعیت بیشتر معمولاً فضای Exploration را افزایش می‌دهد، اما به معنای حذف Procedure نیست. می‌توان Mission، Safety boundary و Evidence capture را ثابت کرد و انتخاب data/sequence/follow-up را تطبیقی گذاشت. برعکس، Subject پایدار هم ممکن است Unknown جدید داشته باشد و به Session دوره‌ای نیاز پیدا کند.

مرحله دو: Consequence و Evidence burden را بسنجید

ریسک بالا به معنی Script-only نیست. Consequence، likelihood/uncertainty، detectability، reversibility، exposure، recovery و authority را ببینید. حوزه حساس ممکن است traceable predefined checks برای Known obligations، independent review برای Evidence و exploratory hazard discovery برای Unknown interactionها نیاز داشته باشد.

برای ساخت Condition→Event→Impact، Treatment و Residual Risk از راهنمای تست مبتنی بر ریسک استفاده کنید. Test Approach یک Risk treatment است، نه تضمین حذف Risk. الزامات قانونی/استانداردی نیز باید از Source و نقش واجد صلاحیت بیایند؛ عبارت «سیستم مالی/پزشکی پس Scripted ضروری است» کافی نیست.

مرحله سه: Degrees of Freedom را آگاهانه تخصیص دهید

بُعدازپیش‌تعریف‌شدهتطبیقی
Mission/Questionسؤال و claim ثابتسؤال با کشف ریسک re-charter می‌شود
Model/CoverageRule/state/pair list ثابتمدل در حین یادگیری گسترش می‌یابد
DataFixture/partition مشخصبراساس مشاهده تولید/تغییر می‌شود
Sequenceگام/ترتیب تعریف‌شدهگام بعد از نتیجه قبلی انتخاب می‌شود
OracleExpected/Invariant/threshold پین‌شدهOracle جدید با source/validation اضافه می‌شود
Technique/Toolروش/runner مشخصتکنیک مناسب یافته انتخاب می‌شود
Stopcase/budget/coverage/thresholdRisk saturation، blocker یا charter change
Evidence detailفیلد/manifest اجباریعمق capture با signal تغییر می‌کند، نه provenance

هیچ رویکردی آزادی صفر یا صد ندارد. اجراکننده یک Test Case نیز هنگام failure تصمیم می‌گیرد retry، بررسی log، توقف یا escalation کند؛ این آزادی باید policy داشته باشد. Explorer هم Mission، Rule، safety، data و time budget دارد. کیفیت Approach از تناسب آزادی با سؤال و توان Evidence می‌آید.

Script چه سطحی از جزئیات باید داشته باشد؟

Script می‌تواند از یک شرط/مثال سطح بالا تا دستور click-by-click باشد. جزئیات بیشتر تکرار لفظی را افزایش می‌دهد اما الزاماً reproducibility یا correctness را بالا نمی‌برد؛ UI locator منقضی، setup پنهان، data مشترک و Oracle مبهم می‌تواند Test Case بسیار دقیق را غیرقابل تکرار کند. سطح را با Skill، Risk، variance قابل قبول، عمر Subject، audit need و maintenance cost تعیین کنید.

ProcedureContract:
  ProcedureID / Version / Purpose / RiskRef
  Subject / Build / Environment / Dependencies
  Preconditions / State / Data / Cleanup
  StepsOrRules / AllowedVariation / ProhibitedVariation
  OracleSource / Expected / Tolerance / TimeWindow
  ResultVocabulary / EvidenceRequired / AttemptPolicy
  ExecutorCapability / Owner / Freshness / ReviewTrigger
  MaintenanceCost / Retirement / ClaimLimit

قابلیت تکرار را ادعا نکنید؛ قرارداد کنید

  • Build/commit/config/feature flag و dependency version؛
  • environment/image/region/device/browser و clock/zone؛
  • initial state، data identity/generator/seed و cleanup؛
  • event order/timing/concurrency و external Stub behavior؛
  • exact input/attempt، actual result و timestamps؛
  • Oracle source/rule/version/tolerance؛
  • log/trace/screenshot/video فقط با privacy/redaction؛
  • expected nondeterminism و Pass/Fail/Inconclusive policy.

اگر سیستم غیرقطعی است، یک Script ثابت همان Outcome را تضمین نمی‌کند. Seed نیز scheduler، clock، dependency یا race را لزوماً بازپخش نمی‌کند. برای Trial/Statistical Oracle/Replay/Retry/Quarantine از راهنمای تست سیستم غیرقطعی استفاده کنید.

Exploratory را با Charter و Model هدایت کنید

ExplorationCharterID / Version
Mission: Explore [Target] with [Resources/Techniques]
  to discover information about [Risk/Question]
Subject / Build / Environment / Data / StartingState
Models / CoverageItems / Oracles / Heuristics
Constraints / Safety / Privacy / NoProductionWrite
TimeboxOrBudget / Stop / ReCharterTrigger
Notes / Evidence / ReproductionMinimum
TesterOrPair / Capability / Support
Debrief / Findings / Unknowns / NextCharter / ClaimLimit

مقاله اصلی Session-Based Test Management SBTM را راهی برای مدیریت فعالیت اکتشافی معرفی می‌کند. این منبع نماینده یک مکتب/روش است، نه استاندارد اجباری. صفحه در مرورگر قابل خواندن است، اما درخواست خط فرمان این ممیزی را با پاسخ ضدربات ۴۰۶ رد کرد. Timebox را بر اساس focus، Risk، setup، accessibility و خستگی انتخاب کنید؛ ۹۰ دقیقه قانون جهانی یا شاخص کیفیت نیست.

Note-taking نباید Testing را متوقف یا Evidence را نابود کند

یادداشت هم‌زمان باید به‌اندازه‌ای باشد که مسیر، مدل، تصمیم، evidence و Unknown را بازیابی کند. timestamp marker، voice note با رضایت، screenshot redacted، console/network capture، command history، generated-data manifest و paired navigator گزینه‌اند. capture همه‌چیز می‌تواند privacy، حجم و distraction بسازد؛ حداقل لازم را پیشاپیش تعریف کنید.

SessionNote:
  At / Thread / Action / Observation
  ModelOrCoverageItem / Oracle / EvidenceRef
  Interpretation / Alternative / Unknown
  FindingCandidate / ReproductionStatus
  DetourReason / CharterChange / TimeSpentClass
  PrivacyRedaction / FollowUp / Correction

Debrief گزارش باگ یا شمارش Session نیست

  • Mission و تغییر آن چه بود؟
  • چه Coverage itemهایی لمس، عمیق، مسدود یا نادیده ماندند؟
  • چه مدل/Oracle/فرضی ساخته یا اصلاح شد؟
  • Observation، Finding، Issue، Question و Unknown چیست؟
  • Evidence کافی/ناقص/نامعتبر و Reproduction status چیست؟
  • چه Risk/Decisionی تغییر کرد و چه چیزی تغییر نکرد؟
  • کدام follow-up باید Procedure، Check، Monitor، Experiment یا Charter باشد؟
  • چه Detour/Setup/Investigation/Test time و چه impedimentی دیده شد؟

Coverage در Scripted به‌راحتی «اندازه‌گیری» نمی‌شود

Executed cases ÷ planned cases فقط پیشرفت یک inventory است. اگر inventory ناقص، تکراری، منقضی یا بدون Oracle باشد، ۱۰۰٪ اجرا درباره Risk coverage کم می‌گوید. Coverage باید مدل و denominator داشته باشد: Requirement، Rule، State/Transition، Risk، Interface، Data partition/boundary، Code، Platform، Locale، Failure mode یا Journey.

Coverage modelEvidenceمحدودیت
Requirement/Ruletrace به examples/resultsSource ممکن است ناقص یا غلط باشد
State/Transitionvisited states/edges با start/endترکیب data/time/concurrency را کامل نمی‌کند
RiskRisk→Question→Evidence→Resultوزن و Unknown نیازمند authority است
Datapartition/boundary/invalid/localecombinatorial interaction باقی می‌ماند
Interface/Dependencycontract/event/failure/fidelityStub رفتار Live را ثابت نمی‌کند
Exploratory threadcharter/model/notes/depth/UnknownSession count سطح پوشش نیست

Test Case را به تازه‌کار واگذار نکنید و Context را حذف نکنید

گام دقیق می‌تواند onboarding را کمک کند، اما اجرای بی‌فهم توسط فرد کم‌تجربه False confidence می‌سازد. Executor باید Purpose، Oracle، variance policy، unsafe state، evidence و escalation را بداند. برای کار حساس pairing، shadow، supervised practice و competency evidence لازم است. مستندات substitute دانش Domain یا judgment نیستند.

Exploration وابسته به قهرمان نیست

مهارت، Domain و مدل‌سازی مهم‌اند، اما طراحی سیستم باید کیفیت را به حافظه یک «تستر نابغه» وابسته نکند. Risk briefing، product tour، model library، paired session، debrief، coaching، accessible tools، examples، Production learning و rotation با handoff قابلیت تیم را افزایش می‌دهند. تعداد defect کشف‌شده معیار مهارت یا ارزش فرد نیست.

Pesticide Paradox را شعار نکنید

یک suite ثابت فقط همان Claimهای تعریف‌شده را دوباره بررسی می‌کند؛ ممکن است هنوز برای regression بسیار ارزشمند باشد. مسئله «مقاوم‌شدن باگ» نیست. Subject، Risk، data، dependency و failure mode تغییر می‌کنند و blind spot باقی می‌ماند. Review trigger، mutation/change analysis، incident feedback، parameter/data renewal، new charters و retirement را برنامه‌ریزی کنید.

Regression یک بسته یک‌دست نیست

  • fast deterministic checks برای invariantهای پایدار؛
  • contract/component checks برای interface و rule؛
  • critical-path E2E محدود با state/data کنترل‌شده؛
  • change-focused scripted examples براساس impact؛
  • exploratory regression برای interaction و Unknown جدید؛
  • specialty evidence برای performance/security/accessibility/reliability؛
  • Production guardrail/monitor برای Claimهایی که pre-production کافی نیست؛
  • incident-derived tests و retirement برای Evidence منقضی.

Usability Testing را با Exploratory Testing یکی نکنید

یک تستر می‌تواند UX issue candidate یا workflow ambiguity را در Exploration پیدا کند؛ اما رفتار، درک و رضایت گروه هدف به پروتکل، participant، task، consent و analysis مناسب نیاز دارد. «برای من گیج‌کننده بود» Observation/Expert input است، نه User finding. Role-playing کاربر یا معلولیت جای پژوهش و lived experience را نمی‌گیرد.

Automation محور مستقل از Exploration است

طراحیاجرای انسانیاجرای ابزارمحور
ازپیش‌تعریف‌شدهProcedure/Checklist/Example دستیAutomated check، model traversal ثابت
تطبیقیChartered exploration/paired investigationابزار برای generation/query/fault/capture؛ انسان مسیر را تطبیق می‌دهد

یک ابزار می‌تواند هزار داده تولید و نتیجه را جمع کند، اما انتخاب بعدی، interpretation و Oracle governance همچنان جداست. یک Explorer نیز می‌تواند script کوچک، query، proxy، API client یا log parser بنویسد. برای قرارداد هر check و lifecycle Evidence به راهنمای Automated Check مراجعه کنید.

الگوی Allocation بر اساس سؤال

سؤال/RiskPredefinedAdaptiveConversion
Rule پایدار تخفیفdecision table/boundaries/checksترکیب Rule با cart/user/timeinteraction پایدار به example
Feature جدیدknown acceptance examples/smokemodel-building charterFinding به Risk/Procedure
پرداخت duplicateidempotency invariant/fault casesretry/reorder/multichannel threadincident path به regression/monitor
Accessibilitycriterion-based checksexpert/user evaluation در scope مناسبbarrier به design/test/control
Performanceworkload/model/SLO/trialsdiagnostic exploration از distributionbottleneck به focused experiment
Incident ناشناختهknown containment/replayinvestigation/hypothesis testingcause/control به check/alert

Portfolio را از «اول Script، بعد Exploration» آزاد کنید

ترتیب به feedback dependency بستگی دارد. گاهی Exploration اولیه مدل و Risk می‌سازد، بعد checks نوشته می‌شوند؛ گاهی smoke/contract checks اول Build را قابل کاوش می‌کنند؛ گاهی در حین Session ابزار ساخته می‌شود؛ گاهی یافته Production Charter بعدی را ایجاد می‌کند. یک pipeline خطی universal، learning loop را پنهان می‌کند.

ApproachPortfolio:
  PortfolioID / DecisionHorizon / Product / Risks
  Questions[] / Consequence / Uncertainty
  Procedures[] / Charters[] / AutomatedChecks[]
  SpecialtyStudies[] / ProductionEvidence[]
  CoverageModels / Oracles / Environments / Data
  FeedbackBudgets / Dependencies / Sequencing
  Entry / Stop / Gate / Exception / Authority
  EvidenceManifest / Unknowns / ResidualRisk
  ReviewTriggers / ConversionQueue / Retirement

Finding را به دارایی پایدار تبدیل کنید—اگر ارزش دارد

  • Defect: reproduction/evidence/impact/triage؛
  • Rule clarification: Source/version/decision و affected artifacts؛
  • Regression check: bounded stable claim و maintenance owner؛
  • Monitor/alert: Production-only signal با threshold/response؛
  • Testability change: hook/log/id/clock/control request؛
  • New charter: Unknown ارزشمند که هنوز Procedure مناسب ندارد؛
  • Experiment: Hypothesis، measure، guardrail و review؛
  • No conversion: signal کم‌ارزش/منقضی با دلیل و retention.

هر finding نباید Automated شود و هر Session نباید Test Case تولید کند. frequency، consequence، oracle stability، determinism، setup، data، false-result cost، maintenance و alternate control را مقایسه کنید. صف Conversion owner، due، decision و expiry می‌خواهد.

مثال فارسی: Checkout با timeout و callback دیرهنگام

در یک سیستم کاملاً خیالی، User با مبلغ canonical IRR و نمایش برچسب‌خورده تومان خرید می‌کند. client پس از fake commit timeout می‌گیرد؛ سپس callback موفق دیر و تکراری می‌رسد. یک Test Case Happy-path فقط Success فوری را می‌بیند؛ Exploration بی‌Oracle نیز ممکن است UI عجیب را «باگ» بنامد. Allocation ترکیبی لازم است.

Risk/ClaimEvidence ازپیش‌تعریف‌شدهEvidence تطبیقی
یک Order بیش از یک تعهد مالی نداشته باشدidempotency invariant + duplicate/reorder casesترکیب retry/back/refresh/device thread
Pending با Failed اشتباه نشودstate/response contract و copy ruleflow/copy/accessibility exploration
Ledger و Reconciliation همگرا شوندtemporal oracle/windowlate/missing/out-of-order diagnostic
Locale درست نمایش داده شودIRR/toman/digit/Unicode examplesRTL/Bidi/long-string/input-paste thread
Evidence قابل replay باشدRun/Attempt/Event IDs و manifestcapture جدید هنگام signal ناشناخته

Session Record نمونه

SessionID: SES-SYN-17
Charter: Explore retry/back/refresh around timeout-after-fake-commit
Build/Env/Data: BUILD-SYN-17 / LOCAL-STUB / DATA-SYN-8
Started/Ended/Zone: 09:00Z / 09:52Z / Asia-Tehran view
Threads: pending-state, duplicate-event, RTL-message, reconciliation
Coverage: 7/9 named states; 4/6 event-order pairs; unknown=device-switch
Observations: OBS-1..OBS-11
Findings: F-2 confirmed, F-3 candidate, F-4 invalidated
Evidence: manifest digest FAKE-77; no raw PII/credential
Detours: 8m data reset; 6m Oracle clarification
Unknowns: late callback after session expiry
Next: contract check candidate + Charter SES-SYN-18
ClaimLimit: one fictional Build/Stub/session; no Production conclusion

Metricهای Approach را ضدبازی کنید

Metricاستفاده محدودGuardrail
Procedure execution statusپیشرفت inventory در Build/windowCoverage/quality یا فرد را اثبات نمی‌کند
Charter coveragenamed model items touched/deep/blockedSession count و bug count جای depth نیست
Evidence validityvalid manifests ÷ expected manifestsValidity، truth/sufficiency نیست
Finding conversiondisposition و closure صفConversion بیشتر الزاماً بهتر نیست
Feedback latencyQuestion→usable evidence/decisionسرعت نباید Evidence minimum را حذف کند
Maintenance burdenupdate/triage/flake/setup timeحذف blind coverage برای کاهش burden ممنوع
  • Defect per Session را target نکنید؛ پنهان‌کاری/تقسیم مصنوعی می‌سازد.
  • Test Case count یا Pass rate را Coverage/Quality/Performance فرد ننامید.
  • نسبت Exploratory/Scripted یا Manual/Automated maturity score نیست.
  • Time spent class برای impediment و planning است، نه utilization فرد.
  • Unknown کمتر می‌تواند ناشی از گزارش‌نکردن باشد، نه یادگیری بهتر.
  • Outcome مشترک Product را به Approach واحد نسبت ندهید.

آزمایشگاه آفلاین: ۱۰۰٪ Script + یک Session برابر کیفیت نیست

این fixture کاملاً ساختگی، آفلاین و بدون Product، سازمان، تستر، کاربر، سیستم، پرداخت یا Outcome واقعی است. Checkout/Order/PaymentAttempt/PSP Stub/Callback/Ledger فقط مدل محلی‌اند. IRR خیالی، تومان صرفاً نمایشی، رقم فارسی/عربی/لاتین، ی/ی، ک/ک، نیم‌فاصله، RTL/LTR/Bidi، UTC، Asia/Tehran و جلالی نمایشی در داده هستند.

// Node.js 24+ — no network/package/real product/tester/user/payment
const fixture = {
  id: "SYN-TEST-APPROACH-ALLOCATION-01",
  superficial: ["100% scripted cases passed", "one 90-minute exploratory session",
    "regression automated", "all requirements traced", "no critical bugs"],
  system: "Fake Checkout/Order/PaymentAttempt/PSP Stub/Callback/Ledger",
  events: ["timeout-before-fake-commit", "timeout-after-fake-commit",
    "retry", "duplicate", "late", "reordered"],
  money: {canonical: "IRR-FAKE", view: "تومانِ صرفاً نمایشی"},
  glyphs: ["۱۲۳", "١٢٣", "123", "کیفیت", "كيفيت", "نیم‌فاصله"],
  time: {instant: "2026-08-13T09:00:00Z", zone: "Asia/Tehran",
    jalali: "نمایشی/غیرمحاسباتی"},
  realProductOrgTesterUserSystemPaymentOutcome: false
};

const groups = {
  identity: ["allocationId","version","status","effectiveFrom","asOf","owner","reviewAt","expiry","supersedes","sourceOfRecord","correctionRoute"],
  context: ["product","service","productGoal","requirement","risk","claim","build","commit","config","environment","dependencies","population","state","data","locale","platform","decisionNeed","deadlineSource","decisionOwner","authority","notClaimed"],
  question: ["questionId","questionVersion","questionClaim","claimSource","subject","competingExplanations","questionUnknowns","consequence","reversibility","evidenceMinimum","freshness","questionLimit"],
  uncertainty: ["problemUncertainty","ruleUncertainty","systemUncertainty","testUncertainty","changeUncertainty","evidenceUncertainty","outcomeUncertainty","uncertaintyEvidence","confidence","uncertaintyOwner","uncertaintyReview"],
  risk: ["condition","event","impact","likelihood","riskUncertainty","detectability","exposure","recovery","inherentRisk","controls","currentRisk","residualRisk","riskOwner","riskAcceptanceOwner","riskReview"],
  freedom: ["missionFreedom","modelFreedom","dataFreedom","sequenceFreedom","oracleFreedom","techniqueFreedom","toolFreedom","stopFreedom","evidenceFreedom","variationAllowed","variationProhibited","freedomRationale","freedomReview"],
  procedure: ["procedureId","procedureVersion","purpose","procedureRiskRef","procedureSubject","procedureBuild","procedureEnvironment","procedureDependencies","preconditions","initialState","procedureData","cleanup","stepsOrRules","allowedVariation","prohibitedVariation","oracleSource","expected","tolerance","timeWindow","resultVocabulary","evidenceRequired","attemptPolicy","executorCapability","procedureOwner","procedureFreshness","procedureReviewTrigger","maintenanceCost","retirement","procedureClaimLimit"],
  charter: ["charterId","charterVersion","mission","target","resources","informationGoal","charterSubject","charterBuild","charterEnvironment","charterData","startingState","models","coverageItems","oracles","heuristics","constraints","safety","privacy","noProductionWrite","timeboxOrBudget","stopRule","recharterTrigger","notesPolicy","charterEvidence","reproductionMinimum","testerOrPair","charterCapability","support","debrief","charterFindings","charterUnknowns","nextCharter","charterClaimLimit"],
  session: ["sessionId","sessionCharterRef","startedAt","endedAt","sessionZone","threads","coverageTouched","coverageDeep","coverageBlocked","coverageMissed","observations","findingCandidates","confirmedFindings","invalidatedFindings","evidenceRefs","detours","setupTime","testTime","investigationTime","sessionUnknowns","nextActions","sessionCorrection"],
  note: ["noteAt","thread","action","observation","modelItem","oracle","noteEvidenceRef","interpretation","alternative","noteUnknown","findingCandidate","reproductionStatus","detourReason","charterChange","timeClass","redaction","followUp","noteCorrection"],
  reproducibility: ["runId","attemptId","eventIds","buildIdentity","dependencyVersions","environmentImage","region","device","browser","clock","zone","stateDigest","dataIdentity","generator","seed","cleanupProof","eventOrder","timing","concurrency","stubBehavior","exactInput","actualResult","timestamps","replayPacket","expectedNondeterminism","inconclusivePolicy"],
  oracle: ["oracleId","oracleType","oracleAuthority","oracleVersion","oracleInput","oracleRule","oracleMethod","oracleTolerance","oracleWindow","oracleIndependence","oracleFailure","oracleUnknown","oracleReview","oracleLimit"],
  coverage: ["coverageModelId","coverageType","coverageItemsDefined","denominator","eligible","touched","deep","blocked","excluded","exclusionReason","coverageSource","coverageWindow","coverageAge","coverageUnknown","coverageLimit","noCaseCountCoverage"],
  evidence: ["manifestId","subjectIdentity","runAttemptRefs","rawEvidence","provenance","capturedAt","collector","digest","freshnessRule","redaction","access","retention","integrity","missingEvidence","invalidEvidence","evidenceUnknown","evidenceCorrection","evidenceClaimLimit"],
  finding: ["findingId","observationRefs","expectedSource","actual","reproduction","impact","severityMethod","scope","confidence","alternatives","findingUnknown","triage","findingOwner","findingStatus","findingCorrection"],
  allocation: ["predefinedEvidence","adaptiveEvidence","automationUse","humanUse","sequencing","dependenciesBetweenApproaches","feedbackBudget","entry","allocationStop","gate","exception","allocationAuthority","allocationDissent","residualRiskInput","allocationReview"],
  conversion: ["conversionId","findingRef","candidateType","frequency","consequence","oracleStability","determinism","setupCost","dataCost","falseResultCost","maintenance","alternateControl","decision","conversionOwner","due","expiry","retirementCandidate","conversionReview"],
  automation: ["automatedCheckBoundary","automationQuestion","automationClaim","automationOracle","automationState","automationData","automationRunner","automationEnvironment","automationAttempts","automationEvidence","automationOwner","automationMaintenance","automationRetirement","automationLimit"],
  usability: ["expertObservation","notUserFinding","researchQuestion","participantCriteria","task","consent","analysis","sampleLimit","noUserRoleplay","noDisabilitySimulation","usabilityClaimLimit"],
  metrics: ["metricId","metricQuestion","definition","numerator","denominator","window","source","owner","limitation","guardrail","procedureStatus","charterCoverage","evidenceValidity","conversionClosure","feedbackLatency","maintenanceBurden","noDefectPerSessionTarget","noIndividualRanking","noMaturityRatio"],
  locale: ["utf8","rtl","ltr","bidi","zwnj","persianYeh","arabicYeh","persianKaf","arabicKaf","persianDigits","arabicDigits","latinDigits","irrCanonical","tomanLabel","utcInstant","ianaZone","jalaliPresentationOnly"],
  review: ["reviewId","plannedAt","heldAt","questionsAnswered","risksChanged","proceduresFit","chartersFit","coverageFit","oraclesFit","evidenceFit","blindSpots","burden","skillGap","toolGap","privacyIssue","safetyIssue","sideEffect","rebalanceDecision","actions","actionOwners","actionDue","reopen","reviewCorrection","reissue","affectedRecords"],
  limits: ["notDefectAbsenceProof","notCoverageAdequacyProof","notQualityProof","notSafetyProof","notComplianceProof","notReliabilityProof","notUsabilityProof","notReleaseProof","notApproachSuperiorityProof","notSkillProof","notProductivityProof","notCostSavingProof","notSuccessProof","notUniversalRatio","noRealTarget"]
};

const required = Object.entries(groups).flatMap(([g,xs]) => xs.map(x => `${g}.${x}`));
const supplied = new Set(fixture.controls || []);
const missing = required.filter(x => !supplied.has(x));
const superficial = fixture.superficial.length === 5
  ? "BALANCED_TEST_STRATEGY_HIGH_QUALITY_READY" : "INCOMPLETE";
console.log(superficial);
console.log(`HOLD-${missing.length}`);
console.log(new Set(required).size === required.length ? "UNIQUE" : "DUPLICATE");
console.log(fixture.realProductOrgTesterUserSystemPaymentOutcome === false
  ? "NO_REAL_TARGET_PASS" : "STOP_REAL_TARGET");

fixture.controls = [...required];
const remaining = required.filter(x => !new Set(fixture.controls).has(x));
console.log(remaining.length === 0
  ? "READY_FOR_TEST_APPROACH_ALLOCATION_REVIEW-0" : `HOLD-${remaining.length}`);

Checker سطحی ۱۰۰٪ Script pass، یک Session، regression خودکار، trace کامل و نبود Critical bug را می‌بیند و به‌اشتباه BALANCED_TEST_STRATEGY_HIGH_QUALITY_READY می‌دهد. اجرای مستقل دقیقاً ۴۰۸ کنترل یکتا را غایب یافت و HOLD-408 داد؛ آزمون جدا نیز با NO_REAL_TARGET_PASS نبود Product، سازمان، تستر، کاربر، سیستم، پرداخت یا Outcome واقعی را تأیید کرد. پس از pin شدن همه کنترل‌های خیالی، READY_FOR_TEST_APPROACH_ALLOCATION_REVIEW-0 فقط آمادگی fixture برای Review است.

ضدالگوهای انتخاب Approach

  • Scripted مساوی نظم/دقت/تکرار و Exploratory مساوی شهود/خلاقیت؛
  • دو قطب مخالف یا جنگ برای انتخاب برنده؛
  • سیستم حساس مساوی Script-only؛
  • Agile مساوی Exploratory و Waterfall مساوی Scripted؛
  • Feature جدید مساوی Exploration-only؛
  • Regression مساوی Procedure یا Automation-only؛
  • Manual و Scripted یا Automation و Exploration به عنوان مترادف؛
  • Test Case دقیق مساوی اجرای مشابه توسط هر فرد؛
  • واگذاری Script حساس به تازه‌کار بدون support؛
  • Explorer قهرمان با شهود منحصربه‌فرد؛
  • Ad hoc مساوی random/unprofessional بدون توصیف skill؛
  • هر Session دقیقاً ۹۰ دقیقه؛
  • یادداشت بعد از Session بدون timestamp/provenance؛
  • ضبط کامل صفحه/log بدون privacy و retention؛
  • Executed cases مساوی Test Coverage؛
  • Session/bug count مساوی Exploration coverage؛
  • Coverage percentage بدون model/denominator؛
  • Pesticide metaphor به جای freshness/retirement؛
  • Test pass مساوی Requirement درست؛
  • Usability نظر تستر مساوی User research؛
  • اول regression سپس exploration به عنوان ترتیب جهانی؛
  • هر finding مساوی regression automation candidate؛
  • Retry برای بازتولید بدون حفظ Attempt اول؛
  • Screenshot مساوی reproduction/evidence کافی؛
  • نسبت Exploratory/Scripted به عنوان maturity/KPI؛
  • تضمین کیفیت، پوشش، سرعت، هزینه یا موفقیت با ترکیب دو رویکرد.

چک‌لیست مالک Test Approach Allocation

  • AllocationID/version/status/owner/review/expiry ثبت شده است.
  • Product/Risk/Claim/Build/Environment/Data/Decision پین شده‌اند.
  • Evidence Question و Competing explanation/Unknown روشن‌اند.
  • عدم‌قطعیت Problem/Rule/System/Test/Change/Evidence/Outcome بررسی شده است.
  • Consequence/Exposure/Reversibility/Recovery و Risk owner مشخص‌اند.
  • Mission/Model/Data/Sequence/Oracle/Tool/Stop freedom آگاهانه تخصیص یافته است.
  • Procedure purpose/state/data/cleanup/oracle/tolerance/attempt دارد.
  • سطح جزئیات Script با skill/risk/change/maintenance متناسب است.
  • Charter mission/target/resources/question/model/coverage/oracle دارد.
  • Safety/Privacy/No-production-write و Re-charter trigger روشن‌اند.
  • Timebox Contextual است و KPI محسوب نمی‌شود.
  • Session note timestamp/thread/action/observation/evidence/unknown دارد.
  • Debrief Coverage/Finding/Unknown/Decision/next action را جدا می‌کند.
  • Reproduction به Build/State/Data/Event/Attempt/Oracle وصل است.
  • اولین Attempt و expected nondeterminism حفظ می‌شوند.
  • Coverage model/denominator/exclusion/age/limit ثبت شده است.
  • Executed cases یا Session count به Quality تبدیل نشده است.
  • Executor capability/support/escalation و Pairing بررسی شده‌اند.
  • Exploration به قهرمان یا حافظه یک فرد وابسته نیست.
  • Regression Portfolio لایه‌های ثابت، تطبیقی، تخصصی و Production دارد.
  • Usability/Accessibility research با Expert input یکی نشده است.
  • Automation محور مستقل و قرارداد Check جدا دارد.
  • Approach sequencing براساس dependency و feedback طراحی شده است.
  • Finding conversion دارای economics/owner/expiry/retirement است.
  • Metricها سؤال/تعریف/مخرج/window/guardrail دارند.
  • هیچ defect/session یا people ranking target وجود ندارد.
  • Review blind spot/burden/skill/tool/privacy/safety را می‌بیند.
  • Rebalance/Correction/Reissue/Affected records فعال‌اند.

Pilot سی‌روزه بدون سیستم یا تست واقعی

هفته اول واژگان، Question، Risk و Degree-of-freedom را روی fixture خیالی تمرین کنید. هفته دوم یک Procedure و یک Charter برای همان Risk بسازید. هفته سوم Session/Debrief/Reproduction/Coverage/Conversion را tabletop کنید. هفته چهارم Portfolio را با تغییر Build و Risk rebalance و validator را اجرا کنید.

  • روز ۱–۵: پنج سؤال را از دوگانه Approach به Evidence question تبدیل کنید.
  • روز ۶–۱۰: آزادی‌ها، Oracle، Data، Stop و Claim limit را تخصیص دهید.
  • روز ۱۱–۱۵: Procedure و Charter را با Build/State خیالی اجرا کنید.
  • روز ۱۶–۲۰: notes/debrief/replay/coverage و Unknown را مستقل ممیزی کنید.
  • روز ۲۱–۲۵: سه Finding را به Check/Monitor/Charter/No-conversion route کنید.
  • روز ۲۶–۳۰: Risk یا Artifact را تغییر دهید و freshness/rebalance/correction را ببندید.

جمع‌بندی

تست اکتشافی و اسکریپت‌محور دو شخصیت «خلاق» و «منظم» نیستند. هر فعالیت تست مقدار مشخصی از تصمیم‌های پیشینی و تصمیم‌های تطبیقی دارد. سؤال حرفه‌ای این است که کدام آزادی، در کجا، برای چه Risk و با چه Evidence در اختیار چه Capability قرار گیرد.

Procedure پایدار Known claim را سریع و قابل بازبینی بررسی می‌کند؛ Exploration مدل و Unknown را گسترش می‌دهد؛ ابزار اجرای هر دو را تقویت می‌کند؛ و یافته‌ها در صورت ارزش به check، monitor، control یا سؤال بعدی تبدیل می‌شوند. این Portfolio عدم‌قطعیت را مدیریت می‌کند، اما نبود defect، کفایت پوشش یا کیفیت محصول را تضمین نمی‌کند.

سؤالات متداول درباره تست اکتشافی و اسکریپت‌محور

تفاوت اصلی Exploratory و Scripted Testing چیست؟

در Exploration، یادگیری حین اجرا بر طراحی و انتخاب Test بعدی اثر مستقیم دارد؛ در روش ازپیش‌تعریف‌شده، بخش بیشتری از procedure/data/sequence/oracle پیش از اجرا ثبت شده است. هر دو می‌توانند ساختاریافته، مستند، انسانی یا ابزارپشتیبان باشند و در یک فعالیت ترکیب شوند.

برای Agile کدام رویکرد بهتر است؟

Agile به‌تنهایی پاسخ نمی‌دهد. Feedback سریع، تغییر، Risk، Build availability، Oracle و تصمیم مهم‌اند. یک تیم می‌تواند checks سریع در CI، examples در refinement، Exploration روی Feature و guardrail در Production داشته باشد. نسبت ثابت یا Approach اختصاصی Agile وجود ندارد.

آیا تست اکتشافی بدون مستندات است؟

خیر. سطح Documentation به Risk و Evidence need بستگی دارد. Charter، model، coverage items، یادداشت زمان‌دار، Evidence manifest، Finding، Unknown و Debrief می‌توانند دقیق باشند. هدف ثبت اطلاعات لازم برای تصمیم و پیگیری است، نه تولید سند حجیم یا ضبط بی‌حد.

آیا تست خودکار همیشه Scripted Testing است؟

یک Automated Check معمولاً Claim/Stimulus/Oracle ازپیش‌تعریف‌شده دارد، اما Automation می‌تواند در Exploration برای generation، query، fault injection، capture و تحلیل به کار رود و انتخاب مسیر توسط انسان تطبیق یابد. Automated/Manual و Predefined/Adaptive دو محور متفاوت‌اند.

برای سیستم پرریسک فقط Test Case دقیق کافی است؟

خیر. Test Case می‌تواند برای obligation و regression شناخته‌شده لازم باشد، اما کفایت آن به Risk coverage، Source/Oracle، Build/State/Data، independence، Evidence و freshness بستگی دارد. Exploration، hazard analysis، specialty testing و Production control نیز ممکن است لازم باشند؛ تصمیم با authority واجد صلاحیت است.

محمد عسکری

محمد هستم، توسعه‌دهنده وب با بیش از ده سال تجربه در برنامه‌نویسی سمت سرور و کاربر. به یادگیری و اشتراک‌گذاری دانش علاقه‌مندم و اخیراً تمرکزم را روی حوزه تست نرم‌افزار گذاشته‌ام تا تجربیاتم را در این زمینه نیز به اشتراک بگذارم و به درک بهتر کیفیت نرم‌افزار کمک کنم.

دیدگاهتان را بنویسید