یک Dashboard میگوید ۴۸۰ باگ پیدا شده، Automation به ۸۷٪ رسیده، Pass rate برابر ۹۸٪ است، فقط دو Defect به Production فرار کرده و NPS نیز ۹ واحد بهتر شده است. آیا این اعداد ثابت میکنند «QA مؤثر بوده»؟ نه. هنوز نمیدانیم چه تصمیمی در حال ارزیابی است، مخرجها چیست، کدام کاربران واقعاً در معرض Change بودهاند، داده از کجا آمده، چه عوامل دیگری Outcome را تغییر دادهاند و سهم ادعاشدهٔ QA دقیقاً چیست.
این راهنما برای عبارتهای «معیارهای اثربخشی تضمین کیفیت»، «KPI تیم QA»، «چگونه عملکرد QA را بسنجیم» و «QA Effectiveness» نوشته شده است. خروجی آن یک فهرست تازه از KPI نیست؛ یک روش برای ساختن ادعای محدود، قابلابطال و قابلاصلاح دربارهٔ مشارکت یک مداخلهٔ کیفیت در یک Outcome مشترک است.
پاسخ کوتاه: اثربخشی QA یک عدد نیست
- از Decision و Evaluation Question شروع کنید، نه از دادهای که در ابزار حاضر است.
- QA را یک مداخله در سیستم مشترک Product/Engineering/Operations بدانید، نه علت یگانهٔ Outcome.
- Contribution Claim، Mechanism، Assumption و Alternative explanation را پیش از تفسیر عدد بنویسید.
- برای هر Metric، Definition، Unit، Numerator، Denominator، Population، Window، Source و Late-data policy ثبت کنید.
- Outcome را با Guardrail، Driver، شواهد کیفی و Confidence بخوانید؛ افراد را با Bug count یا Pass rate رتبهبندی نکنید.
- هر نتیجه باید Expiry، Decision، Owner و Correction path داشته باشد.
این مقاله دقیقاً مالک کدام مسئله است؟
راهنمای متریکهای تست نرمافزار کاتالوگ ۱۲ Metric و فرمولهای آنهاست؛ راهنمای Dashboard تست رابط تصمیم و Semantic layer را پوشش میدهد؛ و چرخهٔ بهبود مستمر QA Signal را به Experiment و Standard/Rollback وصل میکند. این مقاله فقط مالک Evaluation یک Contribution claim است: آیا مداخلهٔ مشخص کیفیت، در Context و Window مشخص، به Outcome مورد نظر کمک کرده و با چه Confidence؟
Performance، Efficiency و Effectiveness را یکی نگیرید
| مفهوم | پرسش | نمونه | چیزی که ثابت نمیکند |
|---|---|---|---|
| Activity | چه کاری انجام شد؟ | Review، Check، Session | ارزش یا Outcome |
| Output | چه خروجی ساخته شد؟ | Finding، Evidence، Scenario | اثر روی کاربر |
| Efficiency | منابع چگونه به Output تبدیل شد؟ | Cost per reviewed change | درستی Outcome |
| Performance | سیستم در چند بعد چگونه عمل کرد؟ | Flow، reliability، learning | علت تغییر |
| Effectiveness | مداخله تا چه حد به Outcome هدف کمک کرد؟ | Contribution claim محدود | Attribution قطعی یا امتیاز فرد |
صفحهٔ رسمی ISO 9001 monitoring، measurement، analysis و evaluation عملکرد و اثربخشی Quality Management System را کنار هم میآورد. این مقاله از همین جدایی مفهومی استفاده میکند، اما Contractها و Loop زیر متن رسمی ISO، تفسیر ممیزی یا ادعای انطباق/گواهی نیستند.
چرا Bug Count میتواند رفتار را منحرف کند؟
وقتی Target به «تعداد باگ هر تستر» وصل شود، Split کردن یک مسئله، ثبت Duplicate، انتخاب سطحیترین Scope و پرهیز از پیشگیری عقلانی میشود. کاهش Bug count نیز دو تفسیر متضاد دارد: Product بهتر شده یا Observation ضعیفتر. عدد بدون Severity، Impact، Opportunity، Detection source، Duplicate policy، Population و Window فقط Count است.
پس تعداد باگ را دور بیندازیم؟
خیر. Count برای workload، Triage capacity، Defect profile یا تغییر Mix مفید است، اگر Identity و طبقهبندی پایدار باشد. در مدیریت Defect Portfolio میتوان آن را با Origin، Detection، Impact، Age، Reopen و Resolution دید. خطا زمانی رخ میدهد که همان Count بدون Theory و مقایسهٔ معتبر به «اثربخشی QA» یا عملکرد فرد ترجمه شود.
QA یک Actor منفرد نیست؛ یک مداخله در سیستم است
Outcome محصول از Product decision، Design، Code، Review، Test، Platform، Operations، Support، Market، Season، User mix و Chance اثر میگیرد. «QA» نیز ممکن است Review requirement، طراحی Testability، Exploratory testing، Automation، Risk facilitation یا Evidence governance باشد. ابتدا Intervention را نام ببرید؛ سپس Contribution آن را بسنجید. عبارت کلی «QA باعث کیفیت شد» نه Subject دارد و نه قابلیت ابطال.
QA Contribution Evaluation Loop
Goal / Decision → Evaluation Question → bounded Contribution Claim → Intervention + Exposure → Mechanism + Assumptions → Activity → Output → Intermediate Outcome → Outcome → Metric Contracts + Qualitative Evidence → Baseline / Comparison + Alternative Explanations → Confidence + Limitations → Decision / Action / Review → Correction / Supersession
این Loop سنتز عملی همین مقاله است، نه استاندارد رسمی ISO، DORA، SPACE یا Magenta Book. نام READY_FOR_CONTRIBUTION_REVIEW در آزمایش نیز فقط کاملبودن حداقل ساختار را نشان میدهد.
از تصمیم شروع کنید، نه از KPI موجود
| Decision | Evaluation question | Evidence use | Authority |
|---|---|---|---|
| ادامه/اصلاح یک Review | آیا Review ریسک X را زودتر قابلتصمیم کرد؟ | Mechanism و finding trace | Process owner |
| Scale یک Check lane | آیا lane زمان بازخورد را با Guardrail ثابت کم کرد؟ | matched changes و attempts | Engineering owner |
| تخصیص ظرفیت | کدام Constraint با Evidence محدود میشود؟ | flow و qualitative evidence | Product/Engineering |
| Stop | آیا Benefit مشاهدهشده از Cost/Harm بیشتر است؟ | range و limitations | Budget/Risk owner |
راهنمای رسمی DORA برای انتخاب Measurement Framework نیز «چرا اندازه میگیریم» و اینکه یافته قرار است کدام هدف و عمل را راهنمایی کند، مقدم میداند؛ همچنین Log-based data را ذاتاً objective نمیخواند. این guidance را در Context خودش بهکار ببرید، نه بهعنوان QA scorecard رسمی.
Evaluation Question Contract بنویسید
EvaluationQuestion id: EQ-042 decision: CONTINUE | ADAPT | SCALE | STOP | INVESTIGATE evaluation_unit: service / change class / cohort intervention: risk workshop v3 intended_outcome: earlier explicit money-state decisions population: checkout changes eligible in window window: 2026-07-01T00:00Z / 2026-07-28T00:00Z not_claimed: product quality, release safety, individual performance owner: quality-system owner decision_authority: engineering lead expiry: 2026-08-15T00:00Z
Question باید پیش از نگاه انتخابی به نمودار نوشته شود. اگر Question پس از دیدن یک جهش مطلوب عوض شود، HARKing و cherry-picking محتمل میشود؛ تغییر را version و دلیل آن را ثبت کنید.
Contribution را با Attribution قطعی اشتباه نگیرید
Attribution میپرسد Outcome بهطور علّی و با چه اندازهای از Intervention ناشی شده است. Contribution میپرسد آیا زنجیرهای معقول و شواهدمند وجود دارد که نشان دهد Intervention یکی از عوامل Outcome بوده، Assumptionها عمل کردهاند و Alternativeها بررسی شدهاند. برای بسیاری از تغییرهای تیمی، Randomization یا Counterfactual قوی در دسترس نیست؛ پس زبان نتیجه باید با Design ارزیابی متناسب باشد.
Magenta Book Annex A دربارهٔ Contribution Analysis Theory of Change، اجرای Intervention، شواهد نتایج و Assumptionها و بررسی عوامل دیگر را لازم میداند و آن را اثبات قطعی اثر علّی معرفی نمیکند. این منبع برای ارزیابی سیاست دولتی است؛ الگوی زیر اقتباس مهندسی نرمافزار است، نه کاربرد رسمی همان روش یا ادعای Impact evaluation.
Contribution Claim را محدود و ابطالپذیر کنید
ContributionClaim
claim: workshop v3 probably contributed to earlier explicit
duplicate-callback decisions for eligible checkout changes
mechanism: shared state model → earlier counterexample → recorded decision
scope: build families b410–b417; synthetic/staging evidence
population: 18 eligible changes; 15 exposed; 3 non-exposed
expected_pattern: decision before implementation on exposed changes
disconfirming_pattern: no exposure-response relation or mechanism trace
alternatives: change mix, senior reviewer, PSP stub upgrade, seasonality
claim_limit: no product-quality, financial-impact or individual claim
expiry: 2026-08-15
Theory of Contribution را روی کاغذ بیاورید
| زنجیره | نمونه | Evidence | شکست ممکن |
|---|---|---|---|
| Input | وقت Reviewer و state model | version/attendance | Artifact stale |
| Activity | Risk workshop | session record | مداخله اجرا نشد |
| Output | Counterexample و decision | stable IDs | Finding بیDisposition |
| Intermediate | تصمیم پیش از Code | timestamps/diff | زمان نادرست |
| Outcome | Rework تصمیمی کمتر | matched change evidence | Change mix سادهتر |
| Guardrail | Review delay/false alarm | queue/reject data | Benefit با Harm خنثی شد |
یک Arrow به معنی Cause نیست. برای هر Arrow، Assumption، Evidence قابلانتظار و نشانهٔ خلاف بنویسید. اگر Activity ثبت شده اما Mechanism دیده نشده، Outcome همزمان را به Intervention نسبت ندهید.
Intervention و Exposure را قابلشناسایی کنید
«تیم تست بهتر کار کرد» Intervention نیست. نسخهٔ Workshop، Facilitator role، Artifact، Eligible rule، شدت Exposure، Start/End و Deviation لازم است. Attendance باینری کافی نیست: یک Change ممکن است قبل از Baseline وارد شده، فقط بخشی از Review را دیده یا Action آن اجرا نشده باشد. Exposure واقعی را از Intended rollout جدا کنید.
Assumption Register نگه دارید
| Assumption | چرا لازم است؟ | Evidence | Trigger بازبینی |
|---|---|---|---|
| Changeها قابلمقایسهاند | Baseline معنیدار بماند | impact/class profile | mix shift |
| Timestampها یک semantics دارند | Time metric معتبر باشد | event dictionary | tool migration |
| Reviewer ظرفیت و اختیار دارد | Finding به Decision برسد | role/action trace | role change |
| Instrumentation پایدار است | Trend مصنوعی نشود | schema/source version | collector update |
Activity، Output و Outcome را جدا ثبت کنید
تعداد Session، Scenario و Check بهترتیب Activity/Output هستند. آنها ممکن است Mechanism را پشتیبانی کنند، اما Outcome کاربر یا کسبوکار نیستند. همچنین Outcome مثل Churn یا Revenue دور از کنترل QA و آلوده به عوامل بسیار است. Intermediate outcome نزدیکتر—مثلاً زمان تا تصمیم معتبر یا سهم Riskهای تصمیمدار—اغلب برای Contribution claim قابلدفاعتر است.
Context و Evaluation Unit را قفل کنید
Service، Product version، Change class، Environment، Channel، Geography، Cohort، Window و Policy version را ثبت کنید. Unit میتواند Change، Release، Incident، User journey یا Team system باشد. Unit را وسط تحلیل از Change به Person عوض نکنید؛ Aggregateهای سطح Service برای ارزیابی فرد معتبر نمیشوند.
Baseline بهتنهایی Counterfactual نیست
Before/after ساده ممکن است Seasonality، Learning، Regression to mean، تغییر Traffic، Build size، Team composition یا Instrumentation را به Intervention نسبت دهد. اگر ممکن است matched changes، phased rollout، interrupted time series یا comparison group مناسب بسازید؛ اگر نه، محدودیت را صریح کنید و Confidence را پایین نگه دارید.
Alternative Explanation را جدی آزمایش کنید
- Changeها کوچکتر یا کمریسکتر شدند؟
- Reviewer باتجربه یا Product owner عوض شد؟
- Environment، Stub، Logging یا Defect taxonomy تغییر کرد؟
- Traffic و User mix یا Support classification جابهجا شد؟
- یک Incident یا Freeze رفتار تیم را موقتاً تغییر داد؟
- Data collection بعد از Intervention کاملتر شد و Trend مصنوعی ساخت؟
Metric Contract: هر عدد باید شناسنامه داشته باشد
MetricContract id: M-EARLY-DECISION-v2 question_ref: EQ-042 role: primary_outcome definition: eligible changes with a risk decision before implementation unit: proportion numerator: eligible changes meeting timestamp and decision rules denominator: all eligible changes with closed observation window population: checkout change class C2/C3 window: rolling 28d; UTC event time exclusions: emergency path, cancelled-before-review source: decision-log v4 + repository events v3 join_key: immutable change_id late_data: reopen window for 7d, then correction missing: UNKNOWN; never zero threshold: directional hypothesis, no universal target owner: measurement steward not_claimed: causality, product quality, person performance
Numerator و Denominator را قبل از Ratio تعریف کنید
Escaped defect rate میتواند Defectهای Production بر همهٔ Defectها، همهٔ Releaseها، همهٔ Changes یا User sessions باشد و هر تعریف پاسخ متفاوتی دهد. Pass rate نیز با Retry، Skipped، Blocked و Not Run تغییر میکند. Ratio بدون Eligible population و closed-status policy قابلیت مقایسه ندارد.
Population، Cohort و Exposure را همنام نکنید
| مجموعه | تعریف | نمونه |
|---|---|---|
| Target population | همهٔ واحدهای مورد ادعا | Changeهای Checkout C2/C3 |
| Eligible | واحدهای مطابق rule | غیراضطراری و قبل از cutoff |
| Assigned | قرار بود Intervention بگیرند | Workshop دعوتشده |
| Exposed | واقعاً Intervention را دریافت کردند | Artifact و action trace موجود |
| Analyzed | در تحلیل نهایی وارد شدند | window بسته و identity معتبر |
Window و زمان رویداد را مشخص کنید
Calendar month، Sprint و rolling ۲۸ days یکسان نیستند. Event time را از ingestion time جدا کنید؛ timezone و cutoff را بنویسید. Incident یا Defect ممکن است هفتهها بعد کشف شود، پس Window کوتاه بهطور ساختاری Escape را کمنمایی میکند. Cohort maturity و observation lag باید کنار Trend باشد.
Source، Lineage و Join را قابل ممیزی کنید
نام ابزار کافی نیست. Schema/version، query، event semantics، join key، deduplication، timezone، access date و transformation digest را نگه دارید. اگر Defect با متن آزاد به Change وصل شود، false match ممکن است. Dashboard فقط Presentation است؛ Source of record و Semantic layer را جدا کنید.
Late Data، Backfill و Correction Policy داشته باشید
CorrectionPolicy provisional_until: window_end + 7d late_event_action: reopen cohort and recompute materiality: denominator ±2% or decision class changes correction_record: old_value / new_value / cause / affected_decision notify: evaluation owner + decision authority supersede: never silently overwrite published conclusion
Data lake backfill، taxonomy repair و late Incident میتوانند نتیجه را عوض کنند. نتیجهٔ بدون provisional/final status و revision history، Evidence قابلاتکا نیست.
Missing، Unknown و Not Applicable را صفر نکنید
نبود Support ticket ممکن است «مشکلی نبود»، «کانال قطع بود»، «کاربر گزارش نکرد» یا «join شکست» باشد. Unknown را یک وضعیت مستقل نگه دارید و نرخ Completeness را گزارش کنید. Imputation باید Method و Sensitivity analysis داشته باشد؛ در Decisionهای پرریسک، Unknown میتواند سبب INVESTIGATE شود.
Threshold را از Context و Action بسازید
هدف جهانی «Coverage ۸۰٪»، «Pass ۹۵٪» یا «Escape صفر» وجود ندارد. Threshold باید Basis، Risk، Direction، deadband، minimum sample، Action، Authority و expiry داشته باشد. Target عددی را مستقیماً به پاداش وصل نکنید؛ Metric وقتی Goal میشود، فشار برای gaming و پنهانسازی Unknown بالا میرود.
Distribution و Uncertainty را پشت Average پنهان نکنید
Median بهتنهایی tail را پنهان میکند؛ Mean به outlier حساس است. Count کم با Ratio پرنوسان میشود. N، quantile، range/interval، segmentation و missingness را نشان دهید. Confidence interval آماری با Confidence در Contribution claim یکی نیست: اولی uncertainty تخمین Metric است، دومی قوت کل زنجیرهٔ Evidence و Alternativeها.
Triangulation: یک نمودار، یک واقعیت نیست
| Evidence | نقش | ضعف | Countercheck |
|---|---|---|---|
| System events | رفتار و زمان | Instrumentation error | sample trace |
| Artifact/Finding trace | Mechanism | Documentation bias | diff/decision |
| Survey/interview | تجربه و توضیح | recall/social desirability | anonymous sample |
| Support/Incident | Field signal | reporting/classification bias | channel completeness |
| Matched comparison | Alternative check | residual confounding | sensitivity analysis |
Leading، Intermediate و Lagging signal را کنار هم بخوانید
Review exposure یک Leading/implementation signal است؛ decision-before-code یک Intermediate outcome؛ field harm یک Lagging outcome. Leading signal سریع اما دور از ارزش است؛ Lagging signal نزدیکتر به اثر اما دیر و پرعامل. زنجیرهٔ هر سه بههمراه Mechanism از انتخاب یک «مهمترین KPI» دفاعپذیرتر است.
Primary Outcome، Guardrail و Driver را تفکیک کنید
| Role | پرسش | نمونه |
|---|---|---|
| Primary outcome | تغییر مطلوب چیست؟ | تصمیم Risk پیش از implementation |
| Guardrail | چه Harm نباید رشد کند؟ | Review queue age / false alarm |
| Driver | Mechanism اجرا شد؟ | Exposure و question→decision trace |
| Context | چه چیزی تفسیر را عوض میکند؟ | Change impact mix |
| Data quality | آیا Measurement معتبر است؟ | join/missing/late rate |
Metric Portfolio کوچک اما متوازن بسازید
برای یک Question معمولاً یک Primary، یک یا دو Guardrail، یک یا دو Driver و یک Data-quality measure کافی است. دهها KPI Attention را پخش و امکان انتخاب پسینی نمودار مطلوب را زیاد میکند. Portfolio باید درون یک Evaluation Packet باشد، نه Scorecard دائمی همهمنظوره.
Coverage چه میگوید و چه نمیگوید؟
Code/branch/requirement/risk coverage تعریفهای متفاوت دارند. Coverage میگوید Control به Subject تعریفشده رسیده؛ درستی Oracle، کیفیت Scenario، absence of defect یا Contribution به Outcome را ثابت نمیکند. افزایش Coverage همراه با Duplicate Check، Flaky result یا کمشدن exploratory observation میتواند Guardrail را بدتر کند.
Pass Rate و Automation Percentage را Outcome ننامید
Pass rate به Result vocabulary، Retry، Quarantine، Skipped/Blocked و Build scope حساس است. Automation percentage نیز Denominator مبهم و maintenance cost پنهان دارد. چرخهٔ Automated Check و Evidence برای Subject/Oracle/Attempt/Flaky/Quarantine/Retirement است؛ آن داده میتواند Driver یا system-health signal باشد، نه گواهی اثربخشی QA.
Escape Rate را «شکست QA» نخوانید
Field Defect یک Signal مشترک Design/Code/Review/Test/Release/Operation است. Detection opportunity، user exposure، severity/impact، cohort maturity، reporting channel و Origin باید مشخص باشد. کاهش Escape ممکن است از Release کمتر، Traffic کمتر یا classification change آمده باشد؛ افزایش آن نیز شاید از Observability و reporting بهتر ناشی شود.
Cycle Time و MTTR مرزهای دقیق میخواهند
Test cycle time از request تا evidence-ready است یا فقط execution؟ Queue و blocked time داخل آن است؟ MTTR گاهی acknowledge-to-fix، detect-to-restore یا report-to-verify است. Start/stop، population و percentile را ثبت کنید. کاهش زمان اگر Unknown، Reopen یا residual harm بالا رود اثربخشی نیست.
NPS، CSAT، Churn و Revenue Attribution دوردستاند
این Outcomeها به قیمت، محتوا، رقابت، Support، UX، season و cohort وابستهاند. همزمانی افزایش NPS با Automation، Contribution را ثابت نمیکند. اگر استفاده میشوند، Mechanism، exposed cohort، survey response bias، lag و Alternativeها لازم است؛ معمولاً آنها Context/lagging signal هستند، نه KPI تیم QA.
Cost of Quality و Automation ROI را Range گزارش کنید
Time saved اغلب با capacity آزادشده اشتباه میشود و avoided defect یک Counterfactual نامطمئن است. Cost باید build، maintenance، triage، environment، false results، data، training، retirement و opportunity را شامل کند. Benefit را با low/base/high assumption، period، discount و sensitivity بنویسید؛ ROI تضمینشده یا علت یگانهٔ Revenue ادعا نکنید.
DORA Metricها QA KPI نیستند
DORA Metricها delivery performance یک Application/Service را در Throughput و Instability توصیف میکنند. آنها را به فرد یا QA department نسبت ندهید و بین Contextهای ناهمگون Blend نکنید. میتوانند Outcome مشترک یا Context باشند، اگر Contribution mechanism و سایر عوامل روشن باشد؛ فهرست و حدودشان در مقالهٔ سرعت و کیفیت از Bet تا Evidence آمده است.
Metric برای یادگیری است، نه رتبهبندی افراد
SPACE در صفحهٔ رسمی Microsoft Research تأکید میکند Developer productivity با یک Metric یا Dimension و صرف Activity فردی سنجیده نمیشود. هرچند SPACE چارچوب QA Effectiveness نیست، این boundary برای جلوگیری از تبدیل Bug count، Case count، Automation rate یا Review comment به People score مستقیم مفید است.
ارزیابی عملکرد فرد به Role expectation، Context، نمونهٔ کار، collaboration، learning و شواهد کیفی خصوصی نیاز دارد. سیستم عملیاتی رهبری QA این مرز را پوشش میدهد. Contribution Evaluation باید تا حد ممکن Product/Service/Intervention-level و برای بهبود سیستم باشد.
Goodhart، Selection و Survivorship را پیشبینی کنید
- وقتی Bug count Target شد، تعداد بالا میرود بدون اینکه Risk knowledge بهتر شود.
- وقتی Pass rate Target شد، Check سخت حذف یا Quarantine میشود.
- وقتی Cycle time Target شد، Work سخت Split یا از Population خارج میشود.
- وقتی فقط Completed item تحلیل شد، Queue و abandoned work ناپدید میشود.
- وقتی فقط Success story انتخاب شد، Failure mechanism دیده نمیشود.
Evaluation Packet را از Dashboard جدا کنید
| بخش Packet | حداقل محتوا |
|---|---|
| Identity | evaluation/version/as-of/supersedes |
| Decision | question/options/authority/expiry |
| Claim | intervention/mechanism/scope/limit |
| Implementation | eligible/assigned/exposed/deviation |
| Evidence | metric contracts/qualitative/lineage |
| Comparison | baseline/design/alternatives |
| Interpretation | confidence/limitations/unknowns |
| Closure | decision/action/review/correction |
Confidence را با Basis گزارش کنید
| Level | معنا در این راهنما | رفتار تصمیم |
|---|---|---|
| INSUFFICIENT | Contract/Exposure/Data ناقص | اندازهگیری یا Design را اصلاح کن |
| LOW | Pattern هست؛ Alternativeهای مهم بازند | Pilot/Investigate |
| MODERATE | Mechanism و چند Evidence همسو؛ محدودیت باقی است | Continue محدود با Guardrail |
| HIGH | Design قوی، نتایج پایدار و Alternativeها ضعیف شدهاند | Scale با monitoring |
این Scale یک convention داخلی مقاله است، نه Scale رسمی منابع. Level بدون Basis، uncertainty، dissent و expiry ممنوع است. HIGH نیز Certainty یا اثبات دائمی نیست.
Decision فقط PASS/FAIL نیست
CONTINUE: همان Scope و monitoring ادامه یابد.ADAPT: Mechanism/Exposure/Instrumentation تغییر کند.SCALE: با Cohort و Guardrail تازه گسترش یابد.STOP: Benefit/Cost/Harm یا evidence خلاف است.INVESTIGATE: Unknown یا Alternative برای تصمیم زیاد است.CORRECT: نتیجهٔ پیشین با دادهٔ تازه supersede شود.
Contribution Evaluation جایگزین تصمیم آمادگی انتشار و پذیرش ریسک نیست. Evidence دربارهٔ اثر یک مداخله، مجوز Release یا اثبات «کیفیت کافی» نمیدهد.
Authority و استقلال نسبی Evaluation را روشن کنید
| Role | اختیار | نباید |
|---|---|---|
| Intervention owner | اجرا و Evidence implementation | تنها Evaluator باشد |
| Measurement steward | Contract/lineage/correction | Threshold کسبوکار را بسازد |
| Evaluator | Alternative/confidence/limitations | Risk را بپذیرد |
| Decision authority | Continue/Scale/Stop و منابع | Data را silently override کند |
| Risk/domain owner | Harm/exception decision | به QA واگذار شود |
Cadence را با Lag و هزینه تنظیم کنید
Data-quality و Driver ممکن است روزانه دیده شوند؛ Intermediate outcome پس از هر Cohort؛ Contribution review پس از mature شدن Window. گزارش ماهانه/فصلی نسخهٔ جهانی نیست. Cadence باید Decision deadline، observation lag، sample، correction window و cost of delay را لحاظ کند. Re-review trigger از تقویم مهمتر است: Scope، Policy، Instrumentation یا Context change.
امنیت، حریم خصوصی و Retention دادهٔ اندازهگیری
Metric warehouse ممکن است نام کارمند، ایمیل، Commit، Ticket، User event، Support text یا Incident detail را Join کند. Purpose limitation، minimization، aggregation، access control، retention، deletion، redaction، audit و incident response لازم است. دادهٔ Product/People را برای هدف تازه بدون Authority و بررسی مناسب reuse نکنید؛ این مقاله مشاورهٔ حقوقی یا Privacy compliance نیست.
AI در Measurement: دستیار، نه Evaluator خودمختار
AI میتواند Draft taxonomy، خوشهبندی پاسخ کیفی، anomaly candidate یا خلاصهٔ Evidence بسازد. اما prompt/model/version، source refs، sample review، false merge/split، زبان فارسی، dissent و redaction باید ثبت شوند. مدل نباید Performance فرد، causal attribution، Risk acceptance یا Scale/Stop را خودکار صادر کند. تغییر مدل نیز Instrumentation change است و Trend break میسازد.
آزمایش تکرارپذیر: پنج عدد سبز، Contribution نامعلوم
Fixture مصنوعی زیر ۴۸۰ باگ، Automation برابر ۸۷٪، Pass rate برابر ۹۸٪، دو Escape و رشد ۹ واحدی NPS دارد و QA_EFFECTIVE اعلام میکند. Auditor به عددها امتیاز نمیدهد؛ حداقل Contract ارزیابی Contribution را میسنجد.
{
"evaluation_id": "",
"context": {"product": "", "service": "checkout", "change": "", "window": "", "cohort": ""},
"question": {"decision": "", "intended_outcome": "", "evaluation_unit": "", "not_claimed": []},
"contribution": {"intervention": "", "mechanism": "", "assumptions": [], "implementation_evidence": [], "exposure": ""},
"primary_metric": {"name": "escaped_defects", "definition": "", "unit": "", "numerator": "", "denominator": "", "population": "", "window": "", "source": "", "late_data": ""},
"guardrails": [],
"baseline": {"value": null, "source": "", "comparability": ""},
"alternatives": [],
"evidence_chain": {"activity": "", "output": "", "intermediate": "", "outcome": "", "qualitative": ""},
"authorities": {"measure_owner": "", "evaluator": "", "decision_owner": ""},
"confidence": {"level": "", "basis": []},
"correction": {"trigger": "", "method": ""},
"people_scoring": true,
"dashboard": {"bugs_found": 480, "automation_percent": 87, "pass_percent": 98, "escaped_defects": 2, "nps_change": 9},
"declared": "QA_EFFECTIVE"
}
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.evaluation_id, 'IDENTITY', 'evaluation_id');
for (const key of ['product', 'change', 'window', 'cohort'])
need(r.context?.[key], 'CONTEXT', `context.${key}`);
for (const key of ['decision', 'intended_outcome', 'evaluation_unit'])
need(r.question?.[key], 'QUESTION', `question.${key}`);
need((r.question?.not_claimed || []).length, 'BOUNDARY', 'question.not_claimed');
for (const key of ['intervention', 'mechanism', 'exposure'])
need(r.contribution?.[key], 'CONTRIBUTION', `contribution.${key}`);
need((r.contribution?.assumptions || []).length, 'ASSUMPTION', 'contribution.assumptions');
need((r.contribution?.implementation_evidence || []).length, 'IMPLEMENTATION', 'contribution.implementation_evidence');
for (const key of ['definition', 'unit', 'numerator', 'denominator', 'population', 'window', 'source', 'late_data'])
need(r.primary_metric?.[key], 'METRIC_CONTRACT', `primary_metric.${key}`);
need((r.guardrails || []).length, 'GUARDRAIL', 'guardrails');
need(r.baseline?.value !== null, 'BASELINE', 'baseline.value');
need(r.baseline?.source, 'BASELINE', 'baseline.source');
need(r.baseline?.comparability, 'BASELINE', 'baseline.comparability');
need((r.alternatives || []).length, 'ALTERNATIVE', 'alternatives');
for (const key of ['activity', 'output', 'intermediate', 'outcome', 'qualitative'])
need(r.evidence_chain?.[key], 'EVIDENCE_CHAIN', `evidence_chain.${key}`);
for (const key of ['measure_owner', 'evaluator', 'decision_owner'])
need(r.authorities?.[key], 'AUTHORITY', `authorities.${key}`);
need(r.confidence?.level, 'CONFIDENCE', 'confidence.level');
need((r.confidence?.basis || []).length, 'CONFIDENCE', 'confidence.basis');
need(r.correction?.trigger, 'CORRECTION', 'correction.trigger');
need(r.correction?.method, 'CORRECTION', 'correction.method');
need(r.people_scoring === false, 'NO_PEOPLE_SCORING', 'people_scoring');
const computed = f.length ? 'HOLD' : 'READY_FOR_CONTRIBUTION_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، پنج Contribution، هشت Metric field، Guardrail، سه Baseline، Alternative، پنج Evidence-chain field، سه Authority، دو Confidence، دو Correction، ممنوعیت People scoring و Decision mismatch. Dashboard سبز هیچ Finding را نمیبندد.
پس از ثبت Evaluation، Context/Cohort/Window، Question و not-claimed، Intervention/Mechanism/Assumption/Exposure، Metric contract و Guardrail، Baseline و Alternativeها، Evidence chain، Authority، Confidence، Correction و people_scoring=false، اجرای دوباره باید count=۰ و READY_FOR_CONTRIBUTION_REVIEW بدهد. این فقط کاملبودن ساختار را میسنجد؛ Truth داده، کیفیت Measurement، اثر علّی، Outcome محصول یا اثربخشی QA را ثابت نمیکند.
آزمایشگاه فارسی و آفلاین: Checkout ریالی ساختگی
یک Dataset کاملاً ساختگی از ۱۸ Change در Checkout بسازید: ۱۵ Change واقعاً Workshop v3 را دیده و سه Change مطابق rollout ندیدهاند. Order، PaymentAttempt، PSP Stub، Callback، Ledger و Reconciliation فقط fake باشند. مبلغ canonical را IRR و تومان را presentation label بنویسید؛ رقم فارسی/عربی/لاتین، ی/ی، ک/ک، RTL/LTR، UTC event time، Asia/Tehran display و تاریخ جلالی صرفاً نمایشی را در Data-quality check بگنجانید.
برای هر Change، Impact/Class/Build، eligibility/assignment/exposure، Artifact/decision timestamps، duplicate/late/out-of-order Callback concern، Review output، rework event و missing/late flag ثبت کنید. هیچ شبکه، Production، شرکت/کاربر/سفارش/پرداخت واقعی، PSP/بانک واقعی، نام، موبایل، ایمیل، IP، account، PAN/CVV2/OTP، Cookie، Token، Credential، Log یا Screenshot استفاده نشود. این Lab ادعای بانکی، مالی، قانونی، امنیتی، آماری یا نمایندگی بازار ایران ندارد.
Pilot سیروزه برای QA Contribution Evaluation
| روز | کار | خروجی | Stop/Review |
|---|---|---|---|
| ۱–۳ | Decision/Question/claim limit | Evaluation Charter | بدون Authority توقف |
| ۴–۷ | Theory/assumption/alternatives | Contribution map | Mechanism نامشخص |
| ۸–۱۲ | Contract و source audit | Metric dictionary | Join/missing نامعتبر |
| ۱۳–۲۰ | یک Cohort کوچک | exposure/evidence trace | Privacy/Harm/queue guardrail |
| ۲۱–۲۵ | comparison/triangulation | alternative analysis | Window نابالغ |
| ۲۶–۲۸ | Confidence/Dissent | Evaluation Packet | Evidence متعارض |
| ۲۹–۳۰ | Decision/Correction trigger | Continue/Adapt/Stop | expiry ثبت شود |
Metric Review جلسهٔ دفاع از عدد نیست
جلسه را با Decision و Unknownها آغاز کنید. Measurement steward Contract و data quality را میگوید؛ Intervention owner implementation/deviation را؛ Evaluator Alternative و Confidence را؛ Domain/Risk owner Harm را. نتیجه، Action/Owner/Due/Verification است. نمودار بدون Action یا Decision فقط اطلاعرسانی است.
Anti-patternهای رایج
| Anti-pattern | خطر | اصلاح |
|---|---|---|
| یک KPI طلایی | تقلیل سیستم پیچیده | portfolio کوچک متوازن |
| Bug/Case per tester | Gaming و آسیب به همکاری | system-level learning |
| Green=effective | Unknown context | claim/evidence/alternative |
| Before/after خام | Confounding | comparison و limitations |
| NPS=QA impact | Attribution دوردست | mechanism/cohort/lag |
| Missing=zero | خوشبینی مصنوعی | UNKNOWN/completeness |
| Average-only | Tail و segment پنهان | N/distribution/segment |
| Silent backfill | Decision بدون ردپا | correction/supersession |
| Dashboard=source | Lineage مبهم | source/semantic/view separation |
| AI causal verdict | خطای غیرقابلپاسخگویی | human authority/evidence refs |
چکلیست Owner پیش از انتشار نتیجه
- Evaluation ID/version/as-of و Decision مشخص است.
- Question، Unit، Population، Window و not-claimed ثبت شدهاند.
- Intervention و Exposure واقعی قابلردیابیاند.
- Mechanism و Assumptionها ابطالپذیرند.
- Activity/Output/Intermediate/Outcome جدا هستند.
- Primary، Guardrail، Driver و Data-quality role روشن است.
- هر Metric Contract کامل و versioned است.
- Missing، late data، backfill و Correction policy تعریف شدهاند.
- Baseline/Comparison و comparability بررسی شدهاند.
- Alternative explanation و Evidence خلاف جستوجو شده است.
- Quantitative و qualitative evidence triangulate شدهاند.
- N/distribution/segment/uncertainty دیده میشود.
- People scoring و Outcome attribution افراطی حذف شده است.
- Privacy/access/retention/redaction کنترل شدهاند.
- Confidence با Basis/limitations/dissent/expiry ثبت شده است.
- Decision/Action/Owner/Due/Verification مشخص است.
- نتیجهٔ قبلی silent overwrite نمیشود.
جمعبندی: از Scorecard به Claim قابلبررسی
معیار معنادار، عدد جذاب یا Benchmark جهانی نیست؛ اندازهای است که برای یک Question و Decision تعریف شده، Population/Window/Source دارد، با Guardrail و Unknown خوانده میشود و در یک Contribution story محدود جای میگیرد. QA مؤثر را نمیتوان از Bug count، Pass rate، Coverage، Automation percentage، Escape، NPS یا ROI بهتنهایی نتیجه گرفت.
مسیر عملی این است: Intervention را دقیق کنید، Mechanism و Assumption را بنویسید، Metric Contract و Comparison بسازید، Alternativeها را امتحان کنید، Confidence و claim limit را اعلام کنید و تصمیم را با Correction path ببندید. آنگاه Measurement به ابزار یادگیری و تخصیص بهتر منابع تبدیل میشود—نه کارخانهٔ امتیاز و قطعیت کاذب.
پرسشهای متداول درباره معیارهای اثربخشی QA
بهترین KPI برای سنجش اثربخشی QA چیست؟
KPI واحد و جهانی وجود ندارد. ابتدا Decision و Evaluation Question را تعریف کنید؛ سپس یک Primary outcome، Guardrail، Driver و Data-quality measure با Contract کامل انتخاب کنید. Metric مناسب برای Release risk، Process intervention و Customer outcome یکسان نیست.
آیا Defect Escape Rate مهمترین معیار QA است؟
Escape یک Field signal مهم است، اما «شکست QA» یا مهمترین معیار همهٔ Contextها نیست. تعریف Detection/Origin، Severity/Impact، Opportunity، release cohort، observation lag، reporting channel و denominator لازم است و تغییر آن باید همراه Change mix و سایر عوامل تفسیر شود.
آیا میتوان Bug Count یا Test Case Count را برای ارزیابی تستر استفاده کرد؟
برای رتبهبندی یا پاداش مستقیم خیر؛ این Countها به Scope، Risk، ابزار، Split/Duplicate policy و فرصت Observation وابستهاند و رفتار را منحرف میکنند. برای capacity/profile میتوان آنها را در سطح سیستم و همراه Context استفاده کرد؛ ارزیابی فرد به Role expectation و شواهد چندبعدی نیاز دارد.
هر چند وقت یکبار معیارهای QA را مرور کنیم؟
فرکانس ثابت روزانه، Sprint، ماهانه یا فصلی پاسخ عمومی نیست. Cadence را با Decision deadline، data lag، cohort maturity، sample size، correction window و cost تنظیم کنید. Driver/Data quality ممکن است زودتر و Contribution claim پس از بستهشدن Window مرور شود.
چگونه ثابت کنیم QA باعث بهبود Outcome شده است؟
واژهٔ «ثابت» فقط با Design علّی متناسب و محدودیتهای آن قابلدفاع است. در بسیاری از تیمها بهتر است Contribution claim بسازید: Theory/Mechanism، اجرای واقعی، Evidence chain، comparison، Alternative explanation، triangulation و Confidence. نتیجه را به Scope/Window محدود و Attribution قطعی را ادعا نکنید.
