اگر امروز برای گسترش مجموعه‌ی تست‌های خود به هوش مصنوعی تکیه کرده‌اید، احتمالاً در حال ساختن یک بدهی فنی هستید که در لباس یک دارایی ظاهر شده است. یک شرکت SaaS در توکیو در اوایل سال ۲۰۲۶ این حقیقت تلخ را تجربه کرد: یک جریان پرداخت به مدت ۷۲ ساعت به‌طور کامل مختل شد، در حالی که تمام خط لوله‌ی CI/CD چراغ سبز نشان می‌داد. طبق گزارش‌های منتشر شده، مدیر QA این شرکت از تعداد تست‌ها رضایت داشت و مدیریت به وجد آمده بود، اما واقعیت تکان‌دهنده این بود که هوش مصنوعی تست‌هایی نوشته بود که فقط «عدم وقوع خطا» را بررسی می‌کردند، نه اینکه «داده‌های درست ذخیره شده‌اند یا خیر».
این شکست، بحرانی رو به رشد به نام کوریِ آزمون (Testing Blindness) را برجسته می‌کند. این وضعیت زمانی رخ می‌دهد که تیم‌ها حجم عظیمی از پوشش تست را تولید می‌کنند، اما توانایی ارزیابی اینکه آیا این تست‌ها واقعاً باگ‌ها را می‌گیرند یا خیر، از دست می‌دهند. در تجربه شخصی من با یک دستگاه M2 Max و ۳۲ گیگابایت رم در محیط تست محلی، دیده‌ام تیم‌هایی که در سه ماه تنها با ابزارهای AI، از «صفر تست» به «۱۲۰۰ تست» رسیدند. هرچند گزارش پوشش تست خیره‌کننده بود، اما نرخ شناسایی نقص‌ها بدتر از قبل شد؛ چون تیم تصور می‌کرد اتوماسیون همه چیز را مدیریت می‌کند.
زمینه فرهنگی کوریِ آزمون
در ژاپن، این موضوع با فرهنگ کانری (Kanri) — یا همان مدیریت سیستماتیک که بر مستندات، رعایت دقیق فرآیندها و کنترل سیستماتیک تأکید دارد — تشدید می‌شود. وزن سازمانی داده شده به متریک‌ها به این معناست که جمله‌ای مثل «هوش مصنوعی ۱۲۰۰ تست تولید کرد» وزن بسیار زیادی دارد. در این حالت، عدد به هدف تبدیل می‌شود و تأیید کیفیت در اولویت دوم پس از رعایت فرآیندها قرار می‌گیرد.
این رویکرد با تیم‌های غربی متفاوت است؛ جایی که توسعه‌دهندگان غربی مدل متفاوتی از شکست را تجربه می‌کنند. آن‌ها بیشتر تمایل دارند وقتی AI تست‌نویسی را «ساده» می‌کند، کلاً تست‌ها را رها کنند. در مقابل، تیم‌های ژاپنی تست‌ها را بدون اینکه بپرسند آیا این تست‌ها چیزی واقعی را می‌سنجند یا خیر، انباشته می‌کنند. هر دو مسیر در نهایت به حوادث ناگوار در محیط عملیاتی ختم می‌شوند.
مکانیسم‌های فنی کوریِ آزمون
کوریِ آزمون از طریق سه شکست فنی خاص رخ می‌دهد:
- آتروفیِ ادعاهای تست (Assertion Atrophy): هوش مصنوعی تست‌هایی می‌نویسد که بررسی می‌کنند «هیچ‌چیز کرش نکند»، به جای اینکه تأیید کنند «رفتار درست رخ داده است». در بازبینی کد، این موضوع مشهود است، اما وقتی ۲۰۰ تست تولیدی توسط AI وجود دارد که باید بررسی شوند، هیچ‌کس با دقت به جزئیات نگاه نمی‌کند.
- کوری نسبت به موارد مرزی (Boundary Case Blindness): تست‌های تولید شده توسط AI دور محور «مسیرهای خوش‌بینانه» (Happy Paths) می‌چرخند. آن‌ها در مواجهه با موارد خاص — مثل ورودی‌های تهی (Null)، شرایط رقابتی (Race Conditions) یا وضعیت‌های سرریز (Overflow) — که نیازمند دانش تخصصی دامنه (Domain Knowledge) هستند و در داده‌های آموزشی AI یافت نمی‌شوند، شکست می‌خورند.
- تورم اعتماد به رگرسیون: وقتی تعداد تست‌ها دو برابر می‌شود، تیم‌ها احساس می‌کنند دو برابر امن هستند. اما اگر ادعاهای تست سطحی باشند، این حس امنیت کاذب ایجاد می‌شود که در واقع نرخ شناسایی نقص‌ها را کاهش می‌دهد.
هزینه پنهانِ بهره‌وری
تجربه یک مهندس QA که در Qiita (بزرگ‌ترین انجمن توسعه‌دهندگان ژاپن) در پستی با عنوان «حل مشکل نبودِ هدفِ تست با AI — سفر یک مهندس QA در Playwright، تست API و CI/CD» به اشتراک گذاشته شد، این تله را به تصویر می‌کشد. نویسنده در پروژه‌ای بود که تست‌های دستی در آن غالب بود و اتوماسیون وجود نداشت و با فشار فزاینده‌ای برای «استفاده از AI» مواجه بود.
در حالی که AI سریعاً تست‌کیس‌ها را تولید کرد و متریک‌ها بهبود یافتند، نویسنده به یک حقیقت حیاتی اعتراف کرد: او مجبور شد ۴ تا ۶ هفته زمان صرف یادگیری دستی Playwright، تست‌های API و مبانی CI/CD کند تا حفره‌هایی را که AI باقی گذاشته بود، پر کند. او اشاره کرد: «AI می‌توانست سینتکس را بنویسد. اما درک اینکه چه چیزی باید تست شود، نیازمند فهم نحوه کارکرد سیستم بود — و این دانش فقط از طریق دیباگینگ عملی به دست می‌آمد».
این وضعیت یک بدهی فنی خاص ایجاد می‌کند. به ازای هر ۱ ساعت صرفه‌جویی در تولید توسط AI، مهندسان ممکن است ۳ تا ۴ ساعت برای تأیید تست‌ها هزینه کنند، آن هم زمانی که یک حادثه در محیط عملیاتی، نقطه کور را آشکار کند. در آن بازه ۴ تا ۶ هفته‌ای یادگیری، مجموعه تست‌ها به جای دارایی، به یک ریسک تبدیل شده بود. AI به عنوان کاتالیزوری برای سرعت عمل می‌کند، اما جایگزینی برای قضاوت مهندسی نیست.
چک‌لیست بقا برای جلوگیری از آتروفی
برای جلوگیری از تحلیل رفتنِ شهودِ دیباگینگ، این اقدامات توصیه می‌شود:
- حسابرسی هفتگی تست‌ها: فقط به گزارش پوشش تست اکتفا نکنید. هر هفته ۵ تست تصادفی تولید شده توسط AI را باز کنید و بپرسید: «چه چیزی باعث می‌شود این تست به‌طور اشتباه پاس شود؟» اگر در ۳۰ ثانیه پاسخ ندادید، نقطه کور شما فعال است.
- سهمیه موارد مرزی: به ازای هر ۱۰ تست «مسیر خوش‌بینانه» توسط AI، اصرار کنید که دو تست برای موارد خاص (Edge Cases) به‌صورت دستی توسط انسان نوشته شود. این کار باعث می‌شود دانش دامنه از ذهن مهندس به کد منتقل شود.
- تست ساعت ۳ صبح: از تیم بپرسید: «اگر سیستم ساعت ۳ صبح خراب شود، آیا این تست‌ها آن را می‌گیرند؟» اگر پاسخ «احتمالاً» است، ادعاهای تست شما به‌اندازه کافی دقیق نیستند. شما باید دقیقاً بدانید کدام ادعا شکست می‌خورد و چرا.
- حفظ تست‌های دستی: یک ماژول کوچک و حیاتی را عمداً به‌صورت دستی تست کنید. این کار شهود خام دیباگینگ را که هنگام اعتماد کامل به اتوماسیون تحلیل می‌رود، حفظ می‌کند.
این تغییر رویکرد نشان می‌دهد ابزارهای تست AI تنها زمانی مفیدند که مهندس دقیقاً بداند چه چیزی را تست می‌کند. تبدیل «تولید» به «جایگزینِ درک»، بدهی‌ای ایجاد می‌کند که فقط با یک شکست در محیط عملیاتی تسویه می‌شود. درس اصلی این نیست که از AI دوری کنیم، بلکه این است که حجم تست را با کیفیت تست اشتباه نگیریم. تست‌هایی که ساعت ۳ صبح شما را نجات می‌دهند، همان‌هایی هستند که با درک درست نوشته شده‌اند، درست در جایی که AI اشتباه کرده است.
نظر شما چیست؟ آیا تیم شما متوجه شده است که توسعه‌دهندگان بدون پرامپت‌های AI، در شناسایی تست‌های مورد نیاز ناتوان‌تر شده‌اند؟ تجربه شما در مورد کیفیت تست‌های تولیدی AI در مقابل پوشش تست‌های دستی چیست؟ نظرات خود را پایین صفحه بنویسید — من به تک تک آن‌ها پاسخ می‌دهم.
گفتگو