تست انطباق؛ Requirement تا Conformance Claim

یک Test Suite سبز است، نام یک استاندارد روی صفحه محصول آمده و فایل PDF با عنوان «Certificate» وجود دارد. آیا می‌توان نوشت «محصول کاملاً منطبق، مورد تأیید، قابل‌همکاری و آماده ورود به همه بازارهاست»؟ نه. شاید ویرایش مرجع اشتباه باشد، Profile انتخابی معلوم نباشد، Requirementهای Optional به‌عنوان Mandatory شمرده شده باشند، چند مورد Applicable اصلاً تست نشده باشند یا صادرکننده اختیار صدور آن ادعا را نداشته باشد. این راهنما تست انطباق (Conformance Testing) را به یک Conformance Claim Record محدود، ردیابی‌پذیر و قابل‌اصلاح تبدیل می‌کند.

خلاصه اجرایی: از نام استاندارد تا ادعای محدود

Subject، Variant، Release، Hardware/Firmware/Software و Configuration را دقیق Pin کنید.
Reference باید Identifier، Edition، Amendment، Corrigendum، Language و تاریخ اثر داشته باشد.
Applicability را از متن Requirement جدا کنید؛ Standard همیشه الزام قانونی نیست.
Profile، Option، Extension، Role و Mode تعیین می‌کنند کدام Requirementها واقعاً اعمال می‌شوند.
هر Requirement باید Source locator، تفسیر، Test/Inspection/Evidence و Verdict داشته باشد.
مخرج Coverage شامل Passed، Failed، Inconclusive، Not tested، Excluded و Unknown است.
Testing، Inspection، Declaration، Certification و Accreditation نقش‌های متفاوت دارند.
Conformance pass به‌تنهایی Interoperability، کیفیت، امنیت، ایمنی یا مجوز بازار را ثابت نمی‌کند.

Conformance Testing چیست؟

تست انطباق بررسی می‌کند یک Implementation تحت شرایط و Scope مشخص، Requirementهای انتخاب‌شده از یک Specification یا سند Normative را برآورده می‌کند یا نه. پاسخ درباره همان Subject، Reference، Profile، Method و Evidence است؛ نه «درستی کلی محصول». Black-box رایج است، اما تنها روش نیست: برخی الزامات به Inspection، تحلیل Artifact، Measurement، Review یا شاهد فرایندی نیاز دارند.

Conformance Assessment از Testing گسترده‌تر است

ISO/CASCO ارزیابی انطباق را مجموعه تکنیک‌ها و فعالیت‌هایی برای نشان‌دادن برآورده‌شدن Requirementهای مشخص می‌داند. Testing می‌تواند یکی از فعالیت‌ها باشد؛ Inspection، Audit، Validation، Verification، Certification یا ترکیب آن‌ها نیز ممکن است در Scheme لازم شوند. یک Test report را بدون مبنا «Certificate» ننامید.

مرز این راهنما با صفحات نزدیک

۱۹۷۴ مالک Conformance Claim عمومی از Reference تا Verdict است. صفحه ادعای انطباق دسترس‌پذیری مالک WCAG/Accessibility scope؛ صفحه تعهد قانونی و Evidence مالک Clause-to-control و Legal applicability؛ و صفحه تست قابلیت همکاری مالک تعامل واقعی Implementationهای مستقل است. برای Coverage claim نیز راهنمای مخرج پوشش تست را ببینید.

Conformance Claim Record چیست؟

ConformanceClaimRecord {
  claim_id, subject_id, reference_set_id, applicability_id,
  profile_id, requirement_baseline_id, suite_id,
  environment_ids[], sample_ids[], execution_ids[],
  verdict_summary, coverage_denominator, deviations[],
  nonconformities[], evidence_ids[], issuer_role,
  scope, limitations[], validity, decision, correction_of
}

این رکورد به بازبین اجازه می‌دهد بپرسد چه چیزی، در برابر کدام متن، با چه انتخاب‌هایی، توسط چه کسی، با کدام روش و تا چه تاریخی ارزیابی شده است. ادعا باید نقل‌پذیر باشد، اما نباید از Scope شواهد بزرگ‌تر شود.

Subject را به Product family تقلیل ندهید

نام تجاری یا خانواده محصول ممکن است ده‌ها Variant داشته باشد. Model، Serial/Lot، Release، Hardware revision، Firmware/Software version، Build/Image digest، Configuration، Feature flag، Dependency، Schema و Labeling را ثبت کنید. نتیجه Variant A با Config X خودکار به Variant B یا Update بعدی منتقل نمی‌شود.

Reference set را با ویرایش کامل Pin کنید

نام «ISO»، «IEEE»، «RFC» یا «استاندارد ملی» کافی نیست. Publisher، Title، Identifier، Edition، Revision، Amendment، Corrigendum، Language، Publication/effective/withdrawal date و Source digest را نگه دارید. گاهی Scheme، Test specification و Interpretation bulletin نیز جزو Reference set هستند.

ReferenceSet {
  base: "STD-FAKE-7:2026",
  amendments: ["A1:2026"],
  corrigenda: ["C1:2026"],
  profile: "P-RETAIL-IR-v2",
  test_spec: "TS-FAKE-11-v4",
  interpretations: ["INT-03", "INT-09"],
  source_digest: "sha256:fictional"
}

Standard، Specification و Technical Regulation یکی نیستند

سند می‌تواند Standard داوطلبانه، Technical regulation اجباری، Contract specification، Procurement requirement، Consortium profile یا Internal policy باشد. در چارچوب توضیحی WTO TBT، Technical regulation اجباری و Standard داوطلبانه تفکیک می‌شوند؛ اما نتیجه حقوقی برای محصول/بازار شما به Jurisdiction، نقش، تاریخ و متن نافذ وابسته است. این مقاله مشاوره حقوقی نیست.

Applicability را به وکیل یا QA پنهان نسپارید

Applicability Record باید Jurisdiction/Market، Product class، Intended use، Actor role، Trigger، Effective period، Exemption، Transition و Authority تفسیر را ثبت کند. QA می‌تواند سؤال و Evidence بسازد؛ تصمیم حقوقی یا Regulator interpretation را جعل نمی‌کند. هر تغییر بازار یا Intended use می‌تواند Baseline را عوض کند.

Profile و Option مخرج Requirement را تغییر می‌دهند

استانداردهای فنی اغلب Role، Class، Level، Profile، Mode، Option، Extension و Parameter دارند. Implementation Conformance Statement یا Capability declaration باید انتخاب‌ها را قبل از تست تثبیت کند. انتخاب Option بعد از دیدن Fail، بدون Version/Reason، نتیجه را دست‌کاری می‌کند.

Normative و Informative را جدا کنید

همه متن یک سند Requirement نیست. Clauseهای Normative، Note/Example informative، Annexهای normative/informative و واژه‌نامه را برچسب بزنید. RFC ۸۱۷۴ معنای واژگان Requirement مانند MUST/SHOULD/MAY را در صورت استفاده طبق شرایط مشخص محدود می‌کند؛ متن رسمی RFC ۸۱۷۴ را به‌عنوان نمونه واژگان ببینید، نه قانون عمومی همه اسناد.

MUST، SHOULD و MAY را ساده‌سازی نکنید

نوع provision	کار ارزیابی	خطای رایج
Mandatory	در صورت Applicability باید Verdict داشته باشد	حذف به‌علت سختی تست
Conditional	شرط و Evidence فعال‌شدن ثبت شود	تبدیل به Optional
Recommended	معنای سند و Scheme بررسی شود	Pass/Fail خودکار
Optional feature	اگر Claim شده، Requirementهای وابسته فعال شوند	اعلام Feature بدون تست
Informative	زمینه/راهنما؛ نه مخرج الزام مگر Scheme بگوید	ساخت Requirement جعلی

Requirement را اتمی و قابل‌ردیابی کنید

یک بند ممکن است چند Subject، Condition، Action، Constraint، Outcome و Exception داشته باشد. آن را به RequirementIDهای پایدار خرد کنید، اما Source text digest و Locator را حفظ کنید. بازنویسی نباید معنای «اگر»، «مگر»، «حداقل»، «در بازه» یا «برای هر» را حذف کند.

Requirement {
  id: "REQ-7.3.2-C",
  source: "STD-FAKE-7:2026 §7.3.2 sentence 2",
  applies_if: "profile=P-RETAIL and mode=ASYNC",
  subject: "consumer",
  action: "reject unknown schema version",
  outcome: "no business side effect",
  exception: "declared compatibility adapter",
  interpretation_id: "INT-09"
}

ابهام را به Interpretation Record تبدیل کنید

«به‌موقع»، «مناسب»، «پشتیبانی»، «سازگار» یا ضمیر مبهم Oracle نمی‌سازد. سؤال، خوانش منتخب، Alternatives، Rationale، مرجع تصمیم، تاریخ، Requirement/Testهای متاثر و Expiry را ثبت کنید. تفسیر داخلی را به نام سازمان استاندارد منتشر نکنید.

Traceability matrix باید Gap را هم نشان دهد

برای هر Requirement، Applicability، Risk/Control، Test/Inspection/Analysis، Evidence، Finding و Decision را پیوند دهید. سلول خالی را سفید نگذارید: NOT_TESTED / NO_METHOD / NO_SAMPLE / BLOCKED / OUT_OF_SCOPE / SUPERSEDED / UNKNOWN بنویسید. Coverage واقعی از همین مخرج می‌آید.

Test Suite مرجع کامل بودن نیست

Suite ممکن است فقط Profile، Version یا Testable assertionهای خاصی را پوشش دهد. Publisher، Version، Scope، Requirement baseline، Selection rule، Exclusion، Known gap، Tool version، Digest و Change log را ثبت کنید. سبزشدن Suite فقط همان Suite را می‌گوید، نه تمام متن یا همه Contextها.

Test case را از Clause copy نکنید

Objective، Preconditions، Configuration، Input، Procedure، Oracle، Expected، Tolerance، Repeat count، Cleanup و Evidence capture را بسازید. Positive case کافی نیست؛ Invalid، Boundary، Missing، Unsupported، State transition و Error behavior را از Requirement استخراج کنید.

Oracle و Tolerance را نسخه‌دار کنید

Expected result می‌تواند Exact، Range، Grammar، State machine، Reference artifact یا Measurement limit باشد. Unit، Resolution، Rounding، Timing point، Uncertainty و Unknown policy را ثبت کنید. برای طراحی Verdict از راهنمای Test Oracle استفاده کنید.

Environment بخشی از Scope است

Lab، Equipment/Serial، Software، Network، Clock، Power، Temperature، Fixture، Calibration و Environment digest را نگه دارید. اگر نتیجه به شرایط Environmental وابسته است، یک اجرای اتاقی به همه دماها، شبکه‌ها یا Deviceها تعمیم ندارد.

Sample و نمایندگی را ثبت کنید

SampleID، Lot/Serial، Quantity، Selection method، Condition، Preparation، Chain of custody و Disposition لازم‌اند. یک Golden unit ممکن است Production variation را نمایندگی نکند. Sampling plan و نتیجه Lot/Population را فقط طبق Scheme و روش آماری معتبر تفسیر کنید.

Measurement بدون Uncertainty ناقص است

Measurand، Method، Instrument، Range، Unit، Resolution، Calibration status، Measurement uncertainty، Traceability و Raw/Corrected value را ثبت کنید. نزدیک Limit، Decision rule اهمیت دارد؛ عدد ۹٫۹۹ در برابر حد ۱۰ بدون Uncertainty و Rounding خودکار Pass نیست.

Deviation را قبل از Verdict پنهان نکنید

انحراف از Method، Environment، Sample، Sequence یا Tool ممکن است مجاز، غیرمجاز یا اثرنامعلوم باشد. Type، علت، Authorization، Requirement/Test متاثر، اثر بر Claim، Owner و Expiry را ثبت کنید. «تغییر کوچک» بدون Impact analysis Evidence را مشکوک می‌کند.

Verdict دوحالته همیشه کافی نیست

PASS: Requirement/Method/Scope اعلام‌شده برآورده شد.
FAIL: Objective evidence با Pass rule ناسازگار است.
INCONCLUSIVE: Evidence برای حکم کافی نیست.
NOT_TESTED: اجرای معتبر انجام نشده است.
NOT_APPLICABLE: با Applicability evidence و مرجع تصمیم.
BLOCKED: پیش‌شرط یا ابزار مانع شده است.
INVALID_EXECUTION: Run برای Verdict قابل‌استفاده نیست.
STALE: تغییر Subject/Reference اعتبار قبلی را برده است.

Coverage denominator را منتشر کنید

Coverage {
  baseline_requirements: 120,
  applicable: 86,
  passed: 70,
  failed: 3,
  inconclusive: 4,
  not_tested: 7,
  blocked: 2,
  not_applicable: 29,
  unknown_applicability: 5,
  claim: "70 passed of 86 applicable; no full-conformance claim"
}

درصد ساده می‌تواند Unknown و Exclusion را پنهان کند. Requirementهای Conditional و Profileهای Claim‌شده را در مخرج درست قرار دهید. «۱۰۰٪ تست‌های اجراشده پاس» ممکن است فقط ۱۰ مورد از ۸۶ الزام Applicable باشد.

Nonconformity از Bug گسترده‌تر یا متفاوت است

عدم انطباق یعنی Objective evidence نشان می‌دهد Requirement مشخص برآورده نشده است. ممکن است علت کد، Label، فرایند، Documentation، Configuration یا Sample باشد. RequirementID، Subject، Evidence، Classification، Correction، Corrective action، Verification و Residual را ثبت کنید. Severity محصول را از Classification Scheme جدا نگه دارید.

Correction و Corrective Action یکی نیستند

Correction مورد مشاهده‌شده را رفع می‌کند؛ Corrective action علت را هدف می‌گیرد. Retest فقط نشان می‌دهد وضعیت جدید در Scope تست‌شده Pass است؛ اثربخشی اقدام یا نبود موارد مشابه نیازمند Evidence جداست.

First، Second و Third Party

First-party خود عرضه‌کننده، Second-party ذی‌نفعی مانند خریدار و Third-party نهاد مستقل از طرفین است. نوع Party، مسئولیت، Conflict، صلاحیت و Scheme را آشکار کنید. «آزمون مستقل» فقط با نام آزمایشگاه ثابت نمی‌شود.

Declaration، Report و Certificate را تفکیک کنید

Artifact	صادرکننده/ماهیت	چه چیزی را نباید القا کند؟
Test report	نتایج روش‌ها و Sampleهای اعلام‌شده	Certification خودکار
Supplier declaration	اظهار مسئولانه First-party	Third-party approval
Inspection report	قضاوت درباره بررسی مشخص	همه Product quality
Certificate	Written assurance طبق Scheme و Scope	Accreditation صادرکننده یا پوشش نامحدود
Accreditation evidence	Recognition صلاحیت Body در Scope معین	Pass بودن هر محصول

Certification و Accreditation فرق دارند

صفحه رسمی ISO درباره Certification Certification را Written assurance یک Body مستقل درباره برآورده‌شدن Requirementهای مشخص و Accreditation را Recognition رسمی صلاحیت Certification body توضیح می‌دهد. ISO خود Certificate محصول/سیستم صادر نمی‌کند. Scheme، Scope و Directory/Status را بررسی کنید؛ Logo تصویرشده شاهد اعتبار نیست.

Scope گواهی را خط‌به‌خط بخوانید

CertificateID، Body، Scheme، Subject/Model، Site، Standard edition، Scope، Exclusion، Issue/Expiry، Surveillance، Suspension/Withdrawal و Mark rules را ثبت کنید. گواهی Management system لزوماً Certification محصول نیست؛ گواهی یک Variant همه خانواده را پوشش نمی‌دهد.

صلاحیت Body وابسته به Scope است

نام Accredited کافی نیست. Accreditation scope، Standard/Method، Site، وضعیت جاری، Personnel/Equipment competence، Impartiality و Recognition موردنیاز Scheme/Market را بررسی کنید. پذیرش بین مرزها به توافق، Scheme و مرجع مقصد وابسته است؛ جهانی و خودکار نیست.

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

Market access ممکن است Registration، Approval، Declaration، Technical file، Label/Mark، Local representative، Surveillance یا پذیرش Report مشخص بخواهد. WTO نیز Conformity assessment procedure را راه تعیین برآورده‌شدن الزامات Regulation/Standard می‌داند، اما الزام خاص کشور/محصول را باید از مرجع جاری همان بازار تعیین کرد. Pass آزمایشگاه به‌تنهایی مجوز عرضه نیست.

Conformance با Interoperability یکی نیست

دو Implementation می‌توانند هر دو ادعای Conformance داشته باشند اما در Profile، Option، Extension، Version، Interpretation یا Error handling مشترک نباشند. Interoperability باید Matrix واقعی طرف‌ها، Configuration، Workflow و Semantic outcome را بیازماید. مقاله بعدی ۱۹۷۶ این موضوع را مالک است.

Conformance با Quality و Fitness فرق دارد

محصول می‌تواند در Scope مرجع منطبق اما کند، دشوار، ناامن یا نامناسب برای کاربر باشد؛ یا Quality خوبی داشته باشد اما یک Clause را Fail کند. Claimهای Reliability، Performance، Security، Safety و Usability را با Requirement و Evidence خودشان بسازید. Certificate «مهر کیفیت کلی» نیست.

گزارش قابل‌ممیزی چه ساختاری دارد؟

ConformanceReport {
  report_id, issuer_and_role, subject_and_samples,
  reference_set, applicability, profile_and_options,
  methods, environment_and_deviations,
  requirement_verdict_table, coverage_denominator,
  nonconformities, inconclusive_and_not_tested,
  measurement_uncertainty, limitations,
  authorized_signatory, issue_date, revision
}

Evidence Pack و Provenance

Reference snapshots، Applicability/Profile declaration، Requirement baseline، Interpretation decisions، Suite/Tool digest، Environment/Calibration، Sample custody، Raw outputs، Verdicts، Coverage، Findings/Nonconformities، Report/Declaration/Certificate evidence، Body scope، Decision و Correction را با Digest و Retention پیوند دهید.

تغییر و انقضا را خودکار Trigger کنید

تغییر Subject، Component، Config، Label، Standard/Amendment، Profile، Interpretation، Suite، Method، Equipment یا Scheme می‌تواند Retest/Review بخواهد. Impact analysis تعیین کند کدام Requirement/Evidence Stale می‌شود. تاریخ Expiry ادعا را از تاریخ فایل جدا کنید.

Living baseline و Drift detection

Reference inventory، Effective dates، Requirement extraction و Trace matrix باید Owner/Freshness داشته باشند. برای کنترل Drift و Supersession از راهنمای مستندات تست زنده استفاده کنید. Scrape یا AI extraction فقط Candidate می‌سازد؛ متن مجاز و Reviewer مرجع لازم‌اند.

واژگان نتیجه را استاندارد کنید

REQUIREMENT_PASS
REQUIREMENT_FAIL
INCONCLUSIVE
NOT_TESTED
NOT_APPLICABLE_WITH_BASIS
APPLICABILITY_UNKNOWN
BLOCKED
INVALID_EXECUTION
DEVIATION_REVIEW_REQUIRED
NONCONFORMITY_OPEN
CLAIM_LIMITED
CERTIFICATE_STATUS_UNVERIFIED
STALE_EVIDENCE
CLAIM_WITHDRAWN

آزمایشگاه فارسی و کاملاً ساختگی پیام

این آزمایشگاه آفلاین یک Sender/Receiver خیالی با Standard ساختگی STD-FAKE-7:2026 دارد. هیچ محصول، سازمان، آزمایشگاه، Regulator، بازار، شبکه، شخص، داده واقعی، Payment، Bank، PSP، Account، Cookie، Token یا Credential وجود ندارد. IRR فقط Label Fixture و تومان صرفاً Presentation غیرحسابداری است.

Subject: FAKE-MSG v2.1, profile=P-RETAIL-IR-v2
Baseline: 12 fictional requirements
Applicable: 8
REQ-7.3.2-C: unknown schema must be rejected with no side effect
REQ-8.1-A: EventID normalization must preserve identifier identity

Injected gaps:
  suite tests only 5 of 8 applicable requirements
  one SHOULD misread as MUST
  one informative example treated as requirement
  edition 2025 logo displayed against 2026 baseline
  fictional certificate issuer has no verified role

سناریوهای فارسی آزمایشگاه

EventIDهای ۷، ۷ و ۷ برای تشخیص Display normalization از Identity mutation.
ی/ی، ک/ک، «تأیید/تایید» و نیم‌فاصله در Label؛ Protocol ID از متن نمایشی ساخته نمی‌شود.
RTL/LTR و Bidi control برای Report rendering، بدون تغییر Raw evidence.
UTC و Asia/Tehran و جلالی فقط Presentation؛ Effective date با Instant canonical سنجیده می‌شود.
۷۰۰۰ IRR و «۷۰۰ تومان» عمداً برای کشف Unit/rounding mismatch.
Profile خاموش، Option Claim‌شده و Amendment جاافتاده برای ساخت Gap مخرج.

Validator قطعی آزمایشگاه

Validator مستقل و بدون Dependency، کنترل‌ها را Group-qualified و یکتا می‌کند. Checker سطحی با دیدن Suite سبز، Logo، نام Standard، PDF Certificate و نبود Bug باز اشتباه می‌گوید FULLY_COMPLIANT_CERTIFIED_INTEROPERABLE_AND_MARKET_READY. ممیزی نبود Applicability، Edition/Profile، Denominator، صلاحیت صادرکننده، Interoperability و Market-access basis را آشکار و نتیجه را Hold می‌کند. پس از Pin شدن مرزها، نتیجه فقط READY_FOR_CONFORMANCE_CLAIM_REVIEW-0 است.

CONTROL_COUNT=366
SUPERFICIAL=FULLY_COMPLIANT_CERTIFIED_INTEROPERABLE_AND_MARKET_READY
AUDIT=HOLD-366
INDEPENDENT_TARGET=real-product-or-organization:false:PASS
CORRECTED=READY_FOR_CONFORMANCE_CLAIM_REVIEW-0
BOUNDARY=offline-fictional-fixture-only; no full compliance, certification, accreditation, interoperability, quality, safety, security, legality, market-access, or real-product claim

دروازه تصمیم پیشنهادی

اگر Subject/Reference/Profile Pin نیست، Claim صادر نشود. اگر Applicability Unknown است، Full conformance ممنوع است. اگر Applicable Requirement بدون Verdict معتبر داریم، Gap آشکار بماند. اگر Issuer role یا Body scope تأیید نشده، Artifact را Report/Unverified claim بنامید. Release/Market decision را مالک مجاز با شرط و Expiry ثبت کند.

Correction و Withdrawal

اگر ویرایش، مخرج، Verdict، Scope یا وضعیت Certificate اشتباه منتشر شد، رکورد قبلی را حذف نکنید. Correction شامل گزاره قدیم/جدید، علت، زمان کشف، Report/Decisionهای متاثر، Notification و Approver باشد. Claim منقضی، Suspended یا Withdrawn باید در UI و Directory قابل‌دیدن باشد.

۲۰ ضدالگوی رایج

Red flagها: نام Standard بدون Edition؛ Logo به‌جای Evidence؛ Suite سبز مساوی Full conformance؛ همه Clauseها Mandatory؛ SHOULD مساوی MUST؛ Informative note در مخرج؛ Profile انتخاب‌شده بعد از Fail؛ N/A بدون Basis؛ حذف Inconclusive؛ درصد بدون Denominator؛ Report مساوی Certificate؛ Certification مساوی Accreditation؛ Accredited بدون Scope؛ Certificate یک Variant برای Family؛ Pass مساوی Interoperable؛ Pass مساوی Quality/Security/Safety؛ International standard مساوی قانون همه کشورها؛ Certificate مساوی Market access؛ Expiry پنهان؛ و پاک‌کردن Claim اشتباه.

چک‌لیست مالک انطباق

Subject/Variant/Build/Config/Label دقیق تثبیت شده است.
Reference/Edition/Amendment/Corrigendum/Language/Effective date معلوم‌اند.
Standard/Regulation/Contract/Scheme و Applicability تفکیک شده‌اند.
Profile/Option/Role/Mode و Capability declaration نسخه‌دارند.
Normative/Informative و Mandatory/Conditional/Optional درست طبقه‌بندی شده‌اند.
هر Requirement Source locator و Interpretation دارد.
Trace matrix Gap و Unknown را نشان می‌دهد.
Suite scope/version/digest/known gaps روشن‌اند.
Environment، Sample، Calibration و Measurement uncertainty ثبت شده‌اند.
Oracle/Decision rule/Tolerance/Unknown policy بازبینی شده‌اند.
مخرج Coverage همه وضعیت‌ها را نگه می‌دارد.
Nonconformity، Correction، Corrective action و Verification تفکیک شده‌اند.
Party/Issuer/Body competence/Accreditation scope تأیید شده‌اند.
Report/Declaration/Certificate/Market decision برچسب درست دارند.
Change، Expiry، Suspension، Withdrawal و Correction قابل‌ردیابی‌اند.

پایلوت ۳۰روزه بدون محصول واقعی

هفته اول Reference inventory، Applicability و Profile ساختگی؛ هفته دوم Requirement extraction/Interpretation/Trace matrix؛ هفته سوم Suite/Environment/Sample/Oracle و اجرای Fixture؛ هفته چهارم Coverage/Nonconformity/Evidence Pack و Claim review مستقل. معیار موفقیت تعداد Pass نیست: Unknown applicability، Trace gap، Interpretation churn، Invalid run، Time-to-evidence و Scope accuracy را بسنجید.

جمع‌بندی

تست انطباق نگهبان مبهم «همه استانداردها» نیست. یک ارزیابی محدود است که Subject مشخص را با Reference و Profile مشخص، Requirement به Requirement، زیر Method و Environment مشخص می‌سنجد. ارزش حرفه‌ای آن در ادعای بزرگ نیست؛ در مخرج صادقانه، صلاحیت روشن، Evidence قابل‌ردیابی و Correction ماندگار است.

پرسش‌های متداول

آیا Pass شدن Test Suite یعنی انطباق کامل؟

فقط اگر Scheme، Baseline، Profile، Applicability، مخرج Requirementها و قواعد Claim همین نتیجه را پشتیبانی کنند. Suite ممکن است بخشی از الزامات را نسنجد.

فرق Certification و Accreditation چیست؟

Certification اطمینان مکتوب یک Body درباره برآورده‌شدن Requirementهای مشخص است؛ Accreditation شناسایی صلاحیت همان Body در Scope مشخص است. یکی جای دیگری نیست.

آیا استاندارد بین‌المللی همیشه اجباری است؟

خیر. ممکن است داوطلبانه باشد یا از طریق Regulation، Contract، Procurement یا Scheme الزام‌آور شود. Applicability به بازار، محصول، نقش، تاریخ و متن جاری وابسته است.

آیا Conformance قابلیت همکاری را تضمین می‌کند؟

خیر. اختلاف Profile، Option، Version، Extension یا Interpretation می‌تواند دو Implementation منطبق را ناسازگار کند. Interoperability test واقعی مکمل لازم است.

حداقل محتوای یک Conformance Claim چیست؟

Subject، Reference/Edition، Applicability، Profile، Requirement baseline، Method/Suite، Environment/Sample، Verdict denominator، Gap/Deviation، Evidence، Issuer role، Scope، Limit، Validity و Correction link.

اجرای تست‌ها

تست انطباق؛ از Requirement تا Conformance Claim