تست قابلیت نگهداری؛ Metric تا Change Trial

پاسخ کوتاه: تست قابلیت نگهداری نرم‌افزار یعنی سنجش یک ادعای محدود دربارهٔ آسانی تحلیل، تغییر و راستی‌آزمایی یک محصول مشخص؛ نه نگاه‌کردن به یک امتیاز سبز و اعلام «کد قابل نگهداری است». یک ارزیابی قابل دفاع، نشانه‌های ساختاری را با Change Trial واقعی اما کنترل‌شده پیوند می‌دهد: یک تغییر نماینده را تعریف می‌کند، زمان فعال و انتظار را جدا می‌سنجد، سطح اثر و بازکاری را ثبت می‌کند، رفتار را قبل و بعد می‌آزماید و نتیجه را فقط به همان Build، Task، نمونه و بازه نسبت می‌دهد.

در این راهنما از تعریف ادعا تا Maintainability Evidence Record، انتخاب Change Task، Baseline، Metric، Testability، Code Review، نتیجهٔ لایه‌ای و تصمیم بازبینی‌پذیر پیش می‌رویم. یک آزمایش آفلاین فارسی نیز نشان می‌دهد چرا Maintainability Index سبز، Lint بدون Finding، Unit Test پاس و وجود مستندات هنوز اثبات نگهداشت‌پذیری یا ریسک پایین نیست.

تست قابلیت نگهداری دقیقاً چه چیزی را می‌سنجد؟

Maintainability یک Construct چندبعدی است. سؤال کاربردی این نیست که «این Repository خوب است؟»؛ بلکه این است: «آیا تیم مجاز می‌تواند نوع معینی از تغییر را در این نسخه، با effort، دامنهٔ اثر، خطا و زمان بازخورد پذیرفتنی انجام دهد؟» پاسخ به Subject، نوع تغییر، مهارت و آشنایی مشارکت‌کننده، ابزار، محیط، Oracle و معیار پذیرش وابسته است.

مدل رسمی ISO/IEC 25010:2023 یک مدل مرجع برای مشخص‌کردن و ارزیابی ویژگی‌های کیفیت محصول ICT ارائه می‌کند. این مدل واژگان و لنز می‌دهد؛ اما به‌تنهایی Threshold پروژه، ابزار، نمونه، Change Task یا Verdict شما را تعیین نمی‌کند. برای جایگاه این موضوع میان کیفیت‌های غیرکارکردی، راهنمای تست غیرکارکردی مرز کلی را نگه می‌دارد.

اسلاگ «ذخیره‌سازی بلندمدت» چرا اشتباه بود؟

Long-term storage testing معمولاً به دوام، خوانایی، Retention، Media degradation، Format migration، Integrity و بازیابی داده مربوط است. محتوای این صفحه دربارهٔ Maintainability کد و محصول است. یکی‌گرفتن این دو Intent هم کاربر را گمراه می‌کند و هم Keyword اشتباه می‌سازد. این بازنویسی مالک «Software Maintainability Change Trial» است و هیچ ادعایی دربارهٔ آرشیو یا ماندگاری رسانه ندارد.

مرز Maintainability با مفاهیم نزدیک

مفهوم	پرسش مالک	چیزی که به‌تنهایی ثابت نمی‌کند
Maintainability	تحلیل، تغییر و Verification این Subject چقدر قابل انجام است؟	ارزش کسب‌وکار یا نبود Defect
Testability	کنترل، مشاهده، Isolation و Oracle چقدر ممکن است؟	سهولت همهٔ انواع تغییر
Reliability	رفتار درست در زمان و شرایط تعریف‌شده چقدر پایدار است؟	سهولت فهم یا اصلاح کد
Operability	اجرا، مشاهده و مداخلهٔ عملیاتی چقدر قابل مدیریت است؟	Modifiability منبع
Portability/Adaptability	انتقال به محیط یا پلتفرم دیگر چگونه است؟	هزینهٔ تغییر منطق محصول
Technical Debt	چه تصمیم/ضعفی هزینه یا ریسک آینده می‌سازد؟	یک عدد قطعی بدهی مالی
کد تست قابل نگهداری	Test asset چگونه تغییر می‌کند؟	Maintainability محصول زیر تست

معماری Test Automation، Fixture، Page Object و Isolation در راهنمای کد تست قابل نگهداری مالک مستقل دارد. این مقاله Test code را فقط یکی از dependencyهای Change Trial می‌بیند.

ادعای قابل آزمون بنویسید، نه صفت کلی

«سامانه Maintainable است» Subject، Task و آستانه ندارد. ادعای بهتر می‌تواند چنین باشد: «در Build B-۱۷، تغییر قانون نمایش مبلغ برای دو Locale منتخب، توسط مشارکت‌کنندهٔ آشنا با زبان ولی ناآشنا با این Module، بدون تغییر API عمومی، با حداکثر چهار فایل Production، Build feedback زیر شش دقیقه، همهٔ Oracleهای رفتاری پاس و بدون Finding بحرانی Review انجام‌پذیر است.» این ادعا نیز فقط پس از اجرا Evidence می‌گیرد؛ جملهٔ قبل از اجرا Requirement است.

قالب Maintainability Claim

ClaimID: MC-017
Subject: repository/component/build/config digest
Change class: corrective | adaptive | perfective | preventive
Task/Scenario: CT-04 v2
Population/Sample: declared participant and task policy
Context: familiarity, language, tools, assistance policy
Measures: locate/change/verify/recover + touch/ripple/rework
Acceptance: threshold, unit, window, aggregation, missing policy
Guardrails: behavior, security, privacy, accessibility, operations
Exclusions: explicitly unsupported modules/change classes
Decision owner / expiry / change triggers: ...

Subject را تا سطح Build ثابت کنید

نام محصول کافی نیست. Repository/branch/commit، Artifact digest، Build، Feature flag، dependency lock، runtime، schema/migration، generated code، submodule، compiler و configuration مؤثر را ثبت کنید. اگر Trial روی commit دیگری اجرا شود، نتیجه قابل نسبت‌دادن به Release هدف نیست. Monorepo نیز به معنی یک Subject واحد نیست؛ Component و dependency boundary لازم است.

Change Task باید نماینده و قابل تکرار باشد

Task نمایشی مانند «نام متغیر را عوض کن» ممکن است فقط Search/Replace را بسنجد. از Change history، Incident، Roadmap، Support request و معماری، طبقات تغییر را استخراج کنید: اصلاح Defect، افزودن Rule، تغییر API، ارتقای dependency، migration داده، تغییر Locale، حذف capability، تغییر observability یا recovery. سپس با Risk×Frequency×Uncertainty نمونه بگیرید و سهم Unsupported را پنهان نکنید.

قالب Change Task Contract

TaskID / version / source / change class
Initial state and reproducible fixture
Request, rationale and acceptance examples
Allowed scope / forbidden scope / public-interface policy
Expected behavior and independent oracle
Risk and required guardrails
Start, stop, pause and abort rules
Allowed docs/tools/AI/assistance; disclosure policy
Deliverables: patch, tests, notes, evidence, rollback
Time budget; incomplete and blocked policy

Baseline بدون Comparability گمراه‌کننده است

مقایسهٔ دو دوره یا دو معماری وقتی معنا دارد که Task class، complexity، participant context، toolchain، environment، interruption policy و Definition of Done قابل‌مقایسه باشند. Faster بودن فرد آشنا نسبت به فرد تازه‌وارد، لزوماً اثر معماری نیست. Baseline را version کنید و هر تفاوت مهم را Change note بدهید؛ در نبود comparability، گزارش «Observed» است نه «Improved by ۳۰٪».

مشارکت‌کننده ابزار اندازه‌گیری نیست

Familiarity با domain/repository/language/framework، تجربهٔ نقش، دسترس‌پذیری، زبان مستندات، setup و allowed assistance بر نتیجه اثر دارد. داده را برای ارزیابی Product جمع کنید، نه رتبه‌بندی افراد. Consent، حداقل‌سازی داده، pseudonymous ParticipantID، retention و دسترسی را روشن کنید. اگر نمونه کوچک است، Distribution و محدودیت را نشان دهید؛ نام افراد یا leaderboard نسازید.

Environment و Toolchain را Pin کنید

OS/image، CPU/memory policy، IDE، compiler، package manager، lockfile، cache state، test runner، static analyzer/rule profile/version، network/dependency mirror و secret stub بر effort اثر دارند. زمان انتظار برای نصب خراب را با زمان تحلیل کد مخلوط نکنید؛ هر دو مهم‌اند اما Owner متفاوت دارند.

چهار ساعت متفاوت را جدا کنید

Active time: مشاهده، تحلیل، ویرایش و Verification فعال.
Elapsed time: فاصلهٔ تقویمی Start تا Done.
Wait time: Build، CI، Review، دسترسی یا dependency.
Blocked time: زمانی که ادامه بدون رفع مانع ممکن نیست.

یک عدد «Lead time» علت را پنهان می‌کند. Timestamp monotonic برای Duration و Instant UTC برای رویدادها نگه دارید؛ نمایش Asia/Tehran یا جلالی فقط Presentation باشد. Pause، interruption، context switch و بازگشت به Task سیاست صریح می‌خواهد.

Locate، Understand، Change و Verify را تفکیک کنید

Trial را به مرحله‌های Locate، Understand، Plan، Modify، Build، Test، Review، Fix و Recover تقسیم کنید. «زمان تکمیل» نمی‌گوید مشکل در کشف محل Rule بود یا CI بیست دقیقه طول کشید. Transition هر مرحله، شروع/پایان، دلیل Pause و Evidence را ثبت کنید؛ Observer نباید با راهنمایی ناخواسته Task را آسان کند.

Change Surface و Ripple را چگونه بسنجیم؟

Files changed یا LOC به‌تنهایی اندازهٔ مفهومی تغییر نیست. Module/service/schema/API/config/test/doc/migration را جدا کنید؛ Expected touch-set را پیش از Trial و Actual touch-set را پس از آن ثبت کنید. Unexpected dependency، public contract change، generated artifact، migration و cross-team handoff می‌توانند Ripple باشند. حذف صد خط شاید ساده‌تر از تغییر یک شرط حساس باشد؛ Direction metric را از پیش اعلام کنید.

Effort، Outcome نیست

تغییر سریع که رفتار را خراب کرده Success نیست. Completion فقط وقتی معتبر است که Acceptance oracle، tests، build، lint/static checks موردنیاز، Review و guardrailها به وضعیت تعریف‌شده رسیده باشند. Incomplete، Blocked، Aborted و Inconclusive را به Fail یا Pass تبدیل نکنید. Defect کشف‌شده پس از Trial نیز با Evidence و Window مشخص به Record برگردد.

Static Metric چه می‌گوید و چه نمی‌گوید؟

Complexity، coupling، duplication، dependency cycle، code smell، churn و ownership concentration می‌توانند Risk signal بسازند. اما ابزار معمولاً بخشی از زبان‌ها/Build path را می‌بیند، rule profile و threshold دارد و generated/vendor/test code را متفاوت حساب می‌کند. هر Finding باید Tool/version/rule/config/location/fingerprint و suppression rationale داشته باشد. مسیر عملی Warning تا Quality Gate در راهنمای تحلیل استاتیک کد جداست.

مستند رسمی Microsoft درباره Maintainability Index فرمول بازپایه‌گذاری‌شدهٔ ۰ تا ۱۰۰ و Threshold رنگ‌های همان ابزار را توضیح می‌دهد. بنابراین MI=۲۴ فقط طبق آن پیاده‌سازی «سبز» است؛ Universal truth، مقایسهٔ بی‌قید بین زبان/ابزار یا اثبات ease-of-change نیست.

عدد بالاتر همیشه بهتر نیست

کاهش LOC ممکن است منطق را فشرده و فهم را دشوار کند. تقسیم Function می‌تواند complexity محلی را کم اما navigation و coupling را بیشتر کند. Duplication محدود گاهی coupling نامناسب را جلوگیری می‌کند. Threshold را با Risk، language، component type و historical distribution تنظیم کنید؛ Gaming metric را با Change Trial، Review و behavioral evidence مهار کنید.

اندازه‌گیری محصول را با استاندارد اشتباه نگیرید

ISO/IEC 25023:2016 مجموعه‌ای پایه از Quality measureها و شیوهٔ کاربرد آن‌ها برای ویژگی‌های مدل کیفیت ارائه می‌کند. ارجاع به استاندارد باید edition، بخش قابل‌اعمال و mapping محلی را داشته باشد. نام ISO روی گزارش، Sample ناکافی، ابزار پیکربندی‌نشده یا Verdict بدون Evidence را معتبر نمی‌کند.

نشانه‌های معماری را کنار فعالیت نگهداشت بگذارید

پژوهش صنعتی Google دربارهٔ پیچیدگی معماری و بار نگهداشت سه دستهٔ measure—ساختار معماری، فعالیت نگهداشت و ادراک توسعه‌دهنده—را جدا بررسی می‌کند و در بیش از ۱۲۰۰ پروژهٔ C++/Java رابطه‌های آماری گزارش می‌دهد. این شواهد دامنه‌دار، آستانهٔ پذیرش برای Repository فارسی شما یا رابطهٔ علّی هر refactor منفرد نیست؛ درس روش‌شناختی آن، تک‌معیاری نبودن است.

Testability را عملیاتی کنید

برای Change هدف بپرسید: آیا Input قابل کنترل، state قابل reset، dependency قابل جایگزینی، clock/randomness قابل مهار، output و side effect قابل مشاهده و Oracle مستقل است؟ Setup time، test selection، feedback latency، flakiness، failure diagnostics و reproducibility را بسنجید. Coverage بالا بدون Oracle یا Isolation، Testability را اثبات نمی‌کند. طراحی و سنجش عمیق این ویژگی در راهنمای تست‌پذیری نرم‌افزار مالک مستقل دارد.

Analyzability را با Incident نمایشی یکی نکنید

در Task تشخیصی، Symptom، log/trace/metric، build/config و known facts را Pin کنید. زمان اولین Hypothesis، تعداد hypothesisهای آزموده‌شده، evidence-to-cause trace، false lead و time-to-reproduce را ثبت کنید. اگر Stack trace مستقیماً پاسخ را لو دهد، Task نماینده نیست؛ اگر هیچ observability داده نشود، شاید Operability را بسنجید نه ساختار کد.

Modularity و Coupling را با اثر تغییر بسنجید

Module boundary فقط Folder نیست. API، schema، event، shared database، config، build graph و ownership نیز coupling می‌سازند. برای Change Task، dependencyهای مورد انتظار/واقعی، interfaceهای تغییرکرده، consumer impact، هماهنگی لازم و rollback unit را ثبت کنید. Fan-out بالا یک نشانه است؛ Evidence اصلی این است که چرا تغییر از Boundary عبور کرد و چه پیامدی داشت.

Reusability هدف مستقل و همیشه مطلوب نیست

Generalization زودهنگام می‌تواند API، abstraction و compatibility burden اضافه کند. Reuse را با مصرف‌کنندهٔ واقعی، variation points، version policy، documentation، test و change impact بسنجید. «ممکن است روزی استفاده شود» Evidence نیست. برای طراحی پیش از پیاده‌سازی، راهنمای بازبینی طراحی و Verification مرز مکمل را پوشش می‌دهد.

Code Review یک Sensor است، نه مهر تضمین

Review duration، rounds، blocking comments، design clarification، test gap و rework را می‌توان ثبت کرد؛ اما complexity Task، availability و familiarity Reviewer را نیز باید دید. Approved بودن به معنی maintainable بودن نیست. دامنه، نقش Reviewer و unresolved concern را نگه دارید. برای خود Test artifact، راهنمای Peer Review تست‌کیس و کد تست مالک جزئیات است.

راهنمای مهندسی Google دربارهٔ Small CL مزایای Change کوچک و self-contained را شرح می‌دهد و هم‌زمان می‌گوید اندازه یک تابع ساده از تعداد خط نیست. این یک Practice سازمانی مفید است، نه قانون جهانی ۱۰۰ خط یا اثبات اینکه هر PR کوچک کم‌ریسک است.

مستندات را با Retrieval Task بسنجید

وجود README یک Boolean ضعیف است. از مشارکت‌کننده بخواهید Owner، entry point، domain rule، run command، dependency policy یا rollback را پیدا کند. زمان، مسیر جست‌وجو، پاسخ، confidence و source freshness را ثبت کنید. Documentation coverage، correctness و findability سه چیز متفاوت‌اند؛ Comment قدیمی می‌تواند تحلیل را بدتر کند.

Pipeline feedback را جزء مسیر تغییر ببینید

Build duration، queue، cache hit، selected tests، retry، flaky quarantine، artifact retention و failure diagnostics بر Verify effort اثر دارند. Retry سبز، نتیجهٔ اول را پاک نمی‌کند. Test Automation باید Contract، Oracle، lifecycle و Retirement داشته باشد؛ جزئیات آن در راهنمای Automated Check و Evidence آمده است.

نمونه و تکرار را از پیش طراحی کنید

یک Task و یک نفر فقط Case evidence می‌دهد. Task strata، participant policy و تعداد تکرار را پیش از دیدن نتیجه ثبت کنید. Median/quantile و range را کنار count نشان دهید؛ missing، censored و aborted را توضیح دهید. Learning و carryover با اجرای دوبارهٔ همان Task رخ می‌دهد؛ برای مقایسهٔ نسخه‌ها از Taskهای هم‌ارز، order balancing یا design مناسب استفاده کنید و محدودیت inference را صریح نگه دارید.

Metric Contract قبل از مشاهدهٔ نتیجه

MetricID / version / construct
Event source and timestamps
Numerator / denominator / unit / direction
Population / task stratum / window
Aggregation / uncertainty / minimum sample
Pause / missing / outlier / retry policy
Tool and extraction query version
Threshold rationale and guardrail
Owner / reviewer / change trigger

لایه‌های Verdict را مستقل نگه دارید

لایه	نمونهٔ Verdict	معنا
SUBJECT	VALID / STALE	هویت Build و config کامل است؟
TASK	REPRESENTATIVE / BOUNDED	Task برای Claim قابل استفاده است؟
ENVIRONMENT	COMPARABLE / INVALID	محیط و ابزار قابل بازتولید است؟
STATIC	PASS / FINDING / INCOMPLETE	Analyzer در Scope چه دید؟
CHANGE	PASS / FAIL / BLOCKED	تغییر با Oracle چه نتیجه‌ای داد؟
REVIEW	ACCEPTED / REWORK / DISSENT	Review چه Findingی داشت؟
CLAIM	SUPPORTED / NOT-SUPPORTED / INCONCLUSIVE	ادعای محدود چه وضعی دارد؟
DECISION	ACCEPT / IMPROVE / RETEST	مالک مجاز چه تعهدی ثبت کرد؟

Maintainability Evidence Record کپی‌پذیر

RecordID / version / status / supersedes
ClaimID; Subject and artifact/config digests
TaskID/class/risk/representativeness/exclusions
ParticipantID/context/consent/assistance; people_scoring=false
Environment/toolchain/analyzer/rule-profile
Baseline ID and comparability differences
Stage events: locate/understand/change/build/test/review/recover
Active/elapsed/wait/blocked + pause policy
Expected/actual touch-set; interface/dependency ripple
Behavioral oracle; static/test/review evidence
Finding/uncertainty/alternative explanations
Layered verdicts and unsupported/unknown scope
Decision/owner/action/due/exception
Expiry/change triggers/correction/withdrawal

از Finding تا تصمیم

Finding باید Observation، معیار نقض‌شده، Evidence reference، Scope، severity rationale و uncertainty داشته باشد. سپس Optionها را مقایسه کنید: accept bounded risk، refactor، add characterization test، improve diagnostics/docs، isolate dependency، split change، replace component یا schedule deeper trial. Tester/assessor Evidence readiness را می‌سنجد؛ مالک فنی/محصول/ریسکِ مجاز تصمیم و trade-off را امضا می‌کند.

Technical Debt را از برچسب به Record تبدیل کنید

هر Debt item باید Decision/origin، affected subject، consequence mechanism، evidence، principal estimate method، recurring interest signal، option، owner، review date و retirement evidence داشته باشد. «هر Code smell بدهی است» یا «MI پایین یعنی هزینهٔ X تومان» دفاع‌پذیر نیست. IRR را canonical و تومان را فقط نمایش برچسب‌خورده نگه دارید؛ نرخ تبدیل، تاریخ و uncertainty لازم است.

ROI و وعدهٔ کاهش هزینه را محدود کنید

Effort گذشته، نرخ نیروی انسانی، opportunity cost، incident loss و future change mix عدم‌قطعیت دارند. Improvement یک metric ساختاری، ROI را اثبات نمی‌کند. Baseline، cash/capacity treatment، horizon، scenario و sensitivity لازم است. هدف کیفی و Threshold نیز باید Construct روشن داشته باشد؛ راهنمای Goal–Construct–Evidence این مرز را پوشش می‌دهد.

آزمایش آفلاین فارسی: سبز اما غیرقابل دفاع

Fixture خیالی SYN-MAINTAINABILITY-CHANGE-01 یک Component ساختگی Checkout دارد. Dashboard می‌گوید MI=۲۴، Lint Finding=۰، Unit tests=PASS و DocumentationPresent=true؛ Checker سطحی فوراً GREEN_MAINTAINABLE_LOW_RISK می‌دهد. اما Task، Subject digest، participant context، environment، baseline، touch-set، Oracle، timing policy، Review evidence، uncertainty، decision و expiry ثبت نشده‌اند.

داده‌های فارسی/ایرانی Fixture

Task خیالی افزودن Rule نمایش مبلغ است: IRR canonical و «تومان» فقط presentation، رقم‌های فارسی/عربی/لاتین، ی/ی و ک/ک، ZWNJ و Bidi، Instant به UTC و نمایش Asia/Tehran/جلالی صرفاً نمایشی. سناریو timeout-before/after-fake-commit، retry، duplicate، late و reorder دارد. هیچ شبکه، Production، شرکت، Repository، توسعه‌دهنده، کاربر، سفارش، پرداخت، PSP، بانک، حساب، پول واقعی، PII، cookie، token، credential یا ادعای حقوقی/مالی/امنیتی ایرانی وجود ندارد.

Validator مستقل و قابل تکرار

const sizes={identity:22,claim:20,task:28,subject:24,participant:20,
 environment:19,baseline:20,execution:30,measurement:40,staticEvidence:24,
 changeEvidence:26,review:20,interpretation:24,decision:20,governance:20,boundaries:14};
const controls=Object.entries(sizes).flatMap(([g,n])=>
 Array.from({length:n},(_,i)=>`${g}.${String(i+1).padStart(2,'0')}`));
if(controls.length!==371||new Set(controls).size!==371) throw Error('CONTROL_SET');
const superficial='GREEN_MAINTAINABLE_LOW_RISK';
const audit=e=>{const n=controls.filter(k=>e[k]!=='PINNED').length;
 return n?`HOLD-${n}`:'READY_FOR_MAINTAINABILITY_REVIEW-0'};

خروجی آزمایش چه بود؟

CONTROL_COUNT=371
SUPERFICIAL=GREEN_MAINTAINABLE_LOW_RISK
AUDIT=HOLD-371
INDEPENDENT_TARGET=real-system-organization-repository-or-developer:false:PASS
CORRECTED=READY_FOR_MAINTAINABILITY_REVIEW-0

۳۷۱ کنترل از ۱۶ گروه با نام group-qualified و assertion یکتایی ساخته شدند؛ عدد حاصل تکرار نام یا padding نیست. پس از Pin شدن همهٔ فیلدهای Fixture، نتیجه فقط «آمادهٔ بازبینی Maintainability» است؛ نه اثبات نگهداشت‌پذیری عمومی، کیفیت معماری، هزینهٔ پایین، ROI، نبود Defect، توان تیم، رضایت توسعه‌دهنده، آمادگی Production یا واقعیت هر سامانه.

Evidence Pack حداقلی

Claim، Task و Metric contractهای versioned؛
commit/artifact/config/tool/analyzer digests؛
fixture و دستور setup/run/reset بدون Secret؛
stage-event log، pause/wait/block reasons و time source؛
patch، expected/actual touch-set و dependency trace؛
test/static/build/review outputs با exit code و timestamp؛
Finding، layered verdict، decision، expiry و Correction.

۲۰ Anti-pattern رایج

MI سبز مساوی Maintainable؛
صفر Code smell مساوی ریسک صفر؛
LOC یا Complexity به‌عنوان Outcome؛
مقایسهٔ Score دو زبان/ابزار بدون Contract؛
Threshold vendor به‌عنوان قانون جهانی؛
یک rename به‌عنوان Change نماینده؛
انتخاب Task پس از دیدن نتیجه؛
ترکیب Active، Wait و Blocked time؛
نادیده‌گرفتن Familiarity و Assistance؛
رتبه‌بندی افراد با زمان Task؛
حذف Run ناقص از denominator؛
Retry تا سبزشدن و پاک‌کردن Run اول؛
Files changed به‌عنوان اندازهٔ مفهومی؛
Coverage بالا به‌عنوان Testability؛
README موجود به‌عنوان Documentation quality؛
Approved PR به‌عنوان کیفیت قطعی؛
هر Duplication به‌عنوان Debt؛
Refactor و feature در یک Trial مبهم؛
تعمیم یک Component به کل Product؛
Record بدون expiry و Correction.

چک‌لیست ۱۸ موردی مالک ارزیابی

Claim محدود و falsifiable است؟
Subject تا Build/config Pin شده؟
Task class و منبع نمایندگی روشن است؟
Scope و Exclusion صریح‌اند؟
Participant context و privacy policy ثبت شده؟
people_scoring=false است؟
Environment و toolchain بازتولیدپذیرند؟
Baseline واقعاً comparable است؟
Active/elapsed/wait/blocked جدا هستند؟
Pause، missing، abort و retry policy قبل از Run ثبت شده؟
Expected و actual touch-set وجود دارد؟
Behavioral Oracle مستقل است؟
Static tool/version/profile و coverage معلوم است؟
Build/Test/Review evidence حفظ شده؟
Uncertainty و alternative explanation نوشته شده؟
Verdictها لایه‌ای هستند؟
Decision owner، action و due date روشن است؟
Expiry، change trigger و Correction مسیر دارند؟

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

هفتهٔ اول واژگان، Claim، privacy و سه Change class خیالی را طراحی کنید. هفتهٔ دوم Runner آفلاین، stage-event schema، metric contract و Evidence Pack را روی Fixture مصنوعی اجرا کنید. هفتهٔ سوم Taskهای هم‌ارز، missing/pause/retry و layered verdict را تمرین کنید. هفتهٔ چهارم یک Reviewer مستقل Recordها را Replay کند، اختلاف تفسیر را ثبت و schema را version کند. اتصال به Repository واقعی، telemetry کارکنان یا تصمیم سازمانی به مجوز، رضایت، امنیت و طراحی جدا نیاز دارد و در این Pilot نیست.

چه زمانی نتیجه را منقضی یا پس بگیریم؟

تغییر معماری، زبان/runtime، dependency major، build system، ownership، test framework، analyzer profile، module boundary یا Change mix می‌تواند Evidence را Stale کند. Expiry تقویمی و event-based هر دو لازم‌اند. اگر داده یا محاسبه غلط بود، Correction با Record قبلی، علت، دامنهٔ اثر، نسخهٔ اصلاحی و notification ثبت شود؛ تاریخچه را بی‌صدا بازنویسی نکنید.

جمع‌بندی اجرایی

تست قابلیت نگهداری یک اسکن دوره‌ای یا رأی سلیقه‌ای نیست. Claim و Change Task را محدود کنید، Subject/Baseline/Environment را Pin کنید، effort را مرحله‌ای بسنجید، static signal را کنار تغییر رفتاری و Review قرار دهید، Testability و ripple را مشاهده کنید و با Verdict لایه‌ای تصمیمی منقضی‌شونده بسازید. اگر فقط Dashboard سبز دارید، هنوز Indicator دارید؛ اگر Change Trial و Evidence قابل Replay دارید، می‌توانید یک ادعای محدود را بازبینی کنید.

سؤالات متداول تست قابلیت نگهداری

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

ارزیابی شواهدی است برای یک ادعای محدود دربارهٔ تحلیل، تغییر و Verification محصول مشخص. بهترین طراحی، metricهای ساختاری را با Change Task نماینده، effort مرحله‌ای، touch/ripple، رفتار، Review و محدودیت نمونه ترکیب می‌کند.

آیا Maintainability Index برای قبولی کافی است؟

خیر. MI به فرمول، زبان، ابزار و سطح aggregation وابسته است و عمدتاً ویژگی‌های منبع را خلاصه می‌کند. Threshold همان ابزار می‌تواند Signal بدهد، اما ease-of-change، documentation، test feedback، dependency ripple یا نتیجهٔ یک تغییر واقعی را به‌تنهایی اثبات نمی‌کند.

برای Change Trial چه Taskی انتخاب کنیم؟

از Change history و ریسک آینده، طبقات corrective/adaptive/perfective/preventive را بسازید و بر اساس Frequency×Risk×Uncertainty نمونه بگیرید. Task باید fixture، acceptance، Oracle، scope، ابزار مجاز و stop policy روشن داشته باشد؛ rename ساده نمایندهٔ همهٔ نگهداشت نیست.

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

هدف را ارزیابی Product قرار دهید، رضایت و حداقل‌سازی داده داشته باشید، ParticipantID مستعار بسازید، Active/Wait/Blocked را جدا کنید و نتیجه را برای رتبه‌بندی فرد به کار نبرید. Familiarity، assistance، interruption و sample limitation باید همراه metric گزارش شوند.

حداقل خروجی ارزیابی Maintainability چیست؟

یک Maintainability Evidence Record شامل Claim، Subject، Task، participant context، environment، baseline، metric contracts، event log، touch-set، behavioral/static/review evidence، uncertainty، verdictهای لایه‌ای، تصمیم، expiry و مسیر Correction. بدون این اتصال، خروجی ابزار فقط یک Indicator است.

تست پایداری

تست قابلیت نگهداری؛ از Metric تا Change Trial