تست قابلیت همکاری؛ Matrix تا Semantic Outcome

دو سامانه می‌توانند به هم وصل شوند، پاسخ HTTP 200 بدهند و JSON معتبر ردوبدل کنند، اما هنوز با هم «کار نکنند». فرستنده مبلغ 7000 IRR را می‌فرستد، Adapter آن را «۷۰۰ تومان» نمایش می‌دهد و گیرنده دوباره ۷۰۰ ریال ذخیره می‌کند؛ یا وضعیت PAID در مقصد به SETTLED ترجمه می‌شود و Workflow زودتر از موعد جلو می‌رود. تست قابلیت همکاری (Interoperability Testing) باید این فاصله میان اتصال فنی و نتیجهٔ مشترک را آشکار کند.

پاسخ کوتاه: تست قابلیت همکاری، رفتار یک ترکیب مشخص از Party، Role، Product، Version، Profile، Configuration و Workflow را در تبادل واقعی یا نماینده می‌سنجد. شاهد معتبر فقط «پیام رسید» نیست؛ باید Transport، Syntax، Terminology، Meaning، Identity، State transition و Business outcome مشاهده و با Oracle نسخه‌دار مقایسه شوند.

مرز ادعا: Pass شدن A v2 ↔ B v3 در Profile و Workflow معین، فقط درباره همان ردیف Matrix و همان Evidence window حرف می‌زند. این مقاله گواهی انطباق، تضمین امنیت/ایمنی/حریم خصوصی، کیفیت کل محصول، آمادگی Production یا قابلیت همکاری با همه Vendorها صادر نمی‌کند.

تست قابلیت همکاری چیست؟

Interoperability Testing بررسی می‌کند طرف‌های مستقل یا نیمه‌مستقل، با مسئولیت‌ها و چرخه انتشار جدا، در یک تعامل تعریف‌شده بتوانند اطلاعات یا کنترل را مبادله کنند، معنای لازم را حفظ کنند و Outcome مورد توافق را بسازند. «طرف» می‌تواند دو محصول، دو Vendor، Client و Server، Publisher و Subscriber، Device و Gateway، یا سامانه شما و شریک بیرونی باشد.

قابلیت همکاری الزاماً دوطرفه نیست. یک Publisher ممکن است فقط Event بفرستد و Subscriber فقط دریافت کند؛ جهت، Role و Acknowledgement باید در Claim نوشته شوند. همچنین این تست ذاتاً فقط Non-functional نیست: قرارداد فنی، رفتار Functional، Workflow، Quality attribute و گاهی فرایند سازمانی همگی ممکن است در Scope باشند.

چرا HTTP ۲۰۰ و JSON معتبر کافی نیست؟

Transport موفق است، اما Encoding یا Compression در مسیر داده را عوض می‌کند.
Schema معتبر است، اما واحد، enum، timezone یا هویت معنای دیگری دارد.
پیام درست فهمیده می‌شود، اما State transition مقصد مجاز نیست.
هر مرحله جدا Pass است، اما Outcome نهایی یا اثر جانبی غلط است.
ترکیب امروز Pass است، اما Version یا Config فردا همان شاهد را Stale می‌کند.

بنابراین «Connected»، «Parseable»، «Conformant» و «Interoperable در Scope معین» چهار گزاره متفاوت‌اند. هر کدام Evidence و مخرج خودش را می‌خواهد.

چهار لایه را مدل بدانید، نه نردبان قطعی

چارچوب رسمی European Interoperability Framework برای خدمات عمومی اروپا لایه‌های Legal، Organisational، Semantic و Technical را معرفی می‌کند و Governance را فراگیر می‌بیند. از این مدل می‌توان برای پرسیدن سؤال‌های بهتر استفاده کرد، نه برای ادعای اینکه هر پروژه دقیقاً چهار سطح جهانی یا یک «بالاترین سطح» دارد.

لنز	پرسش آزمون	نمونه Evidence	مرز
Technical	رابط، Protocol، Syntax و Error چگونه کار می‌کنند؟	Exchange خام، Trace، Schema result	معنا را به‌تنهایی ثابت نمی‌کند
Semantic	مقصد همان مفهوم، واحد و هویت را فهمیده است؟	Source/Received/Interpreted/Stored comparison	Workflow سازمانی را ثابت نمی‌کند
Organisational	Role، مسئولیت، handoff و فرایند هم‌راستا هستند؟	Workflow/Actor agreement و Scenario	مجوز قانونی را ثابت نمی‌کند
Legal	آیا مبادله در Scope قابل‌اجرا و مجاز تعریف شده؟	Applicability review صاحب‌صلاحیت	این مقاله مشاوره حقوقی نیست
Governance	Owner، Version، Change و Decision چگونه کنترل می‌شوند؟	Matrix، Evidence Record، Expiry، Correction	جای اجرای تست را نمی‌گیرد

تفاوت Interoperability و Compatibility

Compatibility معمولاً رفتار یک Product را در Matrix محیط‌ها، نسخه‌ها، Browserها، OSها یا Deviceها می‌سنجد؛ Interoperability بر تعامل Partyها و Outcome مشترک تمرکز دارد. این تمایز مطلق نیست و واژه‌ها در حوزه‌های مختلف فرق می‌کنند. برای Matrix مرورگر/Engine/OS به راهنمای تست Cross Browser رجوع کنید؛ آن مقاله مالک Compatibility وب است.

تفاوت Interoperability و Integration Testing

تست یکپارچه‌سازی مرز و تعامل Componentها یا Systemها را به‌طور گسترده می‌سنجد. Interoperability معمولاً وقتی برجسته می‌شود که طرف‌ها استقلال، Vendor، Release cadence، Profile یا Interpretation جدا دارند و ادعای «کار کردن با یکدیگر» باید محدود شود. هر Interoperability Test می‌تواند System Integration Test باشد؛ هر Integration Test الزاماً ادعای Interoperability چندپیاده‌سازی ندارد.

تفاوت Interoperability و Contract Testing

تست قراردادی API با Pact Interactionهای مورد انتظار Consumer و Provider را سریع و نسخه‌پذیر بررسی می‌کند. Contract می‌تواند ناسازگاری request/response یا message را زود کشف کند، اما مسیر واقعی، negotiation، terminology، Adapter، State مشترک و Outcome سراسری را خودکار اثبات نمی‌کند. Contract evidence یک ستون Matrix است، نه Verdict نهایی همه لایه‌ها.

تفاوت Interoperability و Conformance Testing

تست انطباق Subject را نسبت به Reference/Edition/Profile و Requirementهای مشخص می‌سنجد. دو پیاده‌سازی می‌توانند جداگانه Conformance Claim داشته باشند، ولی به علت Option، Extension، Version، Capability یا Interpretation مشترک‌نبودن با هم کار نکنند. در جهت معکوس نیز یک جفت ممکن است در Workflow محدود کار کند، بی‌آنکه ادعای Conformance کامل داشته باشد.

واحد اصلی ادعا: Interoperability Evidence Record

به‌جای جمله مبهم «سامانه X Interoperable است»، یک Record نسخه‌دار بسازید. Subject این Record یک محصول منفرد نیست؛ رابطهٔ آزموده‌شده میان طرف‌هاست.

InteroperabilityEvidenceRecord {
  record_id, version, status, owner, valid_from, expires_at,
  claim_text, parties_and_roles, products_builds_configs,
  specification_profile_options, workflow_and_outcome,
  matrix_rows, environment, runs, layered_verdicts,
  denominator_gaps_unknowns, evidence_digests,
  decision_scope_conditions, limitations, correction_history
}

Claim را پیش از Test بنویسید

Claim خوب باید بگوید چه کسی با چه کسی، در کدام جهت و Role، با چه نسخه/Profile/Config، برای کدام Workflow و Outcome، در چه بازه Evidence و با چه محدودیت‌هایی آزموده شده است. عبارت «سازگار با همه سامانه‌ها» قابل‌آزمون نیست مگر دامنه «همه» واقعاً تعریف و مخرج منتشر شود.

Claim IOP-042-v1:
  Fake Sender 2.1 as ORDER-PUBLISHER
  with Fake Receiver 3.0 as ORDER-CONSUMER
  through Adapter 1.4 under PROFILE-IR-PAY-v2
  for AUTHORIZE_TO_ACK workflow and canonical IRR outcome
  evidence window: 2026-08-01..2026-08-30
  not claimed: other versions, profiles, workflows, vendors or Production

هویت Party و Artifact را دقیق Pin کنید

PartyID، Role و جهت تعامل
Product/Implementation/Instance و Vendor یا Owner
Release، Build، Commit و Artifact digest
Endpoint و Environment بدون افشای Secret
Config digest، Feature flag، Dependency و Runtime
Adapter، Gateway، Proxy یا Terminology service میان دو طرف

نام محصول یا شماره نسخه بازاری کافی نیست. دو Instance با همان Version ولی Feature flag یا mapping متفاوت می‌توانند Verdict متفاوت داشته باشند.

Role و Directionality را صریح کنید

Sender/Receiver، Client/Server و Producer/Consumer مترادف کامل نیستند. یک طرف ممکن است در Transaction آغازگر و در Callback پاسخ‌دهنده باشد. برای هر leg، Initiator، Responder، Channel، Trust boundary، Acknowledgement و expected side effect را جدا ثبت کنید. Pass مسیر A→B درباره B→A چیزی ثابت نمی‌کند.

Specification، Profile، Option و Capability

نام Standard فقط نقطه شروع است. Edition، Profile، Actor، Option، Extension، Capability snapshot و Interpretationهای محلی باید نسخه داشته باشند. FHIR R4 CapabilityStatement نیز Capability یک پیاده‌سازی یا الزامات مورد انتظار را توصیف می‌کند، اما خودش هشدار می‌دهد ثبت همه تغییرات مؤثر بر قابلیت همکاری دو سیستم در طول ارتقاها به‌ندرت عملی است. پس Capability declaration ورودی انتخاب Test است، نه جایگزین اجرای جفت واقعی.

Interoperability Matrix را بسازید

Matrix فقط جدول Version نیست. هر ردیف باید Party A/B، Role pair، Profile/Option، Adapter، Config، Workflow، Data class، جهت و Risk priority داشته باشد. وضعیت‌های Unsupported و Unknown را حذف نکنید؛ این‌ها بخشی از مخرج‌اند.

Matrix row	ترکیب	Workflow	وضعیت	حد ادعا
M-01	A2.1/P2 → B3.0/P2	Create→Ack	Selected	همین جهت و Workflow
M-02	A2.1/P2 → B2.8/P1	Create→Ack	Unsupported	Pass فرض نشود
M-03	A2.0/P2 ↔ B3.0/P2	Cancel→Compensate	Unknown	Evidence ندارد
M-04	A2.1/P2 → Adapter1.4 → B3.0/P2	Retry after timeout	Selected	Adapter جزو Subject
M-05	A2.1/P2 → B3.1/P2	Create→Ack	Not tested	Release جدید Stale trigger است

Pairwise Testing و خطر تعمیم

اگر تعداد Vendor×Version×Profile×Config×Workflow زیاد است، Risk-based selection، Equivalence و Pairwise می‌توانند اندازه Suite را کم کنند؛ اما پوشش combinatorial باید دقیق گزارش شود. Pass چند Pair منتخب به معنای Pass همه ترکیب‌ها نیست. تعامل سه‌طرفه یا Adapter chain ممکن است Faultی بسازد که در جفت‌های منفرد دیده نمی‌شود.

Transport را جدا Verdict دهید

Protocol/version، endpoint resolution، connection/session، framing، media type، content encoding، compression، chunking، timeout، heartbeat، ordering و acknowledgement را مشاهده کنید. TLS یا Auth ممکن است برای برقراری اتصال لازم باشد، اما Pass این لایه ادعای امنیت کلی نیست.

Syntax و Schema را دقیق‌تر از Valid/Invalid ببینید

SchemaID/version/digest، required/optional، cardinality، nullability، type، format، constraint، unknown-field و extension policy را Pin کنید. Validator، نسخه و Definitionهای زیرین نیز Evidence‌اند. Payload ممکن است Schema-valid باشد اما default، enum یا extension در گیرنده معنای دیگری بسازد.

Terminology و کدها را نسخه‌دار کنید

مستند رسمی Terminology در FHIR R4 میان CodeSystem و ValueSet فرق می‌گذارد و برای Coding، system، version، code و display را از هم جدا می‌کند. این مثال سلامت را قانون همه Domainها نکنید؛ اصل قابل‌انتقال آن این است که Display هویت مفهوم نیست و Code بدون Namespace/Version می‌تواند مبهم باشد.

CodeSystem URI و Version دقیق چیست؟
ValueSet کدام Context را محدود می‌کند؟
Binding و Unknown-code policy چیست؟
Mapping/ConceptMap چه نسخه و Ownerی دارد؟
اگر Translate یک‌به‌چند یا Lossy است، چگونه اعلام می‌شود؟
Case sensitivity، Deprecated code و Display mismatch چه Verdictی دارند؟

Semantic Interoperability را با Outcome بسنجید

یکسان‌بودن نام فیلد کافی نیست. برای هر مفهوم، تعریف کسب‌وکار، واحد، precision/scale، rounding، علامت، null/missing/default، status lifecycle، identity و زمان را ثبت کنید. سپس Source value، Transmitted، Received، Interpreted، Stored و Displayed را کنار هم بگذارید. اختلاف مجاز و Lossy transform باید از پیش اعلام شود.

PreservationTrace {
  concept: "canonical_amount",
  source: { value: "7000", unit: "IRR" },
  transmitted: { minor_value: 7000, currency: "IRR" },
  received: { minor_value: 7000, currency: "IRR" },
  interpreted: { value: 7000, unit: "IRR" },
  stored: { value: 7000, unit: "IRR" },
  display_only: "۷۰۰ تومان",
  loss: "none", outcome: "preserved"
}

Identity، Reference و Correlation

TenantID، EntityID، MessageID، EventID، CorrelationID، CausationID، AttemptID و Idempotency key نقش‌های متفاوت دارند. Normalization نمایشی نباید Identity را بی‌خبر تغییر دهد. Merge، collision، namespace، reused ID و reference به Entity حذف‌شده را تست کنید. برای History و ترتیب رخداد در سامانه توزیع‌شده، راهنمای History تا Replay مکمل است.

زمان، منطقه زمانی و تقویم

Event time، Ingestion time و Processing time را جدا کنید. Instant canonical، timezone ID، offset، DST policy، expiry semantics، clock skew، ordering/lateness window و نمایش تقویم را ثبت کنید. جلالی یا «ساعت تهران» می‌تواند Presentation باشد؛ تبدیل رفت‌وبرگشت آن نباید timestamp یا تاریخ انقضا را تغییر دهد.

Unicode فارسی و Bidi در تبادل

ی/ی، ک/ک، اعداد ۷/۷/۷، نیم‌فاصله، فاصله، Normalization form و Bidi control ممکن است در Search، dedup، signature، identifier یا rendering اثر متفاوت داشته باشند. ابتدا مشخص کنید کدام فیلد Identifier و کدام Label است. Canonicalization بدون قرارداد می‌تواند دو هویت را ادغام یا Signature را نامعتبر کند.

Workflow و State transition را مدل کنید

یک پیام معتبر لزوماً در هر State معتبر نیست. WorkflowID/version، precondition، initiating event، state before/after، Actor handoff، completion، cancellation و compensation را بنویسید. PAID، AUTHORIZED و SETTLED فقط enum نیستند؛ جایگاه زمانی و اختیار Actor را تغییر می‌دهند.

Outcome Oracle را مستقل طراحی کنید

Oracle نباید صرفاً پاسخ مقصد یا همان Mapping مورد آزمون را تکرار کند. منبع، Version، Owner، Observation، Comparator، tolerance، expected state/side effect، forbidden side effect، eventual window و Inconclusive policy لازم‌اند. راهنمای طراحی Test Oracle شیوه کنترل Oracle problem و False Pass را عمیق‌تر پوشش می‌دهد.

OutcomeOracle O-42-v3 {
  source: approved fictional workflow model,
  expected_state: RECEIVED_NOT_SETTLED,
  expected_effects: [one_receipt_record],
  forbidden_effects: [settlement_record, duplicate_notification],
  eventual_window: 5s in virtual clock,
  tolerance: exact canonical IRR integer,
  unknown: INCONCLUSIVE, owner: workflow-owner
}

خطا فقط Defect یک طرف نیست

Difference می‌تواند Product defect، Contract ambiguity، Profile mismatch، Unsupported pair، stale capability، bad fixture، Environment drift، Oracle error یا Unknown باشد. تا Triage انجام نشده، هر اختلاف را به تیم گیرنده نسبت ندهید. Finding باید Observation، Expected، Impact، Hypothesis، Alternative، Owner و Retest evidence داشته باشد.

Error contract و Ack semantics

Error code/meaning، retryable/permanent، partial/rejected/quarantined، dead-letter، payload و side-effect policy را برای هر Profile نسخه‌دار کنید. Ack ممکن است فقط دریافت bytes، پذیرش syntax، قبول برای پردازش یا completion را نشان دهد؛ معنایش را از حدس یا نام status code استخراج نکنید.

Retry، Duplicate و Idempotency

Timeout-before-commit و timeout-after-commit را جدا تزریق کنید. Delivery semantics، retry/backoff/budget، idempotency scope، dedup key/window، replay، out-of-order، late event و reconciliation باید مشترکاً آزموده شوند. یک طرف ممکن است درخواست را duplicate بداند و طرف دیگر Attempt جدید؛ این اختلاف Semantic است.

Backward و Forward Compatibility

Reader جدید با Writer قدیم، Reader قدیم با Writer جدید، mixed fleet، rolling upgrade و rollback را در Matrix جدا کنید. Unknown field، enum جدید، required field، default و extension behavior اهمیت دارند. «Backward compatible» بدون جهت، نسخه و نوع Artifact عبارت ناقصی است.

Adapter و Mapping بخشی از Subject هستند

اگر Translator، ESB، API Gateway، ETL یا Mapper میان طرف‌هاست، نسخه و Config آن را از Claim حذف نکنید. Mapping باید provenance، transformation rule، declared loss، unmapped value و round-trip test داشته باشد. Pass مستقیم A↔B به مسیر A↔Adapter↔B قابل انتقال نیست.

Reference Implementation و Emulator چه ارزشی دارند؟

Reference implementation، Stub، Simulator یا Emulator برای بازخورد سریع و کنترل Fault مفید است؛ اما ممکن است همان Interpretation ناقص Suite را تکرار کند. Fidelity، Version، unsupported behavior و known gaps را اعلام کنید و Pairهای پرریسک را با counterpart واقعیِ مجاز نیز اجرا کنید. نتیجه Emulator را «Vendor verified» ننامید.

Connectathon چه چیزی ثابت می‌کند؟

IHE Connectathon نمونه رسمی یک محیط ساختاریافته و تحت نظارت است که سامانه‌ها برای Actor و Profileهای انتخابی با هم peer-to-peer تست می‌شوند. این الگو ارزش آزمون چندفروشنده را نشان می‌دهد؛ اما نتیجه هر Event را باید با Participant، Product/version، Profile/Actor، Test و تاریخ خودش خواند. Connectathon مترادف Certification عمومی، Production readiness یا ایمنی بالینی نیست.

Interoperability در نرم‌افزار سلامت

در Health IT، Profile، Terminology، Patient/Encounter/Order/Result identity، correction، provenance و Clinical workflow اهمیت ویژه دارند. این مقاله از FHIR و IHE فقط برای توضیح اصول استفاده می‌کند؛ طراحی Hazard، Safety evidence و Workflow بالینی در راهنمای تست نرم‌افزار سلامت مالک مستقل دارد و باید با متخصص صاحب‌صلاحیت انجام شود.

Evidence Pack قابل بازتولید

Claim، Matrix و Capability/Profile snapshots
Party/Artifact/Config/Environment manifests با digest
Fixture/Test case/Oracle/Runner و Seed
Exchange خام، canonical form، Trace و state before/after
Layered verdict، denominator، gaps و Unknownها
Finding/Triage/Correction/Retest و Decision
Redaction، access، retention، custody و reproducibility status

Verdict را چندلایه نگه دارید

TRANSPORT_PASS
SYNTAX_PASS
SEMANTIC_FAIL
WORKFLOW_BLOCKED
OUTCOME_NOT_TESTED
PAIR_INCONCLUSIVE
PAIR_UNSUPPORTED
PAIR_STALE
EXECUTION_INVALID
INTEROPERABILITY_CLAIM_LIMITED

یک Overall label نباید جزئیات را بپوشاند. اگر Transport و Syntax Pass اما Semantic Fail است، سبزکردن کل Pair با میانگین امتیاز گمراه‌کننده است. اگر Oracle یا Environment معتبر نیست، Result را Invalid/Inconclusive کنید، نه Product Fail.

Coverage بدون مخرج معنایی ندارد

Intended، Selected، Executed، Passed، Failed، Inconclusive، Unsupported، Unknown و Excluded pairها را منتشر کنید؛ همچنین Workflow و Outcomeهای کل/آزموده را. درصد «۹۸٪ Interoperable» بدون تعریف مخرج، وزن ریسک و وضعیت‌های حذف‌شده Claim قابل دفاعی نیست.

Change، Expiry و Stale Evidence

تغییر Party release، Profile، Option، Config، Terminology، Adapter، Workflow، Oracle، Environment یا Incident می‌تواند Impact analysis و Retest بخواهد. Evidence تاریخ‌دار است؛ Badge یا صفحه Matrix باید Validity و آخرین Pair اجراشده را نشان دهد. Result قدیمی را بی‌صدا overwrite نکنید.

Correction و Withdrawal

اگر Mapping، مخرج، Identity یا Verdict اشتباه بوده، CorrectionID، گزاره قبلی/جدید، علت، Pairها و Decisionهای متاثر، زمان کشف، Notification و Approver را ثبت کنید. Claim منقضی یا Withdrawn باید در UI قابل‌دیدن بماند و به نسخه جایگزین پیوند بخورد.

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

آزمایشگاه SYN-INTEROP-PAIR-01 هیچ اتصال شبکه، Production، محصول، Vendor، سازمان، شخص، کاربر، سفارش، پرداخت، PSP، بانک، حساب، PII، Token یا Credential واقعی ندارد. Sender/Receiver/Adapter و تمام اعداد ساختگی‌اند. IRR فقط واحد Fixture و تومان فقط Presentation برچسب‌خورده است؛ هیچ ادعای بانکی، مالی، قانونی، امنیتی یا بازار ایران ساخته نمی‌شود.

Parties:
  FAKE-SENDER 2.1 / role=ORDER-PUBLISHER / profile=P-IR-v2
  FAKE-ADAPTER 1.4 / mapping=M-IRR-STATUS-v3
  FAKE-RECEIVER 3.0 / role=ORDER-CONSUMER / profile=P-IR-v2

Injected exchanges:
  amount=7000 IRR; presentation="۷۰۰ تومان"
  status=PAID; bad map=SETTLED
  ids="7", "۷", "٧"; labels="تایید", "تاييد"
  event UTC; display Asia/Tehran; Jalali presentation-only
  timeout-after-fake-commit; retry; duplicate; late; reordered
  schema v2 adds unknown extension; receiver policy differs

False Pass آزمایشگاه

Checker سطحی فقط اتصال، پاسخ ۲۰۰، Schema معتبر، Logo خیالی Profile و نبود Defect باز را می‌بیند و می‌گوید CONNECTED_SCHEMA_VALID_AND_FULLY_INTEROPERABLE. اما این Checker نمی‌بیند که amount دوباره با واحد غلط ذخیره شده، PAID به SETTLED جهش کرده، duplicate دو effect ساخته و نسخه گیرنده در Matrix اصلاً Pin نشده است.

Validator قطعی ۳۸۹ کنترل

یک Validator مستقل، dependency-free و اجراشده با Node.js v24.۱۸.۰، کنترل‌های Group-qualified را در Record/Claim/Party/Config/Profile/Relationship/Matrix/Environment/Transport/Syntax/Terminology/Meaning/Identity/Time/Workflow/Exchange/Error/Reliability/Preservation/Test/Oracle/Execution/Verdict/Evidence/Coverage/Finding/Decision/Lifecycle/Governance/Boundary یکتا کرد. شمارش دستی مبنا نیست؛ Assertion اجرای واقعی دقیقاً ۳۸۹ مورد را تأیید کرد.

CONTROL_COUNT=389
SUPERFICIAL=CONNECTED_SCHEMA_VALID_AND_FULLY_INTEROPERABLE
AUDIT=HOLD-389
INDEPENDENT_TARGET=real-system-or-organization:false:PASS
CORRECTED=READY_FOR_INTEROPERABILITY_EVIDENCE_REVIEW-0
BOUNDARY=offline-fictional-fixture-only; no universal interoperability,
semantic equivalence, data integrity, security, privacy, safety,
compliance, certification, production-readiness, vendor endorsement,
or real-world claim

پس از Pin کردن همه کنترل‌های ساختگی، نتیجه فقط READY_FOR_INTEROPERABILITY_EVIDENCE_REVIEW-0 است؛ نه «Interoperability قطعی». Validator ساختار Record را بررسی می‌کند، نه حقیقت داده، درستی Oracle یا رفتار جهان واقعی.

Test design برای آزمایشگاه

Happy path با حفظ دقیق IRR و State مجاز
Schema-valid ولی enum از نظر معنایی نامعتبر
Unknown field در Writer جدید و Reader قدیمی
Timeout قبل و بعد از fake commit با Retry یکسان
Duplicate، late و reordered event با Idempotency window
Round-trip Mapping و اعلام Lossy transform
Unicode label در برابر Identifier بدون normalization مخفی
UTC canonical در برابر نمایش تهران/جلالی
Ack دریافت در برابر Ack completion
Oracle conflict و Verdict برابر INCONCLUSIVE

دروازه Decision پیشنهادی

اگر Party/Profile/Config/Workflow Pin نیست، Claim صادر نشود. اگر Semantic یا Outcome Fail است، Transport/Syntax Pass آن را جبران نکند. اگر Counterpart واقعی در Scope لازم ولی فقط Emulator آزموده شده، Result مشروط بماند. اگر مخرج Pairها Unknown است، Badge کلی ممنوع باشد. Decision باید Scope، Conditions، Exceptions، Unknowns، Approver، Expiry، Monitoring و Rollback trigger داشته باشد.

نقش‌ها و مسئولیت تصمیم

System/Interface owner: مرز و Versionهای پشتیبانی‌شده
Data/Terminology owner: معنا، Mapping و Unknown policy
Workflow owner: State و Outcome مجاز
Test owner: Matrix، Run و Evidence integrity
Operations: topology، deploy و runtime signal
Security/Privacy/Legal/Safety owner: Claim مستقل حوزه خود
Decision authority: پذیرش Scope/Condition/Expiry و ثبت Dissent

حریم خصوصی و امنیت را جدا ولی هماهنگ نگه دارید

Interoperability ممکن است داده را درست جابه‌جا کند ولی Access control، Purpose limitation، retention یا confidentiality نامناسب باشد. برعکس، کانال امن ممکن است معنای غلط منتقل کند. Fixture مصنوعی را ترجیح دهید؛ Endpoint/Trace/Evidence را کمینه و Redact کنید؛ Secret را وارد گزارش نکنید. Pass این مقاله Security یا Privacy assurance نیست.

Observability برای عیب‌یابی مرزها

Correlation/Causation، exchange digest، timestampهای چندمرحله‌ای، Party build، Adapter mapping، state before/after و outcome را به هم پیوند دهید. Log متن آزاد بدون هویت نسخه و raw artifact برای اختلاف معنایی ضعیف است. Evidence observability باید حداقل داده لازم، دسترسی و retention روشن داشته باشد.

اتوماسیون کجا مفید است؟

Schema validation، Matrix orchestration، fixture generation، transport fault injection، round-trip comparison، terminology lookup، trace linking و stale-trigger detection را می‌توان خودکار کرد. انتخاب معنای درست، Applicability، Workflow outcome، risk acceptance و اختلاف Oracle نیازمند Owner انسانی است. AI می‌تواند Candidate mapping بسازد، نه اینکه بی‌منبع Semantic equivalence اعلام کند.

ارتباط با تست میکروسرویس

در میکروسرویس‌ها، Contract، Event، Idempotency، Saga، Trace و E2E هرکدام بخشی از Evidence را می‌سازند. استراتژی تست میکروسرویس سبد لایه‌ها را مالک است؛ مقاله حاضر روی Claim میان پیاده‌سازی/نسخه/Profileهای مشخص و Semantic Outcome تمرکز دارد.

CDC یا E2E را جای Pair evidence نگذارید

CDC بازخورد سریع و E2E Fidelity مسیر گسترده‌تر می‌دهد، اما هیچ‌کدام به‌تنهایی همه Matrix را پوشش نمی‌دهد. تصمیم سبد CDC/E2E باید بر مرز شواهد، هزینه و ریسک تکیه کند. برای Interoperability، Result هر لایه باید به Pair/Workflow/Outcome و limitations همان Evidence متصل شود.

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

Red flagها: HTTP ۲۰۰ مساوی Interoperable؛ JSON valid مساوی Semantic pass؛ نام Standard بدون Edition/Profile؛ Logo به‌جای Evidence؛ Capability declaration به‌جای execution؛ Conformance هر دو طرف مساوی Pair pass؛ جهت A→B مساوی B→A؛ یک Version نماینده همه نسخه‌ها؛ Emulator مساوی counterpart واقعی؛ Adapter حذف‌شده از Subject؛ Display مساوی Code identity؛ تومان/ریال بدون Unit؛ timestamp محلی بدون timezone؛ Ack مساوی completion؛ retry بدون timeout-after-commit؛ duplicate به‌عنوان Test-data noise؛ هر Difference مساوی Defect گیرنده؛ درصد بدون Denominator؛ Connectathon مساوی Certification عمومی؛ و overwrite کردن Result منقضی.

چک‌لیست مالک Interoperability

Claim، جهت، Party، Role، Workflow و Outcome محدود شده‌اند.
Product/Build/Config/Adapter/Environment digest ثبت است.
Specification/Edition/Profile/Option/Extension/Capability Pin است.
Matrix مخرج Intended/Selected/Unsupported/Unknown را نگه می‌دارد.
Transport و Syntax Verdict مستقل دارند.
Terminology/Meaning/Unit/Status/Identity/Time قرارداد نسخه‌دار دارند.
State transition و forbidden side effect Oracle دارند.
Error/Ack/Retry/Duplicate/Late/Reorder سناریو دارند.
Backward/Forward/Mixed-version جهت‌دار آزموده شده‌اند.
Source→Transmitted→Received→Stored→Display preservation دیده می‌شود.
Fixture/Runner/Seed/Raw evidence و Provenance بازتولیدپذیرند.
Pass/Fail/Inconclusive/Unsupported/Stale/Invalid حفظ می‌شوند.
Difference پیش از Defect شدن Triage می‌شود.
Decision، Condition، Expiry، Change trigger و Correction دارد.
Security/Privacy/Safety/Compliance/Production claim مستقل مانده‌اند.

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

هفته اول Claim/Party/Profile/Role و Matrix ساختگی را ببندید؛ هفته دوم Data/Terminology/Identity/Time/Workflow/Oracle contracts را بسازید؛ هفته سوم Simulator و Faultهای timeout/duplicate/version skew/Unicode را اجرا کنید؛ هفته چهارم Evidence Pack، layered verdict، denominator، Correction و review مستقل را تمرین کنید. معیار موفقیت تعداد Pass نیست: Unknown pair، Semantic escape، Time-to-triage، stale detection، reproducibility و Scope accuracy را بسنجید.

جمع‌بندی

تست قابلیت همکاری مراسم وصل‌کردن دو Endpoint نیست. یک Claim محدود و زنده است که طرف‌ها، نسخه‌ها، Profile، Matrix، تبادل، معنا، Workflow و Outcome را با Evidence قابل‌ردیابی پیوند می‌دهد. بلوغ واقعی در بزرگ‌کردن Badge نیست؛ در آشکار نگه‌داشتن Pairهای آزموده‌نشده، Unknownها، Lossها، Expiry و Correction است.

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

آیا پاسخ HTTP ۲۰۰ یعنی دو سیستم قابلیت همکاری دارند؟

خیر. ۲۰۰ فقط بخشی از Transport/Application exchange است. Syntax، Terminology، Meaning، Identity، State و Outcome می‌توانند Fail باشند.

فرق تست قابلیت همکاری و تست انطباق چیست؟

Conformance یک Subject را نسبت به Reference/Profile می‌سنجد؛ Interoperability رفتار یک ترکیب Party/Version/Role/Workflow را با طرف دیگر می‌سنجد. هیچ‌کدام خودکار جای دیگری نیست.

آیا قابلیت همکاری همیشه دوطرفه است؟

خیر. تعامل می‌تواند یک‌طرفه، request/response، publish/subscribe یا چندمرحله‌ای باشد. Direction و Role هر leg باید در Claim و Matrix مشخص شوند.

آیا Pass یک Vendor با یک نسخه به نسخه‌های دیگر تعمیم دارد؟

نه بدون Evidence و Selection basis. Build، Config، Profile، Adapter و Workflow می‌توانند نتیجه را عوض کنند؛ Pairهای دیگر باید Tested، Unsupported یا Unknown بمانند.

حداقل محتوای Interoperability Evidence Record چیست؟

Claim، Party/Role/Direction، Build/Config، Profile/Capability، Matrix، Workflow/Outcome، Environment، Test/Oracle، layered verdict، denominator/gaps، evidence digests، Decision، Expiry، limitations و Correction history.

تست یکپارچه

تست قابلیت همکاری؛ از Matrix تا Outcome