۱۰ باور غلط درباره تست نرم‌افزار؛ واقعیت چیست؟

پایپ‌لاین سبز بود و ۹۶٪ تست‌ها Pass شده بودند؛ بااین‌حال، چند دقیقه پس از انتشار، سفارش بعضی کاربران دو بار ثبت شد. یک مسیر مبلغ را «ریال» و مسیر دیگر همان عدد را «تومان» تفسیر می‌کرد و Callback تکراری درگاه پرداخت نیز Idempotent نبود. تیم کمبود فعالیت نداشت؛ صدها Test Case اجرا شده بود. مشکل، چند باور غلط درباره تست نرم‌افزار بود: Pass Rate را معادل کیفیت گرفته بودند، اتوماسیون را جایگزین کاوش انسانی می‌دانستند و تصور می‌کردند هرچه لازم بوده پیش از انتشار آزمایش شده است.

افسانه‌های تست فقط جمله‌های نادرست نیستند؛ آن‌ها بودجه، مسئولیت، معیار، زمان انتشار و حتی نوع شواهدی را که تیم جمع می‌کند تغییر می‌دهند. این راهنما ده باور رایج را بدون دفاع صنفی از QA یا وعده «محصول بدون باگ» اصلاح می‌کند. هدف این است که هر شعار را به یک ادعای قابل‌آزمون، یک ریسک تصمیم و یک اقدام روشن تبدیل کنیم.

خلاصه اجرایی: تست تضمین کیفیت نیست؛ درباره کیفیت و ریسک اطلاعات تولید می‌کند. توسعه‌دهنده، تستر، محصول، امنیت و عملیات هرکدام شواهد متفاوتی می‌سازند. اتوماسیون اجرای کنترل‌های تکرارپذیر را سریع می‌کند، اما Oracle، سؤال خوب، کاوش، کاربردپذیری و پذیرش ریسک را به‌تنهایی حل نمی‌کند. نتیجه سبز فقط در Scope، نسخه، محیط، داده و زمان مشخص معنا دارد.

ده افسانه تست نرم‌افزار در یک نگاه

اول واژه‌ها را جدا کنیم: Testing، QA، QC و Debugging

بخش بزرگی از اختلاف‌ها از اینجا می‌آید که چند فعالیت متفاوت را «تست» می‌نامیم. در تعریف عملی این مقاله:

• Testing: مجموعه فعالیت‌های ایستا و پویا برای ارزیابی یک محصول یا Artifact و تولید اطلاعات درباره کیفیت و ریسک؛ از Review نیازمندی تا اجرای کد را دربر می‌گیرد.
• Quality Assurance: اطمینان‌بخشی درباره مناسب‌بودن فرایندها و توان سیستم کاری برای ساخت کیفیت؛ فقط اجرای Test Case نیست.
• Quality Control: ارزیابی خروجی و مقایسه آن با معیارهای مشخص؛ تست می‌تواند بخشی از آن باشد.
• Debugging: یافتن علت Failure/Defect و اصلاح آن؛ کشف یک Failure و تشخیص Root Cause یک کار نیستند.
• User Research و Monitoring: اولی نیاز و تجربه انسان را مطالعه می‌کند و دومی رفتار سامانه زنده را می‌سنجد. هر دو با Testing هم‌پوشانی و مرز دارند، اما جای یکدیگر را نمی‌گیرند.

سیلابس رسمی ISTQB CTFL ۴.۰.۱ نیز Testing را فراتر از اجرای پویا می‌بیند، هفت اصل تست را توضیح می‌دهد و درباره فایده و زیان استقلال تست موضعی متوازن دارد. این منبع واژگان مشترک خوبی است، اما Context پروژه و قانون/استاندارد صنعت شما همچنان تعیین‌کننده‌اند.

یک باور را چگونه آزمایش کنیم

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

1. Claim را محدود کنید: «اتوماسیون بهتر است» مبهم است؛ «اجرای خودکار ۲۰۰ Check پایدار API، بازخورد Pull Request را از سه ساعت به ۱۲ دقیقه می‌رساند» قابل‌بررسی است.
2. ضد‌مثال پیدا کنید: چه شرایطی ادعا را نقض می‌کند؟ تغییر API، Oracle ضعیف، Flakiness یا هزینه نگهداری می‌تواند سود را از بین ببرد.
3. ریسک تصمیم را بنویسید: اگر این باور غلط باشد، چه کسی و چه Outcomeی آسیب می‌بیند؟
4. کوچک‌ترین شاهد کافی را طراحی کنید: Pilot، Baseline، تست متمرکز، مرور مستقل یا Canary؛ سپس نتیجه و Unknownها را ثبت کنید.

این الگو، بحث «موافق یا مخالف تست» را به یک آزمایش اقتصادی و فنی تبدیل می‌کند.

باور غلط ۱: تست فقط هزینه و مانع سرعت است

صورت معکوس این افسانه نیز خطرناک است: «هر تستی سود دارد» یا «رفع باگ در Production همیشه دقیقاً ۱۰۰ برابر گران‌تر است». هزینه یک نقص به زمان کشف، معماری، تعداد کاربران آسیب‌دیده، قابلیت Rollback، تعهد قراردادی، داده از‌دست‌رفته و شدت پیامد بستگی دارد. یک Typo کم‌اثر با خطای محاسبه قسط یا افشای داده یکسان نیست.

گزارش مشهور NIST درباره اثر اقتصادی زیرساخت ناکافی تست یک مطالعه تاریخی مربوط به سال ۲۰۰۲، صنایع و روش‌شناسی مشخص است؛ شاهدی برای مهم‌بودن اقتصاد کیفیت است، نه مجوزی برای چسباندن ضریب ثابت «۱۰۰ برابر» به هر سازمان امروزی. اگر داده داخلی ندارید، عدد را Range و فرض را آشکار بنویسید.

جایگزین عملی: Business Case مبتنی بر Exposure

ارزش یک فعالیت تست را می‌توان به‌طور تقریبی از تفاوت Exposure پیش و پس از شواهد سنجید:

ارزش موردانتظار شواهد ≈ Exposure قبل − Exposure بعد − هزینه ساخت و نگهداری شواهد

مثال کاملاً فرضی: تیم احتمال رخداد دوباره‌پرداخت را پیش از کنترل‌ها بین ۵ تا ۱۰ درصد و زیان یک رخداد را بین ۲ تا ۴ میلیارد ریال برآورد می‌کند. Unit Test برای تبدیل واحد پول، Contract Test درگاه، تست Idempotency و Alert مصالحه مالی ۵۵ میلیون ریال هزینه دارد و احتمال برآوردی را به بازه ۱ تا ۳ درصد می‌رساند. تصمیم باید با Range، منبع فرض‌ها و بازبینی پس از Production ثبت شود؛ نه با ROI ساختگی تا دو رقم اعشار.

• پیامد مالی، حقوقی، ایمنی، اعتماد و عملیات را جدا کنید.
• هزینه فرصت تأخیر و هزینه نگهداری Suite را نیز حساب کنید.
• فعالیت کم‌قدرت را فقط به‌دلیل «قبلاً ساخته شده» نگه ندارید.
• برای انتخاب بین روش‌ها، هزینه ساخت، اجرا، نگهداری و کاهش ریسک هر گزینه را در یک بازه زمانی یکسان مقایسه کنید.

باور غلط ۲: هدف تست فقط پیدا کردن باگ است

Bug یک خروجی ممکن است، نه تنها ارزش تست. Review یک Acceptance Criterion مبهم می‌تواند پیش از نوشته‌شدن کد از چند تفسیر ناسازگار جلوگیری کند. یک تست موفق ممکن است شواهدی درباره انطباق با یک Rule کسب‌وکار بدهد. یک آزمایش عملکرد ممکن است حد ظرفیت را آشکار کند؛ حتی اگر Defect مشخصی ثبت نشود. یک Session اکتشافی نیز می‌تواند Unknownهای مهم را به سؤال قابل‌پیگیری تبدیل کند.

تست خوب می‌تواند به این تصمیم‌ها خدمت کند:

• آیا Requirement قابل‌فهم، سازگار و Testable است؟
• کدام ریسک هنوز شاهد کافی ندارد؟
• آیا Build در محدوده تعریف‌شده قابل انتشار است؟
• در صورت انتشار، چه Guardrail، Canary یا Rollback لازم است؟
• پس از Incident چه Regression و کنترل پیشگیرانه‌ای باید اضافه شود؟

جایگزین عملی: هر تست با یک سؤال و تصمیم

روی Test Plan یک ستون «Decision» اضافه کنید. به‌جای «تست صفحه پرداخت»، بنویسید: «آیا نسخه ۲.۱۴ در برابر Callback تکراری PSP، دقیقاً یک سفارش و یک ثبت دفترکل می‌سازد؟ اگر نه، انتشار Block می‌شود.» اکنون Scope، Oracle و اقدام Failure روشن‌اند. تعداد باگ، بدون چنین نسبتی با تصمیم، معیار ارزش نیست.

باور غلط ۳: هرکسی می‌تواند تست کند؛ یا فقط تستر باید تست کند

هر عضو تیم و حتی کاربر می‌تواند Failure ارزشمندی مشاهده کند. اما مشاهده اتفاقی با طراحی آزمایش منظم یکسان نیست. تست حرفه‌ای به مدل‌سازی ریسک، تکنیک‌های طراحی، شناخت Domain، ساخت Oracle، تحلیل داده، کنترل محیط، مستندسازی بازتولیدپذیر و ارتباط اثر کسب‌وکار نیاز دارد. از سوی دیگر، تبدیل «تستر متخصص است» به «هیچ‌کس جز QA حق تست ندارد» دانش را حبس و بازخورد را کند می‌کند.

مسئله «چه عنوان شغلی‌ای تست کند؟» نیست؛ مسئله این است که برای سؤال موردنظر چه مهارت، استقلال و اختیار تصمیمی لازم است.

باور غلط ۴: توسعه‌دهنده نمی‌تواند کد خود را تست کند و QA مالک کیفیت است

توسعه‌دهنده نزدیک‌ترین فرد به Design و سریع‌ترین سازنده شواهد در سطح Unit و Component است. حذف او از Testing، Feedback را دیر و کد را سخت‌آزمایی می‌کند. در مقابل، نویسنده ممکن است همان فرضی را در کد و تست تکرار کند؛ به همین دلیل Peer Review، Contract Test، دیدگاه محصول، تستر یا متخصص مستقل در ریسک‌های مناسب ارزش دارد.

ISTQB برای استقلال، هم فایده و هم هزینه بیان می‌کند: نگاه متفاوت می‌تواند فرض‌ها را به چالش بکشد، اما جدایی زیاد ممکن است Silo، انتقال مسئولیت یا گلوگاه بسازد. همچنین راهنمای Test Automation در DORA بر مالکیت توسعه‌دهندگان نسبت به Suiteهای سریع و همکاری تستر در سراسر Delivery تأکید دارد؛ نه تحویل کد به یک تیم کنترل کیفیت در انتهای خط.

طیف استقلال به‌جای دیوار Dev و QA

1. Self-check: نویسنده، کد و فرض‌های محلی را سریع بررسی می‌کند.
2. Peer challenge: همکار دیگر Example، Test و Change را مرور می‌کند.
3. Cross-discipline evidence: محصول، QA، امنیت، داده یا عملیات ریسک‌های تخصصی را می‌آزمایند.
4. Independent assessment: در ریسک‌های قانونی، ایمنی، مالی یا تعارض منافع، ارزیاب مستقل وارد می‌شود.

هرچه پیامد Failure، ابهام و تعارض منافع بیشتر باشد، استقلال بالاتر توجیه بیشتری دارد. بااین‌حال مسئولیت ساخت کیفیت بین نقش‌ها توزیع می‌شود و مسئول پذیرش ریسک باید نام‌دار بماند. مدل مالکیت همگانی کیفیت بدون ابهام این مرزها را عملی می‌کند.

باور غلط ۵: اتوماسیون می‌تواند جای تمام فعالیت‌های انسانی را بگیرد

ابزار می‌تواند ورودی بدهد، سامانه را تحریک کند، Outcome را با Oracle تعریف‌شده مقایسه و نتیجه را ثبت کند. اما خودش تعیین نمی‌کند کدام نیاز انسانی مهم است، آیا Requirement درست فهمیده شده، چه رفتار تازه‌ای مشکوک است یا یک Trade-off برای کسب‌وکار پذیرفتنی است. حتی تست تولیدشده خودکار، اگر همان منطق اشتباه محصول را در Assertion کپی کند، با سرعت بالا اطمینان کاذب می‌سازد.

برای تصمیم اقتصادی و معماری، مقایسه تست دستی و خودکار را ببینید؛ برای یادگیری ساختاریافته از رفتار تازه، راهنمای تست اکتشافی Session-Based و برای محدودیت ابزارها در WCAG، راهنمای تست دسترس‌پذیری مرز دقیق‌تری می‌دهند.

باور غلط ۶: عدد بیشتر یعنی کیفیت بیشتر

هزار Test Case، Coverage ۹۰٪، صد Bug یا Pass Rate ۹۸٪ به‌تنهایی نمی‌گویند محصول برای چه کسی و چه استفاده‌ای مناسب است. تیم می‌تواند با خردکردن یک سناریو تعداد Case را بالا ببرد، با Assertهای ضعیف Coverage کد بگیرد، با ثبت Duplicate تعداد Bug بسازد یا با حذف تست‌های سخت Pass Rate را سبز کند. وقتی شاخص هدف شود، رفتار بهینه‌سازی‌شده ممکن است از Outcome واقعی جدا شود.

جایگزین عملی: سبد سیگنال با Guardrail

یک تصمیم انتشار را با سیگنال‌های مستقل بسازید: Outcome مشتری، ریسک‌های بحرانی، Coverage شواهد، سلامت Suite، Failureهای First-run، Unknownها، وضعیت Production و قابلیت Rollback. تعریف و فرمول را نسخه‌دار کنید و هر شاخص را با ضدشاخصی همراه سازید. برای نمونه، کوتاه‌شدن زمان Suite بدون افزایش Flakiness یا کاهش Risk Coverage خوب است. راهنمای ۱۲ متریک تست نرم‌افزار تعریف‌های ضد‌بازی را ارائه می‌کند و راهنمای داشبورد گزارش تست نشان می‌دهد این داده چگونه به اقدام متصل شود.

باور غلط ۷: تست می‌تواند محصول بدون باگ را تضمین کند

فضای ترکیب ورودی، State، زمان، دستگاه، مجوز، شبکه، داده و Dependency در اغلب سامانه‌ها آن‌قدر بزرگ است که Exhaustive Testing عملی نیست. عبور از مجموعه‌ای از تست‌ها فقط می‌گوید در نسخه، محیط، داده و Oracle ثبت‌شده Failure موردنظر مشاهده نشد. حتی این جمله نیز با Flakiness، داده ناکافی یا Assertion ضعیف محدود می‌شود.

دو اصل باید کنار هم دیده شوند:

• Testing حضور Failure را نشان می‌دهد، نه نبود همه Defectها را. Passed evidence عدم‌قطعیت را کم می‌کند، اما اثبات کامل نیست.
• Absence-of-errors fallacy: محصولی که Specification را دقیق اجرا می‌کند، اگر نیاز کاربر یا هدف کسب‌وکار را حل نکند همچنان ناموفق است.

جایگزین عملی: Stop Criteria و Residual Risk

به‌جای «صفر باگ»، معیار توقف را پیشاپیش تعریف کنید: ریسک‌های Blocker، حد Evidence برای سناریوهای بحرانی، وضعیت Defectهای باز، Unknownهای پذیرفته‌شده، SLO/Canary، Rollback آزمایش‌شده و نام پذیرنده ریسک. راهنمای تست مبتنی بر ریسک شدت شواهد را به پیامد Failure وصل می‌کند و چارچوب کیفیت به‌اندازه کافی خوب تصمیم کفایت را از ادعای کمال جدا می‌سازد.

باور غلط ۸: تست یک مرحله در انتهای پروژه است؛ یا Shift Left همه‌چیز را حل می‌کند

کشف ابهام و Defect زودتر معمولاً Feedback را ارزان‌تر و اصلاح را محلی‌تر می‌کند، اما همه سؤال‌ها را نمی‌توان پیش از Deployment پاسخ داد. رفتار زیر بار واقعی، تنظیم Production، تعامل Dependency، الگوی کاربران و Failureهای ناشناخته فقط با شواهد سمت راست چرخه روشن می‌شوند. در نتیجه Shift Left یک حرکت مفید است، نه مقصد نهایی.

راهنمای رسمی Microsoft درباره Shift Right توضیح می‌دهد که بعضی کلاس‌های ارزیابی بدون استقرار کامل یا جزئی قابل‌اجرا نیستند. Production Testing باید Blast Radius، مجوز، داده امن، Kill Switch و Observability داشته باشد و هرگز بهانه حذف کنترل‌های پیش از انتشار نشود. OWASP Web Security Testing Guide نیز امنیت را در تعریف، طراحی، توسعه، استقرار و عملیات توزیع می‌کند؛ Pen Test آخر پروژه یک برنامه امنیتی کامل نیست.

باور غلط ۹: پروژه کوچک یا تغییر کوچک به تست نیاز ندارد

اندازه Repository یا تعداد خطوط Change، پیامد شکست را تعیین نمی‌کند. یک تغییر یک‌خطی در تبدیل تومان/ریال، سطح دسترسی، Timeout یا شرط حذف داده می‌تواند Blast Radius بزرگی داشته باشد. برعکس، یک Prototype دورریختنی بدون داده واقعی ممکن است به Evidence بسیار سبک‌تری نیاز داشته باشد. سؤال درست «پروژه چند نفر است؟» نیست؛ «اگر این تغییر اشتباه باشد، چه می‌شود و برگشت چقدر آسان است؟» است.

حداقل بسته شواهد برای تیم کوچک

• سه تا پنج Journey حیاتی و Failure قابل‌مشاهده آن‌ها؛
• Boundaryهای پول، زمان، مجوز، State و داده؛
• یک Smoke خودکار برای Build/Deploy و مسیر اصلی؛
• Review یک نفر دیگر برای Changeهای پرپیامد؛
• Backup/Restore یا Rollback واقعاً آزمایش‌شده؛
• Log و Alert حداقلی با مالک پاسخ؛
• ثبت صریح ریسک‌هایی که فعلاً پذیرفته شده‌اند.

عمق این بسته با Exposure تغییر می‌کند. اپلیکیشن یادداشت شخصی، سامانه نسخه پزشکی و سرویس انتقال وجه، حتی با کد هم‌اندازه، به شواهد یکسان نیاز ندارند.

باور غلط ۱۰: هوش مصنوعی جای تستر را می‌گیرد و کیفیت را تأیید می‌کند

مدل زبانی می‌تواند از Requirement پیش‌نویس Example بسازد، Test Code اولیه تولید کند، Logها را خوشه‌بندی کند، داده مصنوعی پیشنهاد دهد یا Hypothesisهای بیشتری به تستر نشان دهد. این توانمندی‌ها بهره‌وری بالقوه‌اند؛ اما خروجی مدل ممکن است Requirement مبهم را با اعتماد بالا تکرار کند، API غیرواقعی بسازد، Assertion کم‌قدرت بنویسد، داده حساس را افشا کند یا همان Bias ورودی را گسترش دهد.

AI نه کاربر واقعی است، نه مالک Risk، نه Oracle مستقل و نه پذیرنده مسئولیت انتشار. حتی Agentی که Browser را کنترل می‌کند ممکن است فقط مسیر Happy را با داده نامعتبر «موفق» اعلام کند.

Guardrail استفاده از AI در تست

1. Use Case و ممنوعیت داده را مشخص کنید؛ Secret، PII و کد محدودشده را بدون مجوز ارسال نکنید.
2. مدل، نسخه، Prompt/Context و زمان تولید Artifact را ثبت کنید.
3. خروجی را Candidate بدانید و با Requirement، Contract یا مشاهده مستقل بسنجید.
4. Test Code تولیدشده را مثل Production Code Review، Lint و اجرا کنید.
5. قدرت Oracle را با Mutation، Negative case یا Bug تاریخی آزمایش کنید.
6. نرخ پذیرش، ویرایش، Defect escaped و زمان خالص صرفه‌جویی را بسنجید؛ تعداد Test تولیدشده KPI نیست.
7. برای تصمیم پرریسک Human Sign-off و مسیر اعتراض/توقف نگه دارید.

چارچوب مدیریت ریسک هوش مصنوعی NIST زبان مناسبی برای Govern، Map، Measure و Manage کردن این ریسک‌ها می‌دهد. استفاده از AI باید یک سیستم اجتماعی-فنی قابل‌پایش باشد، نه خرید ابزار و فرض خودکار «هوشمندترشدن کیفیت».

به‌جای یک عدد سبز، Portfolio شواهد بسازید

هیچ سطحی به‌تنهایی کافی نیست. Unit Test سریع ممکن است Contract واقعی را نبیند؛ E2E رفتار واقعی‌تر دارد اما کندتر، شکننده‌تر و سخت‌تر برای تشخیص است؛ Monitoring با داده واقعی کار می‌کند ولی پس از Exposure کاربر. تجربه منتشرشده در Google Testing Blog درباره E2E-heavy strategy نشان می‌دهد وابستگی زیاد به تست‌های بزرگ Feedback و تشخیص را تضعیف می‌کند. نسبت ثابت ۷۰/۲۰/۱۰ را قانون عمومی نگیرید؛ مرز Test Size و Dependency را از معماری خود استخراج کنید.

فصل Testing for Reliability در Google SRE نیز تمایز مهمی دارد: Passing، Reliability را اثبات نمی‌کند؛ تست سنتی و ارزیابی Production هرکدام بخشی از عدم‌قطعیت را کاهش می‌دهند. Portfolio خوب هم Evidence پیشگیرانه دارد، هم آشکارساز سریع و هم پاسخ مهندسی‌شده.

مثال ایرانی: افسانه‌ها چگونه یک انتشار پرداخت را منحرف می‌کنند

سناریوی زیر آموزشی و ساختگی است، اما محدودیت‌های آن از الگوهای رایج سامانه‌های ایرانی گرفته شده است. یک فروشگاه قرار است Checkout جدید را با دو PSP منتشر کند. مدیر می‌گوید «۹۶٪ تست‌ها Pass شده، پس آماده‌ایم»؛ توسعه‌دهنده می‌گوید «Unit Testها سبزند»؛ QA می‌گوید «همه سناریوهای سند اجرا شده» و تیم اتوماسیون می‌گوید «پوشش E2E به ۸۵٪ رسیده است».

ابتدا Context را قابل‌بازتولید کنید

• Commit و Build: نسخه دقیق Frontend، Backend و Migration؛
• Environment: تنظیم PSP، Feature Flag، Cache، Queue و Timezone؛
• داده: کاربر، سبد، واحد پول، Coupon، موجودی و State سفارش؛
• Run identity: اولین Attempt، Retry، زمان UTC و نمایش Asia/Tehran؛
• Dependency mode: Sandbox واقعی، Stub کنترل‌شده یا سرویس Live؛
• قواعد: مبلغ Canonical بر حسب ریال، نمایش تومان، Round و حداقل/حداکثر؛
• نسخه Contract: Request، Callback، Signature و Error mapping هر PSP.

بدون این Context، «Pass» بین اجراها قابل‌مقایسه نیست.

ریسک‌ها را به شاهد تبدیل کنید

نتیجه تصمیم فرضی

پس از اجرای شواهد، تیم دو Failure بحرانی پیدا می‌کند: Callback تکراری یک رکورد دوم می‌سازد و تبدیل مبلغ در Import قدیمی واحد را از Metadata نمی‌خواند. درصد Pass کل فقط از ۹۶ به ۹۴ تغییر می‌کند، اما Release Readiness به‌درستی از «مجاز» به «Block» می‌رود؛ زیرا دو Risk با Impact بالا فاقد شاهد کافی‌اند. پس از Fix، Regression، Reconciliation، Canary پنج‌درصدی، Alert اختلاف Ledger و Rollback آزمایش‌شده، مالک انتشار اجازه Rollout مرحله‌ای می‌دهد. این تصمیم از یک درصد ساخته نشده؛ از Trace ریسک تا شاهد و اقدام ساخته شده است.

فرم قابل‌کپی برای تبدیل افسانه به تصمیم

این قالب کوتاه را در Ticket، Test Plan یا جلسه Release Review قرار دهید:

اگر جلسه‌ای فقط «سبز/قرمز» گزارش می‌دهد و این فیلدها را ندارد، احتمالاً یک افسانه را به Dashboard منتقل کرده‌اید.

ده پرسش برای تشخیص افسانه در جلسه تیم

1. این جمله یک Fact است، Hypothesis است یا ترجیح؟
2. کدام نسخه، محیط، داده و بازه زمانی را توصیف می‌کند؟
3. مخرج عدد چیست و چه وضعیت‌هایی از آن حذف شده‌اند؟
4. چه ضد‌مثالی ادعا را رد می‌کند؟ آیا آن را آزمایش کرده‌ایم؟
5. Oracle از Requirement مستقل است یا همان منطق کد را تکرار می‌کند؟
6. کدام ریسک/کاربر/Outcome از این شاهد پشتیبانی می‌گیرد؟
7. چه Unknown، Blocked، Skipped یا Quarantinedی پنهان مانده است؟
8. اگر نتیجه Failure شود، مالک و اقدام مشخص است؟
9. چه کسی اختیار پذیرش Residual Risk را دارد و حدود آن چیست؟
10. پس از Production چگونه می‌فهمیم فرض ما درست یا غلط بوده است؟

برنامه ۳۰روزه برای حذف افسانه‌های پرهزینه

هفته اول: زبان و تصمیم

• سه جلسه اخیر را مرور و جمله‌های مطلق مانند «همه»، «تضمین»، «صددرصد» و «هرگز» را استخراج کنید.
• Testing، QA، QC، Debugging، Verification، Validation و Monitoring را در یک Glossary یک‌صفحه‌ای تعریف کنید.
• برای یک Release واقعی، Decision، Risk owner و Evidence owner را نام‌گذاری کنید.

هفته دوم: داده و شواهد

• Pass Rate، Coverage و Bug count را با مخرج، Scope، First-run و Unknown بازتعریف کنید.
• یک Risk بحرانی را از Requirement تا Unit/Contract/E2E/Production trace کنید.
• یک تست کم‌ارزش یا Duplicate را حذف و دلیل را ثبت کنید.

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

• توسعه‌دهنده و تستر یک Example workshop و یک Session اکتشافی Pair اجرا کنند.
• یکی از ادعاهای Automation/AI را با Baseline زمان، کیفیت و نگهداری Pilot کنید.
• برای یک ریسک مهم، سطح استقلال مناسب را انتخاب و هزینه/فایده‌اش را بازبینی کنید.

هفته چهارم: انتشار و یادگیری

• یک Release Review را با فرم Claim→Risk→Evidence→Decision اجرا کنید.
• Canary، Alert، Kill Switch یا Rollback را Drill کنید؛ وجود سند، معادل قابلیت عملی نیست.
• نتیجه Production را با فرض‌های هفته اول مقایسه و یک Myth/Policy را اصلاح کنید.

Anti-patternهایی که افسانه را زنده نگه می‌دارند

• استفاده از ضریب ۱۰۰برابر یا درصد ROI بدون منبع و Context؛
• رتبه‌بندی تستر با تعداد Bug و تیم اتوماسیون با تعداد Script؛
• اعلام ۱۰۰٪ Coverage بدون تعریف Dimension و Exclusion؛
• تفسیر Retry-pass به‌عنوان Pass عادی و حذف First Attempt؛
• واگذاری کیفیت به QA و حفظ اختیار انتشار در جایی دیگر؛
• ساخت E2E برای هر Rule و نادیده‌گرفتن Unit/Contract؛
• Automate کردن فرایند ناپایدار پیش از فهم رفتار؛
• یکی‌گرفتن Usability Testing با نظر شخصی اعضای تیم؛
• اجرای Pen Test یا Performance Test فقط شب انتشار؛
• Shift Right بدون Limit، Consent، Observability و Rollback؛
• پذیرش Test تولیدشده با AI بدون Review و اجرای مستقل؛
• پنهان‌کردن Unknown و Blocked برای سبز نگه‌داشتن Dashboard؛
• نوشتن «همه سناریوها تست شد» بدون Model فضای ورودی/State؛
• تبدیل اصل تست به قانون ثابت بدون توجه به محصول و ریسک؛
• Postmortemی که فقط «تست بیشتری بنویسید» را Action item می‌کند.

چک‌لیست کیفیت تصمیم تست

• □ سؤال و Decision هر فعالیت تست مشخص است.
• □ Risk و Outcome کاربر/کسب‌وکار به Evidence متصل است.
• □ Build، محیط، داده، زمان و Attempt ثبت شده‌اند.
• □ Oracle و معیار Failure صریح و تا حد ممکن مستقل‌اند.
• □ Pass، Failed، Blocked، Untested، Skipped و Unknown حفظ شده‌اند.
• □ اتوماسیون بر اساس تکرارپذیری، Feedback و هزینه نگهداری انتخاب شده است.
• □ فعالیت انسانی Charter، Scope و Artifact قابل‌مرور دارد.
• □ سطح استقلال با پیامد و تعارض منافع متناسب است.
• □ هیچ عددی بدون مخرج، Scope و Guardrail گزارش نمی‌شود.
• □ Residual Risk، پذیرنده نام‌دار و Expiry/حدود دارد.
• □ Production feedback و Rollback بخشی از Strategy هستند.
• □ خروجی AI با منبع حقیقت مستقل ارزیابی و داده حساس محافظت شده است.

سؤالات متداول درباره باورهای غلط تست نرم‌افزار

آیا تست نرم‌افزار واقعاً برای هر پروژه‌ای لازم است؟

هر تصمیم ساخت و تغییر به مقداری Evidence نیاز دارد، اما شکل و عمق آن ثابت نیست. Prototype دورریختنی ممکن است با Review و Smoke سبک کافی باشد؛ سامانه مالی یا پزشکی به استقلال، Traceability و شواهد بسیار سخت‌گیرانه‌تر نیاز دارد. معیار، ریسک، پیامد، برگشت‌پذیری و تعهد است؛ نه اندازه تیم.

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

بله؛ Self-test و Unit/Component Test مسئولیت مهم توسعه‌دهنده‌اند. اما ممکن است همان فرض در Implementation و Test تکرار شود. Peer، QA، محصول، امنیت یا ارزیاب مستقل بر اساس ریسک دیدگاه تکمیلی می‌دهند. استقلال یک طیف است و جای مالکیت توسعه‌دهنده را نمی‌گیرد.

آیا اتوماسیون جای تست دستی را می‌گیرد؟

خیر؛ ضمن اینکه «دستی» دسته دقیقی برای همه فعالیت‌های انسانی نیست. اتوماسیون Checkهای تعریف‌شده و تکرارپذیر را سریع می‌کند. کاوش، Usability، تفسیر، مذاکره Requirement و پذیرش Risk همچنان قضاوت می‌خواهند. انتخاب باید بر اساس ریسک، Feedback، ثبات و هزینه نگهداری باشد.

آیا ۱۰۰٪ پوشش تست یعنی نرم‌افزار بدون باگ است؟

خیر. نخست باید معلوم شود Coverage کد، Requirement، Risk، داده، State یا Platform است. حتی ۱۰۰٪ Line Coverage قدرت Assertion، ترکیب Stateها و درستی نیاز کاربر را ثابت نمی‌کند. Coverage نقشه جاهای دیده‌شده است، نه گواه نبود نقص.

آیا هوش مصنوعی در آینده تستر را حذف می‌کند؟

AI احتمالاً بخش‌های بیشتری از تولید و اجرای Artifact را خودکار می‌کند، اما سؤال درست، مدل ریسک، Oracle معتبر، فهم کاربر، تصمیم اخلاقی/حقوقی و مسئولیت انتشار را خودکارانه تضمین نمی‌کند. نقش‌ها تغییر می‌کنند؛ خروجی مدل نیز مانند هر Dependency پرقدرت به Governance، ارزیابی و پایش نیاز دارد.

جمع‌بندی: از شعار به شاهد و تصمیم

افسانه‌زدایی موفق با اثبات «تستر مهم است» تمام نمی‌شود. تیم بالغ می‌پرسد: چه ادعایی داریم، برای کدام تصمیم، با چه ریسکی، در چه Contextی و با کدام Evidence؟ سپس Unknownها، مالک اقدام و پذیرنده Risk را آشکار می‌کند. این رویکرد هم از تست نمایشی و اتوماسیون بی‌هدف جلوگیری می‌کند، هم کیفیت را از دوش یک نقش برمی‌دارد و به مسئولیت‌های روشن در سراسر چرخه تبدیل می‌سازد.