استارتاپ شما از دو Squad به هشت Squad رسیده، اما هر Release هنوز از همان یک صف QA، یک محیط Staging و یک نفرِ دارای دسترسی داده عبور میکند. افزودن تستر، Runner یا Test case شاید خروجی محلی را بیشتر کند؛ اگر گلوگاه جای دیگری باشد، Lead time کل تکان نمیخورد و فقط WIP، هزینه و هماهنگی رشد میکند. مقیاسدادن QA یعنی پیدا کردن و جابهجاکردن محدودیت سیستم، نه بزرگکردن بیهدف یک دپارتمان.
این راهنما یک مسیر عملی برای تیمهای در حال رشد میسازد: Growth signal → Demand map → Flow baseline → Constraint → Capability option → Pilot → Evidence → Scale / Rebalance / Stop. خروجی آن نقشهٔ تقاضا، قرارداد خدمت، مدل ظرفیت، Capabilityهای مشترک و تصمیم مرحلهای است؛ نه نسخهٔ جهانی «همهچیز را خودکار کن» یا «QA را Embedded کن».
پاسخ کوتاه: مقیاسپذیری QA چیست؟
مقیاسپذیری QA توان سیستم محصول و مهندسی برای جذب رشدِ تغییر، تیم، کاربر، Dependency و ریسک است، بدون اینکه هزینه و نیروی انسانی الزاماً به همان نسبت رشد کند یا کیفیت شواهد، زمان تصمیم، Guardrailهای مشتری و سلامت تیم فروبپاشد. QA مقیاسپذیر الزاماً QA سریعتر در هر فعالیت نیست؛ جریان پایانبهپایان را برای تصمیم درستتر و بهموقعتر طراحی میکند.
Scalable quality system
absorbs: more change × more variants × more dependencies × more risk
while protecting: decision evidence + customer guardrails + team health
and avoiding: proportional toil + hidden queue + orphan platform + false green«مقیاس» نیز مطلق نیست. سیستمی که برای ۲۰ تغییر استاندارد در هفته مناسب است ممکن است برای Launch نوروز، مهاجرت PSP یا الزام امنیتی تازه کافی نباشد. بازه، نوع Demand، Service class، Population و هدف تصمیم را همراه واژهٔ Scale بنویسید.
رشد محصول با رشد تقاضای کیفیت یکی نیست
تعداد کاربران ممکن است دهبرابر شود اما اگر معماری، Risk و نرخ تغییر ثابت بماند، Demand تست الزاماً دهبرابر نمیشود. برعکس، افزودن دو Integration مالی یا سه Squad مستقل میتواند بدون رشد کاربر، بار Evidence و هماهنگی را شدیداً تغییر دهد. Growth vectorها را جدا ببینید:
| بردار رشد | نمونه Signal | تقاضای احتمالی کیفیت | دام اندازهگیری |
|---|---|---|---|
| نرخ تغییر | PR/Deploy/Feature بیشتر | Risk review و Feedback بیشتر | تعداد PR نمایندهٔ اندازه یا ریسک نیست |
| سطح محصول | Workflow، API یا Client بیشتر | مدل ریسک، Oracle و Testability تازه | Line of code معیار پوشش تصمیم نیست |
| تیم و مالکیت | Squad و Service بیشتر | Interface، Handoff و Enablement | Headcount بهتنهایی ظرفیت نیست |
| Dependency | PSP، Vendor، Queue و Partner بیشتر | Contract، Virtualization و Failure mode | Integration count شدت وابستگی را نمیگوید |
| ترافیک و Cohort | کاربر، شهر، Device یا Tenant بیشتر | Performance، Resilience و Segment evidence | میانگین کل Tail و Cohort را پنهان میکند |
| تنوع | Locale، مرورگر، نسخه و Plan بیشتر | Combinatorial selection و Pairwise/Risk | ضرب همهٔ حالتها Strategy نیست |
| تعهد و ریسک | مالی، Privacy، Security یا Accessibility | Guardrail، استقلال Evidence و Retention | Checklist مساوی کنترل مؤثر نیست |
| عملیات | Incident، Ticket و Failure demand | Production learning و Prevention | فقط Defect count علت و Impact را حذف میکند |
مرز این مقاله با راهنماهای نزدیک
این صفحه «ساختار سازمانی»، «اتوماسیون» یا «بودجه» را دوباره آموزش نمیدهد. آنها اهرمهای احتمالیاند و باید پس از Constraint انتخاب شوند:
| راهنما | مالک تصمیم | رابط آن با Scale |
|---|---|---|
| مدل عملیاتی QA | Centralized / Embedded / Federated، Team API و Service catalog | پس از شناخت Demand، ساختار و تعامل را انتخاب میکند |
| بودجهبندی QA | TCO، Dependency، Portfolio و Funding gate | گزینهٔ Capability را در کنار تعهدات تأمین میکند |
| سبد Unit/Integration/E2E | مرز Evidence با Risk، Fidelity، سرعت و هزینه | بار را به کوچکترین مرز مسئول منتقل میکند |
| مدیریت دادهٔ تست | Subset، Synthetic، Mask، Provision و Reset | صف داده را به Capability مشترک تبدیل میکند |
| مدیریت محیط تست | IaC، Manifest، Drift، Booking و Readiness | انتظار و ناسازگاری محیط را کنترل میکند |
| تست در CI | Pipeline، JUnit، Artifact، Runner و امنیت | Execution evidence را عملیاتی میکند |
این مقاله مالک رشد سیستم کیفیت است: تقاضا را قابلمشاهده میکند، Constraint را پیدا میکند، اهرم مناسب را آزمایش میکند و پس از هر بهبود دوباره سیستم را متوازن میسازد.
Scale با چه چیزی اشتباه گرفته میشود؟
- بزرگشدن: Headcount، Runner و Suite بیشتر؛ ممکن است هزینه را Scale کند، نه Capability را.
- سرعت محلی: Execution سریعتر؛ ممکن است Queue داده یا تصمیم بدون تغییر بماند.
- استانداردسازی: یک Template برای همه؛ در Riskهای متفاوت میتواند Waste یا Gap بسازد.
- تمرکززدایی: Embedded کردن QA؛ اگر تخصص کمیاب و Platform ندارید، Duplication رشد میکند.
- پلتفرمسازی: ساخت Portal یا Kubernetes؛ بدون Journey مصرفکننده فقط محصول داخلی بیمصرف است.
- اتوماسیون: اجرای ماشینی؛ اگر Oracle، داده و Result semantics ضعیف باشد False green را سریعتر میکند.
- پوشش بیشتر: Test count یا Code coverage بالاتر؛ نسبت آن با Risk و Decision باید روشن باشد.
واحد تقاضا را پیش از مدل ظرفیت تعریف کنید
«تعداد تست» واحد مناسبی برای تقاضای QA نیست؛ یک تست Unit و یک بررسی مهاجرت Ledger قابلجمعزدن نیستند. Work item را حول خروجی تصمیم تعریف کنید: Risk assessment، Dataset آماده، Evidence یک تغییر، بررسی دسترسپذیری، Performance study، Incident learning یا Release memo.
Quality Demand Card
ID / requested date / requester:
Product / service / change identity:
Decision needed:
Risk class and impact:
Population / segment / environment:
Required evidence / oracle:
Service class: Expedite / Fixed-date / Standard / Discovery
Dependencies: data / environment / specialist / vendor
Ready criteria:
Start / finish definition:
Expected artifact:
Authority / risk acceptor:
Due reason, not just due date:
Blocked reason / owner:
Rework or failure-demand flag:
Privacy / security / retention:
Review / expiry:Start و Finish را سختگیرانه تعریف کنید. «Ticket ساخته شد» Start نیست اگر هفتهها در Backlog منتظر است؛ «Test executed» Finish نیست اگر Result نامعتبر، تصمیم نامشخص یا Artifact گم است.
Demand را طبقهبندی کنید، نه اینکه همه را Urgent بنامید
| کلاس | نمونه | سیاست | ریسک سوءاستفاده |
|---|---|---|---|
| Expedite | Incident مالی فعال یا آسیب مشتری | محدود، معیار ورود سخت، مسیر Stop دیگر کارها | هر مدیر کار خود را Incident بنامد |
| Fixed-date | Cutover PSP یا الزام تاریخدار | برنامهٔ معکوس، Dependency و Scope guardrail | Deadline ساختگی جای Risk را بگیرد |
| Standard | تغییر معمول محصول | FIFO مشروط به Risk و SLE | آیتم بزرگ و کوچک قابلقیاس فرض شوند |
| Discovery | ابهام Oracle یا تکنیک تازه | Timebox، سؤال و Evidence خروجی | تحقیق بیپایان بدون Decision |
| Enablement | آموزش Contract test یا Testability | ظرفیت رزروشده و Consumer outcome | کمک موردیِ دائمی و پنهان |
| Obligation | Security، Privacy یا Audit evidence | حداقل کنترل و Authority مستقل | چکلیست بدون اثربخشی |
Service class برای اولویتدهی شفاف است، نه امتیاز ارزش فرد. تعداد Expedite، علت و کارهای متوقفشده را ثبت کنید تا مسیر اضطراری به Lane عادی تبدیل نشود.
Failure demand و Toil؛ رشد پنهانی که خودمان تولید میکنیم
Failure demand کاری است که بهخاطر درستنشدن یا روشننبودن کار قبلی برمیگردد: Re-run بهعلت محیط، بازسازی Dataset، توضیح دوبارهٔ Requirement، Artifact ناقص، Defect تکراری یا نتیجهٔ Unknown. Toil کار دستی، تکراری، قابلاتوماسیون، تاکتیکی و بدون ارزش پایدار است؛ هر کار دستی Toil نیست.
فصل کاهش Toil در کتاب Google SRE توضیح میدهد Engineering برای رشد زیرخطی نسبت به اندازهٔ Service لازم است و هدف ۵۰٪ آن، سیاست بافت خود Google است؛ این عدد نسخهٔ عمومی برای QA یا استارتاپ ایرانی نیست. اصل قابلانتقال این است: اگر Run همهٔ ظرفیت را میبلعد، زمانی برای حذف علت Run باقی نمیماند.
Gross capacity
- planned run/obligation
- interrupts and support
- failure demand and rework
- coordination/handoff
- leave/learning
= visible change capacity
Never infer capacity from headcount × 8 hours.
Measure ranges and protect engineering time that removes future demand.Baseline جریان؛ چهار سنجهٔ حداقلی
راهنمای فارسی Kanban چهار معیار WIP، Throughput، Work Item Age و Cycle Time را حداقل سنجههای جریان معرفی میکند. استفادهٔ این مقاله از آنها به معنی پیادهسازی کامل Kanban نیست؛ برای نام Kanban باید Definition of Workflow، کنترل WIP، سیاستهای صریح و SLE آن راهنما نیز رعایت شود.
- WIP: آیتم شروعشده اما تمامنشده؛ تعداد زیاد، Context switching و Age را بالا میبرد.
- Throughput: تعداد آیتم تمامشده در واحد زمان؛ Mix و اندازه را همراهش گزارش کنید.
- Work Item Age: زمان گذشته از Start برای آیتم باز؛ Aging سریعتر از Average مشکل را نشان میدهد.
- Cycle Time: Start تا Finish برای آیتم تمامشده؛ Distribution و percentile از Mean مفیدترند.
Flow Contract v1
Item: one decision-evidence request, not test case
Population: Standard Checkout changes
Start: Ready criteria passed and active work accepted
Finish: evidence valid + decision recorded + artifact linked
Clock: elapsed hours; weekends included
Segments: risk class / PSP / data dependency / rework
WIP: started not finished at 18:00 UTC daily
Throughput: finished items per rolling 14 days
Age: now - start for open items
Cycle: finish - start for closed items
Late/cancelled/duplicate rules:
Source/version/owner:
SLE: 85% ≤ X days, derived from comparable historical items
Prohibited use: individual ranking or cross-team league tableArrival، Throughput و Backlog را با یک واحد ببینید
اگر در یک Population مشابه، میانگین ۳۰ درخواست در هفته وارد و ۲۴ درخواست تمام میشود، Backlog بهطور حسابی حدود ۶ آیتم در هفته رشد میکند؛ این پیشبینی دقیق آینده نیست چون Mix و Variation عوض میشود. اگر Arrival و Throughput را با واحدهای متفاوت—مثلاً Feature در برابر Test case—مقایسه کنید، عدد بیمعناست.
Utilization صددرصد هدف سالمی برای کار دانشیِ متغیر نیست. با نزدیکشدن ظرفیت اسمی به مصرف کامل، کوچکترین تنوع، Block یا Expedite صف میسازد. Reserve برای Incident، Learning و Constraint removal اتلاف نیست؛ بخشی از قابلیت پاسخ است.
SLE، Deadline و SLA یکی نیستند
- SLE: پیشبینی احتمالی Flow برای آیتم مشابه، مانند «۸۵٪ در ۶ روز یا کمتر»؛ ترجیحاً از تاریخچه.
- Deadline: تاریخ نیاز یک آیتم و دلیل آن؛ احتمال یا سطح خدمت نیست.
- SLA: توافق رسمی خدمت با Scope، ساعت، استثنا و پیامد؛ برای هر تعامل داخلی لازم نیست.
- Target: وضعیت مطلوب برای Improvement؛ نباید تاریخچه را جعل کند.
SLE را با یک Average و بدون Probability اعلام نکنید. آیتم Expedite، Discovery و Standard Distribution یکسان ندارند. اگر Instrumentation تازه است، Best guess را بهعنوان حدس برچسب بزنید و با داده بازنگری کنید.
Value Stream کیفیت؛ صفها را پایانبهپایان ببینید
Signal / change
→ Intake & risk framing
→ Testability / design evidence
→ Data & environment readiness
→ Build / deploy / execution
→ Triage / diagnosis
→ Decision / risk acceptance
→ Release / production observation
→ Learning / preventionبرای هر مرحله، Touch time، Wait، Blocked reason، Rework، Owner، ورودی/خروجی و Artifact را ثبت کنید. بیشتر Lead time ممکن است انتظار باشد، نه اجرا. بهینهسازی ۲۰٪ Execution در فرایندی که ۷۰٪ آن انتظار داده است، نتیجهٔ سیستم را نجات نمیدهد.
Constraint را از روی شواهد پیدا کنید
| نشانه | شاهد لازم | Constraint محتمل | راهحل شتابزده |
|---|---|---|---|
| Ready work کم است | Blocked reason، Requirement churn | Intake/Oracle/Testability | استخدام Executor |
| Dataset دیر میرسد | Queue age، handoff، invalid rate | Data access/provision | Runner بیشتر |
| محیط سبز ولی نامعتبر است | Manifest، drift، readiness | Environment contract | Re-run |
| Execution واقعاً صف دارد | Runner wait، duration distribution | Boundary/suite/infrastructure | Parallel بیحد |
| نتیجه Unknown است | First failure artifact، taxonomy | Oracle/observability/identity | Retry |
| تصمیم منتظر یک مدیر است | Decision wait، authority absence | Governance/rights | تست بیشتر |
| Incident تکرار میشود | mechanism/action effectiveness | Learning/prevention | Regression case انباشته |
| متخصص مدام Interrupt میشود | arrival/mix/context switch | Service model/self-service gap | Embedded کردن همان فرد در همه جا |
Constraint Card؛ قرارداد تشخیص محدودیت
Constraint Card — C-08
Population/window: Standard Checkout evidence; 6 weeks
Observed symptom: p90 cycle=11.8d; 63% elapsed time blocked
Stage: Test data provisioning
Queue evidence: age p50=2.1d / p90=5.4d / WIP=17
Demand/mix: 42 requests; 31 PSP-state datasets
Capacity: 1 authorized operator; 18h/w nominal
Failure demand: 29% invalid/collision/recreate
Upstream/downstream effects: QA idle then batch execution; DBA interruption
Alternative explanations: environment booking, missing Ready fields
Proposed lever: versioned self-service dataset for 3 common states
Expected mechanism: remove handoff + validate before delivery
Outcome: p90 valid-data-ready ≤1d
Guardrails: PII=0; collision=0; invalid≤2%; DBA toil not higher
Pilot/rollback: 2 teams, 21d; manual path retained
Owner/authority/review:
What would falsify this constraint:Constraint «آدم» نیست. عبارت «DBA کند است» تشخیص سیستم نیست؛ صفِ مجوز، سیاست دسترسی، Workflow دستی و تنوع Dataset را مدل کنید. با برطرفشدن یک محدودیت، Constraint معمولاً مهاجرت میکند؛ کارت را بازنشسته و Baseline را دوباره بگیرید.
نردبان اهرمها؛ پیش از Add capacity، Demand را مهندسی کنید
- Eliminate: آیا کار لازم است؟ Test یا Report بدون مصرفکننده را حذف کنید.
- Prevent: آیا Testability، Contract یا Design میتواند Failure demand را نسازد؟
- Reduce variety: Happy pathهای یکسان، Template و Golden path؛ بدون حذف Risk واقعی.
- Move boundary: Evidence را به Unit/Component/Contract یا Production منتقل کنید، اگر Fidelity کافی است.
- Self-service: Data، Environment و Diagnostics را با Guardrail به مصرفکننده بدهید.
- Automate: کار تکراری با Oracle پایدار را ماشینی کنید؛ Error handling و Ownership لازم است.
- Parallelize: فقط وقتی Execution Constraint است و Isolation/هزینه/Rate limit تحمل میکند.
- Pool/specialize: مهارت کمیاب را Service شفاف کنید، نه صف نامرئی.
- Add capacity: Hire/borrow/buy پس از سنجش Ramp، Coordination و TCO.
- Shape demand: WIP limit، Service class و Risk appetite؛ کار کمارزش را Defer/Stop کنید.
ترتیب بالا قانون جهانشمول نیست، اما جلوی پاسخ خودکار «نیروی بیشتر» را میگیرد. بعضی Obligationها حذفپذیر نیستند؛ بعضی Incidentها فوراً ظرفیت انسانی میخواهند. دلیل عبور از هر پله را ثبت کنید.
Capability Map؛ چیزی بسازید که چند تیم واقعاً مصرف کنند
| Capability | Consumer outcome | Foundation | Health/guardrail |
|---|---|---|---|
| Risk framing | تغییر با Evidence scope روشن شروع شود | Taxonomy، authority، template | Rework و missed critical risk |
| Testability | کنترل، مشاهده و Isolation بدون Heroics | hooks، IDs، logs، fault controls | Production exposure و misuse |
| Test data | Dataset معتبر در زمان پیشبینیپذیر | schema، synthetic/mask، access | PII، collision، invalidity |
| Environment | محیط Ready و نسخهدار | IaC، manifest، health، cleanup | drift، orphan cost، secret |
| Trusted feedback | نتیجه سریع و توضیحپذیر | boundary، oracle، identity، CI | flaky، false green، missing artifact |
| Specialist service | Security/Performance/A11y بدون صف پنهان | intake، SLE، enablement، backup | single point، wait، overload |
| Production learning | Risk با مشاهدهٔ واقعی بسته شود | telemetry، cohort، rollback | privacy، alert fatigue، attribution |
پلتفرم کیفیت، Portal نیست
راهنمای Platform Engineering در DORA پلتفرم داخلی را یک محصول با کاربر میداند و بر Journeyهای بحرانی و بازخورد روشن از نتیجهٔ Task تأکید میکند. همبستگیهای پژوهشی DORA نسخهٔ قطعی برای سازمان شما نیستند؛ اصل عملی این است که Platform را با Outcome مصرفکننده، Adoption و Support burden بسنجید، نه تعداد Component.
Quality Platform Service Card
Consumer: squad engineers / QA / release owner
Journey: create valid PSP dataset → run risk suite → inspect evidence
Entry/API/UI:
Ready criteria and supported scope:
Time-to-first-success / SLE:
Output and evidence identity:
Guardrails and prohibited use:
Support class / escalation:
Owner / backup / capacity:
Version / deprecation / migration:
Usage / retention / abandonment:
Run cost / consumer cost:
Exit / export / sunset:Golden path باید مسیر رایج را آسان کند و Escape hatch کنترلشده برای نیاز مشروع داشته باشد. Platformی که همه را مجبور میکند اما Task success پایین دارد، Adoption واقعی ندارد. تیم Platform نباید پیچیدگی را فقط از خود پنهان و به Debugging مصرفکننده منتقل کند.
Foundation پیش از Consumer؛ Dependency را آشکار کنید
Identity / access / audit
↓
Versioned data + environment manifest
↓
Stable oracle + run identity + evidence schema
↓
CI execution / self-service / specialist service
↓
Dashboard / decision automation / scaleساخت ده Dashboard روی Resultهای بیهویت Scale نیست. NIST در Secure Software Development Framework بر رویکرد Risk-based و Outcome-based تأکید میکند و میگوید هزینه، امکانپذیری، کاربردپذیری، قابلیت خودکارسازی و Dependencyهای Foundation در انتخاب Practiceهای Scale مهماند. SSDF راهنمای امنیت توسعه است، نه چارچوب عمومی QA؛ اینجا فقط منطق Risk/Foundation آن با مرز روشن تطبیق داده شده است.
سبد Evidence را بر اساس Mechanism بازطراحی کنید
هرم با نسبت جادویی مقیاس نمیدهد. برای هر Risk بپرسید کوچکترین مرزی که Mechanism و Oracle را با Fidelity کافی میبیند چیست. سپس چند Evidence مستقل برای ناشناختههای مهم حفظ کنید.
| Risk/سؤال | مرز مسئول | شاهد مکمل | چیزی که حذف نمیشود |
|---|---|---|---|
| گردکردن IRR | Unit/property | Contract نمونههای مرزی | نمایش تومان در UI |
| Idempotency Callback | Component/integration با DB | Fault injection و reconciliation | رفتار PSP واقعی محدود |
| Schema سازگار | Consumer-driven contract | Integration smoke | semantic mismatch خارج schema |
| Journey پرداخت | System/E2E محدود | Production cohort | Risk انسانی و مرورگر |
| تابآوری در اوج | Performance/resilience | Canary و telemetry | ظرفیت واقعی Dependency |
Parallel execution چه زمانی مقیاس میدهد؟
- Runner wait سهم معناداری از Lead time و Execution واقعاً Constraint باشد.
- تستها State و Data مستقل، Resource budget و shard balance داشته باشند.
- PSP/Vendor rate limit، DB connection، License و Cloud cost تحمل کنند.
- Artifact، shard failure، cancellation و missing report به Result دروغین منجر نشود.
- Queue پیش و پس از Execution دوباره اندازهگیری شود؛ Constraint ممکن است مهاجرت کند.
اگر Data serialization تنها یک Dataset مشترک میدهد، شش Runner پنج Worker منتظر تولید میکند. اگر Test duration بسیار نامتوازن است، shard count زیاد الزاماً makespan را خطی کم نمیکند. هزینهٔ cold start، cache، network، flakiness و diagnosis را در TCO بیاورید.
آزمایش قطعی: Runner بیشتر یا رفع صف داده؟
یک شبیهسازی قطعی با Node.js ۲۴.۱۸.۰، ۲۴ کار کاملاً ساختگی را از Intake، Data، Execution و Decision عبور داد. Arrival و زمان هر مرحله از قبل در کد ثابت بودند. چهار Policy مقایسه شدند:
| Policy | تغییر ساختگی | Mean lead | p90 lead | Makespan | Constraint مشاهدهشده |
|---|---|---|---|---|---|
| BASELINE | Data×۱، Runner×۲، Decision×۱ | 24.81 | 41.55 | 53.15 | Data |
| MORE_RUNNERS | فقط Runner از ۲ به ۶ | 24.81 | 41.55 | 53.15 | Data |
| DATA_FOUNDATION | Data×۲ و زمان Data ×۰.۶ | 10.60 | 15.35 | 25.01 | Execution |
| BALANCED | Data×۲، Runner×۳، Decision×۲ و عوامل کمتر | 6.91 | 9.50 | 18.45 | Data |
BASELINE total wait
intake=7.95 | data=474.25 | execution=0 | decision=1.10
MORE_RUNNERS total wait
intake=7.95 | data=474.25 | execution=0 | decision=1.10
DATA_FOUNDATION total wait
intake=7.95 | data=71.13 | execution=72.58 | decision=10.38
BALANCED total wait
intake=6.24 | data=72.54 | execution=1.51 | decision=2.35در Dataset نویسنده، Execution در Baseline صف نداشت؛ بنابراین چهار Runner اضافی هیچ عددی را عوض نکرد. بهبود Data، Constraint را به Execution منتقل کرد و تنظیم متوازن نتیجه را دوباره تغییر داد. اینکه در BALANCED مجموع انتظار Data کمی از DATA_FOUNDATION بیشتر است تناقض نیست: Intake سریعتر کار را زودتر به صف Data رسانده و Queue interaction تغییر کرده است.
محدودیت آزمایش: Jobها، Arrival، Duration، Capacity، ضرایب و ترتیب FCFS همگی ساختگی و قطعیاند. اندازه/ریسک واقعی، اولویت، Preemption، Absence، Learning، Failure، Rework، Dependency، Batch، هزینه، رفتار انسان و عدمقطعیت حذف شدهاند. نتیجه Benchmark، Staffing formula، اثبات علیت یا وعدهٔ بهبود نیست؛ فقط نشان میدهد در این مدل، افزایش ظرفیتِ مرحلهٔ بدون صف بیاثر است و Constraint پس از Intervention میتواند مهاجرت کند.
Model ظرفیت؛ Gross time را با Delivery time یکی نگیرید
Capacity Envelope — weekly range
People/roles: 5 QE + 0.5 Security + shared Data
Gross available: 150–170h
Run & obligation: 45–60h
Support/interrupt: 15–35h
Failure demand/rework: 20–40h
Learning/leave/coordination: 20–30h
Change/constraint removal: 25–60h
Specialist bottleneck: Data authorization 18h
Demand arrival: 22–38 comparable items/week
Historical throughput: 20–27/week
Reserve policy: 15% for Expedite/unknown
Assumptions/expiry: no Nowruz launch; valid 30 daysRange از عدد نقطهای صادقانهتر است. ظرفیت Specialist را با جمع ساعت کل پنهان نکنید. پنج مهندس عمومی جای نیمروز Authority امنیت را نمیگیرند. Ramp استخدام، Mentoring، Access، Context و Coordination ممکن است ابتدا ظرفیت خالص را کاهش دهد.
Build، Buy، Borrow، Hire یا Design away؟
| گزینه | مناسب وقتی | هزینهٔ پنهان | شاهد Pilot |
|---|---|---|---|
| Build | Capability تمایزبخش/تکراری و مالک Run دارید | نگهداشت، Support، Exit داخلی | Task success و Run toil |
| Buy | مسئله Commodity و دسترسی پایدار است | FX، تحریم، داده، Vendor lock-in | PoC مصرفکننده و Export |
| Borrow/contract | تقاضا موقت یا مهارت کمیاب است | انتقال دانش و Availability | Artifact و Handoff کامل |
| Hire | تقاضای پایدار و Role واقعی است | Ramp، mentoring، coordination | Capacity بعد از Ramp، نه offer count |
| Enable | کار باید در Stream team بماند | Support نامحدود و skill decay | استقلال با Evidence |
| Design away | Demand از پیچیدگی قابلحذف میآید | تغییر محصول/معماری | Failure demand حذفشده |
Operating model را از روی Interaction انتخاب کنید
هیچ مدل Embedded، Centralized یا Federated ذاتاً «مقیاسپذیرترین» نیست. Stream-aligned ownership برای Feedback روزمره مفید است؛ Pool تخصصی برای Performance/Security پراکنده اقتصادیتر است؛ Platform برای Journey تکراری و Self-service ارزش دارد؛ Enabling team باید Capability منتقل کند و از وابستگی دائمی خارج شود.
- چه کاری باید نزدیک Context محصول باشد؟
- کدام مهارت کمیاب و اشتراکپذیر است؟
- چه تقاضایی تکرارپذیر و مناسب X-as-a-Service است؟
- کجا استقلال Evidence یا Risk authority لازم است؟
- Interaction چه زمانی Collaboration و چه زمانی Service/Facilitation است؟
- Sunset یا Exit از کمک مرکزی چیست؟
جزئیات طراحی Team API، Service class و گذار سازمانی در راهنمای مدل عملیاتی QA آمده است.
حاکمیت کیفیت در Scale؛ مالکیت همگانی بدون رقیقشدن
«کیفیت مسئولیت همه است» اگر حق تصمیم و خروجی نامدار نداشته باشد، در Scale به «مسئولیت هیچکس» تبدیل میشود. راهنمای رهبری تضمین کیفیت و مالکیت همگانی این تفکیک را عمیقتر میکند.
| تصمیم | Owner نمونه | QA contribution | Risk acceptor |
|---|---|---|---|
| Scope محصول | Product | Risk/unknown evidence | Product/business در مرز خود |
| Design/implementation | Engineering | Testability و mechanism challenge | Tech authority |
| Evidence sufficient | Evidence owner | Integrity، coverage و limitation | جدا از ساخت در Risk بالا |
| Release/rollout | Release/service owner | Residual risk memo | Authority نامدار |
| Security/privacy gate | Qualified owner | Test artifact | مجاز و مستقل طبق سیاست |
| Operate/sunset capability | Service owner | Health و consumer evidence | Portfolio/service authority |
Security و Privacy با «بعداً در Scale» سازگار نیستند
- Access least privilege، Environment isolation و Audit از Foundation باشند.
- Artifact، Log، Screenshot و Dataset طبقهبندی و Retention داشته باشند.
- Runner، Container image، Dependency و Secret مسیر Supply-chain کنترلشده داشته باشند.
- Self-service حق تولید داده یا Fault خارج Scope ندهد.
- Automation نتیجهٔ Security/Privacy را بدون Authority مجاز Accept نکند.
- Tool SaaS از نظر Data residency، export، network/payment access و Exit آزموده شود.
Risk-based یعنی کنترل را حذف کنیم نیست؛ یعنی Context، Impact، Requirement، Foundation و شواهد اثربخشی را روشن کنیم. مشاورهٔ حقوقی و سیاست سازمانی را با مقاله جایگزین نکنید.
سناریوی ایرانی: Scale کردن کیفیت Marketplace پیش از نوروز
Marketplace فرضی از دو به شش Squad و از یک به سه PSP میرسد. Change arrival از ۱۸ به ۳۴ Evidence request در هفته افزایش یافته، اما Throughput مقایسهپذیر ۲۲ است. ۴۶٪ Cycle time در انتظار داده/محیط، ۲۱٪ Failure demand و ۱۷٪ کارها Expedite نامیده میشوند. پاسخ اولیهٔ مدیر خرید Runner بیشتر است.
نقشهٔ Demand و Constraint
| Signal | Evidence | تفسیر محدود | اقدام آزمایشی |
|---|---|---|---|
| PSP state data wait | p90=۴.8d؛ invalid=۲۴% | Data candidate constraint | سه Dataset synthetic نسخهدار |
| Staging drift | ۱۳/۳۰ Run با Manifest mismatch | Environment evidence invalid | Readiness gate + immutable manifest |
| UI regression duration | Runner wait=۰؛ execution=90m | فعلاً Queue constraint نیست | Runner خریداری نشود؛ boundary review |
| Decision wait | p90=۲.1d؛ owner غایب | Authority bottleneck | Risk-class delegate + expiry |
| Duplicate callback defects | سه mechanism تکراری | Regression pile کافی نیست | Idempotency invariant + fault simulator |
قرارداد داده و Evidence پرداخت
Canonical money: amount_irr integer
Displayed toman: explicit derived value; never ambiguous string
Identity: order_id + attempt_id + psp_reference + idempotency_key
States: initiated / committed / callback / ledgered / reconciled
Faults: timeout-before-commit ≠ timeout-after-commit
Duplicate: same callback identity; Retry identity separately recorded
Oracles: PSP + Order + Ledger + Outbox + Reconciler
Digits: Persian / Arabic / Latin preserved and normalized by contract
Text: Unicode normalization version; half-space/RTL tested
Time: UTC event instant + Asia/Tehran display
Calendar: Jalali presentation; business rule source named
Segments: PSP / bank / device / network / order type
Data: synthetic IDs; no production PAN/token/phone
Versions: dataset / environment / API / oracle / runner / test codeطرح ۶ هفتهای فرضی
- هفته ۱: Start/Finish، Service class و Flow baseline را اصلاح کنید.
- هفته ۲: Ready policy، WIP limit و Authority map را Shadow اجرا کنید.
- هفته ۳: Dataset service را برای دو Squad و یک PSP Pilot کنید.
- هفته ۴: Environment manifest/readiness و Artifact identity را Gate کنید.
- هفته ۵: Constraint را دوباره اندازه بگیرید؛ اگر Execution صف شد، shard Pilot محدود.
- هفته ۶: Outcome/Guardrail/Toil/Cost را مرور و Scale/Adapt/Stop کنید.
Guardrailهای فرضی شامل PII leak=۰، collision=۰، false-green بحرانی=۰، Reconciliation mismatch بدون owner=۰، DBA toil بیشتر نشود و Team health افت معنادار نکند. عددهای این سناریو نمونهاند و Target واقعی از Baseline و Risk appetite سازمان میآید.
متریکهای سیستم مقیاسپذیری QA
| لنز | سنجهٔ تصمیمپذیر | Countermetric / محدودیت |
|---|---|---|
| Demand | Arrival برحسب class/risk/source | Feature/test count Mix را پنهان نکند |
| Flow | WIP، Age، Throughput، Cycle distribution | Start/Finish و cancelled روشن باشد |
| Queue | Wait/blocked time به تفکیک stage/reason | Touch time با Lead time قاطی نشود |
| Failure demand | Rework/re-run/invalid artifact share | گزارش کمتر با پنهانکاری بازی نشود |
| Capability | Time-to-first-success، self-service completion | Adoption اجباری، support burden و abandonment |
| Evidence | Trusted-result freshness، Unknown، traceability | Pass rate و automation % جای Risk ننشیند |
| Risk/outcome | critical mechanism evidence، customer task/incident cohort | Attribution و severity/population روشن |
| Economics | cost/use، run/change/toil، avoided commitment | صرفهجویی فرضی و benefit overlap |
| Health | interrupt load، after-hours، focus، learning | نظارت فردی و survey cohort کوچک ممنوع |
متریک ضدبازی و قرارداد داده
هدف «Throughput بیشتر» میتواند کار را خرد، Risk را کماظهار و Finish را زود اعلام کند. Cycle time تنها میتواند کار دشوار را از پذیرش خارج کند. Defect escape میتواند با کاهش مشاهدهٔ Production ظاهراً بهتر شود. هر KPI باید Population، identity، formula، window، segment، late data، Quality state، تصمیم، Countermetric و استفادهٔ ممنوع داشته باشد.
- افراد را با Test count، Defect count، Throughput، Automation percentage یا Utilization رتبهبندی نکنید.
- یک Health score تجمیعی اجازه ندهد Critical guardrail را جبران کند.
- UNKNOWN/STALE/INVALID را صفر یا سبز نمایش ندهید.
- قبل و بعد را با تغییر Mix، Season، تیم، Instrumentation و Release بررسی کنید.
- Mean را کنار p50/p85/p90، Tail و Segment نشان دهید.
Scale Review؛ چه زمانی یک Capability را گسترش دهیم؟
Scale Review
Decision and scope requested:
Original constraint and evidence:
Pilot population / exclusions:
Before/after flow distribution:
Outcome / risk evidence:
Guardrails / adverse effects:
Adoption / retention / abandonment:
Failure demand / support / toil:
Run capacity / owner / backup:
TCO / FX / vendor / opportunity cost:
Security / privacy / accessibility:
Dependencies / migration / exit:
Alternative explanations / uncertainty:
Options: Scale / Adapt / Hold / Stop / Retire
Authority / dissent / conditions / expiry:بهبود محلی کافی نیست. اگر Dataset service زمان QA را کم ولی Toil تیم Data را دوبرابر کند، کار فقط جابهجا شده است. Scale باید جریان کل و هزینهٔ کل را ببیند.
نقشهٔ ۳۰/۶۰/۹۰ روزه مقیاسدادن QA
روز ۱ تا ۳۰: مشاهده و مهار WIP
- Population، Demand card، Start/Finish و Service class را تعریف کنید.
- شش هفته Flow، Queue، Block، Failure demand و Expedite را Baseline بگیرید.
- Value stream را با مصرفکننده، Product، Engineering، Ops و متخصصان رسم کنید.
- یک Constraint Card، WIP policy و SLE آزمایشی بسازید.
- Runner/Tool/Hire بزرگ را تا روشنشدن Constraint متوقف یا مرحلهای کنید.
روز ۳۱ تا ۶۰: Pilot یک Capability
- سه گزینهٔ Eliminate/Prevent/Self-service/Add capacity را مقایسه کنید.
- یک Pilot با Outcome، Guardrail، Blast radius، Rollback و Owner اجرا کنید.
- Run identity، Environment/Data version و Evidence artifact را قابلردیابی کنید.
- Adoption، Support burden، Failure demand و Team health را کنار Flow بسنجید.
روز ۶۱ تا ۹۰: Rebalance و مالکیت
- Constraint را دوباره اندازه بگیرید؛ فرض نکنید همان جا مانده است.
- برای Capability موفق، Service card، Runbook، Capacity، SLO/SLE، Backup و Exit بسازید.
- Interaction و Operating model را بر اساس Demand تازه تنظیم کنید.
- Stop/Holdهای منقضی و Platformهای بیمصرف را ببندید.
- Portfolio و بودجهٔ فصل بعد را با Evidence بازتخصیص دهید.
ضدالگوهای مقیاسپذیری تضمین کیفیت
- برابرگرفتن رشد User با رشد خطی Demand QA؛
- Headcount × ساعت بهعنوان ظرفیت واقعی؛
- افزودن Runner وقتی Execution صف ندارد؛
- Automation coverage یا Test count بهعنوان Scale outcome؛
- ۱۰۰٪ Utilization و حذف Reserve؛
- شروع همهچیز و تمامنکردن؛ WIP بیحد؛
- نامیدن همهٔ کارها Expedite؛
- SLE بدون Probability، Population و تاریخچه؛
- بهینهسازی Touch time و نادیدهگرفتن Wait؛
- Retry بهجای تشخیص Failure demand؛
- یک Staging مشترک بدون Booking/Manifest/Reset؛
- Parallel بدون Isolation، shard balance و Cost guardrail؛
- Embedded را مدل جهانی و Pool تخصصی را شکست دانستن؛
- Platform بهعنوان Portal/Tool project بدون Consumer journey؛
- Self-service بدون Access، Audit، Support و Prohibited use؛
- ساخت Consumer پیش از Identity/Data/Oracle Foundation؛
- انتقال Toil از QA به Dev/Data و اعلام صرفهجویی؛
- Scale کردن Prototype بیمالک و بیRunbook؛
- KPI فردی بر اساس Throughput، Defect یا Automation؛
- نادیدهگرفتن FX، تحریم، شبکه، PSP، IRR/تومان، Unicode و زمان تهران.
چکلیست تصمیم برای Scale کردن QA
- Growth vector، Population، Window و Risk را نام بردهایم؟
- واحد Demand خروجی تصمیم است، نه Test count؟
- Start/Finish و Ready criteria قابلممیزیاند؟
- Arrival، WIP، Age، Throughput و Cycle distribution را داریم؟
- Service class و Expedite policy محدود و صریح است؟
- Wait/Block/Rework/Failure demand از Touch time جداست؟
- Constraint با Queue evidence مشخص و Alternative explanation ثبت شده؟
- آیا Eliminate، Prevent، Design away و Self-service پیش از Hire بررسی شدهاند؟
- Foundation و Dependency پیش از Consumer scale روشناند؟
- Boundary هر Evidence با Risk و Fidelity دفاعپذیر است؟
- Parallel فقط در Execution constraint و با Isolation انجام میشود؟
- Model ظرفیت Range، Specialist، Interrupt، Ramp و Reserve را دارد؟
- Operating model بر اساس Interaction انتخاب شده، نه مد بازار؟
- Platform Consumer، Owner، SLE، Support، Version و Exit دارد؟
- Security/Privacy/Accessibility Hard gate مستقلاند؟
- Outcome، Guardrail، Adoption و Support burden Pilot را سنجیدهایم؟
- Toil به تیم دیگری منتقل نشده یا دستکم شفاف است؟
- Constraint پس از Intervention دوباره اندازهگیری میشود؟
- متریک برای رتبهبندی افراد یا Score جبرانی استفاده نمیشود؟
- تصمیم Scale/Adapt/Hold/Stop، Authority، Dissent و Expiry ثبت شده است؟
پرسشهای متداول درباره مقیاسپذیری QA
اولین قدم برای مقیاسدادن QA در استارتاپ چیست؟
خرید ابزار یا استخدام نیست. واحد Demand، Start/Finish و چهار Flow metric را برای یک Population تعریف کنید؛ سپس Wait، Block و Failure demand را روی Value stream ببینید. اولین Constraint را با Evidence انتخاب و یک Intervention محدود آزمایش کنید.
آیا اتوماسیون تست شرط اصلی مقیاسپذیری QA است؟
اتوماسیون یک اهرم مهم است، نه شرط کافی یا همیشه نخستین Constraint. اگر مسئله داده، محیط، Oracle، Authority یا Testability باشد، Automation میتواند Failure را سریعتر تکثیر کند. کاندید را با Risk، تکرار، ثبات، Fidelity، نگهداشت و Evidence انتخاب کنید.
چه زمانی باید تستر یا SDET بیشتری استخدام کنیم؟
وقتی تقاضای پایدار و همواحد از ظرفیت پس از حذف Failure demand و اصلاح Workflow بیشتر است، Role/مهارت محدودکننده روشن است و Ramp/mentoring/coordination در مدل آمده است. Headcount برای Queue ناشی از Access یا تصمیم، درمان مستقیم نیست.
تیم QA متمرکز بهتر مقیاس میگیرد یا Embedded؟
هیچکدام بهطور جهانی. Context روزمره و Feedback نزدیک ممکن است Embedded را مناسب کند؛ مهارت کمیاب، استقلال Evidence و Economy of scale ممکن است Pool مرکزی بخواهد؛ Journey تکراری میتواند Platform شود. اغلب ترکیب Federated با Team API شفاف بهتر آزموده میشود، نه بهعنوان حکم ثابت.
موفقیت Scale را با چه KPIهایی بسنجیم؟
یک KPI کافی نیست. Demand و Flow، Queue/Failure demand، Evidence integrity، Risk/outcome، Consumer adoption، Run cost و Team health را با Countermetric ببینید. بهبود p90 Lead time اگر false green، Incident، Toil یا Support burden را بالا برده، موفقیت کامل نیست.
جمعبندی: QA را با Constraint مقیاس دهید، نه با هیجان ابزار
سیستم کیفیت زمانی مقیاس میگیرد که رشد را به Demand قابلمشاهده تبدیل کند، WIP و Queue را ببیند، محدودیت واقعی را بهجای پرصداترین علامت پیدا کند و Capability را با مصرفکننده و Guardrail بسازد. افزودن Runner، تستر، Platform یا Embedded QA ممکن است پاسخ باشد؛ هیچکدام پیش از Evidence پاسخ پیشفرض نیست.
از یک Population، یک Flow Contract و یک Constraint Card شروع کنید. کوچکترین تغییر قابلبازگشت را اجرا کنید، نتیجهٔ کل سیستم را بسنجید و آماده باشید که Constraint جابهجا شود. مقیاسپذیری یک Migration یکباره نیست؛ چرخهٔ مداوم Observe → Constrain → Enable → Verify → Rebalance است.
