داشبورد تیم برای هر چهار ستون Unit، Integration، System و UAT عدد ۱۰۰٪ و چراغ سبز نشان میدهد. بااینحال Callback تکراری در Checkout مصنوعی، Ledger را دوبار تغییر میدهد. مشکل «نبودن یک Level» نیست؛ هیچیک از Testها سؤال درست را روی Boundary و Fidelity لازم، با Oracle و Evidence همBuild، نپرسیدهاند.
این راهنما سطوح تست نرمافزار را از یک چکلیست چهارخانه به Test Level Allocation Contract تبدیل میکند: Risk/Question → Observation need → Test object/Boundary → Level → Method/Environment/Data/Oracle → Evidence → Gap/Disposition. هدف اجرای اجباری همهٔ Levelها نیست؛ هدف این است که هر سؤال مهم در نزدیکترین نقطهٔ توانمند و با Observation نمایندهٔ کافی پاسخ بگیرد.
خلاصه اجرایی: Level را از Test Object انتخاب کنید
- Test level گروهی از فعالیتهاست که بر Test object و هدف مشخص متمرکز است؛ فقط مرحلهٔ تقویمی یا نوع ابزار نیست.
- Component، Component Integration، System، System Integration و Acceptance Boundaryهای متفاوتی میبینند؛ هیچکدام بهتنهایی کیفیت را اثبات نمیکنند.
- Test type مانند Functional، Performance یا Security با Level فرق دارد و میتواند در چند Level اجرا شود.
- Test Pyramid مدل Portfolio اتوماسیون است، نه مترادف رسمی Test levels و نه نسبت جهانی Unit/Integration/E2E.
- «همهٔ Levelها سبز» بدون Question registry، Object identity، Fidelity و Evidence ادعای کفایت نیست.
- Gap را بر اساس Observation گمشده طبقهبندی کنید؛ حذف یک Label همیشه حذف Testing نیست.
- هر Exclusion/Compensation باید Risk، Authority، Evidence، Expiry و Review داشته باشد.
هدف جستوجو و مرز این مقاله
Intent اصلی اطلاعاتی و اجرایی است: «سطوح تست نرمافزار چیست؟»، «تفاوت Unit، Integration، System و UAT چیست؟»، «آیا میتوان یک Level را حذف کرد؟» و «چطور سبد Test level را بر اساس ریسک انتخاب کنیم؟». این مقاله مالک تصمیم تخصیص سؤال به Level و مدیریت Gap است.
برای طراحی نسبت و سبد اتوماسیون به هرم تست در عمل، برای جزئیات Integration Testing، System Testing و UAT مراجعه کنید. این صفحه تعاریف آنها را تکرار نمیکند؛ Allocation و Evidence gap میان آنها را عملی میکند.
سطح تست چیست؟ تعریف مبتنی بر Test Object
در ISTQB CTFL 4.0.1، Test level نمونهای مشخص از Test process است که با Test object مرتبط میشود. Levelها با ویژگیهایی مثل Object، Objective، Test basis، Defect/Failureهای معمول، Approach و مسئولیتها توصیف میشوند. همین تعریف مانع میشود Level را فقط «قبل/بعد» یا «دستی/خودکار» بدانیم.
| Level | Test object نمونه | Observation اصلی نمونه |
|---|---|---|
| Component | تابع، Class، Module، data conversion | رفتار و Quality جزء در isolation کنترلشده |
| Component Integration | رابط میان Componentها | قرارداد، داده، state و error propagation |
| System | سیستم کامل یا محصول یکپارچه | رفتار End-to-end در Boundary سیستم |
| System Integration | رابط سیستم با سیستم/سرویس بیرونی | protocol، mapping، retry، failure semantics |
| Acceptance | سیستم/محصول در Context پذیرش | نیاز، workflow، readiness یا تعهد تعریفشده |
نام دقیق و Boundary به معماری وابسته است. آنچه در Monolith یک Component است ممکن است در اکوسیستم Microservice یک System باشد. Level را از Object و رابطهاش با محیط تعریف کنید، نه از نام Folder یا Job.
Test Level با Test Type، Technique، Layer و Stage فرق دارد
| مفهوم | پرسش | نمونه |
|---|---|---|
| Level | کدام Test object/Boundary؟ | Component Integration |
| Type | کدام Quality characteristic/هدف؟ | Functional، Performance، Security |
| Technique | Test condition/case چگونه مشتق شود؟ | BVA، Decision table، State transition |
| Layer | کدام Interface فنی را مصرف میکنیم؟ | function، API، UI، protocol |
| Stage | چه زمانی در Flow اجرا میشود؟ | PR، nightly، pre-release، Production observation |
| Method | چطور Observation تولید میشود؟ | review، simulation، automation، exploration |
یک Security question میتواند در Component با static/property checks، در System Integration با protocol tests و در Acceptance با policy evidence بررسی شود. «Security فقط System level است» یا «Manual یعنی Acceptance» طبقهبندی غلط است.
Test Level با Test Pyramid یکی نیست
Test Pyramid مارتین فاولر راهی برای فکرکردن به سبد Testهای خودکار و نسبت بیشتر Testهای کمسطح به Broad-stack است؛ خود مقاله نیز تفاوت تعریفها و استثناهای هزینه/سرعت/پایداری را میپذیرد. Pyramid، UAT را «قلهٔ رسمی» معرفی نمیکند و Level taxonomy را جایگزین نمیسازد.
| Test Level | Test Pyramid |
|---|---|
| تمرکز بر Object، Boundary و Objective | تمرکز بر Portfolio و هزینهٔ Feedback خودکار |
| شامل Acceptance و System Integration | معمولاً Unit/Service/UI یا Low/Broad stack |
| برای Manual/Automated قابلاستفاده | عمدتاً مدل Automation portfolio |
| نسبت عددی تجویز نمیکند | شکل جهتدهنده است، نه درصد جهانی |
Component Testing چه چیزی را میبیند؟
Component level برای مشاهدهٔ رفتار Object کوچکتر و Feedback نزدیک مفید است. Isolation میتواند علت Failure را محدود کند، اما Mock یا Fake ممکن است رفتار واقعی Dependency را حذف کند. Ownership نیز Contextual است؛ Author، Peer، Tester یا ابزار میتوانند مشارکت کنند و «همیشه فقط Developer» قاعدهٔ Level نیست.
- خوب میبیند: boundary logic، state transition داخلی، error branch، property و invariant.
- کمتر میبیند: serialization واقعی، شبکه، deployment، configuration drift و emergent behavior.
- ریسک False confidence: Mock با contract متفاوت، Oracle سطحی، تست implementation بهجای behavior.
Component Integration؛ قرارداد واقعی بین جزءها
این Level تعامل میان Componentها در Boundary تعریفشده را هدف میگیرد: data shape، call sequence، transaction، timeout، error mapping و shared state. لازم نیست همهٔ Componentها ابتدا «کاملاً تستشده» باشند؛ Strategy ممکن است incremental، feature-slice یا risk-first باشد. اما Object/version و Stub fidelity باید روشن باشند.
System Testing؛ رفتار سیستم در Boundary خودش
System level رفتار و قابلیتهای سیستم کامل را در برابر Test basis مناسب میبیند. Functional و برخی Non-functional types ممکناند، اما «System testing همهٔ Security/Performance/Reliability را کامل پوشش میدهد» ادعای نامعتبر است. برخی Characteristics به Specialist environment، Production-like load یا evidence بیرون از یک System run نیاز دارند.
System Integration؛ مرزی که اغلب در E2E گم میشود
System Integration روی تعامل سیستم با سرویسها، Providerها، سختافزار یا اکوسیستم بیرونی تمرکز دارد. یک E2E happy path ممکن است این Level را لمس کند، اما retry، partial failure، version skew، clock، rate limit و protocol semantics را الزاماً پوشش نمیدهد.
| Boundary question | Observation لازم | خطر Fake |
|---|---|---|
| Timeout before/after commit | side effect + response ambiguity | Fake atomic رفتار کند |
| Duplicate callback | idempotency across systems | Stub فقط یک Callback بدهد |
| Version skew | old/new contract combinations | همه روی latest باشند |
| Retry/rate limit | backoff و quota behavior | unlimited provider |
| Clock/timezone | cutoff و expiry بین سیستمها | shared fixed clock |
Acceptance Testing؛ پذیرش کدام نیاز و توسط چه Authority؟
Acceptance level دربارهٔ Validation و پذیرش در Context تعریفشده است. UAT تنها شکل آن نیست؛ operational، contractual/regulatory، alpha/beta یا factory/site acceptance ممکناند. UAT الزاماً آخرین مرحله، با کاربر واقعی، در محیط واقعی یا معادل Release sign-off نیست. جزئیات در راهنمای UAT آمده است.
| Acceptance context | Authority/Evidence نمونه | Claim limit |
|---|---|---|
| User acceptance | representative workflow و business authority | نیازهای ثبتشده، نه market fit |
| Operational acceptance | runbook، monitoring، backup/restore | readiness محدود، نه zero incident |
| Contractual | Clause و evidence rule | همان Scope قرارداد |
| Regulatory | applicable requirement و authorized review | نه Compliance کلی بدون Scope |
| Alpha/Beta | bounded participants و observation | یادگیری، نه کیفیت تضمینی |
Level Allocation Model؛ قرارداد مرکزی
levelAllocationModel: id: LAM-CHECKOUT-28 version: 5 purpose: "تخصیص Quality Question به Object/Boundary توانمند" decision: "ساخت/تغییر/حذف Allocation؛ نه Release verdict" scope: SYN-CHECKOUT@CUT-28 levelTaxonomy: LEVEL-TAX-v4 objectTaxonomy: OBJECT-TAX-v3 claimLimit: "ساختار Observation portfolio؛ نه کفایت یا کیفیت" owner: test-strategy-owner unknowns: [real-provider-fidelity] status: READY_FOR_LEVEL_ALLOCATION_REVIEW
گام اول: از Risk به Quality Question برسید
Level را از روی عادت انتخاب نکنید. ابتدا Risk/Goal/Basis را به سؤال قابلمشاهده تبدیل کنید. تست مبتنی بر ریسک مالک Risk model است؛ اینجا خروجی آن مدل به Observation need تخصیص مییابد.
qualityQuestion: id: Q-IDEMP-28 version: 3 riskId: RISK-IDEMP-9 testBasisRef: BASIS-CALLBACK-v8 qualityCharacteristic: functional-correctness-and-recoverability claim: "هر Callback معتبر حداکثر یک Ledger effect دارد" observationNeed: "state before/after duplicate, late and reordered Callback" requiredFidelity: real-serialization-plus-transaction-boundary requiredIndependence: peer-plus-specialist-review requiredConfig: CONFIG-SYN-28 requiredData: DATA-SYN-28 requiredOracle: ORACLE-IDEMP-v8 deadline: before-release-candidate-review criticality: HIGH ownerCapability: stateful-test-analysis status: ACTIVE
گام دوم: Test Object و Boundary را رسم کنید
| Object ID | داخل Boundary | بیرون/جایگزینشده | Level candidate |
|---|---|---|---|
| OBJ-IDEMP-FN | idempotency function/state model | DB/queue/provider | Component |
| OBJ-CALLBACK-DB | handler + repository + DB | provider/network | Component Integration |
| OBJ-CHECKOUT-SYS | Checkout deployable system | PSP Stub | System |
| OBJ-CHECKOUT-PSP | Checkout + provider boundary | other ecosystem | System Integration |
| OBJ-OPS-WORKFLOW | deploy/observe/reconcile/restore | unscoped organization | Operational Acceptance |
عبارت «E2E» Boundary را توضیح نمیدهد. باید بدانیم کدام Processها واقعیاند، کدام Stub، کدام Queue/DB مشترک، کدام Identity و چه External effectی مشاهده میشود.
گام سوم: Fidelity و Independence را تعیین کنید
Level بالا خودکار Fidelity بالا نمیسازد و Level پایین الزاماً غیرنماینده نیست. Fidelity ابعادی است: protocol، data distribution، timing، concurrency، topology، dependency behavior و observability. Independence نیز جداست: Author، Peer، Specialist، organizational یا external.
| بعد Fidelity | سؤال | Evidence |
|---|---|---|
| Protocol | serialization/error code واقعی است؟ | contract/trace |
| State | transaction و persistence نمایندهاند؟ | before/after state |
| Timing | timeout/retry/clock کنترل شدهاند؟ | timeline |
| Concurrency | interleaving و race قابلمشاهدهاند؟ | schedule/trace |
| Data | boundary/locale/relation شکل درست دارند؟ | data pack manifest |
| Topology | network/process/container مشابه نیاز است؟ | environment manifest |
| Dependency | Fake کدام رفتار را ندارد؟ | fidelity limitation |
گام چهارم: Allocation Record بسازید
allocation: id: ALLOC-IDEMP-28 version: 4 questionId: Q-IDEMP-28 testObjectId: OBJ-CALLBACK-28 testObjectVersion: 7 level: COMPONENT_INTEGRATION boundary: callback-handler+repository+fake-ledger-db interfaces: [callback-http, ledger-repository] dependencies: [PSP-STUB-v8] method: state-transition-plus-duplicate-injection environmentId: ENV-SYN-28 dataPackId: DATA-SYN-28 oracleId: ORACLE-IDEMP-v8 executorCapability: integration-test-engineering independenceLevel: peer-reviewed evidenceRule: same-build-state-manifest freshnessRule: current-change-only resultVocabulary: [PASS, FAIL, ERROR, INCONCLUSIVE] failureOutcome: finding-plus-attribution feedbackTarget: under-8m maintenanceOwner: checkout-capability lifecycleStatus: PILOT rationale: "اولین Boundary دارای transaction واقعی و کنترلشده"
یک سؤال میتواند چند Allocation مکمل داشته باشد
| Allocation | چیزی که میبیند | چیزی که نمیبیند |
|---|---|---|
| Component property | invariant در state model | DB transaction/protocol |
| Component Integration | handler+repository atomicity | provider reordering واقعی |
| System Integration | retry/callback protocol | Production distribution |
| Operational Acceptance | reconcile/restore workflow | absence of future incidents |
تکرار دقیق یک سؤال در همهٔ Levelها اتلاف است. هر Allocation باید Observation افزوده، زمان Feedback یا استقلال متفاوتی داشته باشد؛ وگرنه Candidate ادغام یا Retirement است.
Gap Taxonomy؛ «Level نداریم» تشخیص کافی نیست
| Gap | نشانه | گزینه |
|---|---|---|
| QUESTION_GAP | Risk به سؤال تبدیل نشده | analysis/model |
| OBJECT_GAP | Object/Boundary نامعلوم | architecture map |
| INTERFACE_GAP | تعامل مهم خارج Observation | integration allocation |
| FIDELITY_GAP | Fake رفتار لازم را ندارد | contract/representative test |
| CONFIG_GAP | Config tuple مهم نیست | matrix allocation |
| DATA_GAP | State/locale/boundary غایب | data pack |
| ORACLE_GAP | Reach هست، Verdict معتبر نیست | oracle repair |
| INDEPENDENCE_GAP | Bias کنترل نشده | peer/specialist review |
| TIMING_GAP | Feedback خیلی دیر یا زودِ غیرنماینده | split allocations |
| EVIDENCE_GAP | نتیجه به Subject متصل نیست | manifest |
| MAINTENANCE_GAP | Allocation Stale/بیOwner | repair/retire |
Gap Record؛ تصمیم حذف یا جبران را ثبت کنید
gap: id: GAP-PROVIDER-FIDELITY-28 questionId: Q-IDEMP-28 type: FIDELITY_GAP missingObservation: real-provider-reordering reason: no-authorized-representative-sandbox riskImpact: callback-order-unknown currentEvidence: EVID-COMPINT-28 compensatingEvidence: EVID-RECON-28 options: [contract-simulator, provider-sandbox, production-monitor] decisionAuthority: risk-owner disposition: COMPENSATE owner: integration-capability dueAt: 2026-08-20T12:00:00Z expiry: 2026-09-13T00:00:00Z reviewDue: 2026-08-27T00:00:00Z status: ACTIVE
Dispositionهای Gap
- ADD: Allocation جدید ارزش Observation دارد.
- MOVE: سؤال در Boundary دیگری توانمندتر/سریعتر است.
- SPLIT: Feedback زود و Evidence نماینده به دو Allocation تقسیم میشوند.
- STRENGTHEN: Method/Data/Oracle/Fidelity موجود اصلاح میشود.
- COMPENSATE: Control/Evidence جایگزین زماندار است.
- ACCEPT: Authority، Risk باقیمانده را با Expiry میپذیرد.
- REMOVE: سؤال/Object دیگر معتبر نیست؛ Impact بررسی شده است.
- INVESTIGATE: اطلاعات برای Allocation کافی نیست.
Evidence Manifest؛ سبزی Level را به Subject وصل کنید
evidenceManifest: id: EVID-ALLOC-28 questionId: Q-IDEMP-28 allocationId: ALLOC-IDEMP-28 subjectId: checkout-api@C28 buildId: BUILD-SYN-28 testObjectId: OBJ-CALLBACK-28 environmentId: ENV-SYN-28 dataPackId: DATA-SYN-28 methodVersion: stateful-callback/v8 oracleId: ORACLE-IDEMP-v8 artifact: artifacts/RUN-28/result.json digest: sha256:... startedAt: 2026-08-13T11:00:00Z finishedAt: 2026-08-13T11:08:00Z producer: pipeline/SYN-28 reviewer: peer-reviewer unknowns: [provider-reordering] redaction: synthetic-only retention: 90d status: VALID_PASS
PASS فقط Claim همان Allocation را پشتیبانی میکند. Evidence Component Integration را نمیتوان به System Integration یا UAT تعمیم داد. برای اندازهگیری Coverage چندبعدی و Evidence state، راهنمای پوشش تست نرمافزار را ببینید.
آیا میتوان یک Level را حذف کرد؟
بله، اگر هیچ Question واجد شرایطی Observation منحصربهفرد آن Boundary را نیاز نداشته باشد، یا Observation با Evidence معتبر در Allocation دیگری فراهم شود. اما تصمیم «Unit نداریم» یا «UAT حذف شد» بدون Registry سؤال و Gap analysis قابلدفاع نیست.
| پرسش حذف/ادغام | Evidence لازم |
|---|---|
| چه Questionهایی به این Allocation وصلاند؟ | Question registry |
| Observation منحصربهفرد چیست؟ | Object/Boundary/Fidelity map |
| جایگزین همان Claim را پشتیبانی میکند؟ | same-question evidence |
| Feedback/independence چه تغییری میکند؟ | baseline و trial |
| چه Risk/Unknown باقی میماند؟ | gap disposition/authority |
| اگر اشتباه بود، rollback چیست؟ | prospective change plan |
«همه Levelها» نیز میتواند Portfolio بدی باشد
تستهای تکراری با Oracle یکسان، Suite کند، Environment شکننده و Maintenance بیOwner میتوانند چهار چراغ سبز بسازند و هیچ Observation تازهای ندهند. بهجای شمارش Level، Marginal evidence، Feedback age، Failure attribution، cost و lifetime را بسنجید.
Change Impact؛ Allocation ثابت نمیماند
- تغییر Boundary/Architecture ممکن است Level یا Object را عوض کند.
- تغییر Contract/Provider، Fidelity Gap جدید میسازد.
- تغییر Risk/Basis، Question را اضافه یا retire میکند.
- تغییر Environment/Data/Oracle ممکن است Evidence قبلی را Stale کند.
- تغییر Owner/Tool/Cost، قابلیت نگهداشت را عوض میکند.
Feedback زود در برابر Evidence نماینده
قانون «همیشه پایینترین Level» کافی نیست. اول earliest capable observation را پیدا کنید، سپس اگر Fidelity یا Independence کافی نیست Countercheck نمایندهتر بسازید. Component property در چند ثانیه و System Integration در زمان بیشتر میتوانند یک سؤال را از دو زاویه پشتیبانی کنند؛ یکی جای دیگری نیست.
Cost model؛ قیمت Run فقط بخشی از هزینه است
| هزینه | نمونه | Measure |
|---|---|---|
| Build | طراحی Harness/Oracle/Data | initial effort |
| Run | compute، environment، license | cost/run |
| Feedback | wait و queue | p50/p95 age |
| Diagnosis | trace/attribution | time-to-classify |
| Maintenance | change repair/flakiness | hours/window |
| Opportunity | سؤالهای مهمی که اجرا نشدند | critical gap age |
| Failure cost | واقعی و Contextual | incident/rework data |
قاعدهٔ ۱–۱۰–۱۰۰–۱۰۰۰ یا رشد نمایی هزینه، قانون عمومی نیست. هزینهٔ واقعی به architecture، observability، deployment، blast radius، repair و exposure بستگی دارد. دادهٔ خود سیستم را Baseline کنید؛ عددهای داستانی را ROI ننامید.
Correction؛ اگر Level label یا Evidence اشتباه بود
correction: id: CORR-LEVEL-28 detectedAt: 2026-08-13T13:00:00Z cause: "Test mocked DB داشت اما Component Integration گزارش شده بود" invalidAllocation: ALLOC-IDEMP-28@v3 invalidEvidence: EVID-ALLOC-28@v3 affectedClaims: [COV-Q-IDEMP-28, RELEASE-EVID-28] containment: "Evidence INVALID و Decision downstream متوقف" correctedAllocation: ALLOC-IDEMP-28@v4/COMPONENT newGap: GAP-TRANSACTION-28 revalidation: RUN-28R1 republishStatus: COMPLETE status: CLOSED
آزمایشگاه مصنوعی Checkout فارسی
تمام مثالها در `SYN-CHECKOUT` جدا و جعلیاند: Order، PaymentAttempt، PSP Stub، Callback، Ledger و Reconciliation مصنوعی؛ timeout قبل/بعد از fake commit و Callback تکراری/دیر/جابجا. هیچ شبکه، Production، شرکت، تیم، کاربر، پرداخت، بانک یا PSP واقعی وجود ندارد.
| Question | Allocation زود | Allocation نمایندهتر |
|---|---|---|
| IRR/toman conversion | Component property | System UI/API display |
| Persian/Arabic/Latin digits | parser component | System locale journey |
| Unicode/RTL | normalizer component | browser/render system |
| UTC/Tehran/Jalali | time conversion | cross-system cutoff |
| Duplicate Callback | state property | DB/provider boundaries |
| Reconciliation | ledger component | operational acceptance drill |
IRR canonical و تومان فقط نمایشی و برچسبدار است؛ ارقام فارسی/عربی/لاتین، Unicode NFC، RTL/LTR stable ID، UTC، Asia/Tehran و جلالی صرفاً نمایشیاند. هیچ نام، موبایل، ایمیل، IP، حساب، PAN، CVV2، OTP، Cookie، Token، Credential، Screenshot یا Log واقعی و هیچ ادعای بانکی/مالی/حقوقی/مالیاتی/امنیتی/حریم خصوصی/انطباق دربارهٔ ایران وجود ندارد.
آزمایش اجرایی SYN-TEST-LEVEL-ALLOCATION-GAP-۰۱
یک Validator مستقل، قطعی و بدون dependency با Node.js v26.۷.۰ اجرا شد. Dashboard سطحی Unit، Integration، System و UAT را هرکدام ۱۰۰٪ و سبز نشان میداد و PASS میداد. ممیزی قرارداد ۱۶۷ قاعده داشت.
| گروه | تعداد | نمونه کنترل |
|---|---|---|
| Identity | ۱۶ | Product، Risk، Strategy، Basis، Architecture، Build، Cutoff |
| Model | ۱۴ | Purpose، Decision، Scope، taxonomies، limit، Unknown |
| Question | ۱۶ | Risk/Basis، Claim، Observation، Fidelity، Independence، Oracle |
| Allocation | ۲۴ | Object/Boundary/Level، Method، Config/Data، Evidence، Cost |
| Gap | ۱۶ | type، missing observation، impact، options، authority، expiry |
| Evidence | ۲۰ | Question/Allocation/Object/Build، Method/Oracle، Artifact/digest |
| Governance | ۱۸ | Coverage/Critical rule، exception، change، maintenance، Correction |
| ادعاهای ممنوع | ۳۶ | چهار-Level اجباری، Pyramid/role/type universals، guarantees |
| روابط بینفیلدی | ۷ | Question/Allocation/Evidence/Build/Object/Gap/Compensation |
نسخهٔ سطحی با ۱۶۰ Finding به HOLD رفت: همهٔ ۱۲۴ فیلد قرارداد و ۳۶ ادعای ممنوع Fail شدند. هفت رابطهٔ بینفیلدی بهدلیل نبود فیلدها یا شرط Compensation فعال نشدند؛ شمارش برای قرمزکردن همهٔ Rules دستکاری نشد.
fixture: SYN-TEST-LEVEL-ALLOCATION-GAP-01 rules: 167 superficial dashboard: Unit: 100% Integration: 100% System: 100% UAT: 100% allLevelsGreen: true dashboardVerdict: PASS contractStatus: HOLD findings: 160 corrected model: question: Q-IDEMP-28 allocation: ALLOC-IDEMP-28 object: OBJ-CALLBACK-28 build: BUILD-SYN-28 gapDisposition: COMPENSATE compensatingEvidence: EVID-RECON-28 structuralFindings: 0 status: READY_FOR_LEVEL_ALLOCATION_REVIEW
نسخهٔ اصلاحشده Question، Test Object/Boundary، Level، Fidelity، Method/Environment/Data/Oracle، independence، same-Build Evidence، Gap/Compensation و Governance را کامل کرد و با صفر Finding به `READY_FOR_LEVEL_ALLOCATION_REVIEW` رسید. این وضعیت عمداً صدق Source/Evidence، کفایت سؤال/Allocation، absence of defects، Product quality، Security، market fit یا Release readiness را اثبات نمیکند.
شاخصهای Allocation؛ تعداد Test و Level کافی نیست
| Measure | Countermeasure | خطر |
|---|---|---|
| Active-question allocation coverage | Evidence validity | Mapping تزئینی |
| Critical gap age | Risk/complexity mix | عدد Aggregate شکاف مهم را پنهان کند |
| Feedback age | Fidelity scorecard | سریع ولی غیرنماینده |
| Fidelity gap count | cost/availability | هر Fidelity بیشتر ارزشمند نیست |
| Failure attribution time | Oracle/trace completeness | تشخیص سریعِ غلط |
| Duplicate observation rate | independence/marginal evidence | ادغام بیشازحد |
| Maintenance age/cost | escaped-risk sample | حذف Test برای کاهش هزینه |
| Compensation expiry | compensating evidence freshness | Exception دائمی |
| Correction closure | affected-claim completeness | Close اداری |
Automation و AI در Level Allocation
Automation میتواند Object graph، Question mapping، stale allocation، Evidence binding، Gap age و duplicate observation را بررسی کند. AI میتواند Candidate Level/Boundary یا Gap پیشنهاد دهد؛ اما معماری، Fidelity، استقلال، Risk acceptance، Retirement یا Release را بدون Review تصمیم نگیرد.
- Source architecture/Basis و model/prompt نسخهدار باشند.
- پیشنهاد Level باید Object/Boundary/rationale و Unknown داشته باشد.
- AI label جای اجرای Representative trial را نگیرد.
- داده/کد حساس به سرویس تأییدنشده ارسال نشود.
- Authority انسانی و مسیر Correction/Appeal حفظ شود.
۳۶ ضدالگوی سطوح تست
| ضدالگو | خطر | اصلاح |
|---|---|---|
| همه پروژهها چهار Level | معماری/Context حذف | object taxonomy |
| همه Levelها همیشه لازم | هزینه/تکرار | question allocation |
| Levelها Phase متوالیاند | Feedback دیر | continuous allocation |
| Level=Pyramid | دو مدل مخلوط | separate portfolio |
| UAT قله Pyramid | taxonomy غلط | acceptance context |
| UAT همیشه آخر | Early validation حذف | purpose/timing |
| UAT فقط کاربر واقعی | Authority/representation مبهم | acceptance contract |
| UAT محیط واقعی | Safety/privacy | fidelity rationale |
| Unit فقط Developer | Role universal | capability |
| Unit همیشه سریع/ارزان/پایدار | Guarantee کاذب | measure |
| Integration بعد از Unit کامل | ترتیب اجباری | strategy |
| System همه NFRها | Specialized gaps | type allocations |
| Security فقط System | multi-level evidence حذف | question map |
| Performance فقط System | component/boundary signal حذف | layered evidence |
| Acceptance=market fit | Validation claim گسترده | claim limit |
| System test=brand protection | causality کاذب | bounded outcome |
| Skip Level=Defect | Gap/Outcome اختلاط | observation gap |
| Skip Level=Project failure | فاجعهسازی | risk decision |
| Level بیشتر=کیفیت بیشتر | duplicate evidence | marginal value |
| Test investment=Quality | Guarantee | evidence/limits |
| Testing=Security | Controlهای دیگر حذف | security program |
| Testing=Customer trust | Outcome causality | separate measures |
| ۱–۱۰–۱۰۰–۱۰۰۰ | عدد بیContext | actual cost baseline |
| هزینه همیشه نمایی | Architecture/repair حذف | measure distribution |
| Untested code=bad code | Coverage/quality اختلاط | risk evidence |
| No Unit=Technical debt | علت قطعی | debt evidence |
| Coverage=Confidence | Oracle/fidelity حذف | multi-signal |
| هر Risk در هر Level | تکرار اجباری | complementary allocation |
| Level name=Fidelity | Fake پنهان | fidelity dimensions |
| E2E=System | Boundary مبهم | object map |
| Mock=Unit | Tool defines level | object/boundary |
| Manual=Acceptance | Method defines level | separate method |
| Automation=Component | Method defines level | separate axes |
| Pyramid ratio جهانی | Goodhart | contextual portfolio |
| AI Level auto-approval | Architecture/Risk authority | human review |
| Remove Level=Remove Testing | label/object confusion | question impact |
چکلیست ممیزی Level Allocation
- Program/Product/Goal/Risk/Strategy/Basis نسخهدارند؟
- Architecture، Deployment، Environment و Data model قفلاند؟
- Repository، Commit، Build، Deployment و Cutoff مشخصاند؟
- Model ID/version، Purpose، Decision و Scope دارد؟
- Level/Object taxonomy تعریف شدهاند؟
- Claim limit و Unknownها حاضرند؟
- هر Question به Risk/Basis وصل است؟
- Quality characteristic و bounded Claim روشناند؟
- Observation need نوشته شده است؟
- Fidelity/Independence/Config/Data/Oracle requirements ثبتاند؟
- Criticality، deadline و Owner capability معلوماند؟
- Allocation ID/version و Question ID سازگارند؟
- Test Object/version و Boundary دقیقاند؟
- Interfaces و Dependencies آشکارند؟
- Level از Object انتخاب شده، نه ابزار/عنوان؟
- Method، Environment، Data و Oracle Pin شدهاند؟
- Executor capability و Independence level متناسباند؟
- Evidence/Freshness rule و Result vocabulary دارید؟
- Failure outcome، Cost و Feedback target مشخصاند؟
- Maintenance owner و Lifecycle status وجود دارند؟
- Rationale ارزش Observation را توضیح میدهد؟
- Gap بر اساس missing observation طبقهبندی شده؟
- Gap دارای Risk impact، options و Authority است؟
- Compensation دارای Evidence معتبر است؟
- Disposition، Owner، dueAt، expiry و reviewDue ثبتاند؟
- Manifest به Question/Allocation/Object/Build همان رکورد متصل است؟
- Artifact/digest/times/producer/reviewer حاضرند؟
- Unknown/redaction/retention/status معلوماند؟
- Critical-question rule Aggregate را کنترل میکند؟
- Change impact و Maintenance/Retirement rules فعالاند؟
- Correction affected claims و revalidation را پوشش میدهد؟
- Measureها Guardrail دارند و تیم/فرد را رتبهبندی نمیکنند؟
برنامه ۳۰ روزه برای بازطراحی سطوح تست
| بازه | کار | خروجی |
|---|---|---|
| روز ۱–۵ | یک Flow و ۱۰ Risk/Question را Baseline کنید | Question registry |
| روز ۶–۱۰ | Object/Boundary/Fidelity map بسازید | Taxonomy و current allocations |
| روز ۱۱–۱۵ | Gapها و duplicate Observationها را طبقهبندی کنید | Gap register |
| روز ۱۶–۲۰ | یک ADD/SPLIT/STRENGTHEN و یک Retirement Pilot کنید | Evidence/cost baseline |
| روز ۲۱–۲۵ | Compensation/Exception و Correction drill اجرا کنید | Affected-claim path |
| روز ۲۶–۳۰ | Measure/Guardrail و Portfolio را Review کنید | Keep/Adapt/Stop |
موفقیت Pilot «پنج Level کامل» یا تعداد Test بیشتر نیست. موفقیت یعنی Critical question بیObservation کمتر، Evidence به Object/Build درست متصل، Feedback و Fidelity متعادل، Gapها زماندار و Allocationهای تکراری/بیOwner قابلحذف شوند.
جمعبندی: Level را چک نکنید؛ Observation را طراحی کنید
نادیدهگرفتن Level بهخودیخود فاجعه نیست و اجرای همهٔ Levelها نیز موفقیت نیست. خطر واقعی، سؤال مهمی است که هیچ Test object/Boundary توانمندی آن را مشاهده نمیکند یا Evidence آن به Subject درست متصل نیست. Allocation Contract، Level را به Risk و Observation پیوند میدهد؛ Gap Record حذف/جبران را شفاف میکند؛ و Correction اجازه میدهد برچسب و Evidence غلط پیش از تصمیم اصلاح شوند.
سوالات متداول درباره سطوح تست نرمافزار
سطوح اصلی تست نرمافزار کداماند؟
در Taxonomy رایج ISTQB، Component، Component Integration، System، System Integration و Acceptance مطرحاند. هر Level با Test object و Objective تعریف میشود. معماری و Context تعیین میکنند Object دقیق چیست و کدام Levelها برای سؤالهای شما لازماند.
تفاوت Unit، Integration، System و UAT چیست؟
تفاوت اصلی Object/Boundary و Objective است: Unit/Component روی جزء، Integration روی تعامل، System روی سیستم کامل و UAT روی پذیرش نیاز/workflow تعریفشده تمرکز دارد. Method دستی/خودکار، Type و زمان اجرا این Levelها را بهتنهایی تعیین نمیکنند.
آیا همه پروژهها باید همه سطوح تست را داشته باشند؟
خیر. از Risk و Quality question شروع کنید و ببینید کدام Object/Boundary Observation منحصربهفرد میدهد. حذف یا ادغام Level باید با Question registry، Evidence جایگزین، Gap disposition، Authority و Expiry قابلدفاع باشد.
Test Pyramid چه تفاوتی با Test Levels دارد؟
Test Levels Taxonomy مبتنی بر Test object/Objective است؛ Test Pyramid مدل فکری برای سبد Testهای خودکار و Feedback/cost در Low versus Broad stack. Pyramid درصد جهانی نمیدهد و UAT یا System Integration را بهطور خودکار روی یک شکل ثابت قرار نمیدهد.
اگر یک Level را حذف کنیم حتماً باگ بیشتری میرسد؟
الزاماً نه. پیامد به سؤالهای متاثر، Observation جایگزین، Fidelity، Oracle، Independence و Risk بستگی دارد. بهجای پیشبینی قطعی، Trial قابلبازگشت اجرا کنید و Critical gap، escaped-risk sample، Feedback و Maintenance را با Guardrail بسنجید.
