Pass rate این هفته ۹۶٪ است؛ هفتهٔ قبل ۹۴٪ بود. Dashboard سبز شده و مدیر نتیجه میگیرد فرآیند تست بهتر شده است. اما شاید Denominator عوض شده، Retry فقط آخرین Attempt را نگه داشته، سه Result دیر رسیده، Scope سادهتر شده یا این دو نقطه صرفاً نوسان عادی همان Process باشند. مقایسهٔ دو عدد نه Signal را ثابت میکند، نه Cause را، نه Improvement را.
این راهنما برای عبارتهای «استفاده از معیارهای تست برای بهبود فرایند»، «تحلیل روند KPI تست»، «SPC در QA»، «Noise و Signal در متریک» و «چگونه از داده تست اقدام بسازیم» نوشته شده است. موضوع آن انتخاب Metric یا اجرای Experiment نیست؛ موضوع، خواندن درست سری زمانی Metric و ساختن Investigation/Action متناسب است.
پاسخ کوتاه: هر تغییر عددی، تغییر Process نیست
- Metric Contract و Data quality را پیش از Trend بررسی کنید.
- نقاط را به ترتیب Event time و با Denominator/Population ثابت یا شفاف رسم کنید.
- Baseline را از دورهای همگن و قابلدفاع بسازید و وسط Monitoring بیدلیل جابهجا نکنید.
- Target، Specification و Control limit را سه مفهوم مستقل نگه دارید.
- Common-cause variation، Special-cause signal، Measurement break و Unknown را جدا کنید.
- Signal فقط Investigation را آغاز میکند؛ علت و اقدام را خودکار صادر نمیکند.
- Improvement claim را به Experiment/Contribution Evaluation بسپارید و Correction path داشته باشید.
مالکیت این مقاله با کدام مسئله است؟
راهنمای متریکهای تست Metric و فرمولها را انتخاب میکند؛ راهنمای Dashboard تست Semantic layer و رابط تصمیم را میسازد؛ راهنمای اثربخشی QA Contribution claim را ارزیابی میکند؛ و راهنمای بهبود مستمر QA Experiment را اجرا و بررسی میکند. مقالهٔ حاضر فقط مالک Metric Signal Review است: آیا سری زمانی هنوز Noise موردانتظار است، Signal قابلتحقیق دارد، Measurement شکسته یا فعلاً Unknown است؟
Test Metric Signal Review Loop
Decision / Question → versioned Metric Contract → Snapshot + Data Quality Gate → ordered Time Series + Context annotations → Baseline / Chart or Run-rule choice → Variation / Signal classification → Investigation Packet → Measurement-break | Common-cause | Special-cause | Unknown → Action policy → Experiment / RCA / Flow-recovery handoff → Verification / Re-baseline / Correction
این Loop سنتز عملی همین مقاله است، نه استاندارد NIST، NHS، ISTQB یا یک نسخهٔ رسمی SPC برای مهندسی نرمافزار. خروجی READY_FOR_SIGNAL_REVIEW در آزمایش نیز فقط کاملبودن Contract را نشان میدهد.
«چیزی را که اندازه نمیگیری نمیتوانی بهبود بدهی» قانون نیست
این جملهٔ رایج سه مشکل دارد: همهٔ پدیدههای مهم بهآسانی قابلاندازهگیری نیستند؛ Measurement میتواند رفتار را تغییر دهد؛ و اندازهگیری بدون Question ممکن است فقط هزینه و قطعیت کاذب بسازد. Observation، گفتوگو، نمونهٔ Evidence و تجربهٔ کاربر نیز دادهاند. بهتر است بپرسیم: برای کدام تصمیم، چه Evidence با چه محدودیتی لازم است؟
Data با Fact و Insight یکی نیست
| لایه | نمونه | ریسک |
|---|---|---|
| Event | Attempt در ۱۰:04Z تمام شد | رویداد گم/تکراری |
| Record | Outcome=FAILED | Vocabulary غلط |
| Metric | Failed/eligible executed | مخرج مبهم |
| Signal | الگوی نامعمول نسبت به Baseline | Rule/assumption نامناسب |
| Explanation | Environment drift محتمل است | Correlation بهجای Cause |
| Decision | Investigate/Experiment | Authority یا Guardrail غایب |
دو نقطه Trend نمیسازند
«این هفته از هفتهٔ قبل بدتر است» انتخاب دو مشاهده از Process متغیر است. حتی پنج نقطهٔ صعودی ممکن است با Definition change یا Seasonality ساخته شود. Time series کامل، ترتیب واقعی، Baseline، Annotation و Rule از درصد تغییر دونقطهای یا فلش سبز/قرمز اطلاعات بیشتری میدهد.
RAG وضعیت را رنگ میکند، Variation را توضیح نمیدهد
Red/Amber/Green فقط فاصله از Threshold را نشان میدهد. Process ممکن است همیشه سبز اما رو به وخامت باشد، همیشه قرمز اما باثبات بماند، یا هر هفته اطراف Threshold رنگ عوض کند بدون تغییر واقعی. رنگ باید View ثانویه باشد و Time series/Population/Data freshness قابل drill-down بماند.
NHS Making Data Count چه مرزی میدهد؟
راهنمای رسمی NHS England Making Data Count محدودیت مقایسههای دونقطهای و گزارش RAG را مطرح و Time series/SPC را برای گفتوگوی بهتر دربارهٔ Variation معرفی میکند. این منبع در Context سلامت نوشته شده است؛ ما منطق دیدن Variation را اقتباس میکنیم، نه قواعد بالینی، عدد نمونه، تضمین تصمیم یا استاندارد نرمافزار.
Common cause و Special cause یعنی چه؟
| نوع | معنا | مثال فرضی QA | واکنش اولیه |
|---|---|---|---|
| Common cause | Variation طبیعی سیستم فعلی | نوسان عادی queue با mix ثابت | System-level improvement، نه tampering |
| Special-cause signal | الگوی بعید نسبت به Baseline | shift پس از Runner upgrade | Investigation زمانمند |
| Measurement break | Metric دیگر همان پدیده را نمیسنجد | Retry schema عوض شده | Data hold/repair/correction |
| Unknown | Evidence برای طبقهبندی کافی نیست | سه هفته late data | جمعآوری/Window mature |
Glossary رسمی NIST/SEMATECH Common cause را Variation طبیعی مؤثر بر همهٔ خروجیها و Special cause را منبع بزرگ/متناوب/پیشبینیناپذیر تعریف میکند. نمونههای QA بالا مثالهای این مقالهاند، نه طبقهبندی رسمی NIST برای تست نرمافزار.
Control Chart چه چیزی نشان میدهد؟
NIST Control Chart را نمودار یک characteristic در برابر زمان/نمونه با Center line و Control limitهای آماری توصیف میکند. نقطه بیرون Limit یا الگوی غیرتصادفی، Investigation را توجیه میکند. Chart علت، خوب/بدبودن، Product quality یا اقدام نهایی را خودکار تعیین نمیکند.
Control limit با Target و Specification فرق دارد
| خط | منشأ | پرسش | نباید |
|---|---|---|---|
| Center line | رفتار Baseline | مرکز Process کجاست؟ | Target فرض شود |
| Control limit | Variation Process و روش Chart | چه چیزی نسبت به Process نامعمول است؟ | حد پذیرش باشد |
| Target | هدف تصمیم/بهبود | کجا میخواهیم باشیم؟ | از دادهٔ فعلی مشتق شود |
| Specification/SLO | نیاز/تعهد/Policy | چه محدودهای قابلقبول است؟ | Signal آماری تلقی شود |
NIST صریحاً Control limit را برای Statistical control و Specification limit را برای عملکرد مورد انتظار محصول جدا میکند. در Metricهای نرمافزار نیز «طبیعی برای Process فعلی» میتواند برای Risk یا Goal نامطلوب باشد.
Stable میتواند Unacceptable باشد
صفحهٔ رسمی NIST دربارهٔ In Control but Unacceptable میگوید In control فقط predictability آماری را نشان میدهد؛ Average یا Variation هنوز میتواند نامطلوب باشد. برای مثال، Age همواره بین ۹ تا ۱۳ روز و بدون Signal خاص است، اما SLE چهارروزه را دائماً نقض میکند. پاسخ، اصلاح System از مسیر Experiment است، نه انتظار برای Outlier.
Metric Question Contract بنویسید
MetricQuestion id: MSR-042 decision: INVESTIGATE | HOLD | EXPERIMENT | OBSERVE metric_ref: M-QUEUE-AGE-v3 evaluation_unit: eligible evidence request population: Checkout C2/C3 window: weekly event-time snapshot question: has the process changed beyond expected variation? direction_of_good: lower, subject to false-negative guardrail target_ref: SLE-policy-v4 not_claimed: cause, product quality, individual performance owner: test-flow owner decision_authority: engineering lead
Metric Contract را قبل از Series قفل کنید
MetricContract id/version: M-PASS-ATTEMPT-v4 definition: eligible terminal attempts by outcome unit: proportion numerator: PASS terminal attempts denominator: PASS+FAIL+ERROR+INCONCLUSIVE terminal attempts population: Checkout regression lane exclusions: cancelled-before-start; never silently quarantined event_time: finished_at UTC interval: ISO week source/schema: runner-events v6 join/dedupe: run_id + check_id + attempt_id retry: preserve every attempt; show final-check view separately late/missing: provisional 7d; UNKNOWN not zero owner: measurement steward change_policy: new version and bridge analysis
اگر Definition، Denominator، Result vocabulary، Retry یا Source عوض شد، یک Series پیوسته ندارید مگر Bridge معتبر ساخته شود. تغییر فرمول را با Annotation کوچک پنهان نکنید؛ Metric version را عوض و تحلیل قبل/بعد را محدود کنید.
Snapshot Contract، دادهٔ قابلبازتولید میسازد
Snapshot id: SNAP-MPASS-2026W31-r2 metric_version: M-PASS-ATTEMPT-v4 extracted_at: 2026-08-10T08:00:00Z event_cutoff: 2026-08-03T00:00:00Z query_digest: sha256:demo-only source_versions: runner-v6 / quarantine-v3 included/eligible: 1182 / 1210 missing/duplicate/late: 4 / 7 / 17 completeness: 0.9769 status: PROVISIONAL supersedes: SNAP-MPASS-2026W31-r1 limitations: late mobile-run uploads
Data Quality Gate پیش از Statistical rule است
- Metric version و Source schema همان Baseline است؟
- Event time، interval و timezone ثابتاند؟
- Missing، duplicate، late و correction نرخ قابلقبول دارند؟
- Denominator و eligibility rule در تمام نقاط قابلبازتولید است؟
- Join key، retry، quarantine و reopened status drift نکردهاند؟
- Backfill یا collector outage با Annotation ثبت شده است؟
اگر Gate رد شود، وضعیت MEASUREMENT_HOLD است؛ از سری خراب Special cause نسازید. Repair نیز ممکن است نتیجهٔ قبلی را تغییر دهد، پس Correction لازم است.
Event time و Ingestion time را مخلوط نکنید
یک Run جمعه تمام و شنبه Upload شده است. گروهبندی با ingestion time آن را در هفتهٔ دیگر میگذارد و shift مصنوعی میسازد. Metric باید زمان رخداد را برای Population و cutoff تعریف کند و ingestion lag را جداگانه بهعنوان Data-quality measure بسنجد.
Denominator drift، Ratio را بیمعنا میکند
۹۵٪ از ۲۰ Check با ۹۵٪ از ۲۰۰۰ Check یک Evidence نیست. اگر Suite، eligibility، Quarantine یا result closure عوض شود، Ratio ممکن است تغییر کند بدون اینکه Process بهتر/بدتر شود. Numerator، Denominator، eligible/missing count و mix را کنار هر نقطه نگه دارید.
Rate، Count و Duration یک Chart family ندارند
| Data | نمونه | مسئلهٔ طراحی |
|---|---|---|
| Continuous duration | Cycle time | skew، censoring، autocorrelation |
| Proportion | failed/eligible | varying denominator |
| Count per unit | Defect per change | opportunity/overdispersion |
| Rare event interval | time between critical escape | zero-heavy/long gaps |
| Ordinal class | severity | فاصلهٔ عددی واقعی نیست |
Chart را از روی نام Metric انتخاب نکنید. Distribution، independence، subgroup، denominator و collection design مهماند. در دادهٔ کم، autocorrelated یا متغیر نرمافزار، کمک تحلیلگر آماری ارزشمند است؛ این مقاله فرمول جهانی یا نسخهٔ جایگزین متخصص نمیدهد.
Run Chart چه زمانی انتخاب سادهتری است؟
وقتی دادهٔ Baseline برای Limit قابلدفاع کافی نیست، Run chart با ترتیب زمان و median میتواند شروع مناسبی برای دیدن shift/trend باشد. اما Rule، minimum points و handling ties باید پیشتعریف شود. Run chart نیز Cause یا Improvement را ثابت نمیکند و با تغییر Definition شکسته میشود.
Rational Subgroup را بر اساس Process بسازید
ترکیب Mobile/API، PR/Nightly، C1/C4 یا دو Environment در یک نقطه میتواند variation source را پنهان کند. Subgroup باید واحدهایی را جمع کند که تحت شرایط قابلمقایسه تولید شدهاند. Segmentation پسینی برای شکار داستان مطلوب ممنوع است؛ rule و hierarchy را پیشاپیش ثبت کنید.
Baseline Contract بنویسید
Baseline id/version: BL-MPASS-v2 metric_version: M-PASS-ATTEMPT-v4 period: 2026-W10..W29 points: 20 subgroup: checkout regression / weekly inclusion: final snapshots with completeness ≥ 0.98 exclusions: documented collector outage W17 known_changes: runner upgrade W09, before baseline method/assumptions: proportion chart; independence reviewed center/limits: derived values with code/version frozen_at: 2026-07-27T00:00:00Z review_trigger: metric/process/source structural change approved_by: measurement steward + flow owner
Baseline را با Intervention آلوده نکنید
اگر rollout در هفتهٔ ۱۲ شروع شده، Weeks ۱–۲۰ را بیتفکیک برای Limit نگیرید؛ Signal ممکن است در Baseline حل شود. Phase I برای ساخت/پاکسازی Baseline و Phase II برای Monitoring را جدا کنید. Exclusion فقط با علت قابلردیابی است، نه حذف نقطهٔ نامطلوب.
Limit را هر ماه برای سبزشدن محاسبه نکنید
Control limit متحرکِ بیقاعده، تغییر را جذب و قابلیت مقایسه را نابود میکند. NIST نیز یادآور میشود Chart عملکرد فعلی را با گذشته مقایسه میکند و تغییر مکرر Limits فایده را از بین میبرد. Freeze، trigger، review، version و bridge period لازم است.
چه زمانی Re-baseline مجاز است؟
- Metric definition/Source/Population ساختاری عوض شده است.
- Process change پایدار و با Evidence تأیید شده است.
- Special cause شناخته و دورهٔ جدید باثبات شده است.
- Context قدیمی دیگر Decision فعلی را نمایندگی نمیکند.
- Baseline پیشین خطای داده یا assumption نقضشده دارد.
Re-baseline نتیجهٔ بد را پاک نمیکند. Old/new baseline، effective date، reason، decision، affected conclusion و approver را نگه دارید.
Signal rule را پیش از دیدن نمودار ثبت کنید
| Rule family | حساسیت | Trade-off |
|---|---|---|
| یک نقطه بیرون Limit | جهش بزرگ | false alarm وابسته به assumptions |
| Run/shift یکطرف Center | جابجایی پایدار | rule/count باید پیشتعریف شود |
| Trend پیوسته | drift | seasonality/ties اثر دارد |
| Zone rules | shift کوچکتر | حساسیت و هشدار بیشتر |
| EWMA/CUSUM | تغییر کوچک تجمعی | تنظیم/تخصص بیشتر |
یک Rule set جهانی برای همهٔ Metricهای تست وجود ندارد. Multiple rules نرخ false signal را تغییر میدهند. Code/version، parameters، rationale و validation را در SignalPolicy نگه دارید.
Direction of Good همیشه یکطرفه نیست
Bug count کمتر میتواند کیفیت یا Observation ضعیفتر باشد؛ Pass rate بالاتر میتواند Suite آسانتر باشد؛ Cycle time کمتر میتواند Scope حذفشده باشد. برای هر Metric، Benefit hypothesis و Countermetric بنویسید. Signal را ابتدا «نامعمول» بخوانید، سپس با Context تعیین کنید مطلوب، نامطلوب یا مبهم است.
Signal، Cause نیست
نقطه بیرون Limit نمیگوید Automation خراب، Tester کمکار یا Code بد است. فقط میگوید Pattern نسبت به Model/Baseline نامعمول است. Deployment calendar، Artifact/Build، Environment, Data, Runner, policy، team capacity و customer events را با Stable IDs بررسی کنید.
Investigation Packet بسازید
SignalInvestigation id: SIG-MPASS-2026W31 metric/baseline/policy: M-v4 / BL-v2 / SP-v3 snapshot/points: SNAP-r2 / W24..W31 signal: run-of-8 below center detected_at: 2026-08-10T08:10:00Z data_quality: FINAL; completeness 0.991 context_events: runner-v6 at W30; change-mix stable hypotheses: retry schema / environment drift / product instability disconfirming_checks: raw attempts / matched build / second environment owner/due: test-infra owner / 2026-08-12 interim_action: preserve evidence; no automatic rollback status: INVESTIGATING conclusion/correction_ref: pending
Context Annotation با Explanation فرق دارد
Annotation میگوید «Runner v6 در W30 فعال شد»؛ Explanation میگوید «Runner v6 باعث shift شد» و Evidence بیشتری میخواهد. Artifact deployment، Policy، Holiday، traffic، staffing و outage را بدون ادعای علت روی Timeline نگه دارید. سپس Hypothesisها را به آزمون خلاف وصل کنید.
Correlation و همزمانی را به علت تبدیل نکنید
Shift پس از Workshop ممکن است از Workshop، Change mix، freeze یا Instrumentation آمده باشد. Signal review محل اثبات Improvement نیست. برای ارزیابی اثر، Evaluation design و Alternativeها را به Contribution Evaluation تحویل دهید.
Common-cause Action با Special-cause Action فرق دارد
| Classification | Action policy | مثال |
|---|---|---|
| Measurement break | Hold، repair، recompute، correct | schema/retry change |
| Special-cause candidate | Preserve evidence، investigate local event | runner outage |
| Common cause + unacceptable | System experiment | queue همیشه بالاتر از SLE |
| Common cause + acceptable | Observe با review trigger | variation در guardrail |
| Unknown | Mature window/collect evidence | late/missing زیاد |
واکنش به هر نقطه با فشار، expedite یا تغییر نفر Tampering میسازد. برعکس، Common cause بودن به معنی رضایت نیست؛ Process نامطلوب باثبات به Intervention سیستمی نیاز دارد.
Tampering چگونه Variation را بیشتر میکند؟
اگر بعد از هر هفتهٔ بد Scope، نفر، Tool یا threshold را عوض کنید، خودِ Reaction منبع Variation و Attribution مبهم میشود. Action policy باید deadband، evidence minimum، authority و cooldown داشته باشد. Emergency Harm مسیر جدا دارد و نباید منتظر Rule آماری بماند.
Metric Signal Review جایگزین Incident Response نیست
آسیب فعال، Security event، از دسترفتن پول/داده یا outage با Playbook عملیاتی مهار میشود، حتی اگر هیچ Signal آماری وجود نداشته باشد. Control Chart ابزار safety gate یا compliance نیست. پس از Containment، Evidence میتواند برای فهم Variation استفاده شود.
RCA را فقط پس از Signal معتبر آغاز کنید
Signal review Problem statement و Evidence boundary میسازد؛ علت ریشهای را تعیین نمیکند. برای Incident/recurring failure، راهنمای RCA از شواهد تا اقدام مالک Hypothesis/causal evidence/action verification است. عبارت «۵ چرا گفت Automation کم است» RCA معتبر نیست.
Process Recovery را با یک Outlier شروع نکنید
برای Flow ناپایدار، Identity/Intake/WIP/Age/SLE/Constraint و Baseline عملیاتی لازم است. اگر Evidence از بیثباتی ساختاری حکایت دارد، آن را به بازیابی فرایند تست تحویل دهید؛ این مقاله Operating model یا maturity transformation نمیسازد.
Improvement باید Experiment شود
برای Common cause نامطلوب یا Hypothesis یک Intervention کوچک با Baseline، Outcome، Guardrail، Stop، rollback و review بسازید. Signal پس از Intervention فقط یکی از Evidenceهاست. چرخهٔ کامل Hypothesis→Experiment→Decision را بهبود مستمر QA پوشش میدهد.
Measurement System را هم اندازه بگیرید
| Data-quality measure | تعریف | Countercheck |
|---|---|---|
| Completeness | valid received / expected | expected population audit |
| Late rate | after cutoff / eligible | event-ingestion lag |
| Duplicate rate | duplicate IDs / received | dedupe false merge |
| Join failure | unmatched / join-eligible | key drift |
| Correction rate | revised points / published | materiality/reason |
| Definition drift | unbridged version changes | schema registry |
Censoring، Open Work و Survivorship را ببینید
Cycle time فقط Finished itemها را میبیند؛ Work دشوارِ باز از نمودار حذف میشود. Age و Open count را کنار distribution پایانیافته نگه دارید. Cancelled، abandoned و carried-over status باید مشخص باشد. در غیر این صورت Process با پنهانکردن Work بهتر بهنظر میرسد.
Autocorrelation و Seasonality را نادیده نگیرید
هفتههای متوالی مستقل نیستند؛ Queue این هفته روی هفتهٔ بعد اثر دارد. Sprint boundary، پایان ماه، تعطیلات، release train و load cycle نیز Pattern میسازند. Assumption نقضشده false signal میدهد. Segment، model یا روش مناسب را با تحلیلگر انتخاب کنید و Limit ساده را کورکورانه اعمال نکنید.
Rare Event و Zero-heavy data احتیاط میخواهد
Critical escape ممکن است ماهها صفر باشد. Average هفتگی یا درصد با Denominator کوچک جهشهای فریبنده میسازد. Time-between-events، cumulative exposure یا narrative Incident evidence شاید مناسبتر باشد. صفر را Absence of risk یا proof of prevention نخوانید.
Segmentation هم درمان است، هم دام
Aggregate میتواند API regression را پشت UI پنهان کند؛ Segment زیاد نیز false discovery و داستانسازی میآورد. Segment hierarchy، minimum volume، multiplicity caveat و roll-up rule را پیشتعریف کنید. هر Segment Metric Contract و Data-quality view خودش را میخواهد.
Tool نمودار میسازد، Meaning نه
TestRail، Jira، CI، BI یا Spreadsheet میتواند event جمع و Chart رسم کند؛ هیچکدام Definition، Population، Chart suitability یا Cause را خودبهخود معتبر نمیکنند. Export، API، timezone، permissions، audit trail، schema evolution، retention و exit path را پیش از Tool adoption بررسی کنید.
AI میتواند Signal candidate بسازد، نه Verdict
AI برای anomaly candidate، annotation suggestion، data-quality query و خلاصهٔ Investigation مفید است. Model/prompt/version، training window، false alert، concept drift و Evidence refs لازم است. AI نباید Cause، blame، Risk acceptance، re-baseline یا Action را خودکار صادر کند؛ تغییر Model نیز Measurement change است.
Correction Record از تاریخچه محافظت میکند
MetricCorrection id: COR-MPASS-042 metric/snapshot: M-v4 / SNAP-W31-r1 reason: 17 late attempts after cutoff old/new: 0.960 / 0.944 signal_before/after: NONE / OUTSIDE_LIMIT affected_decision: OBSERVE → INVESTIGATE approved_at/by: 2026-08-11T09:00Z / measurement steward supersedes: prior chart and brief notification: flow owner + decision authority raw_evidence_retained: yes, subject to retention policy
Dashboard را silently overwrite نکنید. Old/new value، علت، Signal و Decision متاثر، approver و notification را ثبت کنید. Correction با دستکاری Historical baseline برای حذف Signal فرق دارد.
امنیت، حریم خصوصی و Retention
Series ممکن است Build، Commit، Ticket، نام کارمند، Log یا User event را Join کند. Purpose limitation، least privilege، aggregation، redaction، retention/deletion، access audit و incident response لازم است. People monitoring را پشت برچسب Process improvement پنهان نکنید؛ این مقاله مشاورهٔ حقوقی/حریم خصوصی نیست.
آزمایش تکرارپذیر: ۱۲ هفته سبز، Evidence قرمز
Fixture مصنوعی زیر ۱۲ هفته با Pass rate بین ۹۴ تا ۹۷، Target برابر ۹۰ و همهٔ RAGها سبز دارد و IMPROVEMENT_CONFIRMED اعلام میکند. Auditor رنگ یا Average را نمیسنجد؛ Contract، Data quality، Baseline، Signal policy، Investigation و Action governance را بررسی میکند.
{
"review_id": "",
"context": {"product": "", "service": "checkout", "metric_version": "", "population": "", "window": "", "timezone": ""},
"question": {"decision": "", "direction_of_good": "", "not_claimed": []},
"metric": {"definition": "", "unit": "proportion", "numerator": "", "denominator": "", "event_time": "", "source": "", "retry": ""},
"data_quality": {"completeness": null, "missing_policy": "zero", "late_policy": "", "duplicate_policy": "", "snapshot_id": ""},
"baseline": {"id": "", "period": "", "points": 12, "method": "", "assumptions": [], "frozen_at": "", "known_changes_excluded": false},
"chart": {"family": "", "selection_basis": "", "subgroup": "", "signal_rules": [], "target_separate_from_limits": false},
"investigation": {"owner": "", "due": "", "evidence_refs": [], "alternatives": []},
"actions": {"measurement_break": "", "common_cause": "", "special_cause": "", "unknown": "", "guardrail": "", "automatic_process_change": true},
"rebaseline": {"trigger": "", "method": "", "history": ""},
"correction": {"trigger": "", "method": ""},
"dashboard": {"target": 90, "values": [95,96,94,97,95,96,94,95,96,95,97,96], "rag": "GREEN"},
"declared": "IMPROVEMENT_CONFIRMED"
}
const fs = require('node:fs');
const r = JSON.parse(fs.readFileSync(process.argv[2], 'utf8'));
const f = [];
const need = (ok, rule, path) => { if (!ok) f.push({ rule, path }); };
need(r.review_id, 'IDENTITY', 'review_id');
for (const key of ['product', 'metric_version', 'population', 'window', 'timezone'])
need(r.context?.[key], 'CONTEXT', `context.${key}`);
for (const key of ['decision', 'direction_of_good'])
need(r.question?.[key], 'QUESTION', `question.${key}`);
need((r.question?.not_claimed || []).length, 'BOUNDARY', 'question.not_claimed');
for (const key of ['definition', 'numerator', 'denominator', 'event_time', 'source', 'retry'])
need(r.metric?.[key], 'METRIC_CONTRACT', `metric.${key}`);
need(r.data_quality?.completeness !== null, 'DATA_QUALITY', 'data_quality.completeness');
need(r.data_quality?.missing_policy && r.data_quality.missing_policy !== 'zero', 'DATA_QUALITY', 'data_quality.missing_policy');
for (const key of ['late_policy', 'duplicate_policy', 'snapshot_id'])
need(r.data_quality?.[key], 'DATA_QUALITY', `data_quality.${key}`);
for (const key of ['id', 'period', 'method', 'frozen_at'])
need(r.baseline?.[key], 'BASELINE', `baseline.${key}`);
need((r.baseline?.assumptions || []).length, 'BASELINE', 'baseline.assumptions');
need(r.baseline?.points >= 15, 'BASELINE', 'baseline.points');
need(r.baseline?.known_changes_excluded === true, 'BASELINE', 'baseline.known_changes_excluded');
for (const key of ['family', 'selection_basis', 'subgroup'])
need(r.chart?.[key], 'CHART_DESIGN', `chart.${key}`);
need((r.chart?.signal_rules || []).length, 'SIGNAL_POLICY', 'chart.signal_rules');
need(r.chart?.target_separate_from_limits === true, 'LIMIT_BOUNDARY', 'chart.target_separate_from_limits');
for (const key of ['owner', 'due'])
need(r.investigation?.[key], 'INVESTIGATION', `investigation.${key}`);
need((r.investigation?.evidence_refs || []).length, 'INVESTIGATION', 'investigation.evidence_refs');
need((r.investigation?.alternatives || []).length, 'INVESTIGATION', 'investigation.alternatives');
for (const key of ['measurement_break', 'common_cause', 'special_cause', 'unknown', 'guardrail'])
need(r.actions?.[key], 'ACTION_POLICY', `actions.${key}`);
need(r.actions?.automatic_process_change === false, 'NO_AUTO_ACTION', 'actions.automatic_process_change');
for (const key of ['trigger', 'method', 'history'])
need(r.rebaseline?.[key], 'REBASELINE', `rebaseline.${key}`);
for (const key of ['trigger', 'method'])
need(r.correction?.[key], 'CORRECTION', `correction.${key}`);
const computed = f.length ? 'HOLD' : 'READY_FOR_SIGNAL_REVIEW';
if (r.declared !== computed) f.push({ rule: 'DECISION_MISMATCH', path: 'declared' });
console.log(JSON.stringify({ computed, count: f.length, findings: f }, null, 2));
process.exitCode = f.length ? 2 : 0;
نسخهٔ ناقص باید HOLD و ۴۸ Finding بدهد: Identity، پنج Context، سه Question/boundary، شش Metric، پنج Data-quality، هفت Baseline، پنج Chart/signal/limit، چهار Investigation، شش Action، سه Re-baseline، دو Correction و Decision mismatch. ۱۲ نقطهٔ سبز و Target هیچ Finding را نمیبندند.
پس از تکمیل Contract، Snapshot/Data quality، Baseline حداقل ۱۵نقطهای و بدون known change، Chart/rule/limit boundary، Investigation، Action policy بدون تغییر خودکار، Re-baseline و Correction، اجرای دوباره باید count=۰ و READY_FOR_SIGNAL_REVIEW بدهد. این فقط کاملبودن ساختار را میسنجد؛ صحت داده، suitability آماری، وجود Signal، Cause، Improvement یا Product quality را اثبات نمیکند.
آزمایشگاه فارسی و آفلاین: سری زمانی Checkout ساختگی
برای Practice، ۲۴ هفته Event کاملاً ساختگی از Checkout بسازید: Order، PaymentAttempt، PSP Stub، Callback، Ledger و Reconciliation fake؛ Build/Environment/Change-class stable IDs؛ Resultهای duplicate/late/out-of-order و یک collector outage؛ یک Runner change پس از Baseline؛ Pass-attempt ratio، Queue age و Join-failure guardrail. مبلغ canonical را IRR و تومان را فقط presentation label نگه دارید.
رقم فارسی/عربی/لاتین، ی/ی و ک/ک، RTL/LTR، UTC event time، Asia/Tehran display و جلالی صرفاً نمایشی را Data-quality case کنید. هیچ Network، Production، شرکت/تیم/کاربر/سفارش/پرداخت/PSP/بانک واقعی، نام، موبایل، ایمیل، IP، account، PAN/CVV2/OTP، Cookie، Token، Credential، Log یا Screenshot استفاده نشود. Lab ادعای بانکی، مالی، قانونی، امنیتی، آماری یا نمایندگی ایران ندارد.
Pilot سیروزه برای Signal Review
| روز | کار | خروجی | Stop/Review |
|---|---|---|---|
| ۱–۳ | Question/Metric/owner | Contract v1 | بدون Decision توقف |
| ۴–۷ | Source/event/join audit | Snapshot contract | missing/late نامعلوم |
| ۸–۱۲ | Time series و annotation | ordered dataset | version break |
| ۱۳–۱۶ | Baseline/subgroup/assumption | Baseline review | known change آلوده |
| ۱۷–۲۰ | Rule/false-alert/action policy | Signal policy | Chart نامتناسب |
| ۲۱–۲۴ | Shadow alerts | Investigation packets | alert fatigue |
| ۲۵–۲۷ | Measurement/Common/Special/Unknown | classification review | auto blame/action |
| ۲۸–۳۰ | Experiment/handoff/correction | Continue/Adapt/Stop | History حفظ شود |
Signal Review Cadence
Data-quality alert ممکن است پس از هر ingest، operational Signal روزانه، و stable-process review ماهانه باشد؛ نسخهٔ جهانی وجود ندارد. Cadence را با event volume، detection cost، Harm، lag، false-alert capacity و Decision deadline تعیین کنید. Review باید Signal/Unknown/Action/Owner/Due/Verification ثبت کند، نه فقط اسلاید Trend.
Anti-patternهای Metric-to-Action
| Anti-pattern | خطر | اصلاح |
|---|---|---|
| این هفته/هفتهٔ قبل | Noise بهجای Trend | ordered series/baseline |
| RAG-only | Variation پنهان | time series/limits/target |
| Target=control limit | طبیعی با مطلوب یکی میشود | سه مرز مستقل |
| هر Outlier=Cause | Jump to conclusion | investigation packet |
| هر Signal=bad | جهت مبهم | benefit/countermetric |
| هر هفته Limit تازه | Signal جذب میشود | freeze/rebaseline policy |
| Missing=zero | خوشبینی مصنوعی | UNKNOWN/data hold |
| Completed-only | Survivorship | Age/Open/censored |
| Auto-action | Tampering/Harm | human authority/guardrail |
| Silent correction | تصمیم بیردپا | supersession record |
چکلیست Owner پیش از Action
- Decision/Question/owner/authority و not-claimed روشن است.
- Metric version، Definition، Numerator و Denominator ثابت است.
- Population، eligibility، Window، event time و timezone ثبت شدهاند.
- Snapshot/query/source/join/dedupe قابلبازتولید است.
- Missing/duplicate/late/correction و Completeness دیده میشود.
- Series بهترتیب زمان و با N/Denominator رسم شده است.
- Subgroup و Segmentation پیشتعریف و قابلدفاع است.
- Baseline version/period/exclusion/known changes/freeze روشن است.
- Chart family و Assumptionها با Data سازگارند.
- Signal rules/parameters/version و false-alert trade-off ثبت شدهاند.
- Target/Specification از Center/Control limits جداست.
- Direction of good و Countermetric مشخص است.
- Signal با Cause یا Improvement برابر نشده است.
- Context events، Hypothesis و disconfirming check ثبت شدهاند.
- Measurement/Common/Special/Unknown Action policy وجود دارد.
- Incident/Harm مسیر فوری مستقل دارد.
- Re-baseline trigger و History تعریف شده است.
- Correction، affected decision و notification ثبت میشود.
- People scoring، blame و auto-action غیرفعال است.
- Privacy/access/retention/redaction کنترل شدهاند.
جمعبندی: از Trend تزئینی به Signal قابلاقدام
متریک تست وقتی به Improvement کمک میکند که اول خودش قابلاعتماد باشد، سپس Variation آن در Time و Context درست خوانده شود. دو نقطه، RAG، Target یا Average بهتنهایی Signal نمیسازند. Control limit نیز Goal نیست و Stable بودن به معنی Acceptable بودن نیست.
مسیر سالم این است: Question و Contract، Snapshot/Data gate، Series/Baseline، Signal policy، Investigation، Classification و Action متناسب. Measurement break را repair کنید؛ Special-cause candidate را بررسی کنید؛ Common cause نامطلوب را با Experiment تغییر دهید؛ Unknown را بالغ کنید؛ و هر تصمیم عوضشده را با Correction حفظ کنید.
پرسشهای متداول درباره تحلیل روند معیارهای تست
آیا بهترشدن Metric نسبت به هفتهٔ قبل نشانهٔ Improvement است؟
خیر. ممکن است نوسان عادی، تغییر Denominator/Scope، late data یا Measurement drift باشد. Series کامل، Baseline، Data-quality gate و Signal rule لازم است. حتی Signal مطلوب پس از Intervention نیز بهتنهایی Cause یا Improvement پایدار را ثابت نمیکند.
تفاوت Control Limit با Target چیست؟
Control limit از Variation تاریخی Process و روش Chart میآید و نامعمولبودن را میسنجد. Target/Specification از Goal، Requirement، Risk یا Policy میآید و مطلوب/قابلقبولبودن را بیان میکند. Process میتواند داخل Limits ولی دور از Target باشد.
برای متریکهای تست Run Chart بهتر است یا Control Chart؟
به Question، Data type، volume، denominator، independence، subgroup و Baseline بستگی دارد. Run chart برای شروع با دادهٔ محدود سادهتر است؛ Control chart با Contract و assumption مناسب Variation را دقیقتر مدل میکند. یک Chart family جهانی برای همهٔ Metricها وجود ندارد.
آیا هر Special-cause signal به RCA نیاز دارد؟
ابتدا Data quality و Measurement break را رد و Investigation متناسب بسازید. Signal ممکن است مطلوب، نامطلوب یا مبهم باشد. RCA رسمی برای Incident یا مسئلهٔ تکرارشوندهٔ مهم مناسب است؛ هر هشدار آماری به جلسهٔ سنگین یا اقدام فوری نیاز ندارد.
چه زمانی باید Baseline و Control Limits را عوض کنیم؟
پس از تغییر ساختاری Metric/Source/Population، Process change تأییدشده و پایدار، Special cause شناختهشده یا کشف خطای Baseline؛ نه برای سبزکردن Dashboard. Old/new version، effective date، reason، bridge، approver و affected decisions را حفظ کنید.
