KPI تضمین کیفیت؛ سیستم سنجش ضدبازی برای مدیر QA

یک تیم QA در پایان فصل چنین گزارشی می‌دهد: «۱۸۰۰ تست اجرا شد، ۹۲٪ تست‌ها خودکار است و Pass rate به ۹۹٫۲٪ رسید.» همه‌چیز عالی به نظر می‌رسد—تا وقتی بفهمیم دو نقص بحرانی به تولید فرار کرده، فقط ۵۸٪ ریسک‌های اولویت‌دار Evidence کافی داشته‌اند و کاربر پس از timeout پرداخت در ۰٫۲۸٪ تلاش‌ها بیش از ۱۵ دقیقه بلاتکلیف مانده است. عددها غلط نیستند؛ سیستم سنجش سؤال غلطی را جواب داده است.

این راهنما دربارهٔ فهرست‌کردن چند KPI محبوب نیست. نشان می‌دهد مدیر QA چگونه از هدف محصول و تصمیم واقعی، یک سیستم KPI تضمین کیفیت بسازد: Outcome را به سؤال و Metric tree تبدیل کند، برای هر Metric قرارداد داده و محدودیت بنویسد، Activity را با Outcome و Guardrail متوازن کند، کیفیت داده را Gate کند، اثر ناخواسته و بازی‌پذیری را پایش کند و Metricهای بی‌فایده را بازنشسته سازد. KPI خوب «ارزش QA را اثبات» نمی‌کند؛ شواهدی محدود برای یک تصمیم مشخص فراهم می‌کند.

خلاصه اجرایی: سیستم KPI در یک نگاه

از تصمیم شروع کنید، نه از ابزار: اول بگویید چه کسی دربارهٔ چه چیزی تصمیم می‌گیرد؛ سپس سؤال و Measure را طراحی کنید.
KPI با هر Metric یکی نیست: KPI زیرمجموعه‌ای کوچک، حساس و متصل به هدف/تصمیم است؛ Diagnostic metric می‌تواند زیادتر و موقتی باشد.
Activity را Outcome ننامید: تعداد تست، درصد اتوماسیون و تعداد باگ، حجم یا ویژگی فرایند را نشان می‌دهند؛ به‌تنهایی کیفیت مشتری یا بهره‌وری فرد را ثابت نمی‌کنند.
هر Metric قرارداد می‌خواهد: تعریف، فرمول، Population، Window، Segment، Source، Freshness، Owner، Limitation و Change history.
Metric را با Countermetric جفت کنید: سرعت بازخورد بدون Flakiness و Depth، یا Escape بدون Severity/Exposure/Detection opportunity قابل‌اعتماد نیست.
یک Score مرکب حقیقت نیست: وزن‌ها و Normalization قضاوت‌اند و می‌توانند اختلاف مهم را پنهان کنند؛ اجزا و Gateها را جدا نشان دهید.
برای رتبه‌بندی فردی استفاده نکنید: فعالیت تست به کار تیمی، نوع ریسک، فرصت و Context وابسته است و هدف‌گذاری آن رفتار را منحرف می‌کند.
Review و Retire بخشی از طراحی‌اند: KPI دائمی نیست؛ با تغییر هدف، Population، Instrumentation یا رفتار، باید اصلاح یا حذف شود.

مرز این مقاله با صفحات نزدیک چیست؟

این صفحه مالک «حاکمیت سبد KPI برای مدیر QA» است، نه همهٔ موضوعات اندازه‌گیری:

برای فرمول، تفسیر و محدودیت ۱۲ شاخص عملی، متریک‌های تست نرم‌افزار را ببینید.
برای ساخت رابط تصمیم، Drill-down و Semantic layer، راهنمای داشبورد گزارش تست مالک موضوع است.
برای تبدیل Signal به Hypothesis و آزمایش تغییر، از بهبود مستمر QA استفاده کنید.
برای Expected loss، TCO، Attribution و ROI، صفحهٔ ارزش تجاری تست نرم‌افزار را بخوانید.

خروجی این مقاله یک «Metric Governance Pack» است: Metric tree، Dictionary/Contract، Portfolio متوازن، Decision rule، Data-quality gate، Review log و سیاست استفادهٔ انسانی.

KPI، Metric، Indicator، Target و Evidence چه فرقی دارند؟

مفهوم	کارکرد	مثال Checkout
Goal/Outcome	وضعیت ارزشمند برای کاربر/کسب‌وکار	خریدار نتیجهٔ قطعی پرداخت را بدون برداشت اضافه ببیند.
Question	ابهامی که برای تصمیم باید پاسخ گیرد	چه سهمی از تلاش‌ها بعد از ۱۵ دقیقه هنوز نتیجهٔ قطعی ندارند؟
Measure	مشاهدهٔ خام یا مشتق‌شده	زمان تا Terminal state برای هر Attempt
Metric/Indicator	قاعدهٔ محاسبه روی Measureها	unresolved_15m / eligible_attempts × 100
Target/Threshold	محدودهٔ مطلوب، هشدار یا اقدام	≤۰٫۱٪ در پنجرهٔ rolling هفت‌روزه
KPI	Indicator کلیدی متصل به هدف و تصمیم	نرخ نتیجهٔ نامعلوم برای Gate و اولویت پایداری
Diagnostic metric	برای توضیح علت، نه هدف مدیریتی	نرخ timeout به تفکیک PSP و نسخه
Evidence	Metric همراه Context، lineage و محدودیت	روند Segmentشده + کیفیت داده + رخدادهای دیررس

یک KPI بدون تصمیم، فقط عددی پرهزینه است. یک Target نیز نباید با KPI یکی فرض شود: Indicator وضعیت را می‌سنجد، Target قضاوت مورد توافق را اضافه می‌کند و Action rule می‌گوید در صورت عبور چه باید کرد.

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

اندازه‌گیری می‌تواند توجه ایجاد کند، اما تضمین نمی‌کند Outcome بهتر شود. وقتی Metric به Target پرریسک، پاداش یا رتبه‌بندی تبدیل شود، افراد منطقی رفتارشان را با آن سازگار می‌کنند. نتیجه ممکن است بهینه‌سازی Proxy، تغییر طبقه‌بندی یا حذف موارد سخت از Population باشد.

Target باریک	رفتار قابل پیش‌بینی	Countermetric/کنترل
تعداد Test case	خردکردن سناریوها و تکرار کم‌ارزش	پوشش ریسک + Mutation/Defect challenge نمونه‌ای
درصد Automation	خودکارسازی موارد آسان و نگه‌داشتن تست بی‌ارزش	زمان Feedback + Flakiness + هزینه نگه‌داری + Outcome
Pass rate	حذف/Skip/Quarantine یا اجرای فقط Suite آسان	Untested/Blocked/Unknown + Scope ثابت + attempt lineage
Defect count	تورم گزارش یا پرهیز از Prevention	شدت/Exposure/recurrence + Customer outcome
Defect escape صفر	تغییر برچسب، سرزنش گزارش‌دهنده یا Release بسیار محافظه‌کار	Learning/reporting safety + Flow + Opportunity + Exposure
Cycle time کم	کاهش عمق Evidence یا کوچک‌کردن Population	Risk evidence + Rework + change instability

چارچوب پژوهشی SPACE برای بهره‌وری توسعه‌دهنده تصریح می‌کند بهره‌وری را نمی‌توان با یک Metric یا صرفاً دادهٔ Activity سنجید؛ ابعاد رضایت/بهزیستی، Performance، Activity، Communication/Collaboration و Efficiency/Flow باید با توجه به سطح و Context دیده شوند. استفادهٔ ما برای تیم QA اقتباس است، نه ادعای اینکه SPACE یک استاندارد KPI تست است.

اصل مرکزی: Outcome → Question → Measure → Decision

Outcome
  └─ Decision
      └─ Questions
          ├─ KPI / leading indicator
          ├─ KPI / outcome indicator
          ├─ Guardrail / countermetric
          └─ Diagnostic metrics
               └─ Measures → sources → data-quality rules

نسخهٔ جاری ISTQB CTAL Test Management v3.0 نیز Test metric را به Test objective متصل می‌کند و Project، Product و Process metric را از هم تفکیک می‌کند؛ Metric مناسب Planning/Monitoring/Control ممکن است با Metric Completion متفاوت باشد. این نقطهٔ شروع خوبی است، اما طراحی کسب‌وکاری، داده و ضدبازی همچنان بر عهدهٔ سازمان است.

گام اول: Decision Contract بنویسید

پیش از انتخاب KPI، برای هر مخاطب Decision contract بسازید:

Decision Contract DC-QA-07
Decision: آیا روی کاهش feedback latency سرمایه‌گذاری کنیم؟
Owner: Engineering/Product leadership
Cadence/deadline: ماهانه / 2026-09-01
Scope: Checkout، App/API، ایران، Releases 6.3–6.5
Outcome at risk: نتیجهٔ درست و سریع پرداخت
Questions: کجا انتظار ایجاد می‌شود؟ اثر آن بر rework و release چیست؟
Options: حذف bottleneck، parallelize، کاهش scope، عدم اقدام
Evidence freshness: حداکثر 7 روز
Minimum segments: release، PSP، test lane، risk class
Action rule: Pilot فقط اگر gap پایدار و data quality سالم باشد
Decision log/review date:

یک KPI می‌تواند برای یک تصمیم مفید و برای تصمیم دیگر مضر باشد

مدت اجرای Regression برای Capacity planning مفید است؛ برای سنجش کیفیت محصول کافی نیست. Defect age برای Triage صف مفید است؛ برای رتبه‌بندی تستر بی‌معنا و زیان‌آور است. همیشه کنار KPI بنویسید «برای چه تصمیمی مجاز است» و «برای چه استفاده‌ای ممنوع است».

گام دوم: Metric tree بسازید، نه KPI pile

انباشت KPI یعنی هر واحد عدد محبوب خودش را روی Dashboard بگذارد. Metric tree رابطهٔ فرضی بین Outcome، Driver و Diagnostic را آشکار می‌کند:

Outcome: پرداخت درست و قطعی
├─ Product outcome
│  ├─ unresolved_15m rate
│  └─ duplicate charge / amount mismatch
├─ Risk evidence
│  ├─ risk-weighted evidence coverage
│  └─ critical unknown age
├─ Feedback flow
│  ├─ p50/p95 commit→trusted signal
│  └─ blocked time by reason
├─ Delivery/production balance
│  ├─ change lead time / deployment frequency
│  └─ change fail + recovery / rework
└─ Test-system health
   ├─ flaky/retry/quarantine rate
   └─ false negative / data freshness / maintenance toil

فلش‌های این درخت «فرضیهٔ اثر» هستند، نه اثبات علیت. مثلاً کاهش Feedback time ممکن است Rework را کم کند، اما تغییر اندازهٔ Batch، تجربهٔ تیم یا نوع Release نیز اثر دارد. اگر رابطه برای تصمیم مهم است، با Cohort، Pilot یا طرح تحلیلی مناسب بررسی شود.

گام سوم: سبد متوازن KPI برای QA طراحی کنید

سبد پایه را از پنج لنز بسازید. لازم نیست از هر خانه دقیقاً یک KPI دائمی داشته باشید؛ انتخاب به هدف و بلوغ داده بستگی دارد.

لنز	پرسش	نمونه KPI/Indicator	خطر تفسیر
Outcome کاربر/محصول	کاربر نتیجهٔ درست و قابل‌اعتماد می‌گیرد؟	critical journey success، unresolved state، customer-impact minutes	Attribution مستقیم به QA
ریسک و Evidence	برای خطرهای مهم چه می‌دانیم/نمی‌دانیم؟	risk-weighted evidence coverage، unknown age، gate exception	Coverage اسمی بدون کفایت شاهد
Flow و Feedback	Signal معتبر چه مدت در صف می‌ماند؟	commit→trusted-signal p50/p95، blocked/wait، feedback arrival before decision	سرعت به قیمت Depth
کیفیت تولید/یادگیری	پس از Release چه شکست و تکراری دیده می‌شود؟	impact-weighted escape، recurrence، recovery/reconciliation	سرزنش QA یا تغییر طبقه‌بندی
سلامت سیستم تست	خود Evidence چقدر قابل اعتماد و پایدار است؟	flaky/retry/quarantine، false-negative sample، stale data، maintenance toil	بهینه‌سازی ابزار به جای Outcome
سلامت انسانی/همکاری	سیستم کار امکان تمرکز و اعلام خبر بد می‌دهد؟	interrupt load، wait for review، survey/qualitative signals	نظارت فردی و نقض حریم خصوصی

DORA معیارهای تحویل نرم‌افزار را برای توانایی تیم در تحویل امن، سریع و کارآمد ارائه می‌کند و توصیه می‌کند چارچوب متناسب با هدف سازمان انتخاب و توسط تیم Cross-functional مسئول ساخت/تحویل/عملیات برای بهبود استفاده شود. DORA score یک KPI اختصاصی QA یا ابزار رتبه‌بندی تیم‌ها نیست؛ فقط بخشی از تصویر Flow/production است.

گام چهارم: Metric Contract و Dictionary نسخه‌دار بسازید

Metric Contract v2
ID / name / version:
Goal / question / decision / owner:
Type: outcome | driver | guardrail | diagnostic
Definition / formula / unit / direction:
Numerator / denominator / eligible population:
Event identity / deduplication / retry semantics:
Window / aggregation / percentile:
Mandatory segments / exclusions:
Source / lineage / refresh / late-data policy:
Data-quality checks / status when invalid:
Baseline / target / warning / action rule:
Countermetric / expected behavior response:
Known limitations / prohibited uses:
Access / retention / privacy:
Change history / review / retirement trigger:

نمونه: زمان رسیدن به Signal معتبر

Name: Commit-to-trusted-signal p95
Start: accepted commit timestamp on protected branch
End: first terminal test evidence that passes data-quality rules
Population: production-bound commits for Checkout; bots/docs excluded by rule
Unit/aggregation: minutes؛ p50 and p95 per rolling 7 days
Segments: lane, risk class, service, blocked reason
Retries: attempt chain counted once; trusted end is final valid attempt
Late data: recompute for 48h; mark provisional before closure
Target: p95 <= 30m (Pilot, review after 4 weeks)
Guardrails: flaky =85%; critical escapes=0
Invalid state: missing commit/run identity >1% → KPI UNKNOWN
Allowed: flow-improvement prioritization
Prohibited: individual tester ranking or release quality alone

در معیارهای زمان، میانگین می‌تواند Tail را پنهان کند. Google SRE دربارهٔ SLI/SLO بر تعریف شرایط اعتبار، Population و منبع اندازه‌گیری تأکید می‌کند و برای توزیع‌های چوله استفاده از Percentile را به Mean ترجیح می‌دهد. p95 نیز جادو نیست: باید همراه p50، حجم نمونه و Segment دیده شود.

گام پنجم: Data-quality gate را پیش از Target اجرا کنید

اگر داده معتبر نیست، عدد را صفر، آخرین مقدار یا سبز نشان ندهید؛ وضعیت باید UNKNOWN/STALE/INVALID باشد. حداقل Gateها:

Completeness: چه سهمی از Eventهای واجد شرایط Source/ID/Version/Time دارند؟
Uniqueness: Retry، rerun و callback تکراری چگونه Deduplicate می‌شوند؟
Validity: Status، واحد، Amount و Enum در Domain مجازند؟
Consistency: Client، API، Test runner و Warehouse یک معنا دارند؟
Timeliness: Refresh و Late-arrival داخل Window تصمیم هستند؟
Traceability: از KPI به Query، Semantic definition و رخداد خام می‌رسیم؟
Coverage bias: دستگاه، PSP، Region یا Failure state از Instrumentation جا نمانده است؟
Change detection: Schema، Query یا Pipeline بی‌اعلان عوض نشده است؟

if eligible_event_identity_missing > 1%: status = UNKNOWN
else if refresh_age > 2 * expected_interval: status = STALE
else if schema_version not in approved_versions: status = INVALID
else: compute KPI and attach quality badge

Badge کیفیت داده باید کنار KPI بماند، نه در صفحهٔ مخفی مهندسی داده. تصمیم‌گیر باید بداند «۰٫۰۷٪» Final است یا Provisional و چه بخشی از Population پوشش ندارد.

Baseline، Target، Threshold و Forecast را قاطی نکنید

مفهوم	پرسش	خطای رایج
Baseline	در تعریف و Window مشخص، اکنون کجا هستیم؟	تبدیل محدودیت فعلی به هدف مطلوب
Target	چه سطحی با Outcome و هزینه متناسب است؟	کپی Benchmark بدون Context
Warning threshold	کجا بررسی را شروع کنیم؟	تعبیر خودکار هر عبور به Incident
Action threshold	کدام شرط اقدام مشخص را فعال می‌کند؟	Threshold بدون Owner/Runbook
Forecast	اگر روند/فرض ادامه یابد، احتمالاً کجا می‌رسیم؟	عرضهٔ پیش‌بینی به‌عنوان واقعیت
Control limit	Variation فرایند در دادهٔ مناسب چه الگویی دارد؟	یکی‌گرفتن با Target کسب‌وکار

Target چگونه تعیین شود؟

Outcome و پیامد Miss را روشن کنید.
Metric contract و Baseline قابل‌اعتماد بسازید.
Segment و Distribution را ببینید؛ Mean یا Snapshot کافی نیست.
تعهد قانونی/قراردادی و نیاز کاربر را از Benchmark جدا کنید.
گزینه‌های Target را با هزینه، ریسک و رفتار ناخواسته مقایسه کنید.
Target آزمایشی را با Review date و Guardrail تصویب کنید.
تغییر Target را با Diff و Decision log ثبت کنید.

Metricهای رایج QA را چگونه سالم کنیم؟

تعداد Test و Pass rate

تعداد اجرا برای Capacity و هزینه مفید است، نه ارزش. Pass rate باید Denominator و Statusهای Failed/Blocked/Untested/Skipped/Inconclusive/Quarantined/Unknown را حفظ کند. Retry نباید attempt شکست‌خورده را محو کند. کنار آن Risk evidence و Suite health را نشان دهید.

پوشش تست

Coverage می‌تواند Code، Requirement، Risk، State، Data partition، Platform یا Journey باشد. ۹۰٪ Line coverage به معنی ۹۰٪ خطر نیست. برای مدیریت QA، Risk-weighted evidence coverage و Unknownهای پرپیامد معمولاً از درصد خام معنادارترند؛ Coverage نیز Evidence of exercise است، نه اثبات Correctness.

Defect escape و DRE

Escape را به Cohort انتشار، Detection opportunity، Exposure، Severity و Customer impact متصل کنید. نبود گزارش ممکن است از Instrumentation یا گزارش‌دهی ضعیف باشد. Escape «شکست شخص QA» نیست؛ Signal سیستم طراحی، کد، Review، تست، Release و عملیات است. برای موارد دیرکشف‌شده Window بسته‌شدن Cohort لازم است.

Defect density و Rejected defect

LOC و Story point واحدهای ناپایدار برای مقایسهٔ تیم‌ها هستند. Rejected defect نیز ترکیبی از Duplicate، Expected، Cannot reproduce، bad environment و اختلاف Requirement است؛ Percent بالا بدون Reason taxonomy چیزی دربارهٔ مهارت تستر ثابت نمی‌کند. Trend را در یک Context ثابت و با نمونه‌برداری کیفی بررسی کنید.

درصد اتوماسیون و ROI

درصد Test case خودکار، ارزش یا صرفه‌جویی را نشان نمی‌دهد. Journey بحرانی، Feedback latency، Detection yield، Flakiness، نگه‌داری، زیرساخت، Triage و Opportunity cost را ببینید. ROI به TCO، منفعت منتسب، عدم قطعیت و سناریو نیاز دارد و در صفحهٔ تخصصی ارزش تجاری توضیح داده شده است.

NPS، CSAT و درآمد

این‌ها Outcomeهای محصول/کسب‌وکار با علت‌های متعددند: قیمت، محتوا، پشتیبانی، عملکرد، اعتماد، رقابت و کمپین. از آن‌ها برای Context و بررسی رابطه استفاده کنید، نه ادعای «QA باعث افزایش NPS شد». Attribution به طرح مقایسه و شواهد بیشتر نیاز دارد.

کیفیت محصول را با Vocabulary مشترک پوشش دهید

اگر سبد فقط Reliability و Defect را ببیند، Functional suitability، Performance efficiency، Compatibility، Interaction capability، Security، Maintainability، Flexibility و Safety ممکن است نامرئی شوند. ISO/IEC 25010:2023 یک مدل نه‌ویژگی برای Specification و Evaluation کیفیت محصول ICT ارائه می‌کند. از آن برای کشف Blind spot استفاده کنید؛ استاندارد KPI، Target یا اولویت محصول شما را تعیین نمی‌کند.

Quality attribute map
Attribute → affected journey → harm/risk → evidence → indicator → decision

Security → پرداخت → افشای Token → review/test/log audit → open critical risk → gate
Reliability → callback → برداشت تکراری → fault/reconciliation → duplicate charge → rollback
Interaction capability → نتیجه → اقدام دوباره → user study/RUM → unresolved/retry → design priority
Maintainability → تغییر PSP → delay/rework → change cohort → trusted feedback p95 → platform investment

سبد KPI را بر اساس Horizon و مخاطب لایه‌بندی کنید

Horizon	مخاطب/تصمیم	نمونه Signal	Cadence
Run/Build	مهندس؛ تشخیص و اقدام فوری	failure state، data invalid، flaky attempt	رویدادی
Release	Release owner؛ GO/HOLD/Scope split	risk evidence، unknown، guardrail، exception	Gate
Product/Service	Product/SRE؛ اولویت و پایداری	journey outcome، SLO، customer-impact	هفتگی/ماهانه
Capability	QA/Engineering leadership؛ سرمایه‌گذاری	feedback distribution، toil، bottleneck، test health	ماهانه/فصلی
Strategy	Leadership؛ Portfolio و ریسک	Outcome trend، risk concentration، investment experiment	فصلی

عدد Run-level را مستقیم به هیئت‌مدیره نبرید و KPI فصلی را برای Debug استفاده نکنید. Aggregation باید Drill-down و معنا را حفظ کند. برای قالب Status، Audience و Decision request به گزارش تست حرفه‌ای مراجعه کنید.

چرا Composite score و رتبه‌بندی چراغ راهنما نیستند؟

ترکیب Pass rate، Automation، Escape و Cycle time در «QA Health = ۸۷» چهار مسئله دارد:

واحدها و جهت‌ها متفاوت‌اند و Normalization انتخابی است.
وزن‌ها قضاوت ارزشی‌اند؛ وزن ۴۰٪ Automation یک حقیقت علمی نیست.
Compensation رخ می‌دهد: Activity بالا می‌تواند Failure بحرانی را بپوشاند.
یک عدد، Uncertainty، Missing data، Segment و Dissent را حذف می‌کند.

اگر Score برای خلاصه لازم است، فرمول/وزن/نسخه را منتشر کنید، اجزا را کنار آن نگه دارید، Critical guardrail را Non-compensatory کنید، Missing را امتیاز خوب ندهید و Sensitivity وزن‌ها را نشان دهید. اغلب یک Scorecard کوچک با وضعیت مستقل Outcome/Risk/Flow/Test-health بهتر از عدد واحد است.

Decision scorecard (not a team grade)
Outcome gate:       PASS | FAIL | UNKNOWN
Risk evidence:      SUFFICIENT | GAP | UNKNOWN
Feedback flow:      WITHIN TARGET | REVIEW
Test-system health: HEALTHY | DEGRADED | INVALID
Decision:           eligible for review; never automatic GO

آزمایش قطعی: Activity score چگونه Outcome بد را برنده می‌کند؟

برای نمایش یک خاصیت محدود، چهار Release cohort ساختگی در Node.js مقایسه شدند. مدل Activity-only از سه ورودی استفاده کرد: ۴۵٪ تعداد تست Normalizeشده، ۳۰٪ درصد Automation و ۲۵٪ Pass rate. مدل دوم Score نساخت؛ چهار Gate مستقل داشت: Outcome، Risk evidence، Feedback و Test-system health.

Runtime: Node.js 24.18.0

Activity-only ranking:
R-A  97.40  | critical escapes=2 | unresolved=0.28%
R-C  80.07  | critical escapes=0 | unresolved=0.09%
R-B  67.60  | critical escapes=0 | unresolved=0.07%
R-D  59.00  | critical escapes=0 | unresolved=0.05%

Activity winner: R-A

Decision gates:
R-A investigate | failed outcome, riskEvidence, feedback
R-B eligible    | all four gates passed
R-C investigate | failed riskEvidence, feedback, testSystem
R-D eligible    | all four gates passed

مرز ادعای آزمایش

آزمایش نشان می‌دهد با این داده و وزن‌های ازپیش‌انتخاب‌شده، Score قابل‌جبران R-A را با وجود Outcome بد اول می‌کند؛ Gateهای مستقل آن را برای بررسی علامت می‌زنند. این خروجی ثابت نمی‌کند Gate همیشه بهتر است، R-B/R-D Release مناسبی دارند یا این آستانه‌ها برای پروژهٔ واقعی معتبرند. Cohortها، وزن‌ها، Thresholdها و رابطه‌ها ساختگی‌اند؛ حجم نمونه، عدم قطعیت، تغییر Mix، هزینه، علیت، کیفیت واقعی Evidence و رفتار انسانی مدل نشده است. هدف Demonstration ریسک Aggregation/compensation است، نه Benchmark، مدل بلوغ یا فرمول رتبه‌بندی.

نمونه ایرانی: KPIهای Checkout و PSP

یک Marketplace فرضی در ایران Checkout را روی دو PSP اداره می‌کند. UI مبلغ تومان نشان می‌دهد اما API، Ledger و Settlement مقدار Canonical را به IRR نگه می‌دارند. timeout-after-commit، callback تکراری/دیررس، Reconciliation و اختلاف زمان UTC/Asia/Tehran خطرهای اصلی‌اند.

Outcome و Decision

Outcome: نتیجهٔ درست و قطعی پرداخت بدون برداشت/سفارش تکراری
Decision 1: Release 6.4 را GO/HOLD/Scope-split کنیم؟
Decision 2: سرمایهٔ فصل بعد را به PSP failover، test data یا CI capacity بدهیم؟

Portfolio پیشنهادی

نقش Metric	تعریف کوتاه	Target/قاعدهٔ نمونه	Countermetric/Segment
Outcome	duplicate charge و IRR mismatch	=1 → STOP/incident	PSP، release، display toman
Outcome	unresolved_15m / eligible attempts	≤۰٫۱٪، rolling 7d	late event completeness، PSP
Risk evidence	جمع وزن ریسک‌های دارای شاهد کافی / کل وزن	≥۸۵٪ و هیچ Critical Unknown	کیفیت/تازگی Evidence
Flow	commit→trusted signal p50/p95	p95≤۳۰ دقیقه Pilot	Flaky≤۳٪، depth ثابت
Test health	retry-attempt / initial attempts	روند و علت، نه پاداش	quarantine age، false-negative sample
Learning	recurring production failure by mechanism	کاهش Cohort-matched	reporting volume/safety

قرارداد دادهٔ ایرانی

Amount: مقدار Canonical با نام/واحد IRR؛ تومان فقط Presentation با Rule تبدیل نسخه‌دار.
Digits: ارقام فارسی ۱۲۳، عربی ۱۲۳ و لاتین ۱۲۳ پیش از Matching Normalize شوند، Raw حفظ شود.
Unicode: ی/ی، ک/ک و نیم‌فاصله در Dimensionهای متنی و Search rule مشخص باشند.
Time: Instant در UTC ذخیره؛ عملیات با Asia/Tehran؛ نمایش شمسی یک View است و Window را تغییر نمی‌دهد.
Identity: attempt_id، payment_id، PSP reference، callback event_id و idempotency_key تفکیک شوند.
Late/replay: callback دیررس Window را Backfill کند؛ Duplicate به Volume موفقیت اضافه نشود.
Segmentation: PSP، نسخه App/API، شبکه، دستگاه، مسیر Normal/Retry/Recovery و Campaign traffic.
Privacy: PAN، CVV، Token، موبایل و دادهٔ شخصی وارد Label یا Dashboard عمومی نشود.

تصمیم نمونه

Pass rate برابر ۹۸٫۷٪ است، اما Risk evidence برای timeout-after-commit فقط ۷۶٪ و دادهٔ PSP-A به دلیل ۴٪ Event فاقد Identity، INVALID است. تصمیم خودکار HOLD نیست؛ Status «Evidence insufficient» به Release owner می‌رود. گزینه‌ها: تکمیل Instrumentation، Scope split به PSP-B یا Risk acceptance محدود با Rollback trigger. برای ساخت انتظار و Target مشترک با ذی‌نفعان، قرارداد انتظار کیفیت مکمل این Decision است.

تحلیل روند: Snapshot کافی نیست

p50/p95 و Distribution را به‌جای Mean تنها ببینید.
Cohort Release را ببندید تا Escape دیررس به نسخهٔ درست برگردد.
Volume/Mix را کنار Rate نگه دارید؛ درصد روی ۲۰ نمونه با ۲۰هزار یکسان نیست.
Segment را پیش از Aggregation بررسی کنید تا گروه آسیب‌دیده در کل پنهان نشود.
Seasonality، کمپین، تعطیلات، جمعه و اختلال PSP را Annotation کنید.
تغییر Instrumentation، Query و Taxonomy را روی نمودار علامت بزنید.
Confidence/uncertainty را در تصمیم‌های حساس گزارش کنید؛ از دقت اعشاری کاذب پرهیز کنید.
هم‌زمانی Trendها را علیت ننامید؛ برای تغییر از Pilot/Control یا تحلیل مناسب استفاده کنید.

Google SRE در پایش سیستم‌های توزیع‌شده کاربردهای Trend، مقایسه، Alert، Dashboard و Retrospective analysis را جدا می‌کند و بر Signalهای سطح خدمت و Drill-down تأکید دارد. همهٔ Metricها Pager یا KPI مدیریتی نیستند؛ شدت و Actionability مسیرشان را تعیین می‌کند.

Alert، KPI، Dashboard و Report را جدا نگه دارید

Artifact	سؤال	ویژگی
Alert	اکنون اقدام فوری لازم است؟	Threshold/condition، Owner، Runbook، Dedup
KPI	در مسیر هدف/تصمیم هستیم؟	Contract، Target، Countermetric، Review
Dashboard	وضعیت و Trend را چگونه Drill-down کنیم؟	Freshness، Semantic consistency، role view
Report	در Window چه رخ داد و چه آموختیم؟	Narrative، Context، limit، decision request
Diagnostic	علت احتمالی چیست؟	High-cardinality، موقت، فنی
Decision log	چه کسی با چه Evidence چه انتخابی کرد؟	Version، Dissent، expiry، review

حاکمیت تغییر: Metric نیز Version دارد

Metric change MC-18
Metric: unresolved_15m v2 → v3
Change: exclude user-cancel-before-PSP; add late callback backfill 48h
Reason/evidence: v2 denominator mixed non-payment attempts
Impact: historical trend +0.03pp after recompute
Compatibility: pre-v3 points labeled legacy
Dashboard/alert/decision contracts affected:
Approved by: Product analytics + QA + Finance
Effective / backfill / review date:

تغییر Query یا Denominator می‌تواند Trend را بشکند. اگر Backfill ممکن نیست، خط نسخه را روی نمودار حفظ کنید و قبل/بعد را بدون Caveat مقایسه نکنید. Target نیز جدا Version می‌شود؛ تغییر تعریف Metric با Relaxکردن Target یک اتفاق نیست.

سیاست اخلاقی و انسانی استفاده از KPI

KPIهای تیم/سیستم را برای رتبه‌بندی فردی، تنبیه یا اخراج به‌کار نبرید.
قبل از جمع‌آوری داده، Purpose، دسترسی، Retention و استفادهٔ ممنوع را اعلام کنید.
دادهٔ Git/Test/Chat حضور، تلاش شناختی، کیفیت تصمیم یا همکاری نامرئی را کامل نشان نمی‌دهد.
تفاوت فرصت را لحاظ کنید: تستر Incident-heavy یا حوزهٔ پرریسک Activity قابل‌مقایسه با دیگری ندارد.
Metric سلامت انسانی را Aggregate، حداقلی و همراه روش کیفی نگه دارید؛ مدیر نباید تشخیص پزشکی دهد.
افراد باید تعریف Metric، دادهٔ خود و مسیر اصلاح خطا را بتوانند ببینند.
AI می‌تواند Anomaly یا Draft narrative پیشنهاد کند، اما نباید Performance فرد، علت یا Risk acceptance را خودکار استنتاج کند.
خبر بد را جریمه نکنید؛ کاهش گزارش Defect/Incident شاید کاهش ایمنی گزارش‌دهی باشد.

برای طراحی People/Flow metrics و ظرفیت بدون Hero culture، سیستم عملیاتی رهبری تیم QA را ببینید. KPI سازمانی جای گفت‌وگوی خصوصی، شواهد چندمنبعی و حمایت عملکرد را نمی‌گیرد.

Review ماهانه سبد KPI

KPI Portfolio Review
1. کدام Decision واقعاً با هر KPI گرفته شد؟
2. Data-quality و Unknown چه بود؟
3. چه رفتار/بازی/ترسی ایجاد شد؟
4. آیا Countermetric خراب شد؟
5. آیا Segment یا Tail پنهان ماند؟
6. آیا رابطه Driver→Outcome هنوز فرض معقولی است؟
7. Keep | Modify | Split | Pause | Retire؟
8. Owner، تغییر، موعد و Validation بعدی؟

Triggerهای بازنشستگی KPI

هدف یا Decision دیگر وجود ندارد.
هیچ اقدام متفاوتی با تغییر KPI انجام نمی‌شود.
هزینهٔ جمع‌آوری/توضیح بیشتر از ارزش تصمیم است.
Proxy ارتباط معنادار خود را با Outcome از دست داده است.
Metric به‌طور پایدار بازی می‌شود و کنترل آن نامتناسب است.
Instrumentation یا Population قابل اتکا نیست.
Metric دیگری همان سؤال را با هزینه یا آسیب کمتر پاسخ می‌دهد.
Target اشباع شده و Variation باقی‌مانده تصمیم‌ساز نیست.

Anti-patternهای KPI تضمین کیفیت

KPI cemetery: عددها جمع می‌شوند اما Owner/Decision ندارند.
Vanity green: Pass/Automation بالا بدون Risk/Unknown.
One-number health: Score مرکب Failure بحرانی را جبران می‌کند.
Tool-first: KPI از فیلدهای آمادهٔ ابزار انتخاب می‌شود.
Benchmark worship: Target صنعت بدون Population و Context کپی می‌شود.
Mean-only: Tail و Segmentهای آسیب‌دیده حذف می‌شوند.
Denominator drift: جمعیت تغییر می‌کند اما Trend پیوسته نمایش داده می‌شود.
Retry laundering: Failed attempt پشت Final pass پنهان می‌شود.
Unknown as zero: قطع داده بهبود KPI دیده می‌شود.
Escape blame: شکست سیستمی به امتیاز فرد QA تبدیل می‌شود.
Count productivity: Test/bug/commit حجم فعالیت را عملکرد می‌نامد.
Automation quota: تست کم‌ارزش فقط برای افزایش درصد نگه داشته می‌شود.
Target equals baseline: وضعیت فعلی نیاز کاربر فرض می‌شود.
Target without action: قرمزشدن Owner یا Runbook ندارد.
Causality theater: همبستگی KPI با NPS/درآمد «ارزش اثبات‌شده» نام می‌گیرد.
Data quality hidden: Freshness و Missing فقط نزد تیم داده می‌ماند.
Permanent exception: Threshold بعد از هر Miss Relax می‌شود.
Metric surveillance: دادهٔ تیم برای کنترل فردی و نقض حریم خصوصی مصرف می‌شود.
Dashboard as communication: خطر فوری به امید دیده‌شدن Push نمی‌شود.
No retirement: Metric قدیمی برای همیشه هزینه و توجه می‌گیرد.

برنامهٔ ۳۰روزه ساخت سیستم KPI

هفته اول: Inventory و Decision audit

یک Value stream و دو Decision واقعی را انتخاب کنید.
KPI/گزارش موجود را با Owner، هزینه و اقدام آخر Inventory کنید.
Metricهای بدون Decision و استفاده‌های پرریسک فردی را علامت بزنید.
Outcome، Quality attribute و ریسک‌های اولویت‌دار را ببندید.

هفته دوم: Tree و Contract

Outcome→Question→Metric tree را با تیم Cross-functional بسازید.
۳ تا ۵ KPI و Countermetricهایشان را انتخاب کنید.
Metric Contract، lineage و Data-quality gate را نسخه‌بندی کنید.
Historical baseline را با Segment و محدودیت محاسبه کنید.

هفته سوم: Shadow mode و Adversarial review

KPI را بدون پاداش/تنبیه در Shadow mode اجرا کنید.
بپرسید چگونه می‌توان هر Metric را بدون بهبود Outcome بهتر کرد.
Retry، Missing، Late data، تغییر Mix و Threshold boundary را تست کنید.
Score/گزارش را با Releaseهای واقعی و Narrative کارشناسان مقایسه کنید.

هفته چهارم: Pilot تصمیم و Review

یک Decision را با Pack جدید اجرا و Log کنید.
میزان Unknown، زمان تصمیم و Actionability را بسنجید.
Metricهای زائد را Retire و Contractهای مبهم را اصلاح کنید.
Cadence ماهانه، Owner داده و سیاست استفادهٔ انسانی را تصویب کنید.

موفقیت ۳۰ روزه «Dashboard جدید» نیست. باید بتوانید نشان دهید یک تصمیم با Evidence روشن‌تر گرفته شد، یک Unknown زودتر دیده شد، یک رفتار بازی‌پذیر کنترل شد یا یک Metric بی‌مصرف حذف شد.

چک‌لیست تصویب هر KPI

هدف، سؤال و Decision مشخص‌اند؟
Decision owner و Cadence نام‌دارند؟
Metric نقش Outcome/Driver/Guardrail/Diagnostic دارد؟
Definition، فرمول، واحد و جهت روشن‌اند؟
Numerator، Denominator و Population بسته‌اند؟
Retry، Duplicate و Event identity تعریف شده‌اند؟
Window، Aggregation و Percentile مناسب‌اند؟
Segmentهای اجباری و گروه‌های حذف‌شده معلوم‌اند؟
Source، lineage، Freshness و Late data سیاست دارند؟
Data-quality failure وضعیت UNKNOWN/INVALID می‌سازد؟
Baseline و Target از هم جدا و نسخه‌دارند؟
Threshold به Action، Owner و Runbook وصل است؟
Countermetric و Guardrail داریم؟
رفتار ناخواسته/راه بازی‌کردن بررسی شده است؟
Limitation و استفاده‌های ممنوع نوشته شده‌اند؟
آیا Metric برای رتبه‌بندی فردی ممنوع است؟
Privacy، Access و Retention متناسب‌اند؟
Componentها پشت Composite score پنهان نشده‌اند؟
Review date و Retire trigger داریم؟
هزینهٔ نگه‌داری با ارزش تصمیم متناسب است؟

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

۱. مهم‌ترین KPI تضمین کیفیت چیست؟

KPI جهانی و واحدی وجود ندارد. انتخاب به Outcome، خطر، مرحلهٔ محصول و Decision بستگی دارد. یک سبد کوچک معمولاً Outcome کاربر، کفایت Evidence ریسک، Flow بازخورد و سلامت سیستم تست را با هم می‌بیند. Defect escape یا Pass rate به‌تنهایی «مهم‌ترین» نیستند و می‌توانند رفتار را منحرف کنند.

۲. چند KPI برای تیم QA مناسب است؟

برای یک Decision horizon معمولاً ۳ تا ۵ KPI کلیدی به‌همراه Countermetric و Diagnosticهای Drill-down نقطهٔ شروع مناسبی است، نه قانون. اگر هر KPI به تصمیم متفاوت و Owner واقعی متصل باشد، تعداد می‌تواند تغییر کند. Portfolio را بر اساس Actionability و هزینه Review کنید، نه سهمیه.

۳. آیا نرخ فرار نقص KPI خوبی برای عملکرد QA است؟

برای یادگیری کیفیت سیستم، با Cohort، Severity، Exposure و Detection opportunity مفید است؛ برای امتیاز فرد یا نسبت‌دادن شکست فقط به QA مناسب نیست. طراحی، توسعه، Review، تست، Release، عملیات و Reporting روی Escape اثر دارند. Window دیرکشف و سلامت گزارش‌دهی نیز باید لحاظ شود.

۴. چگونه ROI تیم QA را با KPI ثابت کنیم؟

KPI به‌تنهایی علیت یا ROI را ثابت نمی‌کند. یک Business case به TCO کامل، منفعت منتسب، Baseline/Counterfactual، عدم قطعیت، سناریو و جلوگیری از Double count نیاز دارد. از KPI برای مشاهدهٔ مکانیسم و Outcome استفاده کنید و برای ادعای اثر، Pilot یا طرح مقایسهٔ متناسب بسازید.

۵. KPIها را هر چند وقت یک‌بار بازبینی کنیم؟

کیفیت داده و Alertهای عملیاتی می‌توانند روزانه پایش شوند؛ Portfolio و رفتار ناخواسته معمولاً ماهانه؛ Target و ارتباط با Outcome فصلی یا با تغییر هدف/محصول. هر تغییر Schema، Population، Query، Vendor یا Decision نیز Review فوری می‌خواهد. تاریخ مشخص بهتر از «به‌طور منظم» است.

جمع‌بندی: KPI باید سؤال تصمیم را روشن کند، نه تیم را زیبا نشان دهد

سیستم سنجش سالم از Outcome و Decision شروع می‌شود، نه تعداد فیلدهای TestRail یا نمودارهای آماده. KPIهای محدود را در Metric tree جای می‌دهد، Activity را با Outcome/Risk/Flow/Test-health متوازن می‌کند، برای داده Contract و Gate دارد، Countermetric و استفادهٔ ممنوع تعریف می‌کند و اجازه نمی‌دهد Score مرکب یا رتبه‌بندی فردی، واقعیت را پنهان کند.

از یک Value stream و دو تصمیم شروع کنید. اگر عددی طی یک ماه هیچ انتخابی را تغییر نداد، هیچ Unknownی را آشکار نکرد و هیچ آزمایشی نساخت، احتمالاً KPI نیست—هزینهٔ مشاهده‌ای است که باید اصلاح یا بازنشسته شود.

مدیریت تست

KPI تضمین کیفیت؛ طراحی سیستم سنجش ضدبازی برای QA