اگر امروز از هوش مصنوعی برای تسریع خط لوله تضمین کیفیت استفاده میکنید، احتمالاً در حال ساخت یک بدهی فنی هستید که در لباس دارایی ظاهر شده است. در اوایل سال ۲۰۲۶، یک شرکت نرمافزاری در توکیو تعداد تستهای خود را در یک فصل ۴۰٪ افزایش داد، اما یک نقص حیاتی در جریان پرداختها ۷۲ ساعت بهطور مخفیانه فعال بود؛ زیرا تاییدیه (Assertion) تستهای تولیدشده توسط AI اساساً ناقص بودند.
این پدیده که «کوری تست» (Testing Blindness) نامیده میشود، زمانی رخ میدهد که تیمها معیارهای پوشش کد را بر توانایی واقعی تست در شناسایی باگ ترجیح دهند. به نظر ما، این یک ریسک سیستمی است؛ چراکه توسعهدهندگان از مدل زبانی بزرگ (LLM) — که شبیه کتابخانهداری است که میلیاردها صفحه را خوانده و حالا با همان لحن جواب میدهد — برای نوشتن ساختار تست استفاده میکنند، بدون آنکه منطق زیربنایی سیستم را درک کنند. همانطور که در تحلیلهای قبلی ما دربارهی توهمات مدلها اشاره کردیم، تکیه بر خروجیهای صیقلخورده اما توخالی میتواند فاجعهبار باشد. در همین راستا، تکیه مطلق بر یک مدل واحد بدون لایههای کنترلی میتواند منجر به آسیبهای جدی شود، موضوعی که پیشتر در بررسی ریسکهای زیرساختی مدلهای تکگانه به آن پرداختیم.
به نقل از گزارش مفصلی در Qiita (بزرگترین جامعه توسعهدهندگان ژاپن)، یک مهندس دریافت که تستهای AI دچار «تحلیل رفتگی تاییدیه» شدهاند. یعنی تستها فقط بررسی میکنند که «خطایی رخ نداده است»، نه اینکه «دادههای صحیح ذخیره شدهاند». طبق این گزارش، سه نقطه شکست اصلی شناسایی شده است:
- کوری نسبت به موارد مرزی: AI تستها را حول مسیرهای خوشبینانه (Happy Paths) متمرکز میکند و ورودیهای تهی (Null) یا شرایط رقابتی (Race Conditions) را که باعث کرش واقعی میشوند، نادیده میگیرد.
- تورم اعتماد به رگرسیون: دو برابر شدن تعداد تستها حس امنیت کاذبی ایجاد میکند، در حالی که نرخ واقعی شناسایی نقصها کاهش مییابد. این چالش با تلاشهای اخیر برای پیشبینی دقیقتر شکستها همسو است، همانطور که OpenAI با استفاده از شبیهسازیهای جدید سعی دارد دقت پیشبینی خرابیها را افزایش دهد.
- مالیات تاییدیه: به ازای هر ساعت صرفهجویی در تولید تست، تیمها ۳ تا ۴ ساعت زمان برای بررسی دستی پس از وقوع حادثه در محیط عملیاتی هزینه میکنند.
برای یک توسعهدهنده، این به معنای آن است که AI کاتالیزور سرعت است، نه جایگزینی برای قضاوت انسانی. نویسنده مقاله در Qiita اشاره کرد که مجبور شده است مفاهیم Playwright و تست API را بهطور دستی یاد بگیرد تا شکافهایی را که AI ایجاد کرده بود، شناسایی کند.
گام بعدی شما
- برای هر ۱۰ تست مسیر خوشبینانه تولیدشده با AI، حداقل ۲ تست مورد مرزی (Edge Case) را بهصورت دستی بنویسید.
- در بازههای هفتگی، ۵ تست تصادفی AI را انتخاب کرده و تحلیل کنید که چه تغییری در کد باعث میشود این تست بهاشتباه «پاس» شود.
- تمرکز را از «درصد پوشش کد» به «نرخ شناسایی باگهای واقعی» تغییر دهید.
اما این مشکل تنها بخشی از بحران است؛ اثر این «اعتماد کاذب» بر معماریهای میکروسرویس را در گزارش بعدی بررسی خواهیم کرد.
گفتگو