تخمین تست نرم‌افزار؛ روش‌ها، فرمول و مثال

مدیر محصول می‌پرسد: «تست این Release چند روز طول می‌کشد؟» پاسخ «سه روز» ساده و آرامش‌بخش است؛ اما معلوم نیست Scope چیست، چند نفر واقعاً در دسترس‌اند، محیط چه زمانی آماده می‌شود، Defect/retest چطور حساب شده و Confidence عدد چقدر است. سه روز بعد، تیم QA «تخمین اشتباه» متهم می‌شود؛ درحالی‌که چیزی که ارائه شده Forecast شرطی نبوده، یک عدد بی‌زمینه بوده است.

تخمین تست نرم‌افزار پیش‌گویی یا تعهد قطعی نیست. تخمین خوب می‌گوید با Baseline، داده و فرض‌های فعلی، برای کدام Scope چه Effort، Duration و Costی در چه Range و سطح اعتمادی انتظار می‌رود؛ چه Riskهایی عدد را جابه‌جا می‌کنند و چه زمانی باید Re-estimate کرد.

در این راهنما WBS، Expert/Analogy، Ratio/Extrapolation، Three-point/PERT، Wideband Delphi، Planning Poker و Forecast مبتنی بر Flow را با فرمول و مثال بررسی می‌کنیم. سپس یک Release پرداخت فروشگاه ایرانی را از نفر-ساعت تا تاریخ، Contingency و گزارش Actual پیش می‌بریم.

خلاصهٔ اجرایی تخمین تست

هدف تصمیم و تاریخ «as-of» تخمین را مشخص کنید.
Technical baseline و Scope/out-of-scope را قفل کنید.
فعالیت‌ها را با WBS کامل—نه فقط اجرای Test—فهرست کنید.
Driverها، وابستگی‌ها، فرض‌ها و Riskها را ثبت کنید.
تکنیک متناسب با بلوغ اطلاعات انتخاب و با روش دوم Cross-check کنید.
Point estimate را کنار Range/Scenario و Confidence گزارش کنید.
Effort را از Duration و Cost جدا محاسبه کنید.
ظرفیت واقعی، Calendar، کار غیرقابل‌موازی و Waiting را وارد Schedule کنید.
Contingency را به Risk مشخص وصل کنید؛ Padding پنهان نسازید.
Triggerهای Re-estimation و Owner را تعیین کنید.
Baseline اولیه را حفظ و Current forecast را جدا Update کنید.
Actual و علت اختلاف را برای کالیبراسیون بعدی ثبت کنید.

تخمین تست دقیقاً چه خروجی‌هایی دارد؟

خروجی	پرسش	واحد نمونه
Size/Scope	چه مقدار کار و چه Coverageای؟	Feature، risk item، test condition، API/flow
Effort	مجموع کار انسانی لازم؟	نفر-ساعت/نفر-روز
Duration	از شروع تا پایان چقدر زمان تقویمی؟	روز کاری/تاریخ
Cost	هزینهٔ نیروی نقش‌ها، ابزار، محیط و Vendor؟	ریال/تومان/ارز با تاریخ نرخ
Range/Scenario	در شرایط بهتر/محتمل/بدتر چه می‌شود؟	مثلاً ۱۲–۱۸ روز؛ با تعریف
Confidence	کیفیت داده و احتمال پوشش Range چقدر است؟	کمیِ کالیبره یا کیفیِ تعریف‌شده
Assumptions/Risk	عدد تحت چه شرطی معتبر است؟	فهرست نسخه‌دار با Owner

ISTQB CTAL-TM v3.0 Test estimation را برآورد Time، Effort و Cost فعالیت می‌داند و تفاوت Person-hours با elapsed duration را صریح می‌کند. این تفکیک جلوی یک خطای رایج را می‌گیرد: ۱۶۰ نفر-ساعت الزاماً با دو نفر در ۱۰ روز تمام نمی‌شود.

تخمین با Plan و Commitment فرق دارد

Estimate/Forecast: بهترین تصویر فعلی از Outcome نامطمئن؛
Target: نتیجه یا تاریخ مطلوب کسب‌وکار؛
Budget: سقف منابع قابل‌مصرف؛
Plan: مسیر انتخاب‌شده برای رسیدن به Outcome؛
Commitment: تعهدی با Scope، کنترل و اختیار مشخص.

اگر Target پنج روز است و Forecast دوازده روز، تخمین را به پنج تغییر ندهید. گزینه بسازید: Scope/Risk coverage کمتر، Feature flag، نیروی/محیط دیگر، زمان بیشتر یا پذیرش Risk. Target ورودی تصمیم است، نه دادهٔ تخمین.

پیش‌نیاز: Baseline و Scope قابل‌ردیابی

تخمین بدون Baseline عمر کوتاهی دارد. حداقل این موارد را ثبت کنید:

Build/Requirement/API/schema و تاریخ نسخه؛
Feature، Journey، platform/browser/device و integrationهای در Scope؛
نوع Test و سطح Coverage مورد انتظار؛
out-of-scope و Deferredهای صریح؛
Entry/Exit، Definition of Done و Release gate؛
محیط، داده، ابزار و dependency؛
تیم/مهارت/Availability و Calendar؛
کیفیت ورودی و Unknownها.

ابهام Requirement را به «تلاش تست بیشتر» تبدیل نکنید؛ اول سوال و Assumption بسازید. راهنمای تحلیل نیازمندی در STLC برای کشف State، Boundary، Rule و Acceptance evidence مفید است. خروجی Estimate باید در Test Plan به Scope، منابع، Schedule، Risk و Entry/Exit وصل شود.

WBS تست: فقط «طراحی و اجرا» را حساب نکنید

گروه کار	فعالیت نمونه
Analysis/Planning	Requirement review، risk analysis، approach، estimation، coordination
Test design	condition/case/charter، review، traceability، oracle
Data/Environment	seed/mask/synthetic، account/tenant، deploy، dependency/stub، access
Implementation	automation، fixture، helper، contract، instrumentation
Execution	smoke، functional، integration، system، exploratory، non-functional
Failure work	triage، evidence، defect report، investigation support
Retest/Regression	fix verification، impact regression، rerun analysis
Reporting/Release	status، completion، residual risk، release verification
Maintenance	test/data/env/tool update، quarantine debt، cleanup

آماده‌سازی داده و محیط معمولاً روی Critical path می‌افتد. برای Masking، Synthetic و isolation از راهنمای مدیریت داده تست استفاده کنید. Automation هم «صرفه‌جویی فوری» نیست؛ ساخت و نگهداری Candidateها را با استراتژی اتوماسیون تست برآورد کنید.

سطح شکست WBS

کار را تا جایی خرد کنید که Owner، Expected output، dependency و Range قابل‌فهم باشد. Rule ثابت «هر Task کمتر از هشت ساعت» وجود ندارد. خردکردن بیش‌ازحد هزینهٔ هماهنگی می‌سازد و کار پنهان را کم نمی‌کند.

روش‌های تخمین تست و زمان استفاده

روش	ورودی	مناسب	ریسک
Expert judgment	دانش فرد/گروه	Early estimate، کار نو	Anchoring/authority/optimism
Analogy	Actual مشابه + تعدیل تفاوت	محصول/تیم تکرارشونده	شباهت ظاهری
WBS bottom-up	فعالیت و Estimate جزء	Scope نسبتاً روشن	کار/وابستگی جاافتاده
Ratio	Driver تاریخی × نرخ	کار استاندارد و دادهٔ پایدار	نرخ صنعتی/تیم دیگر
Extrapolation	بخشی از Actual فعلی	پس از شروع کار نماینده	نمونهٔ اولیه ناممثل
Three-point/PERT	O/M/P و فرض ریسک	عدم‌قطعیت Task	Range ذهنیِ بدون کالیبراسیون
Wideband Delphi	تخمین مستقل + بحث	دانش توزیع‌شده	زمان/Facilitation
Planning Poker	اندازه نسبی/بحث اختلاف	Backlog تیم پایدار	تبدیل اجباری Point→Hour
Flow forecast	Throughput/cycle time history	ورودی مشابه و policy نسبتاً پایدار	نادیده‌گرفتن تغییر regime

ISTQB CTFL v4.0.1 Ratio-based، Extrapolation، Wideband Delphi و Three-point را در تکنیک‌های تخمین توضیح می‌دهد. هیچ روش به‌تنهایی حقیقت تولید نمی‌کند؛ داده و فرض باید کنار نتیجه بمانند.

Expert judgment و Analogy را قابل دفاع کنید

Expert judgment

به‌جای «تستر ارشد گفت پنج روز»، کارشناسان مستقل این Packet را پر کنند:

Scope/Driverهای دیده‌شده؛
Most likely و Range؛
سه Assumption کلیدی؛
Riskهایی که Pessimistic را می‌سازند؛
Reference class یا تجربهٔ مشابه؛
Confidence و Missing information.

سپس اختلاف بالا/پایین بررسی شود. هدف میانگین‌گرفتن کور نیست؛ آشکارکردن برداشت متفاوت از Scope، Technique یا Risk است.

Analogy

Actual پروژهٔ قبل را با Driver تعدیل کنید:

Release قبلی ۱۲۰ نفر-ساعت بود؛ این Release دو Integration به‌جای یک، Mobile matrix کوچک‌تر، Regression automation بالغ‌تر و Environment ناپایدارتر دارد. هر Adjustment با دلیل و بازه ثبت شود.

از دادهٔ تیم/محصول دیگر فقط با احتیاط استفاده کنید. «پروژه مشابه» باید Technology، test level، quality gate، team skill، environment و defect/rework profile قابل‌قیاس داشته باشد.

Ratio و Extrapolation

Ratio

نمونهٔ نرخ داخلی: Median effort طراحی/اجرای API condition در شش Release اخیر، به تفکیک complexity band. سپس:

Estimated effort = size driver × calibrated rate

تعداد Test case به‌تنهایی Size خوبی نیست؛ Granularity قابل بازی است و Caseهای ساده/پیچیده برابر نیستند. Driver می‌تواند risk item، endpoint type، business rule، platform combination یا Story class باشد، اگر Definition و دادهٔ تاریخی دارد.

Extrapolation

اگر ۲۰٪ Scope واقعاً نماینده اجرا شده است:

Forecast remaining = remaining comparable units × observed effort per unit

Setup اولیه، learning curve، tail defect و سخت‌ترین Scenarioها را جدا کنید. ده Case آسان اول نمایندهٔ Authorization/Concurrency آخر نیست. Forecast را پس از هر Batch با Actual به‌روز کنید، اما Baseline اولیه را پاک نکنید.

Three-point و PERT با فرمول

برای هر Task سه سناریو تعریف کنید:

O، خوش‌بینانه: شرایط خوبِ ممکن، نه معجزه؛
M، محتمل: شرایط عادی با دادهٔ فعلی؛
P، بدبینانه: Riskهای مشخصِ ممکن، نه آخرالزمان.

فرمول PERT رایج:

E = (O + 4M + P) / 6

SD ≈ (P - O) / 6

مثال آماده‌سازی محیط: O=۱۲، M=۲۰ و P=۴۴ نفر-ساعت:

E = (12 + 4×20 + 44) / 6 = 22.7 person-hours

SD ≈ (44 - 12) / 6 = 5.3 hours

این SD بر فرض‌های سادهٔ PERT تکیه دارد. آن را خودکار به «۹۵٪ تضمین» تبدیل نکنید؛ Estimateهای Task هم‌بسته‌اند، Rangeها قضاوتی‌اند و توزیع واقعی ممکن است نامتقارن باشد. برای Range پروژه از Scenario analysis یا Simulation با دادهٔ کالیبره و Correlation معقول استفاده کنید.

PERT با میانگین ساده فرق دارد

(O + M + P) / 3 میانگین سادهٔ سه‌نقطه‌ای است؛ PERT وزن بیشتری به M می‌دهد. فرمول را همراه نسخه و دلیل انتخاب ثبت کنید تا دو Spreadsheet نتیجهٔ متفاوت را «همان روش» ننامند.

Wideband Delphi و Planning Poker

Wideband Delphi

Scope/Definition یکسان به افراد داده شود.
هر فرد مستقل Estimate و Assumption بنویسد.
Facilitator توزیع و دلیل Extremeها را بدون فشار مقام مطرح کند.
گروه Scope/Risk را روشن کند.
دور مستقل تکرار و Range/اختلاف باقی‌مانده ثبت شود.

Consensus اجباری نیست؛ اختلاف ممکن است Unknown واقعی باشد و باید در Range بماند.

Planning Poker و Story point

Planning Poker برای آشکارکردن برداشت متفاوت و Relative sizing مفید است. Story point ساعت نیست و بین تیم‌ها قابل‌مقایسه نیست. Velocity/Throughput باید برای Forecast همان سیستم استفاده شود، نه KPI بهره‌وری یا هدفی که تیم برای رسیدن به آن Size را تغییر دهد.

Scrum Guide 2020 یک Technique خاص مثل Story point یا Planning Poker را تجویز نمی‌کند؛ Developers اندازه را تعیین می‌کنند و روش متناسب Context تیم است. تبدیل ثابت «هر Point = شش ساعت» اغلب عدم‌قطعیت را پنهان می‌کند؛ فقط تاریخچهٔ تجربی و Distribution می‌تواند رابطهٔ محلی بسازد.

Forecast مبتنی بر Flow و Monte Carlo

Kanban Guide چهار Flow metric پایه را WIP، Throughput، Work Item Age و Cycle Time می‌داند. برای تیمی با Definition of Workflow پایدار و Itemهای نسبتاً مشابه، این داده‌ها از حدس فردی قوی‌ترند.

دو پرسش Forecast

When: با Scope معلوم، تا چه تاریخی چند درصد شانس پایان داریم؟
How many: تا تاریخ معلوم، چند Item با چه Range‌ای تمام می‌شود؟

Monte Carlo می‌تواند از تاریخچهٔ Throughput یا Cycle time نمونه‌برداری مکرر کند و توزیع Outcome بسازد. ورودی و فرض را ثبت کنید:

بازهٔ تاریخچه و دلیل Comparable بودن؛
تعریف Started/Finished و Unit؛
WIP فعلی و Work item age؛
تعطیلات/ظرفیت و policy change؛
Scope growth یا Blocked dependency؛
تعداد Simulation و Percentile گزارش‌شده.

اگر Team، Tool، Definition of Done یا نوع Work عوض شده، تاریخچهٔ قدیمی regime دیگری است. Simulation عدم‌قطعیت داده را نمایش می‌دهد؛ دادهٔ نامعتبر را اصلاح نمی‌کند.

Effort، Duration و Cost را جدا محاسبه کنید

Effort

Total effort = Σ activity effort by role + explicit risk work/contingency

نفر-روز را با ساعت کاری تعریف کنید؛ ۱ نفر-روز در دو سازمان ممکن است ۶ یا ۸ ساعت باشد. فعالیت‌های Product/Developer/SRE که برای Test لازم‌اند جدا دیده شوند، نه رایگان فرض شوند.

ظرفیت موثر

Daily test capacity = Σ(actual available hours allocated to this scope)

به‌جای «بهره‌وری ۸۰٪» ثابت، Calendar واقعی، on-call، support، جلسه، مرخصی، کار هم‌زمان و دادهٔ Allocation گذشته را استفاده کنید. این ضریب دربارهٔ ظرفیت سیستم است، نه قضاوت عملکرد فرد.

Duration

تقریب اولیه:

work days ≈ parallelizable effort / effective team capacity

سپس این‌ها را اضافه/مدل کنید:

کار غیرقابل‌موازی و Critical path؛
انتظار Build، Environment، Data، Fix و Vendor؛
Calendar، تعطیلی، Shift و Timezone؛
Queue/WIP و context switching؛
Review/approval و Release window؛
Defect arrival و Retest loop.

افزودن نفر Duration را خطی نصف نمی‌کند؛ Onboarding، coordination، محیط محدود و Task غیرقابل‌تقسیم وجود دارد.

Cost

Cost = Σ(effort by role × loaded rate) + tool/license + environment/device + vendor + contingency

برای تیم ایرانی، واحد ریال/تومان، تاریخ نرخ ارز، مالیات/پرداخت و ریسک دسترسی Vendor را صریح ثبت کنید. تبدیل ارز پنهان Estimate را غیرقابل‌بازتولید می‌کند.

Contingency را از Padding پنهان جدا کنید

درصد جهانی ۱۰، ۱۵ یا ۲۵ برای همه پروژه‌ها مبنا ندارد. Contingency باید از Risk و عدم‌قطعیت Estimate بیاید:

Risk	احتمال/شرط	اثر Effort/Duration	پاسخ
محیط ناپایدار	در سه Release از پنج	۸–۲۰h + انتظار	health gate، owner، clone
Sandbox درگاه قطع	Window نامطمئن	۰–۲ روز تقویمی	stub + reschedule
Requirement Retry تغییر کند	تصمیم Product باز	۱۲–۳۶h redesign/retest	decision deadline
Defect پراثر	بر اساس reference class	triage/fix wait/retest	risk budget و lane

Expected monetary/time value مانند probability × impact می‌تواند شروعی شفاف باشد، اما Riskها ممکن است هم‌بسته و Probabilityها قضاوتی باشند. Scenario/Simulation و مدیریت Trigger دقیق‌تر است. Reserve و شرایط مصرف آن را جدا از Base estimate و Ownerدار نگه دارید.

مثال عملی: تخمین تست بازپرداخت فروشگاه ایرانی

Baseline

API بازپرداخت، پنل پشتیبانی و Web status در Scope؛ Mobile UI خارج از Scope؛
دو درگاه Sandbox، Callback success/timeout/duplicate؛
تومان در UI و ریال در Ledger؛
دو QA با مجموع ۱۱ ساعت ظرفیت تخصیص‌یافته در روز؛
Environment از روز دوم؛ تصمیم Retry policy تا پایان روز اول؛
Release gate: invariant مالی، authorization، idempotency، regression و rollback evidence.

WBS سه‌نقطه‌ای

فعالیت	O	M	P	PERT E (h)
تحلیل Risk/Requirement	۸	۱۲	۲۰	۱۲٫۷
طراحی/Review Test	۱۶	۲۴	۳۶	۲۴٫۷
داده و محیط	۱۲	۲۰	۴۴	۲۲٫۷
API/Integration/System execution	۲۴	۳۶	۶۰	۳۸٫۰
Triage/Retest allowance	۱۶	۲۸	۵۲	۳۰٫۰
Automation/Regression update	۱۲	۲۰	۳۶	۲۱٫۳
Report/Release verification	۶	۸	۱۴	۸٫۷
جمع	۹۴	۱۴۸	۲۶۲	۱۵۸٫۱

۹۴ و ۲۶۲ «حد تضمین‌شده» یا Percentile نیستند؛ Scenario envelope حاصل جمع قضاوت‌های Task هستند و Correlation را دقیق مدل نمی‌کنند. Expected نزدیک ۱۵۸ نفر-ساعت است، اما Schedule با تقسیم ساده تمام نمی‌شود.

از Effort تا Duration

158 / 11 ≈ 14.4 work days فقط Lower-order calculation است. Environment روز دوم آماده می‌شود، تصمیم Product blocker تحلیل است، Sandbox window دارد و Retest به Fix وابسته است. تیم Current forecast را ۱۵ تا ۲۲ روز کاری با Confidence متوسط گزارش می‌کند؛ شرط آن تصمیم Retry در روز اول و Availability تعریف‌شده است. Confidence کیفی باید در سازمان تعریف و با Actual کالیبره شود.

گزینه‌های تصمیم

گزینه	تغییر	پیامد
A	Scope کامل	۱۵–۲۲ روز؛ Risk پوشش‌داده‌شده
B	درگاه دوم بعد از Release	Duration کمتر؛ Feature flag و residual risk ثبت شود
C	نیروی بیشتر	فقط Taskهای قابل‌موازی؛ onboarding/env limit باقی است
D	Target ثابت	Risk-based depth؛ موارد حذف‌شده و owner تصمیم روشن

کشف Failure و Retest باید با Definition یکسان ثبت شود؛ گزارش باگ حرفه‌ای رفت‌وبرگشت Triage را کم می‌کند، اما Defect arrival همچنان عدم‌قطعیت Schedule است.

تخمین در Agile و Continuous Delivery

تخمین در روش تکرارشونده حذف نمی‌شود؛ Horizon کوتاه و Update بیشتر می‌شود:

Backlog: Relative size/Reference class و Risk؛
Iteration: ظرفیت/Throughput و Definition of Done؛
Release: Flow-based forecast و Scenario؛
PR/Pipeline: زمان Signal هر Lane؛
Production verification: Window، traffic و rollback budget.

Automation Suite باید در زمانی نتیجه دهد که Decision منتظر آن است. راهنمای Continuous Testing Fast/slow lane، Feedback budget و Owner شکست را طراحی می‌کند. افزودن Test به Suite فقط Effort ساخت نیست؛ Duration Pipeline و Triage آینده را نیز تغییر می‌دهد.

چه زمانی Re-estimate کنیم؟

Scope/Acceptance/architecture یا interface تغییر کند؛
Environment/Data/Dependency در موعد مقرر آماده نشود؛
Actual Batch از Range یا نرخ تاریخی خارج شود؛
Defect arrival/severity و Retest loop از فرض عبور کند؛
تیم/Availability/Calendar یا Vendor access تغییر کند؛
Tool/automation به‌جای Signal، Flake/maintenance بسازد؛
Risk جدید یا Incident/Compliance requirement وارد شود؛
Milestone اطلاعاتی مشخص برسد: refinement، first build، first execution.

Re-estimate تاریخچه را بازنویسی نکند. این سه ستون را نگه دارید:

Original baseline estimate: آنچه در زمان تصمیم می‌دانستیم؛
Current forecast: بهترین تصویر امروز؛
Actual: کار/زمان واقعی با Classification علت.

دادهٔ تاریخی درست جمع کنید

فیلد	چرا لازم است؟
Scope/size/risk class	Comparable reference class
Team/skill/allocation	تفاوت ظرفیت و learning
Environment/data readiness	Waiting و blocker
Effort by activity/role	Driver واقعی هزینه
Start/finish/blocked time	Cycle/lead time و queue
Defect/retest profile	Rework distribution
Automation/flake/maintenance	هزینهٔ Signal
Estimate version/range/confidence	Calibration
Change reason	Scope creep در برابر estimate error

Time tracking ریزدانه نباید ابزار نظارت فردی شود؛ Definition، حریم و هدف یادگیری تیم روشن باشد. Data بد رفتار را منحرف می‌کند: اگر Hours کمتر پاداش بگیرد، افراد فعالیت ضروری را ثبت نمی‌کنند.

کیفیت تخمین را چگونه بسنجیم؟

خطای Point

Signed error = Actual - Estimate

Absolute error = |Actual - Estimate|

Percentage error وقتی Actual صفر/کوچک است مشکل دارد و Aggregate آن می‌تواند گمراه کند. Median/Distribution را به تفکیک Work class ببینید؛ Average تنها Tail را پنهان می‌کند.

Calibration Range

اگر ۸۰٪ Range اعلام می‌کنید، در نمونهٔ کافی باید تقریباً ۸۰٪ Actualها داخل Range باشند. اگر همیشه ۴۰٪ داخل‌اند، Range یا Confidence بد کالیبره است. Sample کوچک و تغییر regime را ثبت کنید.

Bias

آیا Forecastها پیوسته کمتر از Actual‌اند؟ علت را به Optimism خلاصه نکنید: Scope change، untracked waiting، WBS ناقص، Target pressure یا reference class غلط را تفکیک کنید.

راهنمای رسمی GAO برای تخمین معتبر بر هدف/Scope، Technical baseline، WBS، فرض‌ها، داده، روش، Sensitivity/Risk، مستندسازی و Update با Actual تأکید دارد. گرچه برای برنامه‌های هزینه‌ای گسترده نوشته شده، این اصول برای Estimate تست نیز الگوی ممیزی مفیدی هستند.

برای جلوگیری از KPI بازی‌پذیر، راهنمای متریک‌های تست را برای Denominator، Window، Baseline و Decision به کار ببرید.

گزارش تخمین برای ذی‌نفعان

نسخهٔ یک‌پاراگرافی

تا ۱۵ مرداد و بر اساس Requirement v3/API v7، Scope بازپرداخت دو درگاه ۱۵۸ نفر-ساعت Expected و ۱۵–۲۲ روز کاری با Confidence متوسط Forecast می‌شود. شرط‌ها: تصمیم Retry تا فردا، محیط از روز دوم و مجموع ظرفیت ۱۱h/day. Riskهای اصلی Sandbox، Defect مالی و تغییر Rule هستند. اگر Target ده روز است، گزینهٔ پیشنهادی Flag درگاه دوم و ثبت residual risk است. Re-estimate در first build یا شکستن هر شرط انجام می‌شود.

در Status بعدی Original estimate، Current forecast، Actual-to-date، Remaining و تغییر فرض را جدا گزارش کنید. قالب گزارش تست تصمیم‌محور Recommendation و Decision owner را از هم جدا نگه می‌دارد.

قالب کامل Test Estimate

Estimate ID / as-of / author / reviewers: …
Decision/purpose: …
Baseline/build/requirements: …
Scope / out-of-scope / quality gates: …
WBS / roles / dependencies: …
Technique + reference data: …
O/M/P or flow sample: …
Effort point/range: …
Duration/date range: …
Cost + currency/rate date: …
Confidence definition: …
Assumptions/ground rules: …
Risk/contingency/owner: …
Options/trade-offs: …
Re-estimation triggers/date: …
Original/current/actual links: …
Approver/decision: …

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

هفتهٔ اول: Definition و Baseline

Effort/Duration/Cost/Started/Finished را تعریف کنید.
WBS template و Assumption/Risk log بسازید.
پنج Estimate اخیر و Actual موجود را جمع کنید.
Work classهای قابل‌مقایسه را تعیین کنید.

هفتهٔ دوم: Pilot

یک Release را با WBS + Three-point تخمین بزنید.
یک Cross-check با Analogy/ratio انجام دهید.
Range، Confidence و Trigger را قبل از اجرا قفل کنید.
Target pressure را به Option تبدیل کنید.

هفتهٔ سوم: Flow و Actual

WIP، Throughput، Cycle time و Waiting reason را ثبت کنید.
Batch اول را Extrapolate و Current forecast را Update کنید.
Baseline را حفظ و Change reason را Classify کنید.
یک Forecast سادهٔ Flow/Simulation را آزمایش کنید.

هفتهٔ چهارم: Calibration

Estimate/Range/Actual را مقایسه کنید.
WBS omission، Bias، Scope change و blocker را تفکیک کنید.
Rate/reference class و Risk trigger را اصلاح کنید.
Review ماهانه/فصلی با Owner و حداقل Sample تعریف کنید.

اشتباه‌های رایج در تخمین تست

یک عدد بدون Range: عدم‌قطعیت پنهان می‌شود.
Target به‌جای Estimate: مذاکره به داده تبدیل می‌شود.
فقط اجرای Test: تحلیل، داده، محیط، triage و retest جا می‌افتد.
Effort = Duration: Capacity، waiting و critical path حذف می‌شوند.
دو نفر = نصف زمان: کار غیرقابل‌موازی و coordination نادیده است.
بهره‌وری ثابت ۸۰٪: Calendar واقعی با قضاوت فردی جایگزین می‌شود.
بافر ۱۰–۲۵٪ جهانی: Risk مشخص و Confidence وجود ندارد.
Point = Hour: Relative size به تعهد زمانی جعلی تبدیل می‌شود.
Velocity KPI: Size قابل بازی و مقایسهٔ تیم‌ها مخرب می‌شود.
Test case count خام: Complexity و granularity نادیده است.
PERT = تضمین احتمال: Correlation و calibration حذف می‌شوند.
Actual بدون Context: Scope change با خطای Estimate مخلوط می‌شود.
Re-estimate با پاک‌کردن Baseline: یادگیری و Accountability از بین می‌رود.
Open-source/automation = زمان صفر: ساخت/نگهداری/Infra/Triage حساب نمی‌شود.
فشار برای کاهش عدد: Risk به‌جای Option در Estimate پنهان می‌شود.

چک‌لیست نهایی تخمین تست

هدف تصمیم و as-of date ثبت شده است.
Technical baseline، Scope و out-of-scope روشن‌اند.
Quality gate و سطح Coverage مشخص است.
WBS تحلیل تا گزارش/نگهداری را پوشش می‌دهد.
Data/environment/dependency و Owner ثبت شده‌اند.
Technique و Reference data قابل‌ردیابی است.
روش دوم Estimate را Cross-check کرده است.
Point، Range/Scenario و Confidence کنار هم‌اند.
Effort، Duration و Cost جدا محاسبه شده‌اند.
Capacity از Allocation/Calendar واقعی آمده است.
Critical path، waiting و non-parallel work در Duration هستند.
Contingency به Risk/شرط/Owner وصل است.
Assumptionها و Sensitivityهای اصلی ثبت شده‌اند.
گزینه‌های Scope/Time/Resource/Risk برای Target conflict وجود دارد.
Re-estimation trigger و milestone تعریف شده است.
Original baseline، Current forecast و Actual جدا نگهداری می‌شوند.
Metric کالیبراسیون برای یادگیری است، نه رتبه‌بندی فرد.

سوالات متداول تخمین تست نرم‌افزار

بهترین روش تخمین تست چیست؟

روش جهانی وجود ندارد. در Early stage از Expert/Analogy، با Scope روشن از WBS/Three-point، و برای جریان تکرارشونده از Throughput/Cycle-time استفاده کنید. یک روش دوم Cross-check و Assumption/Range را ثبت کنید؛ کیفیت ورودی مهم‌تر از نام Technique است.

فرمول PERT برای تخمین تست چیست؟

فرمول رایج E=(O+4M+P)/6 و انحراف تقریبی (P-O)/6 است. O/M/P باید سناریوهای تعریف‌شده باشند. این فرمول به‌تنهایی Probability تضمین‌شده نمی‌دهد؛ Correlation، دادهٔ تاریخی و کالیبراسیون Range پروژه لازم‌اند.

نفر-ساعت را چطور به روز کاری تبدیل کنیم؟

Effort قابل‌موازی را بر ظرفیت تخصیص‌یافتهٔ واقعی تیم تقسیم کنید، سپس کار غیرقابل‌موازی، Critical path، انتظار Build/محیط/Fix، Calendar، WIP و Retest loop را وارد کنید. تقسیم ساده بر تعداد افراد معمولاً Duration را کم‌برآورد می‌کند.

آیا Story point را می‌توان به ساعت تبدیل کرد؟

تبدیل ثابت و جهانی خیر. Story point Relative size داخلی تیم است. تاریخچهٔ همان تیم می‌تواند Distribution محلی برای Forecast بسازد، اما Point بین تیم‌ها قابل‌مقایسه و Velocity معیار بهره‌وری نیست. برای Date forecast از Flow/Throughput و دادهٔ واقعی کمک بگیرید.

چه مقدار Buffer برای تست مناسب است؟

درصد جهانی وجود ندارد. Contingency را از Risk register، Three-point/scenario، دادهٔ Defect/Environment و Confidence مطلوب استخراج کنید. Base estimate، Reserve، شرط مصرف، Owner و Revisit trigger را جدا گزارش کنید تا Padding پنهان نشود.

منابع و یادداشت بازبینی

تفکیک Effort/Duration/Cost و تکنیک‌ها با ISTQB CTAL-TM ۳.۰ و CTFL ۴.۰.۱؛ اصول Baseline/WBS/Assumption/Risk/Sensitivity/Actual با GAO Cost Estimating Guide؛ Flow metricها با Kanban Guide؛ و مرز Scrum/Story-point با Scrum Guide ۲۰۲۰ تطبیق داده شده‌اند. آخرین بازبینی محتوایی: ۱۵ مرداد ۱۴۰۵. عددها و Range مثال آموزشی‌اند؛ آن‌ها را بدون Scope، داده و کالیبراسیون تیم خود به Commitment تبدیل نکنید.

جمع‌بندی: تخمین خوب عددی نیست که هرگز تغییر نکند؛ مدلی است که با تغییر Evidence به‌طور شفاف Update می‌شود. Baseline را بنویسید، WBS را کامل کنید، Range و Confidence بدهید، Effort را از Duration جدا کنید، Risk را پنهان نکنید و Actual را برای Forecast بعدی یاد بگیرید.

تست نرم افزار

تخمین تست نرم‌افزار؛ روش‌ها، فرمول و مثال عملی