مسئولیت قانونی نرم‌افزار؛ Obligation تا Evidence

پاسخ کوتاه: تست نرم‌افزار نه بیمهٔ حقوقی است، نه مسئولیت را منتقل می‌کند و نه به‌تنهایی Due Diligence، انطباق یا دفاع موفق را ثابت می‌کند. کار ارزشمند QA این است که یک الزامِ شناسایی‌شده را به Control، سؤال آزمون، شواهد دارای منشأ، Finding و تصمیم نسخه‌دار متصل کند؛ با محدوده و چیزهایی که اثبات نشده‌اند. خروجی این راهنما یک Software Obligation Evidence Record است؛ ورودی قابل‌ممیزی برای مالک ریسک و مشاور حقوقی، نه نظر حقوقی.

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

مالکیت این مقاله: زنجیرهٔ Obligation تا Evidence

موضوع این مقاله «چه کسی قانوناً مسئول است؟» نیست؛ پاسخ آن به حوزه، نقش، محصول، قرارداد، رفتار، زمان، آسیب و مرجع رسیدگی وابسته است. موضوع عملی مقاله این است: وقتی Legal/Compliance/Contract owner یک Obligation candidate را شناسایی می‌کند، تیم محصول چگونه آن را تا Control، Test، Evidence، Finding، Release decision و Correction قابل‌ردیابی نگه دارد؟

برای تعیین شمول و ادعای محدود دسترس‌پذیری، راهنمای Applicability و Conformance Claim را بخوانید. دادهٔ شخصی در محیط تست مالکیت حریم خصوصی دادهٔ تست است؛ تعهدهای مجوز Dependency به پروندهٔ مجوز متن‌باز تعلق دارد. این صفحه آن‌ها را دوباره تعریف نمی‌کند؛ Evidence مربوط را به پروندهٔ تعهد متصل می‌کند.

پنج ادعای قدیمی که باید حذف شوند

«تست جامع و مستند قوی‌ترین مدرک Due Diligence است»؛
«امضای UAT بخشی از مسئولیت را به مشتری منتقل می‌کند»؛
«نادیده‌گرفتن Regression به‌راحتی مصداق Negligence است»؛
«اگر مستند نشده، از نظر حقوقی رخ نداده است»؛
«QA یک بیمه‌نامه یا سپر محکم در برابر دعواست».

هر پنج عبارت، نتیجهٔ حقوقی را از یک Artifact فنی استنتاج می‌کنند. Test ممکن است ناقص، نامرتبط، قدیمی یا بدون Oracle معتبر باشد؛ سند ممکن است خلاف واقع، دست‌کاری‌شده یا خارج از Context باشد؛ UAT ممکن است استثنا و حق‌های باقی‌مانده داشته باشد؛ و مسئولیت ممکن است به قانون آمره، قرارداد، نقش، Cause و Harm وابسته باشد. QA باید کیفیت Evidence را توضیح دهد، نه نتیجهٔ دعوا را.

Liability، Compliance و Risk Reduction یکی نیستند

مفهوم	پرسش	QA چه می‌دهد؟	QA چه نمی‌دهد؟
Liability	آیا یک شخص/نهاد در برابر خسارت مسئول است؟	Fact و Evidence فنی محدود	حکم مسئولیت، تقصیر، سببیت یا خسارت
Compliance	آیا الزامات قابل‌اعمال رعایت شده‌اند؟	نتیجهٔ آزمون Controlهای مشخص	تعیین Applicability یا ادعای کلی انطباق
Risk reduction	آیا احتمال/پیامد سناریو تغییر کرده؟	Signal و Counterevidence	ریسک صفر یا تضمین عدم حادثه
Due diligence	رفتار مورد انتظار در Context چه بوده؟	رکورد Practice و Decision	Verdict حقوقی یا دفاع تضمینی
Acceptance	آیا معیار توافق‌شده برای Scope مشخص پذیرفته شد؟	Evidence و استثناهای UAT	Waiver یا انتقال عمومی مسئولیت

زنجیرهٔ اصلی را قابل‌ردیابی کنید

Instrument / Contract / Policy
  → Applicability candidate
  → Obligation / Required outcome
  → Risk scenario / Control
  → Test question / Oracle / Scope
  → Evidence / Result / Unknown
  → Finding / Response / Verification
  → Decision / Residual risk / Conditions
  → Monitoring / Correction / Supersession

این زنجیره به معنی اثبات حقوقی نیست. هدفش جلوگیری از دو شکاف است: Requirementی که هیچ Control قابل‌مشاهده ندارد و Testی که معلوم نیست به کدام Outcome متصل است. هر پیکان باید نسخه، Owner، زمان و محدودیت داشته باشد.

Instrument را پیش از تفسیر نام‌گذاری کنید

قانون، مقرره، دستورالعمل مرجع، قرارداد، SLA، استاندارد، Scheme ارزیابی انطباق و سیاست داخلی قدرت و دامنهٔ یکسان ندارند. برای هر Instrument، عنوان رسمی، صادرکننده، نوع، حوزه، نسخه، تاریخ اثر/اعمال، URL رسمی، وضعیت انتقال به قانون ملی و تاریخ مشاهده را نگه دارید. خلاصهٔ وبلاگ یا ترجمهٔ غیررسمی جای متن جاری را نمی‌گیرد.

Applicability یک Snapshot است، نه حدس از صنعت

اینکه محصول «مالی»، «سلامت»، «AI» یا «SaaS» است برای تعیین قانون کافی نیست. Legal entity، نقش، بازار، محل عرضه/اثر، کاربر، نوع داده، فعالیت، تاریخ، نسخه، بخش مستثنا، رابطهٔ قراردادی و قانون ملی را ثبت کنید. وضعیت می‌تواند APPLIES / DOES_NOT_APPLY / PARTIAL / UNKNOWN / QUALIFIED_REVIEW باشد؛ QA نباید Unknown را به Yes تبدیل کند.

مثال GDPR: Test بخشی از یک الزام مشروط است

مادهٔ ۳۲ GDPR با توجه به State of the art، هزینه، ماهیت/Scope/Context/Purpose پردازش و Risk حقوق و آزادی اشخاص، اقدامات فنی و سازمانی متناسب می‌خواهد. بند ۱(d) فرایندی برای Testing، Assessing و Evaluating منظم اثربخشی اقدامات امنیتی را در میان گزینه‌های «as appropriate» می‌آورد. این متن نمی‌گوید Pen Test پاس‌شده مساوی Compliance است و شمول GDPR برای هر شرکت ایرانی خودکار نیست.

مثال CRA: Role، Product، Timeline و Procedure مهم‌اند

طبق خلاصهٔ رسمی Cyber Resilience Act، تعهدهای اصلی متوجه Manufacturer محصول دارای عنصر دیجیتالِ عرضه‌شده در بازار اتحادیه است و Scope/استثنا و Roleهای Importer/Distributor جدا هستند. Risk assessment، الزامات ضروری، Technical documentation، Conformity assessment، Support period و Vulnerability handling یک بسته‌اند؛ اجرای چند اسکن به‌تنهایی آن بسته را تکمیل نمی‌کند.

در تاریخ این بازبینی، بخش Notification نهادهای ارزیابی از ۱۱ ژوئن ۲۰۲۶ اعمال شده؛ تعهدهای گزارش CRA از ۱۱ سپتامبر ۲۰۲۶ و اجرای کامل از ۱۱ دسامبر ۲۰۲۷ زمان‌بندی شده است. این تاریخ‌ها باید در رکورد با as-of=2026-08-13 و Change watch ذخیره شوند؛ مقاله نباید یک الزام آینده را «هم‌اکنون کاملاً لازم‌الاجرا» معرفی کند.

مثال Product Liability Directive: نرم‌افزار در Scope آمده، اما با شرط

Directive (EU) 2024/2853 رژیم مسئولیت محصول اتحادیه را برای محصولات از جمله Software به‌روز می‌کند؛ اما مادهٔ ۲ آن را برای محصولاتی که پس از ۹ دسامبر ۲۰۲۶ در بازار قرار می‌گیرند یا به خدمت گرفته می‌شوند اعمال می‌کند و Free/Open-source خارج از فعالیت تجاری را مستثنا می‌داند. Directive به انتقال ملی نیاز دارد و حقوق قراردادی/غیرقراردادی ملی دیگر را کنار نمی‌زند. پس «Software مشمول است» آغاز تحلیل است، نه پایان آن.

مثال ایران: مادهٔ ۷۸ را بیش از متنش گسترش ندهید

مادهٔ ۷۸ قانون تجارت الکترونیکی دربارهٔ خسارت در بستر مبادلات الکترونیکی بر اثر نقص یا ضعف سیستم مؤسسات خصوصی/دولتی و استثنای فعل شخصی متن مشخصی دارد. از آن نمی‌توان بدون تحلیل، یک قاعدهٔ جهانی برای هر Software، هر Defect، هر شخص و هر خسارت ساخت. «بستر»، «نقص یا ضعف»، انتساب، فعل شخصی، ضرر، رابطهٔ سببیت و مقررات دیگر نیازمند بررسی پرونده‌ای و حقوقی‌اند.

قانون مسئولیت مدنی نیز Test checklist نیست

مادهٔ ۱ قانون مسئولیت مدنی ایران از لطمهٔ بدون مجوز، عمد یا بی‌احتیاطی و ضرر مادی/معنوی سخن می‌گوید؛ مواد بعدی نیز رسیدگی و اوضاع‌واحوال را دخیل می‌کنند. یک Team نمی‌تواند از «Regression اجرا نشد» مستقیماً «بی‌احتیاطی و مسئولیت ثابت شد» نتیجه بگیرد. همان‌طور که Regression پاس‌شده نیز Cause، Damage یا مسئولیت را منتفی نمی‌کند.

Obligation را به Outcome قابل‌بررسی تبدیل کنید

ObligationID / InstrumentID / Clause / Version
ObligatedParty / Role / Subject / Trigger / RequiredOutcome
EffectiveAt / AppliesAt / Deadline / Frequency / Duration
OfficialSource / ApplicabilityStatus / Assumptions / Exceptions
EvidenceExpected / DecisionAuthority / QualifiedReviewer
NotInterpreted / AsOf / ChangeWatch / Supersedes

RequiredOutcome باید به زبان مرجع وفادار بماند. اگر Clause «اقدامات متناسب با Risk» می‌خواهد، آن را به «هر فصل Pentest» تقلیل ندهید. اگر Contract Availability را با فرمول مشخص می‌سنجد، Load test فقط پیش‌بینی است؛ گزارش عملیاتی همان Window ممکن است Evidence متفاوتی باشد.

قانون، قرارداد و Policy را در یک ستون نریزید

منبع	نمونهٔ Owner	Evidence ممکن	خطر ساده‌سازی
Law/Regulation	Legal/Compliance	Control operation و assessment	تبدیل متن متناسب/مشروط به Checklist ثابت
Contract/SLA	Contract owner + Counsel	Acceptance، SLI، Notice	نادیده‌گرفتن تعریف، استثنا و governing law
Standard/Scheme	Assurance owner	Conformity artifacts	نامیدن Guideline به‌عنوان قانون
Internal policy	Policy owner	Process/approval records	فرض اینکه Policy قانون خارجی را کامل می‌کند
Test strategy	QA/Test owner	Risk-to-evidence map	صدور ادعای Compliance از Pass rate

Role Map مانع «مسئولیت توسعه‌دهنده» مبهم می‌شود

Producer، Manufacturer، Provider، Controller، Processor، Supplier، Integrator، Operator، Customer و End user همیشه یک شخص نیستند و واژه‌ها در Instrumentهای مختلف معنای خاص دارند. Legal entity و Role را کنار هر Obligation ذخیره کنید. نام تیم فنی، مالک قانونی یا طرف قرارداد را به‌صورت خودکار تعیین نمی‌کند.

Contract Snapshot قبل از UAT

ContractID/version، Parties، Governing law، Scope، Promise، Acceptance criteria، SLA، Warranty، Limitation، Indemnity، Notice، Audit، Change و Survival را به‌صورت ارجاع نگه دارید؛ تفسیر را به Counsel بدهید. Test team می‌تواند معیار قابل‌آزمون و تناقض را مشخص کند، اما اثر حقوقی Clause یا اعتبار Limitation را تعیین نمی‌کند.

UAT پذیرش محدود است، نه انتقال خودکار مسئولیت

یک Sign-off بدون Criteria version، Participant authority، Environment، Data، Scope، Exception، Open item و معنای قراردادی مبهم است. حتی Sign-off صحیح ممکن است فقط بگوید Journeyهای مشخص در Snapshot معین پذیرفته شدند. برای طراحی Artifact به راهنمای UAT تصمیم‌محور مراجعه کنید؛ از آن Waiver، پذیرش Defect پنهان یا انتقال مسئولیت را استنتاج نکنید.

SLA را با Test پیش‌بینی جایگزین نکنید

Load/Stress/Resilience test دربارهٔ مدل بار، محیط و Faultهای مشخص Evidence می‌دهد. SLA ممکن است SLI، Window، Exclusion، Maintenance، Time zone، Measurement source، Credit و Notice تعریف کند. Pass آزمایش پیش‌تولید تضمین نمی‌کند SLO عملیاتی در آینده رعایت می‌شود؛ Monitoring واقعی نیز بدون تعریف قراردادی، نتیجهٔ حقوقی صادر نمی‌کند.

Risk Scenario را قبل از Test Type بنویسید

ScenarioID / Asset / Stakeholder / Event
CauseCandidates / ExposurePath / HarmCandidate
LikelihoodRange / SeverityRange / Duration / Reversibility
ExistingControls / Assumptions / Uncertainty / TimeHorizon
ObligationLinks / ContractLinks / DecisionNeeded

فهرست ثابت «Security، Performance، UAT و Regression» پاسخ هر ریسک نیست. Scenario تعیین می‌کند چه Quality attribute، چه Fidelity، چه Population و چه زمان لازم است. Accessibility، Localization، Financial correctness، Safety، Privacy، Interoperability، Maintainability یا Support/update ممکن است از Pen test مهم‌تر باشند.

Control پلی میان Obligation و Test است

ControlID، Purpose، Owner، Design، Implementation، Operation، Scope، Frequency، Dependency، Failure mode، Override و Change history را ثبت کنید. Test باید سؤال کند «این Control در این شرایط تا چه حد Outcome را پشتیبانی کرد؟» نه اینکه صرف وجود ابزار یا Pipeline را Compliance بداند.

Control Design با Operating Effectiveness فرق دارد

Design review می‌پرسد Control در صورت اجرای درست می‌تواند Risk را Address کند؟ Implementation review می‌پرسد ساخته و پیکربندی شده؟ Operating evidence می‌پرسد در Window واقعی کار کرده؟ یک Policy خوب، یک اسکرین‌شات تنظیمات یا یک Run موفق این سه را هم‌زمان ثابت نمی‌کند.

Test Contract باید Claim محدود داشته باشد

TestID / ControlID / ObligationLink / RiskLink
Question / Method / Oracle / Population / Sample
Environment / Build / Configuration / Data / Preconditions
Window / Independence / ToolVersion / MethodVersion
Expected / PassRule / UnknownRule / Limitations / NotProven

«Security test passed» بدون Asset، Authorization، Method، Coverage و Findingهای باز یک Label است. «Regression ۹۸٪ pass» بدون Population و Risk mapping نمی‌گوید کدام Obligation پشتیبانی شده. TestID باید به Control و نسخهٔ Requirement وصل باشد و هر تغییر مهم Reassessment ایجاد کند.

Oracle از متن الزام کپی نمی‌شود

عبارت‌هایی مانند Appropriate، Reasonable، Secure، Timely یا Accessible نیازمند Interpretation و Decision authority هستند. QA نمی‌تواند خودسرانه آن‌ها را به Threshold تبدیل کند. Oracle باید منبع، Approver، نسخه، فرض‌ها، Error tolerance و چیزهای خارج از سنجش را نشان دهد؛ اختلاف نظر نیز ثبت شود.

Security testing فقط با Authorization

Instrument حقوقی، Risk بالا یا نیت دفاعی مجوز اجرای تست روی Target واقعی نیست. Authorization، Rules of Engagement، Asset/Activity/Time/Terms، Stop condition، Third-party boundary و Incident route را پیش از اقدام تثبیت کنید. Evidence امنیتی باید حداقلی باشد؛ دسترسی ناخواسته به Secret/PII توقف و مسیر امن می‌خواهد. برای اتصال Control امنیتی به Pipeline، راهنمای DevSecOps و Evidence مفید است.

دادهٔ واقعی، Evidence را خودکار بهتر نمی‌کند

Production dump یا لاگ کامل ممکن است Privacy، Confidentiality، Contract و Security risk تازه بسازد. Purpose، مجوز/مبنای Candidate، Minimization، Synthetic preference، Access، Retention، Delete، Transfer و Re-identification را کنترل کنید. «برای دفاع نگه می‌داریم» مجوز نامحدود جمع‌آوری یا نگهداری نیست.

Evidence با Document انباشته‌شده فرق دارد

EvidenceID، Claim، Source، Collector، Event time، Collection time، Environment، Build، Run، Tool/method version، Provenance، Integrity، Access، Retention، Redaction و Link به Counterevidence لازم‌اند. Test case بدون نتیجه، Screenshot بدون Context، Export قابل‌ویرایش و داشبورد زنده بدون Snapshot ممکن است برای تصمیم نامناسب باشند.

«اگر مستند نشده، اتفاق نیفتاده» را کنار بگذارید

نبود Record می‌تواند یک Control gap باشد، اما ثابت نمی‌کند Event رخ نداده یا Test اجرا نشده؛ همان‌طور که وجود Record صحت محتوا را ثابت نمی‌کند. عبارت دقیق‌تر این است: «برای Claim و Decision موردنظر، Evidence قابل‌اعتبارسنجی کافی در System of Record یافت نشد.» سپس Missing، مالک و مسیر اصلاح را ثبت کنید.

Integrity یعنی تاریخچهٔ قابل‌توضیح، نه فایل تغییرناپذیر ابدی

System of record، نقش‌های Write/Read، Audit trail، Hash/signature در صورت نیاز، Clock، Backup، Export و Chain of custody باید متناسب باشند. خطا را نباید برای حفظ ظاهر پاک کرد؛ Correction با Actor، زمان، دلیل، مقدار قبل/بعد و اثر بر Decision ثبت شود. Legal hold و Retention/deletion را Counsel/Records owner تعیین می‌کند.

Result پنج‌حالته از Pass/Fail سالم‌تر است

SUPPORTED: Observation با Rule ثبت‌شده سازگار است؛
NOT_SUPPORTED: Observation با Expected ناسازگار است؛
INCONCLUSIVE: Evidence برای نتیجه کافی نیست؛
NOT_RUN: آزمون اجرا نشده یا معتبر آغاز نشده؛
OUT_OF_SCOPE: سؤال به Snapshot حاضر تعلق ندارد.

حتی SUPPORTED فقط Claim همان Test را پشتیبانی می‌کند. آن را به COMPLIANT، SAFE، NO LIABILITY یا DUE DILIGENCE PROVEN تغییر نام ندهید.

Coverage یک بردار است، نه درصد تزئینی

Requirement، Control، Risk، Population، Configuration، Time، Journey، Role، Data class و Failure mode Coverage را جدا کنید. ۱۰۰٪ Test-case execution ممکن است فقط ۳۰٪ Controlهای قابل‌اعمال یا یک Configuration را پوشش دهد. Exclusion و Negative space—آنچه هیچ Test مناسبی ندارد—باید کنار Coverage claim دیده شوند.

Regression Pass یعنی عدم مشاهده در محدوده

Regression suite دربارهٔ رفتارهای نمونه‌گیری‌شده، Oracle و Environment مشخص Evidence می‌دهد. Pass به معنی نبود Defect ناشناخته، نبود Regression خارج از Coverage یا رعایت همهٔ Obligationها نیست. Fail نیز بدون Cause analysis ثابت نمی‌کند تیم بی‌احتیاط بوده یا Damage رخ خواهد داد.

Finding را از Allegation حقوقی جدا کنید

FindingID / TestID / EvidenceIDs
Criteria / Condition / Difference / Confidence
RiskScenarioLink / ObligationLink / EffectCandidate
Cause=UNKNOWN unless investigated / Counterevidence
Owner / Response / Due / Verification / Status
NotClaimed = breach, negligence, causation, damage, liability

QA می‌تواند بگوید «Control X در Build Y و Scenario Z نتیجهٔ مورد انتظار را نداد». نباید بدون Authority بگوید «شرکت قانون را نقض کرده»، «این Negligence است» یا «این Defect موجب خسارت شد». چنین نتیجه‌هایی به تحلیل گسترده‌تر و گاه Expert/Court نیاز دارند.

Defect، Breach، Damage و Causation چهار گام‌اند

یک Defect فنی ممکن است هیچ Obligation قابل‌اعمالی را نقض نکند؛ یک Control gap ممکن است هنوز Damage ایجاد نکرده باشد؛ یک Damage ممکن است Causeهای جایگزین یا Intervening event داشته باشد. Timeline، Exposure path، Alternative causes و Contribution را حفظ کنید و Cause را تا بررسی معتبر UNKNOWN نگه دارید.

Supplier Evidence را به Trust badge تقلیل ندهید

Component/Supplier identity، Contract evidence، Attestation scope، SBOM/provenance، Update commitment، Support end، Vulnerability process و Assurance limits را ثبت کنید. گواهی، پرسشنامه یا «vendor says compliant» فقط در Scope و تاریخ خودش Evidence است. مسئولیت یا Risk داخلی با Outsource خودکار ناپدید نمی‌شود؛ برای مرز Contract/Coverage/Residual risk، راهنمای انتقال ریسک QA را ببینید.

NIST SSDF منبع Practice است، نه حکم مسئولیت

NIST SP 800-218 (SSDF 1.1) مجموعه‌ای سطح‌بالا از Practiceهای توسعهٔ امن برای کاهش Vulnerability و اثر آن و بهبود ارتباط تأمین‌کننده/خریدار ارائه می‌کند. NIST در ۲۰۲۵ Draft نسخهٔ ۱.۲ را نیز منتشر کرده، اما در تاریخ این مقاله نسخهٔ ۱.۱ همچنان Final است. SSDF را می‌توان برای Control map و vocabulary به کار برد؛ انطباق با آن به‌تنهایی قانون ایران، CRA، GDPR یا مسئولیت محصول را تعیین نمی‌کند.

Evidence جمع کنید، اما Data minimization را نشکنید

میل به «هرچه بیشتر، دفاع بهتر» می‌تواند Evidence pollution و Risk تازه بسازد. حداقل لازم برای Claim، Redaction، Segregation، Access expiry و Retention end را تعریف کنید. Credential، Secret، PAN/CVV2/OTP، دادهٔ سلامت، کدملی، محتوای خصوصی یا Material دارای Privilege را بدون Purpose و مجوز روشن وارد Test record نکنید.

Release Decision را از Legal Opinion جدا کنید

ReleaseDecisionID / Candidate / AsOf
EvidenceSnapshot / Supported / NotSupported / Unknown
OpenFindings / ObligationCandidates / ApplicabilityStatus
Options / ResidualRisk / RiskOwner / DecisionAuthority
LegalReviewStatus / SecurityReview / PrivacyReview
Decision / Rationale / Conditions / Monitoring / Expiry
NotClaimed = compliant, legally safe, no liability

QA Evidence را آماده و محدودیت را برجسته می‌کند؛ Product/Risk owner دربارهٔ گزینه و Risk تصمیم می‌گیرد؛ Counsel نظر حقوقی می‌دهد؛ نهاد/مرجع صلاحیت‌دار نتیجهٔ رسمی را در Scope خودش می‌گیرد. برای خروجی Evidence Snapshot، گزارش خلاصهٔ تست تصمیم‌محور را استفاده کنید.

Legal review یک مهر سبز مبهم نیست

Reviewer، Qualification/jurisdiction، Question، Facts supplied، Documents، Assumptions، Advice date، Scope، Limitations و Change trigger را ثبت کنید. عبارت «Legal approved» بدون Question و Snapshot قابل استفاده نیست. Advice محرمانه یا Privileged نیز نباید بی‌دلیل در Ticket عمومی کپی شود؛ فقط Status و Action مجاز را طبق Policy ذخیره کنید.

Operational evidence پس از Release ادامه دارد

Complaint، Incident، Field telemetry، Vulnerability، Update، Support period، Change، Recall/withdrawal candidate و Customer notice می‌توانند Snapshot پیش از Release را منقضی کنند. Owner، Threshold، Review cadence و Route را تعیین کنید. Telemetry نیز Purpose و Privacy boundary می‌خواهد؛ «برای مسئولیت» مجوز نظارت نامحدود نیست.

Incident route جای Defect workflow نیست

اگر Harm جاری، Exploitation، Data breach، Safety event یا Deadline گزارش مطرح است، Ticket عادی و Retest بعدی کافی نیست. Incident owner باید Containment، Preservation، Notice candidate و Legal/regulatory clock را ارزیابی کند. QA Timeline و Evidence فنی می‌دهد، اما Trigger قانونی یا Notification recipient را حدس نمی‌زند.

Automation فقط Completeness و Drift را کمک می‌کند

Automation برای Missing link، version mismatch، stale source، expired approval، Coverage gap، Evidence hash، deadline reminder و Supersession مفید است. نباید از Pass rate یا کلمات «GDPR/CRA/UAT» حکم Applicability، Compliance، Due diligence یا Liability بسازد. Gate پراثر نیازمند Context و Authority انسانی است.

AI می‌تواند خلاصه کند، نه رأی حقوقی بدهد

ارسال قرارداد، Advice، Evidence، Secret یا PII به مدل بیرونی بدون مجوز می‌تواند Disclosure تازه بسازد. Provider/model/version، Data route، Retention، Redaction، Prompt، Grounding و Human review را ثبت کنید. AI می‌تواند Missing field و Trace candidate پیشنهاد دهد؛ نباید Clause اختراع یا Risk/Compliance/Liability verdict تولید کند.

State Model جلوی «قانونی تأیید شد» را می‌گیرد

IDENTIFIED → SOURCE_VERIFIED → APPLICABILITY_REVIEW
APPLICABILITY_REVIEW → APPLIES | PARTIAL | DOES_NOT_APPLY | UNKNOWN
APPLIES/PARTIAL → OBLIGATION_MAPPED → CONTROL_MAPPED
CONTROL_MAPPED → EVIDENCE_PLANNED → EVIDENCE_COLLECTED
EVIDENCE_COLLECTED → SUPPORTED | NOT_SUPPORTED | INCONCLUSIVE
any active state → CHANGE_REVIEW | INCIDENT_ROUTE | ON_HOLD
decision → MONITORING → CLOSED | CORRECTED | SUPERSEDED

Transition باید Actor، زمان، Source و Rationale داشته باشد. SUPPORTED نتیجهٔ Evidence است، نه Legal status. CLOSED نیز به معنی حذف Record یا پایان مسئولیت نیست؛ فقط معیار Closure همان پرونده برآورده شده است.

Change Triggerها را از ابتدا تعریف کنید

تغییر قانون، Guidance، استاندارد یا Transposition؛
تغییر بازار، Role، Legal entity، Product یا Intended use؛
نسخه، Configuration، Supplier یا Data flow تازه؛
Incident، Complaint، Damage allegation یا Field evidence؛
شکست Control، Test method یا Monitoring؛
تغییر Contract/SLA/Acceptance/Warranty؛
Correction منبع، Evidence یا Advice.

Correction باید به تصمیم‌های متاثر برسد

CorrectionID، Reason، Old/New claim، Source، Affected decisions، Audience، Approver، Issued at، Distribution و Confirmation را ثبت کنید. فقط ویرایش Silent یک Dashboard کافی نیست. اگر Test اشتباه Pass شده، Instrument منقضی بوده یا Applicability عوض شده، Decision owner و مصرف‌کنندگان قبلی باید مطلع شوند.

آزمایش قطعی: هفت چراغ سبز جعلی

یک Validator مستقل و بدون Dependency با Node.js ۲۴.۱۸.۰ روی Fixture کاملاً ساختگی اجرا شد. Checker سطحی فقط دید Testing «جامع» است، مستندات کامل‌اند، Security scan و Regression پاس شده‌اند، UAT امضا شده، Critical defect شناخته‌شده‌ای نیست و Lawyer در پرونده ذکر شده؛ سپس به‌اشتباه نتیجه داد:

SUPERFICIAL=LEGALLY_DEFENSIBLE_AND_LIABILITY_REDUCED

ممیز قراردادی ۳۱۷ کنترل یکتا را در ۲۸ گروه بررسی کرد: Identity، Decision، Subject، Instrument، Applicability، Obligation، Contract، Role، Scenario، Control، Test، Evidence، Result، Finding، Coverage، Security، Privacy، Quality، Acceptance، Release، Causality، Supplier، Operation، Records، Communication، Governance، Lifecycle، Correction و Limits. هیچ‌کدام در Fixture سطحی نبود:

CONTROL_COUNT=317
AUDIT=HOLD-317
INDEPENDENT_BOUNDARY=qa-legal-conclusion:false:PASS

قاعدهٔ مستقل، نبود Legal conclusion صادرشده توسط QA را کنترل کرد و عمداً جزو Missingها نبود. پس از پرکردن تمام فیلدهای ساختاری با مقدارهای ساختگی و فعال‌کردن مرزهای No legal opinion/liability verdict/due-diligence verdict/compliance claim/zero risk/defense guarantee/responsibility transfer/causation finding، نتیجه چنین شد:

CORRECTED=READY_FOR_OBLIGATION_EVIDENCE_REVIEW-0
BOUNDARY=structure-only; no applicability, obligation, compliance,
due diligence, defect, breach, damage, causation, liability,
defense, risk acceptance, or legal correctness proven

چرا صفر Finding هنوز دفاع حقوقی نیست؟

ممکن است Instrument اشتباه، Applicability ناقص، Clause بد تفسیر، Oracle نامعتبر، Evidence ساختگی، Sample نامتناسب یا Authority نامناسب باشد. Validator فقط آمادگی ساختار برای Review را می‌سنجد. نتیجهٔ درست READY_FOR_OBLIGATION_EVIDENCE_REVIEW است؛ نه COMPLIANT یا NO LIABILITY.

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

برای تمرین، یک Checkout خیالی با Order، PaymentAttempt، PSP Stub، Callback، Ledger، Reconciliation و Notification فقط در حافظه/فایل محلی بسازید. Scenarioها شامل Timeout قبل/بعد از Commit ساختگی، Retry، Duplicate، Callback دیرهنگام، Reordering، Refund و Failure در Notification باشند. هیچ Network، Production، شرکت، کاربر، تراکنش، PSP یا بانک واقعی وجود ندارد.

سه Instrument ساختگی تعریف کنید: قرارداد نمایشی با Availability formula، Policy داخلی برای Duplicate handling و Requirement خیالی برای Retention. هدف، نگاشت Instrument→Obligation→Control→Test→Evidence→Decision است؛ نه شبیه‌سازی قانون ایران یا بانکداری. هر Instrument با برچسب FICTIONAL / NOT LEGAL TEXT ذخیره شود.

شناسه‌های Entity/Product/Instrument/Obligation/Control/Test/Run/Evidence/Finding/Decision پایدار و ساختگی‌اند. مبلغ فقط IRR تخیلی و تومان صرفاً نمایش برچسب‌خورده است. ارقام فارسی/عربی/لاتین، ی/ی، ک/ک، ZWNJ، RTL/LTR/Bidi، زمان UTC و نمایش Asia/Tehran و تاریخ جلالیِ صرفاً نمایشی آزموده می‌شوند. هیچ PII، نام، کدملی، موبایل، ایمیل، IP، PAN، CVV2، OTP، حساب، Cookie، Token، Credential، Log یا Screenshot واقعی وارد Lab نمی‌شود.

LabBoundary = {
  network: false,
  production: false,
  realLawOrContract: false,
  realPersonOrOrganization: false,
  realPaymentOrPersonalData: false,
  legalOpinion: false,
  purpose: "validate obligation-to-evidence trace only"
}

تمرین سه‌مرحله‌ای بدون پروندهٔ واقعی

یک Clause کاملاً ساختگی را به Required outcome و Control نسخه‌دار تبدیل کنید.
برای Control، Test question/Oracle/Population/Unknown rule بسازید و دو Evidence متعارض تولید کنید.
نتیجه را Inconclusive نگه دارید، Optionهای Decision را مقایسه و سپس با Fact تازه Correction/Supersession اجرا کنید.

تمرین موفق آن نیست که همه‌چیز Pass شود؛ موفقیت یعنی تیم بتواند توضیح دهد چه چیزی مشاهده شد، چه چیزی مجهول ماند، چه کسی اختیار تصمیم داشت و Correction چگونه به مصرف‌کنندهٔ Evidence رسید.

Anti-patternهایی که باید رد شوند

«Test پاس شد، پس قانون رعایت شده»؛
«UAT امضا شد، پس مسئولیت منتقل شد»؛
«Regression اجرا نشد، پس Negligence ثابت است»؛
«مدرک زیادتر همیشه دفاع بهتر است»؛
«اگر ثبت نشده، رخ نداده»؛
«Pen test مهم‌ترین کنترل هر قانون است»؛
«GDPR برای هر نرم‌افزار ایرانی اعمال می‌شود»؛
«CRA اکنون کامل برای همهٔ Appها لازم‌الاجراست»؛
«Directive مسئولیت محصول مستقیماً قانون همهٔ کشورهاست»؛
«مادهٔ ۷۸ پاسخ هر خسارت نرم‌افزاری است»؛
«Legal approved یعنی بدون Risk»؛
«گواهی Vendor مسئولیت ما را حذف می‌کند»؛
«Pass rate یعنی Coverage تعهد»؛
«Compliance score را می‌توان از ابزار گرفت»؛
«Finding فنی همان Breach است»؛
«Defect همان Cause خسارت است»؛
«Policy داخلی جای Contract/Law را می‌گیرد»؛
«Legal hold یعنی نگهداری ابدی همهٔ داده‌ها»؛
«AI می‌تواند Clause و Liability را تفسیر نهایی کند»؛
«QA باید دفاع حقوقی را تضمین کند».

چک‌لیست Owner پیش از Evidence Review

RecordID، نسخه، Owner، as-of و Supersession روشن است.
Decision question، Optionها، Authority و Not-deciding ثبت شده‌اند.
Legal entity، Product/version، Market، Role، Lifecycle و Third party مشخص‌اند.
Instrument رسمی، نوع، Clause، تاریخ اثر/اعمال و Change watch دارد.
Applicability با Nexusها، Exception، Assumption و Reviewer چندحالته است.
Obligated party، Trigger، Required outcome، Deadline و Evidence expected روشن‌اند.
Contract/SLA/UAT فقط در Scope و معنای نسخه‌دار استفاده شده‌اند.
Scenario، Harm candidate، Exposure، Control و Uncertainty متصل‌اند.
Control design/implementation/operation از هم جدا شده‌اند.
Test دارای Question، Oracle، Population، Sample، Build، Data و Limit است.
Security test مجوز، Scope، Stop و Route دارد.
Test data حداقلی، مجاز، محدود و دارای Delete/Retention است.
Evidence دارای Provenance، Integrity، Access، Redaction و Counterevidence است.
Supported/Not-supported/Inconclusive/Not-run/Out-of-scope حفظ می‌شوند.
Coverage برداری و Negative space قابل مشاهده است.
Finding از Breach، Negligence، Cause، Damage و Liability جدا است.
Supplier claim با Scope/time/limits نگه داشته شده است.
Release decision، Risk owner، Condition، Monitoring و Expiry دارد.
Legal review به Question/Facts/Snapshot متصل است، نه مهر مبهم.
Incident/Complaint/Field evidence مسیر Reassessment دارند.
System of record، Audit trail، Retention، Legal hold و Correction کنترل شده‌اند.
هیچ Compliance، Due diligence، دفاع، انتقال مسئولیت یا Zero-risk ادعا نشده است.

Pilot سی‌روزهٔ Obligation-to-Evidence

هفتهٔ اول: یک محصول و حداکثر سه Instrument/Contract candidate را با Counsel/Owner روی پرونده‌های Sanitized انتخاب و Applicability/Role map را بسازید. هفتهٔ دوم: پنج Obligation را به Risk/Control/Test trace کنید. هفتهٔ سوم: Evidence provenance، Coverage و Unknown را ممیزی و یک Decision tabletop اجرا کنید. هفتهٔ چهارم: تغییر Instrument یا Evidence را تزریق و Correction/Supersession را تا همهٔ مصرف‌کنندگان تمرین کنید.

شاخص Pilot تعداد Test یا Pass rate نیست. درصد Obligationهای دارای Source/as-of/Owner، Control بدون Test، Test بدون Obligation، Evidence بدون Provenance، Unknown پنهان، Decision بدون Authority، منبع stale، Correction تاییدنشده و دادهٔ بیش‌ازحد را بسنجید. این معیارها برای رتبه‌بندی افراد یا ادعای Compliance نیستند.

منابع چگونه استفاده شده‌اند؟

GDPR Article ۳۲ فقط برای نشان‌دادن پیوند Risk/اقدام متناسب/ارزیابی منظم اثربخشی؛ CRA برای اهمیت Role، Scope، Risk assessment، Technical documentation، Conformity procedure، Support/Vulnerability lifecycle و تاریخ‌های متفاوت اجرا؛ Directive ۲۰۲۴/۲۸۵۳ برای نشان‌دادن ورود Software به Scope یک رژیم خاص با تاریخ/استثنا/انتقال ملی؛ قوانین ایران برای توجه به متن، ضرر، انتساب و اوضاع پرونده؛ و NIST SSDF برای Practice و Vocabulary توسعهٔ امن استفاده شده‌اند. هیچ‌کدام Checklist جهانی یا نظر حقوقی این مقاله نیستند.

جمع‌بندی

نقش حرفه‌ای تست در ریسک مسئولیت، ساختن «سپر» نیست؛ ساختن شواهد صادقانه و قابل‌تصحیح است. Instrument و Applicability پیش از Obligation، Obligation پیش از Control، Control پیش از Test، Test پیش از Claim، و Evidence/Unknown پیش از Decision می‌آیند. نتیجهٔ خوب پرونده‌ای است که Owner و Counsel بتوانند هم آنچه را پشتیبانی شده ببینند و هم فاصله، عدم‌قطعیت و تاریخ انقضای آن را—بدون اینکه QA حکم قانون صادر کند.

سوالات متداول

آیا تست جامع می‌تواند Due Diligence را ثابت کند؟

به‌صورت عمومی خیر. «جامع» بدون Obligation، Risk، Scope، Oracle و زمان معنا ندارد و Due diligence یک نتیجهٔ حقوقی/زمینه‌ای است. Test record می‌تواند بخشی از Fact pattern باشد؛ متخصص واجد صلاحیت باید آن را کنار قانون، قرارداد، Practice، تصمیم‌ها، Cause و Harm بررسی کند.

آیا امضای UAT مسئولیت را به مشتری منتقل می‌کند؟

چنین قاعدهٔ عمومی وجود ندارد. اثر Sign-off به Contract، Authority، Scope، Criteria، Exception، Defect، Warranty، قانون قابل‌اعمال و واقعیت پرونده وابسته است. QA فقط Acceptance evidence و محدودیت‌هایش را ثبت می‌کند و انتقال یا Waiver را اعلام نمی‌کند.

کدام نوع تست برای کاهش ریسک قانونی مهم‌تر است؟

نوع ثابت جهانی وجود ندارد. ابتدا Applicability، Required outcome و Risk scenario را روشن کنید؛ سپس Control و Test مناسب را انتخاب کنید. ممکن است Security، Accessibility، Financial correctness، Safety، Reliability، Privacy، Localization، Interoperability یا Operational monitoring اولویت داشته باشد.

آیا نگهداری همهٔ لاگ‌ها و نتایج، دفاع را قوی‌تر می‌کند؟

لزومی ندارد و می‌تواند Risk تازه بسازد. Evidence باید Purpose، حداقل لازم، Provenance، Integrity، Access، Retention، Redaction و Delete/Legal-hold rule داشته باشد. دربارهٔ پروندهٔ واقعی و Material محرمانه/دارای Privilege از Counsel و Records/Privacy owner راهنمایی بگیرید.

QA در پروندهٔ مسئولیت نرم‌افزار دقیقاً چه می‌گوید؟

QA می‌گوید کدام سؤال، روی کدام نسخه/محیط/Population، با چه Oracle و Method آزموده شد؛ چه Observation و Evidence به دست آمد؛ Coverage و Unknown چه بود؛ و کدام Finding نیازمند تصمیم یا Verification است. QA به‌تنهایی Compliance، تقصیر، سببیت، خسارت، مسئولیت یا دفاع حقوقی را تعیین نمی‌کند.

تست امنیت

تست و مسئولیت قانونی نرم‌افزار؛ از Obligation تا Evidence