۱۲ اشتباه رایج در تست نرم‌افزار و راه اصلاح آن‌ها

Regression تیم ۹۸٪ Pass شده، اما انتشار متوقف است: ۱۲ تست Flaky چندبار Rerun شده‌اند، محیط پرداخت از صبح Blocked است و هیچ‌کس نمی‌داند دو درصد Fail واقعاً به کدام ریسک مربوط‌اند. مشکل «کم‌کاری تستر» نیست؛ فرایند تست سیگنال تصمیم‌پذیر تولید نمی‌کند.

در این راهنما ۱۲ اشتباه رایج تست نرم‌افزار را با نشانه، علت ریشه‌ای محتمل، اقدام اصلاحی و Guardrail بررسی می‌کنیم. هدف ساختن یک Checklist سرزنش نیست؛ الگوهای سیستمی را پیدا می‌کنیم که باعث بازخورد دیر، پوشش ظاهری و تصمیم انتشار مبهم می‌شوند.

روش استفاده: از جدول تشخیص سریع یک یا دو الگوی پرهزینه را انتخاب کنید، دو تا چهار Sprint خط مبنا بگیرید، یک تغییر کوچک اجرا کنید و پیامد محصول را کنار سلامت فرایند بسنجید.

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

Defect محصول رفتاری است که با انتظار معتبر ناسازگار است. اشتباه یا Anti-pattern تست، شیوه‌ای در سیستم کار است که احتمال کشف دیرهنگام، سیگنال نامعتبر یا تصمیم ضعیف را بالا می‌برد. یک باگ Production الزاماً «شکست QA» نیست؛ ممکن است از نیاز مبهم، طراحی، کد، داده، مانیتورینگ، محدودیت زمان یا تصمیم آگاهانه پذیرش ریسک آمده باشد.

برای اصلاح، از سه پرسش شروع کنید:

• کدام تصمیم با اطلاعات ناکافی گرفته شد؟
• کدام Signal دیر، مبهم یا غیرقابل‌اعتماد بود؟
• چه تغییری در سیستم احتمال تکرار را کم می‌کند؟

واژگان و اصول پایه در سرفصل رسمی ISTQB CTFL v4.0.1 آمده است، اما نسخه عملی فرایند باید با زمینه تیم شما سازگار شود.

جدول تشخیص سریع اشتباه‌های رایج

نشانه	الگوی شکست محتمل	اولین آزمایش اصلاحی
همه باگ‌ها روزهای آخر پیدا می‌شوند	تست به یک مرحله پایانی تبدیل شده	QA در Refinement یک Story پرریسک شرکت کند
تست زیاد است، اما Incident حیاتی تکرار می‌شود	پوشش بر اساس شمارش، نه ریسک	سه مسیر حیاتی و حالت‌های شکست را مدل کنید
Failها با Rerun سبز می‌شوند	سامانه تست قابل‌اعتماد نیست	علت Fail و Flaky را جدا و مالک تعیین کنید
Regression ساعت‌ها طول می‌کشد	لایه تست نامناسب و UI-heavy	ده تست کند را به API/Component منتقل کنید
Release report فقط Pass Rate دارد	ریسک و داده ناقص پنهان است	Blocked، Not Run و ریسک باقی‌مانده را جدا کنید
تیم روی Severity بحث بی‌پایان دارد	اثر، فوریت و مالک تصمیم مبهم‌اند	مثال‌های شدت و SLA تصمیم را مشترک تعریف کنید

۱. تست فقط در انتهای توسعه شروع می‌شود

نشانه

QA اولین‌بار Feature را روی Build تقریباً نهایی می‌بیند؛ سؤال بنیادی نیازمندی به Change request تبدیل می‌شود؛ Sprint در انتظار «تأیید QA» می‌ماند.

علت سیستمی

تست به معنی اجرای محصول ساخته‌شده تعریف شده است، نه ارزیابی Artifactهای نیازمندی، طراحی، کد و عملیات. نقش‌ها به‌جای جریان بازخورد، Handoff می‌سازند.

اصلاح

• در Refinement، مثال، مرز، Permission و Failure mode را مرور کنید.
• پیش از UI، قرارداد API یا Prototype را بررسی کنید.
• Static review، Unit/Component test و Testability را داخل جریان توسعه قرار دهید.
• پس از انتشار نیز Telemetry و Incident را به مدل تست برگردانید؛ Shift-left جای Shift-right را نمی‌گیرد.

Guardrail: حضور QA در جلسه به‌تنهایی موفقیت نیست. زمان رسیدن اولین بازخورد معتبر و تعداد ابهام‌های حل‌شده پیش از ساخت را ببینید.

۲. تست بر اساس متن Requirement، نه هدف و ریسک

نشانه

تمام Acceptance Criteria تیک خورده‌اند، اما جریان واقعی کاربر یا اثر مالی نادیده مانده است. تستر فقط رفتار نوشته‌شده را تأیید می‌کند و درباره چیزهای نوشته‌نشده سؤال ندارد.

علت سیستمی

Requirement با حقیقت کامل اشتباه گرفته شده است. نیاز کاربر، قید عملیات، تهدید و سناریوی اختلال بیرون سند مانده‌اند.

اصلاح

برای هر Story، User، Goal، Rule، Example، Risk، Dependency و Unknown را استخراج کنید. تکنیک‌ها را از راهنمای تحلیل نیازمندی برای تستر به کار ببرید.

مثال: «کاربر می‌تواند پرداخت کند» باید به مبلغ، مالک سفارش، وضعیت مجاز، Retry، Callback تکراری، Timeout، لغو و تطبیق Ledger شکسته شود.

Guardrail: تستر مالک نهایی Requirement نیست؛ سؤال باز باید صاحب تصمیم و مهلت پاسخ داشته باشد.

۳. Testability و Observability نادیده گرفته می‌شوند

نشانه

برای ساخت داده ساعت‌ها زمان لازم است؛ نتیجه در UI دیده نمی‌شود؛ Log فاقد Correlation ID است؛ زمان یا سرویس بیرونی قابل‌کنترل نیست.

علت سیستمی

قابلیت تست به‌عنوان مسئولیت بعد از توسعه دیده می‌شود. Interface برای تزریق وابستگی، Clock، داده مصنوعی و Signal تشخیصی طراحی نشده است.

اصلاح

• Test hook امن، Factory داده و Reset محدود بسازید.
• Correlation ID را از UI/API تا Queue و Log نگه دارید.
• Clock و پاسخ سرویس بیرونی را در محیط تست کنترل کنید.
• Feature flag، Health check و پیام خطای قابل‌تشخیص تعریف کنید.

Guardrail: Test hook نباید در Production مسیر دورزدن مجوز بسازد. Threat review، Scope و کنترل دسترسی لازم است.

۴. Scope و معیار تصمیم انتشار مبهم‌اند

نشانه

عبارت‌هایی مثل «تست کامل شود» یا «همه‌چیز سبز باشد» جای معیار دارد. وقتی زمان کم می‌شود، کسی نمی‌داند چه چیزی حذف یا چه ریسکی پذیرفته شده است.

علت سیستمی

Test plan به فهرست فعالیت یا سند طولانی تبدیل شده، اما سؤال تصمیم، داخل/خارج دامنه، مالک ریسک و Exit criteria روشن نیست.

اصلاح

یک برنامه سبک اما تصمیم‌محور بسازید: هدف Release، Riskها، مدل پوشش، محیط/داده، Evidence، Entry/Exit و مسیر Escalation. قالب عملی در راهنمای Test Plan آمده است.

Guardrail: Exit criterion نباید به «صفر باگ» یا درصد Pass تنها تقلیل یابد. استثنا و پذیرش ریسک باید نام و تاریخ داشته باشد.

۵. پوشش با تعداد Test Case یا درصد کد اشتباه گرفته می‌شود

نشانه

تیم می‌گوید «پوشش ۹۰٪ است» اما مخرج، سطح و اهمیت آن مشخص نیست. Test Caseها برای بالا بردن عدد خرد می‌شوند و Assertionهای کم‌ارزش زیادند.

علت سیستمی

Coverage یک مفهوم چندبعدی است: Requirement، Risk، State، Rule، Data، Platform، Code و Interface. یک عدد منفرد همه آن‌ها را نشان نمی‌دهد.

اصلاح

• ریسک‌های حیاتی را وزن بدهید.
• State/Transition، Decision rule و Data class را مدل کنید.
• Code coverage را برای یافتن کد اجرا‌نشده استفاده کنید، نه اثبات کیفیت.
• تازگی نتیجه و کیفیت Oracle را کنار وجود تست ببینید.

نوشتن تست کمتر اما دقیق‌تر را با تکنیک‌های طراحی Test Case تمرین کنید.

Guardrail: هدف عمومی «۱۰۰٪ Requirement» یا «۸۰٪ Code coverage» برای همه محصولات معتبر نیست. Threshold باید به ریسک و سطح تست وصل باشد.

۶. همه‌چیز از UI تست می‌شود

نشانه

Regression کند و شکننده است، علت Fail مبهم است و برای یک Rule ساده باید مرورگر و چند سرویس بالا باشند.

علت سیستمی

تیم ابزار UI را زودتر از معماری تست انتخاب کرده یا API/Component testability ندارد. رفتار تکراری در چند لایه بدون هدف متفاوت تست می‌شود.

اصلاح

• Rule محاسباتی را نزدیک‌ترین لایه قطعی تست کنید.
• قرارداد و Integration را در مرز سرویس پوشش دهید.
• UI را برای Journeyهای حیاتی، اتصال واقعی و تجربه نگه دارید.
• هدف هر تست و علت انتخاب لایه را ثبت کنید.

Guardrail: «هرچه پایین‌تر بهتر» نیز قانون مطلق نیست. نقص قرارداد، Configuration یا Journey فقط در Unit test دیده نمی‌شود.

۷. اتوماسیون هدف می‌شود، نه وسیله بازخورد

نشانه

تیم درصد اتوماسیون را KPI می‌کند، سناریوهای کم‌ثبات را Script می‌کند و بخش بزرگی از ظرفیت صرف تعمیر Locator و داده می‌شود.

علت سیستمی

تعداد Script قابل‌شمارش است، اما ارزش بازخورد، فرکانس اجرا، هزینه نگهداری و احتمال شکست نادیده می‌مانند.

اصلاح

کاندید را بر اساس تکرار، ثبات، ارزش ریسک، قابلیت تشخیص و هزینه کل انتخاب کنید. در راهنمای اتوماسیون تست مدل تصمیم و TCO توضیح داده شده است.

Guardrail: Manual و Automated را به دو تیم رقیب تبدیل نکنید. تست اکتشافی دانش تولید می‌کند و تست خودکار دانش پایدار را سریع تکرار می‌کند.

۸. Flaky، Blocked و خطای محیط داخل Rerun پنهان می‌شوند

نشانه

Job با Retry دوم سبز است؛ هیچ‌کس Fail اول را بررسی نمی‌کند. Not Run از گزارش حذف می‌شود و Pass Rate خوش‌بینانه می‌ماند.

علت سیستمی

سبزبودن Pipeline مشوق قوی‌تری از اعتماد به Signal است. مالکیت محیط، داده و Quarantine مشخص نیست.

اصلاح

• Fail اولیه و Rerun را هر دو ذخیره کنید.
• علت را Product/Test/Data/Environment/Unknown دسته‌بندی کنید.
• Quarantine باید مالک، Ticket و مهلت داشته باشد.
• Blocked/Invalid/Not Run را مخرج و ریسک مستقل گزارش کنید.
• داده و محیط را تا حد ممکن تکرارپذیر و قابل‌پاک‌سازی کنید.

نحوه ثبت نتیجه و Triage در راهنمای اجرای تست آمده است.

Guardrail: Quarantine دائمی قبرستان تست نسازد. ریسک بدون پوشش باید در تصمیم Release دیده شود.

۹. Pass Rate به‌عنوان حکم کیفیت استفاده می‌شود

نشانه

گزارش فقط «۹۷٪ Passed» دارد؛ معلوم نیست کدام Build، Platform، Scope یا Risk سنجیده شده و سه درصد دیگر Fail، Blocked یا Not Run هستند.

علت سیستمی

عدد ساده برای گزارش مدیریتی جذاب است، اما زمینه تصمیم حذف می‌شود. مجموعه تست نیز ممکن است با محصول همگام نباشد.

اصلاح

کنار Pass Rate، Scope، Build، نتیجه‌های نامعتبر، ریسک وزن‌دار، نقص‌های باز، تغییرهای تست‌نشده و اطمینان تیم را بنویسید. نتیجه باید یک Recommendation مشروط بسازد: Release، Release محدود، توقف یا پذیرش ریسک.

Guardrail: سبزشدن تست‌های کم‌خطر نباید Fail مسیر پرداخت را رقیق کند.

۱۰. Bug report و Triage به گلوگاه تبدیل می‌شوند

نشانه

Ticketهای Duplicate و بدون Build زیادند، Severity برای فشار دادن Priority بالا می‌رود، نقص روزها بدون مالک می‌ماند.

علت سیستمی

تعریف مشترک اثر، فوریت، شواهد حداقلی و Workflow وجود ندارد. تیم‌ها از Tracker به‌عنوان محل پرتاب کار استفاده می‌کنند.

اصلاح

• Severity را به اثر و دامنه شکست وصل کنید.
• Priority را به فوریت و ترتیب رسیدگی در زمینه Release وصل کنید.
• Triage را با نقش تصمیم، SLA و مسیر اختلاف تعریف کنید.
• Duplicate را به Canonical issue لینک و شواهد تازه را حفظ کنید.
• Defect aging و زمان تا Triage را بر اساس شدت ببینید.

Stateها و مسئولیت‌ها در چرخه عمر باگ به‌صورت عملی آمده‌اند.

Guardrail: کرش همیشه Priority بالا ندارد و غلط متن همیشه Priority پایین ندارد؛ زمان و زمینه کسب‌وکار تصمیم را عوض می‌کند.

۱۱. ریسک‌های غیرکارکردی به روز آخر موکول می‌شوند

نشانه

Feature از نظر Function درست است، اما کند، ناامن، دسترس‌ناپذیر یا در شبکه ضعیف غیرقابل‌استفاده است. تست بار یا اسکن امنیتی درست قبل Release درخواست می‌شود.

علت سیستمی

ویژگی‌های کیفی به جمله‌هایی مانند «سریع و امن باشد» محدود شده‌اند؛ NFR قابل‌اندازه‌گیری، Threat model و محیط نماینده وجود ندارد.

اصلاح

• NFR را با Metric، Scope، Load، Percentile و Threshold بنویسید.
• امنیت، دسترس‌پذیری، بازیابی و Privacy را در طراحی وارد کنید.
• تست بار و امنیت را فقط با مجوز، سقف و شرط توقف انجام دهید.
• برای شبکه و Deviceهای واقعی کاربران ایرانی Scenario بسازید.

راهنمای تست غیرکارکردی روش تبدیل صفت کیفی به الزام قابل‌آزمون را نشان می‌دهد.

Guardrail: ابزار اسکن یا عدد میانگین جای متخصص، Threat model و p95/p99 را نمی‌گیرد.

۱۲. متریک‌ها افراد را تنبیه می‌کنند و یادگیری متوقف می‌شود

نشانه

تستر با تعداد Bug، توسعه‌دهنده با تعداد Defect یا تیم با درصد Pass رتبه‌بندی می‌شود. افراد برای خوب‌ماندن عدد، Scope را تغییر می‌دهند یا مسئله را دیر گزارش می‌کنند.

علت سیستمی

Metric فعالیت به هدف تبدیل شده است. Outcome، Flow، Coverage و سلامت سیستم کنار هم دیده نمی‌شوند و Incident فقط به یافتن مقصر ختم می‌شود.

اصلاح

• متریک را به سؤال و تصمیم وصل کنید.
• Outcome مشتری، Risk coverage، Feedback time و Flaky/Blocked را متوازن ببینید.
• از Post-incident review بدون سرزنش، اقدام دارای مالک و پیگیری اثربخشی استفاده کنید.
• تغییر تعریف و Data quality را روی نمودار ثبت کنید.

مدل ۱۲شاخصی و دام‌های Goodhart در راهنمای متریک‌های تست نرم‌افزار توضیح داده شده است.

Guardrail: «بدون سرزنش» به معنی بدون مسئولیت نیست؛ مالک اقدام، موعد و بازبینی باید روشن باشند.

مثال عملی: اصلاح فرایند پرداخت فروشگاه

تیم فروشگاه با سه علامت روبه‌رو است: ۹۶٪ Pass، هفت درصد Flaky و دو Incident callback تکراری. به‌جای هدف «افزایش Pass به ۹۹٪»، این زنجیره را اجرا می‌کند:

1. تعریف ریسک: Order نباید با callback تکراری دوباره اثر مالی بگیرد.
2. Testability: Correlation ID و Stub کنترل‌شده درگاه اضافه می‌شود.
3. لایه مناسب: Idempotency در Component/API، یک Journey در UI.
4. داده: callbackهای موفق، دیررس، تکراری و با مبلغ ناهماهنگ ساخته می‌شوند.
5. Signal: Fail بدون Rerun پنهان ثبت و علت دسته‌بندی می‌شود.
6. Release evidence: پوشش حالت، p95 بازخورد، Flaky و ریسک باقی‌مانده گزارش می‌شوند.

قبل	تغییر	پس از دو Sprint	تفسیر
UI suite طولانی	Rule به API/Component منتقل شد	p95 بازخورد کمتر	سرعت با حفظ Journey حیاتی
۷٪ Flaky	Clock/Stub و مالک Quarantine	۳٪	بهبود، اما صفر ادعا نشده
Callback تکراری بدون تست	State/Idempotency model	پوشش معتبر	ریسک شناخته‌شده کنترل شد
Pass Rate تنها	Outcome + coverage + health	گزارش تصمیم‌محور	شفافیت بیشتر، نه فقط عدد بهتر

اعداد باید از خط مبنای همان تیم بیایند؛ این جدول Benchmark عمومی نیست.

برنامه ۳۰روزه برای اصلاح فرایند تست

هفته اول: مشاهده بدون تغییر KPI

• پنج Release/Build اخیر را نمونه‌برداری کنید.
• زمان انتظار، Fail category، Blocked و Incident را ثبت کنید.
• سه تصمیمی را که داده ناکافی داشتند مشخص کنید.

هفته دوم: یک الگوی شکست و قرارداد داده

• فقط یک یا دو Anti-pattern پرهزینه را انتخاب کنید.
• تعریف Metric، Scope، مبدأ/مقصد زمان و مالک را بنویسید.
• راه‌حل کوچک با شرط توقف طراحی کنید.

هفته سوم: آزمایش محدود

• روی یک Feature یا Pipeline اجرا کنید.
• Outcome و Guardrail را هم‌زمان اندازه بگیرید.
• اثر جانبی مانند زمان Review یا پوشش ازدست‌رفته را ثبت کنید.

هفته چهارم: تصمیم و استاندارد حداقلی

• ادامه، اصلاح یا توقف آزمایش را با شواهد انتخاب کنید.
• Runbook کوتاه و مالک نگهداری بسازید.
• درس آموخته را به Definition of Done، Template یا Pipeline برگردانید.

قواعد یک Retrospective مفید

• رویداد و Timeline را پیش از تفسیر ثبت کنید.
• به‌جای «چه کسی خطا کرد؟» بپرسید «چرا این تصمیم در آن لحظه منطقی به نظر می‌رسید؟»
• علت را با برچسب «خطای انسانی» متوقف نکنید.
• حداکثر چند اقدام کم‌تعداد، دارای مالک و موعد انتخاب کنید.
• اثربخشی اقدام را در Release بعدی بازبینی کنید.
• اگر ریسک آگاهانه پذیرفته شده، آن را به‌عنوان اشتباه بازنویسی نکنید.

چک‌لیست سلامت فرایند تست

• تست از Requirement/Design شروع و با Production learning ادامه دارد.
• Risk، Scope و Exit decision برای Release روشن‌اند.
• مدل پوشش مخرج و اهمیت مشخص دارد.
• تست در نزدیک‌ترین لایه ارزشمند اجرا می‌شود.
• اتوماسیون بر اساس ارزش بازخورد و TCO انتخاب شده است.
• Fail، Flaky، Blocked و Not Run جدا دیده می‌شوند.
• محیط، داده و Correlation برای تشخیص کافی‌اند.
• Bug workflow اثر، فوریت، مالک و SLA دارد.
• NFRها قابل‌اندازه‌گیری و زودهنگام‌اند.
• Metric برای تصمیم تیمی است، نه رتبه‌بندی فرد.
• Incident به مدل تست و اقدام قابل‌پیگیری برمی‌گردد.

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

رایج‌ترین اشتباه در تست نرم‌افزار چیست؟

یک پاسخ جهانی وجود ندارد. تست دیرهنگام، پوشش بدون ریسک و سیگنال ناپایدار الگوهای رایج‌اند. از نشانه و داده تیم خود شروع کنید؛ «مهم‌ترین» مورد، الگویی است که اکنون تصمیم یا پیامد شما را بیشتر آسیب می‌زند.

چگونه بفهمیم پوشش تست کافی است؟

کفایت به Risk و تصمیم بستگی دارد. Requirement، State، Rule، Data، Platform، Interface و Code را با مخرج روشن مدل کنید؛ سپس ریسک تست‌نشده و کیفیت Oracle را گزارش دهید. هیچ درصد عمومی برای همه پروژه‌ها وجود ندارد.

آیا اتوماسیون بیشتر همیشه فرایند را بهتر می‌کند؟

خیر. اگر تست کم‌ارزش، شکننده یا در لایه اشتباه باشد، بازخورد کندتر و پرهزینه‌تر می‌شود. فرکانس، ثبات، قابلیت تشخیص، پوشش ریسک و بار نگهداری را کنار تعداد Script ببینید.

فرق Severity و Priority چیست؟

Severity اندازه و دامنه اثر نقص است؛ Priority فوریت و ترتیب رسیدگی در زمینه کسب‌وکار و Release. تعریف و نمونه‌ها باید مشترک باشند و تصمیم اختلاف، مالک مشخص داشته باشد.

Shift-left یعنی تمام تست‌ها را زودتر اجرا کنیم؟

خیر. یعنی بازخورد مناسب را زودتر بسازیم: مرور Requirement، Static analysis و تست نزدیک کد. بعضی شواهد فقط در سیستم یکپارچه یا Production کنترل‌شده به دست می‌آیند؛ Shift-right و پایش نیز لازم‌اند.

جمع‌بندی

اشتباه‌های تست اغلب ویژگی فردی نیستند؛ نتیجه ساختار تصمیم، مشوق، معماری و جریان بازخوردند. یک فهرست ۱۲تایی را یک‌جا «پیاده» نکنید. نشانه پرهزینه را انتخاب کنید، علت را با شواهد بسنجید، یک آزمایش کوچک انجام دهید و Guardrail داشته باشید. فرایند خوب تست، باگ صفر وعده نمی‌دهد؛ ریسک و عدم‌قطعیت را زودتر و صادقانه‌تر به تصمیم تبدیل می‌کند.