یک Data Pack شامل یکمیلیون رکورد است، ۱۰۰٪ با Schema سازگارند و اسکن PII هیچ موردی پیدا نکرده؛ آیا داده برای تست آماده و امن است؟ نه لزوماً. ممکن است همهٔ رکوردها یک Happy path تکراری باشند، روابط و Stateها نامعتبر باشند، دادهٔ زمانی/فارسی/Concurrency وجود نداشته باشد، Pack از Snapshot نامعلوم آمده باشد، Quasi-identifierها امکان Linkage بدهند یا Run دادهای غیر از Artifact تأییدشده را مصرف کند.
مدیریت داده تست در سطح اجرا یعنی ثابت کنیم یک Data Pack برای یک Data Request، Risk، Build و Run مشخص Fit for Purpose است و از Source/Generator تا Provision، مصرف، Mutation و Cleanup قابل ردیابی میماند. این راهنما یک Test Data Fitness & Provisioning Contract میسازد: Request/Obligation → Source/Generation lineage → Privacy/Utility → Validation → signed Pack → Lease/Namespace → Run consumption → Reset/Cleanup → Correction/Revoke/Retire.
راهنمای مدیریت داده تست یا TDM مالک Strategy، انتخاب Synthetic/Masking/Subsetting و معماری کلی است. واحد تحلیل این صفحه یک Request و یک Pack واقعی در جریان Provisioning است: چه دادهای خواسته شد، چه دادهای تحویل شد و آیا همان داده در Run مصرف شد؟
پاسخ کوتاه: Data Pack مناسب تست چیست؟
Pack مناسب فقط Schema-valid یا شبیه Production نیست. باید Obligationهای Test Basis را با رکوردهای یکتا و قابل نگاشت برآورده کند؛ Constraint، رابطه، State، زمان، Locale و Concurrency را اعتبارسنجی کند؛ Lineage و Transformation آن معلوم باشد؛ Privacy risk و Utility trade-off سنجیده شود؛ با digest و Lease به Namespace مشخص Provision شود؛ و Run دقیقاً همان digest را مصرف کند.
- بیشتر الزاماً Coverage بیشتر نیست.
- واقعگرایانه الزاماً Representative برای Risk نیست.
- Schema-valid الزاماً Domain-valid یا State-valid نیست.
- PII scan صفر الزاماً Anonymous یا کمریسک نیست.
- Generated with a seed الزاماً قابل بازتولید نیست اگر Recipe/Tool/Source/Schema تغییر کرده باشند.
مرز این صفحه با TDM، Data Generation و Privacy
| پرسش | مالک محتوایی | مرز این صفحه |
|---|---|---|
| Synthetic، Masked، Subset یا Production-like؟ | داده تست واقعی یا مصنوعی | مقایسه و انتخاب Source family |
| Faker، Property-based و Generator چگونه کار کنند؟ | تولید داده تست | تکنیک و ابزار Generation |
| Privacy Requirement چگونه آزموده شود؟ | تست حریم خصوصی داده | Requirement-specific privacy testing |
| Data و Environment چگونه همنسخه شوند؟ | مدیریت محیط تست | Environment Manifest/Drift/Lease |
| یک Request و Pack چگونه Fit، تحویل و مصرف شوند؟ | همین راهنما | Fitness/Lineage/Provisioning/Use/Correction |
Test Data Fitness & Provisioning Contract چیست؟
این Contract زنجیرهٔ قابل ممیزی از سؤال تست تا Artifact مصرفشده را ثبت میکند. Pack بدون Request ممکن است زیبا و بزرگ باشد ولی هیچ Decision را پشتیبانی نکند. Request بدون Pack digest نیز در زمان Failure قابل بازسازی نیست.
TestDataFitnessProvisioningContract
TDMProgram / product / goal / risk / strategy / dataPolicy
basis / schema / generator / sourceSnapshot / environment / build / run
DataRequest:
id / version / status / decision / question / consumer / due
population / obligations / boundaries / negative / state
relationships / temporal / locale / concurrency / volumeShape
nonGoals / acceptance / owner
DataPack:
id / version / supersedes / purpose / classification
sourceEntity / generationActivity / responsibleAgent / derivedFrom
transformPlan / toolVersion / seed / recipe
schema / constraints / relations / state / time / currency / locale
privacyAssessment / utilityImpact / validation / fitnessDecision
artifact / digest / lease / namespace / accessWindow / expiry
freshness / reset / cleanup / quota / collision / rollback
consumingActor / build / run / mutations / useManifest
owner / SLA / review / correction / revoke / retireData Request را پیش از ساخت داده بنویسید
«برای Regression داده میخواهیم» Request قابل اجرا نیست. Decision، Question، Consumer، Due، Build/Environment و Risk را پین کنید. سپس Obligation registry بسازید: هر Rule، Boundary، Invalid class، State transition، Relationship، Time case، Locale و Concurrency case شناسه داشته باشد. Pack باید به این Registry Map شود.
DataRequest: DATA-REQ-IDEMP-23@3
decision: آیا BUILD-R23 برای Checkهای idempotency دادهٔ fit دارد؟
question: duplicate/late/reordered Callback با identity معتبر ساخته میشود؟
obligations:
- unique Tenant/Order/Attempt/Event identities
- one intentional exact duplicate pair
- PENDING→COMMITTED once
- invalid unknown Attempt
- before/after fake commit and late/reordered windows
nonGoals:
- no production distribution or customer realism
- no performance, privacy-compliance or release proofCoverage obligation با Row count فرق دارد
یکمیلیون Row ممکن است یک Partition را تکرار کند. Coverage به Registry مستقل و نگاشت یکتا نیاز دارد. برای هر Obligation، eligibility، expected valid/invalid، required relation/state و Evidence را ثبت کنید. Duplicate، foreign، unknown و N/A را از covered جدا نگه دارید.
| Obligation | Data member | Validation | Claim limit |
|---|---|---|---|
| BND-AMOUNT-0 | ROW-01 amountIRR=0 | expected rejected | فقط این Boundary |
| REL-ORDER-ATTEMPT | ROW-03/04 | 1:n relation resolves | نه همهٔ relationshipها |
| STATE-DUPLICATE | EV-05/EV-05 duplicate | one effect after two events | نه event-loss |
| TIME-LATE | EV-08 | after window label + expected handling | نه Clock correctness کل سامانه |
| LOC-FA-DIGITS | ROW-11 | digit normalization expected | نه همهٔ Localeها |
Schema validity فقط اولین Gate است
Schema نوع و حضور فیلد را میسنجد. ممکن است status="PAID" از نظر نوع String درست باشد ولی برای Order بدون PaymentAttempt از نظر Domain نامعتبر باشد. Validatorها را لایهبندی کنید: structural، domain constraint، uniqueness، referential integrity، state transition، temporal، distribution/shape، privacy و purpose-specific fitness.
| Gate | پرسش | خطای عبوری از Schema |
|---|---|---|
| Domain | مقدار طبق Rule مجاز است؟ | amount منفی با type عدد |
| Relationship | کلیدها و Cardinality معتبرند؟ | Attempt بدون Order |
| State | State/transition ممکن است؟ | CANCELLED→PAID بدون event |
| Temporal | Ordering/window/expiry معتبر است؟ | Callback قبل از Attempt |
| Purpose | Obligationهای Request را برآورده میکند؟ | همه Rowها Happy path |
Lineage: Pack از کجا و چگونه ساخته شد؟
برای بازتولید و مسئولیتپذیری، Source entity، Generation/Transformation activity، Software/Person/Team agent، input snapshot، recipe، tool version، seed، started/ended time و output digest را ثبت کنید. Generated بودن، Lineage را حذف نمیکند؛ Generator نیز میتواند bug یا bias داشته باشد.
W3C PROV-O یک مدل عمومی برای Entity، Activity و Agent و روابطی مانند used، wasGeneratedBy و wasDerivedFrom ارائه میدهد. این استاندارد Test-data fitness یا Privacy را اثبات نمیکند؛ از واژگان آن برای زنجیرهٔ منشأ قابل تبادل استفاده کنید.
Source family را صریح Label کنید
| Source type | مزیت محتمل | ریسک/محدودیت |
|---|---|---|
| Fully synthetic | کنترل Boundary/Invalid و بدون record-level mapping | realism/distribution gap؛ generator bug |
| Masked/transformed copy | structure/relationship نزدیکتر | linkage، residual identifier، utility distortion |
| Subset | حجم کمتر و relationship واقعیتر | selection bias، rare cases حذف |
| Hand-crafted fixture | Intent خوانا و دقیق | scale/change maintenance |
| Captured interaction | Failure reproduction | consent/secret/PII/freshness |
| Generated model/property | space exploration | oracle/shrink/seed/model gap |
نام «Production-like» Classification نیست. مشخص کنید کدام characteristic شبیه است: schema، relationship، distribution، volume، temporal pattern یا format؛ و کدام نیست.
Synthetic با Safe یا Representative برابر نیست
دادهٔ Synthetic میتواند نام یا شناسهای تصادفاً شبیه شخص واقعی بسازد، Bias داشته باشد، Constraint را نقض کند یا distribution غیرواقعی بدهد. Conspicuous labeling، reserved domain/range، forbidden-pattern scan، uniqueness namespace و privacy/utility assessment لازماند. Synthetic برای Purpose مشخص ساخته میشود، نه تقلید مبهم همهٔ Production.
اگر مدل روی دادهٔ واقعی آموزش دیده یا generator نمونهها را حفظ کرده باشد، «Synthetic» بهتنهایی عدم افشا را ثابت نمیکند. Training/source lineage و memorization/linkage risk را جدا بررسی کنید.
Masking و De-identification تضمین ناشناسبودن نیست
حذف نام و موبایل ممکن است Quasi-identifierهایی مانند تاریخ، منطقه، مبلغ، الگوی رخداد یا ترکیب نادر را باقی بگذارد. Linkage با Dataset دیگر میتواند Subject را بازشناسایی کند. Method، attacker model، auxiliary data، residual risk و approval را ثبت کنید. Hash ثابت نیز ممکن است قابل Dictionary یا cross-dataset linkage باشد.
NIST SP 800-188 تأکید میکند De-identification باید در Risk analysis سنجیده شود و ممکن است Bias، inaccuracy یا utility loss ایجاد کند؛ گاهی هدف Accuracy و identifiability همزمان دستیافتنی نیست. این راهنما مشاورهٔ حقوقی ایران/اروپا/آمریکا یا تضمین عدم بازشناسایی نیست.
Direct identifier، Quasi-identifier و Sensitive attribute را جدا کنید
| نوع | نمونهٔ عمومی | کنترل |
|---|---|---|
| Direct identifier | نام، شماره/شناسهٔ مستقیم | remove/replace/tokenize با governance |
| Quasi-identifier | ترکیب زمان/مکان/سن/رفتار | linkage assessment، generalization/suppression |
| Sensitive attribute | رفتار/وضعیت خصوصی | purpose/minimization/access |
| Secret | token/key/cookie | never copy؛ revoke/rotate if exposed |
| Operational confidential | fraud rule/internal topology | classification و least privilege |
Scanner صفر فقط Rule/Patternهای همان Scanner را گزارش میکند. Metadata، attachment، free text، image، log، backup و relationshipها را فراموش نکنید.
Privacy و Utility را با هم اعتبارسنجی کنید
Masking قوی ممکن است رابطهها یا distribution لازم برای Test را خراب کند؛ Utility بالا ممکن است Privacy risk را زیاد کند. برای Purpose تعریفشده Measure کنید: obligation satisfaction، domain validity، relationship preservation، distribution distance، rare-case retention و false-result rate؛ در کنار linkage risk، identifier finding و access/retention exposure.
PrivacyUtilityDecision
purpose / dataClassification / attackerModel / auxiliarySources
deidentificationOrSyntheticMethod / parameters / version
directIdentifierScan / quasiIdentifierAndLinkageAssessment
residualPrivacyRisk / approval / access / retention
utilityObligations / distortion / bias / limitations
decision: USE | ADAPT | RESTRICT | REJECT
no claim: anonymous forever or fit for every purposeRelationship و Referential Integrity را آزمون کنید
Foreign key pass فقط وجود Parent را میسنجد؛ Cardinality، ownership، tenant boundary و semantic relation جدا هستند. Order یک Customer/Tenant دارد، چند Attempt ممکن است و Event باید به Attempt درست وصل شود. Negative dataset نیز باید invalid relation را عمدی و Labelشده بسازد، نه تصادفی.
- Orphan، cross-tenant reference و duplicate natural key را Check کنید.
- Cardinality min/max و conditional relationship را نسخهدار کنید.
- Soft delete، historical version و slowly changing entity را مدل کنید.
- Generator و Validator یک Library/Rule implementation مشترک نداشته باشند که یک bug را تکرار کند.
Stateful data را به Snapshot تخت تقلیل ندهید
بسیاری از Failureها در Transition و event ordering رخ میدهند، نه در Row مستقل. Initial state، Event sequence، guard، resulting state، invariant و invalid transition را در State Model نگه دارید. Setup مستقیم State نهایی ممکن است Side effect و invariantهایی را دور بزند که از مسیر واقعی ساخته میشوند.
برای Reproduction، Snapshot plus event log یا deterministic recipe مفید است. «یک Order PAID بساز» کافی نیست؛ باید معلوم باشد با کدام Attempt/Event/Ledger و چه ترتیب زمانی ساخته شده است.
Time، Expiry و Ordering بخشی از Data Contract هستند
Created-at قدیمی، token expired، timezone mismatch یا event reordered میتواند Verdict را عوض کند. Instant canonical را از نمایش محلی جدا کنید؛ Clock/Timezone، relative offset، validity window و ordering tie-breaker را ثبت کنید. «امروز» در Fixture reproducible نیست.
| Case | Contract | Failure mode |
|---|---|---|
| Expiry boundary | T-1ms/T/T+1ms با fake clock | off-by-one/timezone |
| Late event | eventAt و receivedAt جدا | ingestion delay |
| Reordered events | sequence/event ID + ordering rule | wrong final state |
| Duplicate retry | same idempotency identity | double effect |
| Jalali display | UTC instant + Asia/Tehran view | presentation/storage conflation |
دادهٔ فارسی، RTL و پول را دقیق مدل کنید
ارقام فارسی/عربی/لاتین، نیمفاصله، شکلهای ی/ک، NFC/NFKC، bidi marks، فاصله، Emoji و طول grapheme Failure modeهای متفاوتاند. Stable technical ID را از display string جدا کنید. Currency unit باید در فیلد و نام Measure روشن باشد؛ ریال و تومان را با Label و conversion rule مخلوط نکنید.
Random Persian string بدون Oracle ممکن است فقط Parser را confuse کند. هر Variant به Obligation و expected normalization/rejection وصل شود. Dataset این صفحه ادعای پوشش کامل زبان فارسی یا همهٔ قواعد مالی ایران ندارد.
Concurrency به Namespace و Lease نیاز دارد
Parallel test وقتی ایمن است که Identity و mutation scope جدا باشند. Worker ID، Run ID، Tenant/namespace، quota و collision policy تعریف کنید. استفاده از «اولین Order آماده در DB» دو Worker را به یک Subject وصل میکند. Lease باید owner، TTL، access window و revoke داشته باشد.
ProvisionLease
leaseId: LEASE-R23-01
pack: DATA-PACK-R23-IDEMP@4 / digest
destination: ENV-DATA-R23
namespace: TEN-SYN-R23 / RUN-R23 / WORKER-{1,2}
consumer / actor / accessWindow / expiresAt
quota / collisionPolicy / freshness
reset / cleanup / deletionVerification / rollback
prohibited: shared mutable customer/order poolProvisioning فقط Copy کردن فایل نیست
Artifact باید signed/digestable باشد و Destination readiness، schema compatibility، access، seed/load order و validation پس از load داشته باشد. Ready time، request-to-ready latency و Failure vocabulary ثبت شود: REQUEST_INVALID، PACK_INVALID، PRIVACY_HOLD، ENV_NOT_READY، LOAD_ERROR، READY، EXPIRED، REVOKED.
Provision success با Test fitness برابر نیست. Load ممکن است کامل شود ولی Pack برای Risk غلط باشد. Fitness Decision پیش از Provision و consumption digest پس از آن هر دو لازماند.
Freshness را از Realism جدا کنید
Pack تازه یعنی با Basis/Schema/Generator/Policy/Build مورد نیاز سازگار است؛ نه اینکه جدیدترین Production copy باشد. هر تغییر Schema، Constraint، Risk، Generator یا De-identification method میتواند Pack را Stale کند. Freshness SLA باید dependency-aware باشد.
Pack immutable را بیصدا patch نکنید. نسخهٔ جدید با supersedes، impact analysis و affected Runها منتشر شود. Run تاریخی باید به digest مصرفشدهٔ قبلی اشاره کند.
Reset، Cleanup و Deletion Evidence متفاوتاند
| عمل | هدف | Evidence |
|---|---|---|
| Reset | بازگرداندن Namespace به initial state | state/digest comparison |
| Cleanup | حذف mutationهای Run | resource list before/after |
| Revoke | قطع دسترسی/مصرف Pack | lease/access denial |
| Delete | حذف Artifact و copyهای scoped طبق Policy | deletion manifest + backup caveat |
| Retire | خروج Pack/Recipe از مصرف آینده | reason/supersession/archive |
اجرای command Cleanup بهتنهایی deletion proof نیست. Backup، cache، attachment، log و downstream copy را در Scope ثبت کنید. حذف گسترده و target مبهم خطرناک است؛ فقط Lease/Run identity معتبر را هدف بگیرید.
Run باید مصرف همان Pack را ثابت کند
Test Report باید Build/Run/Actor/Test IDs، Pack ID/version/digest، Lease/Namespace، start/end، mutation log، outcome، Unknown و use manifest داشته باشد. «داده آماده بود» کافی نیست. اگر Data در حین Run mutate شد، Delta و ownership را ثبت کنید.
DataUseManifest
actor / build / run / tests
packId / version / consumedDigest
lease / namespace / environment
startedAt / finishedAt / mutations
outcomes / unknowns / evidenceRefs
resetOrCleanupRef / privacyIncidentRef
claimLimit: consumed pack, not test correctness or release proofValidator را از Generator مستقل نگه دارید
اگر Generator و Validator همان Rule code را مصرف کنند، یک bug مشترک میتواند دادهٔ غلط را تولید و صحیح اعلام کند. Validator identity/version/digest را ثبت کنید؛ independent constraints، metamorphic checks، manually reviewed golden cases و injected faults به کشف همخطایی کمک میکنند.
Fault injection نمونه: یک relationship را حذف، Tenant را duplicate، State نامعتبر یا date ordering را برعکس کنید. Validator باید هر Fault مورد انتظار را بگیرد. این آزمایش Validator quality را محدود میسنجد، نه کفایت کل Data.
Fitness Decision را نسخهدار و محدود کنید
| Status | معنا | محدودیت |
|---|---|---|
| FIT_FOR_REQUEST | Obligation/Privacy/Validation لازم برای Request نامدار پذیرفته شد | فقط همان Purpose/Build/Window |
| FIT_WITH_LIMITATION | Blind spot/exception پذیرفتهشده دارد | Decision authority و guardrail |
| HOLD | Evidence یا Gate ناقص/نامعتبر است | نه Product failure |
| REJECT | Pack برای Request مناسب نیست | ممکن است برای Purpose دیگر معتبر باشد |
| REVOKED | پس از Finding privacy/integrity/access مصرف متوقف شد | Affected runs باید پیدا شوند |
از «Data quality score» واحد برای جمعکردن Privacy، Utility، Coverage و Freshness استفاده نکنید. شکست Hard gate با حجم زیاد یا realistic-looking rows جبران نمیشود.
Correction، Revoke و Affected-run analysis
اگر بعداً معلوم شد Pack حاوی identifier، رابطهٔ غلط یا Source ناشناخته بوده، Artifact را بیصدا جایگزین نکنید. Revoke Lease، جلوگیری از مصرف آینده، یافتن همهٔ Runهای مصرفکننده با digest، ارزیابی Outcomeهای متاثر، Notification، Correction و superseding Pack لازماند.
DataPackCorrection
correctionId / packId / badDigest / finding
detectedAt / source / privacyOrFitnessImpact
activeLeasesRevoked / affectedRuns / affectedDecisions
containment / deletionOrAccessAction
correctedPack / newDigest / revalidation
notification / owner / closureEvidenceآزمایش بازتولیدپذیر: یکمیلیون Row در برابر ۱۴۸ Finding
Fixture آفلاین و کاملاً مصنوعی SYN-TEST-DATA-FITNESS-PROVISIONING-01 با Node.js v24.۱۸.۰ ساخته شد. Dashboard سطحی یکمیلیون Row، ۱۰۰٪ Schema-valid و صفر یافتهٔ PII scanner را دید و PASS داد. Audit دارای ۱۵۲ Rule بود.
{
"ruleCount": 152,
"superficial": {
"status": "PASS",
"message": "1,000,000 rows; 100% schema-valid; zero PII scanner findings"
},
"contractAudit": {
"status": "HOLD",
"findingCount": 148
}
}چهار واقعیت سطحی عمداً در Audit نیز PASS ماندند: Size مثبت بود، Schema field PASS بود، direct-identifier scanner نتیجهٔ عددی صفر داشت و Pack ID ساختاری موجود بود. اما ۱۴۸ Failure دیگر نشان دادند این چهار واقعیت برای Fitness/Privacy کافی نیستند: ۱۳ Identity کهنه/متحرک؛ Request تکراری و بدون Decision/Question/Obligation/Owner؛ Pack بدون Purpose/Lineage/Recipe/Constraint/State/Time/Locale؛ Privacy بدون Purpose/Linkage/Residual risk/Utility/Access/Retention؛ Validation بدون Domain/Relationship/Boundary/State/Temporal/Concurrency/independent Oracle/Fault injection؛ Provisioning بدون digest/Lease/Namespace/Expiry/Reset/Cleanup؛ Run بدون Actor/consumed digest/mutation/evidence؛ Lifecycle/economics ناقص؛ و ۲۸ ادعای مطلق.
دو اصلاح آزمایش و دلیل آنها
اجرای اول نشان داد ۱۴۴ Finding واقعی است نه ۱۴۸ مورد انتظار، زیرا چهار کنترل سطحی واقعاً معتبر بودند. بهجای دستکاری Counter، چهار کنترل substantive جاافتاده اضافه شد: Request lifecycle status، Validator identity، Pack expiry و consuming actor. اجرای دوم بهدرستی نشان داد Rule count اکنون ۱۵۲ و Finding count برابر ۱۴۸ است؛ چهار واقعیت اولیه همچنان PASS میمانند. انتظار نهایی بر ۱۴۸ Finding واقعی تثبیت و کل Fixture دوباره اجرا شد.
نسخهٔ اصلاحشدهٔ Data Pack
نسخهٔ اصلاحشده TDM-۲۳/SYN-CHECKOUT/PG-۱۶/RISK-v12/TEST-STRAT-v7/DATA-POL-v5/BASIS-v10/SCHEMA-v23/GEN-v8/SRC-SYN-v23/ENV-DATA-R23/BUILD-R23/RUN-R23 را پین کرد. Request نسخهٔ ۳، Obligation registry دقیق و Non-goal ساخت؛ Pack کاملاً Synthetic نسخهٔ ۴ با PROV-style lineage، Recipe/Seed/Validator مستقل، Constraint/Relationship/State/Time/Locale، Privacy/Utility assessment و injected fault validation ساخته شد.
Artifact signed با Lease/Namespace/Access/Expiry/Reset/Cleanup Provision شد؛ Run actor همان digest را مصرف و mutation/use manifest را ثبت کرد؛ Correction/Revoke/Retire و measures کامل شدند. Validator با صفر Finding وضعیت READY_FOR_DATA_PACK_REVIEW داد؛ نه حقیقت/کفایت Source/Validation/Evidence، عدم بازشناسایی، نمایندگی Production، Coverage، نبود باگ، Product quality یا Release را تضمین کرد.
آزمایشگاه Checkout فارسی و ایرانی
Lab یک Checkout جدا از شبکه با Order، PaymentAttempt، PSP Stub جعلی، Callback، Ledger Stub و Reconciliation مصنوعی است. Pack دقیقاً ۱۲ Row obligation-shaped برای duplicate/late/reordered event، timeout قبل/بعد از fake commit، invalid attempt، State transition، relation و parallel namespace دارد؛ هیچ ادعای شباهت توزیعی به Production ندارد.
| بعد | قرارداد Fixture | محدودیت |
|---|---|---|
| پول | مقادیر ساختگی canonical بر حسب IRR؛ تومان فقط view برچسبدار | نه ادعای مالی/بانکی ایران |
| متن/رقم | ارقام فارسی/عربی/لاتین، Unicode NFC، RTL/LTR و stable Latin IDs | نه پوشش کامل Locale |
| زمان | ISO instant/UTC؛ Asia/Tehran view؛ جلالی فقط presentation | نه قاعدهٔ حقوقی/تسویه |
| Privacy | SYN label، reserved IDs، no real-subject relation | نه تضمین Privacy جهان واقعی |
| هویت | Tenant/Order/Attempt/Event/Ledger/Run/Build/Pack/Evidence جدا | نه مشتری یا تراکنش واقعی |
هیچ Network، Production، شرکت، کاربر، پرداخت، بانک، PSP، نام، موبایل، ایمیل، IP، حساب، PAN، CVV2، OTP، Cookie، Token، Credential، Screenshot یا Log واقعی وجود ندارد. این Lab توصیهٔ بانکی، مالی، حقوقی، مالیاتی، امنیتی، حریم خصوصی، GDPR/HIPAA/CCPA یا Compliance ایران نیست.
Role و Decision right در TDM
| تصمیم | Capability پاسخگو | Evidence |
|---|---|---|
| Obligation/fitness | Test design + domain | Request/Registry/validation |
| Source/Transformation | Data engineering | Lineage/recipe/digest |
| Privacy risk/approval | Privacy/security/legal authority طبق Context | assessment/approval/limitation |
| Provision/Lease | Platform/environment | namespace/access/expiry/health |
| Use/Mutation/Cleanup | Run consumer + pack owner | use/deletion manifest |
| Revoke/Correction | incident authority | affected-run/containment evidence |
مرکز متمرکز TDM تنها یک Operating model ممکن است. Platform self-service با guardrail، federated ownership یا embedded capability نیز ممکناند. «یک تیم مرکزی لازم است» را بدون بررسی Flow/Scale/Policy تجویز نکنید.
Automation و AI در تولید داده
Automation میتواند Request validation، generation، scanning، packaging، Provision و Cleanup را تکرارپذیر کند. AI میتواند Candidate row، rare combination یا masking transformation پیشنهاد کند. اما Prompt/model/version، Source permission، Generated output، Validator و Reviewer باید ثبت شوند.
AI-generated data ممکن است PII را حفظ/تقلید، Constraint را نقض، rare group را stereotype یا Secret را از Context بازتاب دهد. مدل نباید Privacy approval، Fitness Decision، Cleanup target یا Release را مستقل تأیید کند. Validator deterministic و human gate متناسب باقی میماند.
متریکهای Data Pack با Countermetric
| Measure | تعریف لازم | Countermetric |
|---|---|---|
| Request-to-ready latency | درخواست معتبر تا Pack provisioned/validated | Fitness/Privacy failure |
| Consumer wait | blocked minutes منتسب به Data | overprovision/cost |
| Obligation satisfaction | unique valid members بر Registry | duplicate/unknown/stale |
| False-result contribution | Outcome غلط تأییدشده ناشی از Data | verification opportunity |
| Reproduction rate | same recipe/digest/state outcome بازسازی شد | Product/environment drift |
| Collision rate | namespace/lease conflict در eligible runs | setup/compute cost |
| Privacy finding | direct/quasi/linkage/access/retention finding | utility distortion |
| Cleanup/deletion closure | scoped resources verified removed/revoked | backup/log/downstream caveat |
| Pack cost | build/storage/provision/support minutes/cost | value of signal/coverage |
Row count، GB، تعداد Synthetic record، Scanner score یا Provision speed را برای رتبهبندی افراد استفاده نکنید. این Incentive به تولید حجم بیمصرف، مخفیکردن Unknown و حذف Validation دشوار منجر میشود.
Pilot سیروزهٔ یک Data Pack
| بازه | کار | خروجی/گیت |
|---|---|---|
| روز ۱–۵ | یک Risk/Run، wait baseline و Obligation registry را انتخاب کنید | Data Request پذیرفتهشده |
| روز ۶–۱۰ | Source family/Lineage/Recipe/Privacy/Utility را طراحی کنید | Source decision و non-goals |
| روز ۱۱–۱۵ | Pack تولید و Schema/Domain/Relation/State/Time/Locale validate شود | Fault-injected validator report |
| روز ۱۶–۲۰ | Artifact/digest/Lease/Namespace/Provision/Parallel/Expiry آزمون شود | Provision game day |
| روز ۲۱–۲۵ | Run consumption/mutation/reset/cleanup/correction/revoke تمرین شود | Use + deletion/correction manifests |
| روز ۲۶–۳۰ | Fitness/privacy/latency/cost/false-result Review شود | Keep/Adapt/Restrict/Reject/Scale decision |
Pilot موفق با یکمیلیون Row یا Zero scanner finding تعریف نمیشود؛ باید یک Run مشخص همان Pack معتبر را بهموقع مصرف کند، Faultهای تزریقشده کشف شوند و Cleanup/Correction قابل اثبات باشد.
۳۴ ضدالگوی مدیریت Data Pack
- Row count=Coverage؛ Schema PASS=Fit؛ realistic=representative؛ Production distribution=test need.
- Full Production copy پیشفرض؛ Production copy بهترین؛ Subset همیشه ارزان؛ Synthetic همیشه safe/realistic.
- Masking=anonymous؛ zero PII scanner=no sensitive data؛ hash=irreversible؛ direct ID تنها Risk.
- Request بدون Decision/Risk/Consumer؛ Pack بدون Obligation؛ Happy path تکراری؛ Invalid row بیLabel.
- latest schema/current data؛ Source نامعلوم؛ Generator بدون version؛ seed بدون recipe/tool/source.
- Generator=Validator؛ no fault injection؛ relationship فقط FK؛ State فقط status field؛ «امروز» در Fixture.
- ریال/تومان بیUnit؛ Persian digits بیOracle؛ Unicode normalization مخفی؛ Jalali در storage canonical.
- Shared mutable pool؛ first available order؛ parallel بدون namespace؛ Lease بیTTL؛ cleanup target مبهم.
- Provisioned=Fit؛ load success=Ready؛ Run بدون consumed digest؛ mutation بیLog؛ reset=deletion.
- Tool=Governance؛ central team اجباری؛ TDM=Quality/Security/Speed guarantee؛ Data prevents defects.
- آمار ثابت ۵۰٪ اتلاف/۱۰۰× هزینه؛ GDPR بهعنوان قانون جهانی؛ Test env همیشه ناامنتر.
- AI output=approved؛ scanner score=Privacy decision؛ Silent pack replacement؛ Revoke بدون affected-run analysis.
چکلیست ۲۸ نقطهای ممیزی Data Pack
- Program/Product/Goal/Risk/Strategy/Policy/Basis نسخهدارند.
- Schema/Generator/Source/Environment/Build/Run تغییرناپذیرند.
- Request ID/version/status/Decision/Question/Consumer/Due روشناند.
- Population و Obligation registry مستقل وجود دارد.
- Boundary/Negative/State/Relation/Time/Locale/Concurrency مشخصاند.
- Volume/shape requirement و Non-goal نوشته شدهاند.
- Pack ID/version/supersedes/Purpose/Classification معلوماند.
- Source Entity/Activity/Agent/Derivation/Transformation ثبت شدهاند.
- Tool/version/seed/recipe و input snapshot پین شدهاند.
- Schema/Constraint/Relation/State/Time model نسخهدارند.
- Currency/Locale/Encoding/Normalization صریحاند.
- Membership digest و Artifact digest ثبت شدهاند.
- Privacy purpose/approval/minimization/access/retention معلوماند.
- Direct identifier و Quasi/linkage جدا ارزیابی شدهاند.
- Method/Residual risk/Utility impact و limitation ثبت شدهاند.
- Validator identity مستقل از Generator است.
- Domain/Uniqueness/Referential/Distribution validation انجام شده است.
- Boundary/Negative/State/Temporal/Locale/Concurrency validation انجام شده است.
- Injected fault و Oracle independence آزموده شدهاند.
- Fitness Decision فقط به Request نامدار محدود است.
- Destination/Lease/Namespace/Consumer/Access/Ready/Expiry معلوماند.
- Freshness/Reset/Cleanup/Quota/Collision/Rollback تعریف شدهاند.
- Consuming actor/Build/Run/Test/digest/time ثبت شدهاند.
- Mutation/Outcome/Unknown/Use manifest موجود است.
- Owner/SLA/Review/Correction/Revoke/Retire مشخصاند.
- Provision latency/Wait/Utility/Privacy/Cost guardrail سنجیده میشوند.
- Deletion بهجای صرف اجرای Cleanup با Evidence تأیید میشود.
- هیچ تضمین Privacy، Coverage، Quality، Security، Speed یا Release نتیجه نشده است.
جمعبندی: دادهٔ تست یک Artifact تصمیمساز است
مشکل مدیریت داده با خرید ابزار، کپی Database یا تولید Row بیشتر حل نمیشود. Data Request باید از Risk و Decision بیاید؛ Pack باید Obligationها را برآورده و Lineage/Privacy/Utility معتبر داشته باشد؛ Provisioning باید Artifact را با digest/Lease به Run وصل کند؛ و Mutation/Cleanup/Correction باید قابل ممیزی بماند.
از یک Pack کوچک و Purpose-specific شروع کنید. اگر نمیتوانید بگویید هر Row کدام Obligation را پوشش میدهد، از کجا آمده، چه کسی ساخت/تأیید کرد، کدام Run همان digest را مصرف کرد و چه زمانی حذف شد، یکمیلیون Row فقط ابهام بزرگتری است.
سوالات متداول مدیریت دادههای تست
Data Pack چه تفاوتی با Database تست دارد؟
Data Pack یک Artifact نسخهدار با Purpose، members، Lineage، validation و digest است؛ Database/Environment مقصدی است که Pack در Namespace و Lease مشخص Provision میشود و ممکن است چند Pack/Run را میزبانی کند. نام Database بهتنهایی دادهٔ مصرفشده را مشخص نمیکند.
آیا دادهٔ Synthetic همیشه از دادهٔ Production امنتر است؟
نه بهصورت مطلق. Fully synthetic بدون record-level mapping میتواند Privacy risk را کم کند، اما Generator/Training source ممکن است افشا یا شباهت واقعی بسازد و Artifact همچنان Confidential باشد. Source lineage، reserved identifiers، scanner/linkage assessment، access و retention لازماند.
آیا Masking یا حذف PII داده را Anonymous میکند؟
تضمینی نیست. Quasi-identifier، relationship، free text، metadata و auxiliary datasets میتوانند Linkage/Re-identification را ممکن کنند. Method و attacker model، residual risk، utility impact و Context حقوقی باید ارزیابی شوند؛ اسکن صفر فقط Rule set همان Scanner را نشان میدهد.
برای اجرای Parallel تست چگونه Data collision را کم کنیم؟
برای هر Run/Worker Namespace و identity مستقل، Seed/Pack مشخص، Lease/TTL، quota و collision policy بسازید؛ State مشترک را read-only یا partition کنید؛ Cleanup را فقط روی Run identity انجام دهید؛ و random-order/parallel series را برای کشف تداخل اجرا کنید.
بهترین KPI برای مدیریت داده تست چیست؟
KPI جهانی وجود ندارد. برای Flow مشخص، Request-to-ready latency، consumer wait، obligation satisfaction، false-result contribution، reproduction/collision، Privacy finding، cleanup closure و Pack cost را با Countermetric بسنجید. Row count، GB یا Scanner score را هدف مستقل نکنید.
