اگر تصور می‌کنید با ظهور عامل‌های هوش مصنوعی، نیاز به تست نرم‌افزار از بین می‌رود، سخت در اشتباهید. در واقع، توانایی تأیید مستقل کدها اکنون به کمیاب‌ترین و ارزشمندترین مهارت در مهندسی نرم‌افزار تبدیل شده است. در حالی که عامل‌ها می‌توانند در چند ثانیه درخواست‌های تغییر کد (Pull Requests) را ارسال کنند و مهاجرت‌های سیستمی را آغاز نمایند، و ربات‌های بازبینی پیش از آنکه شما قهوه‌تان را بنوشید، تغییرات را «ایمن» اعلام کنند؛ اما صنعت اکنون در حال کشف این حقیقت است که سرعت، هرگز دلیلی بر صحت نیست.
شکاف اعتماد در پذیرش هوش مصنوعی
این تغییر رویکرد در حالی رخ می‌دهد که پذیرش ابزارهای هوش مصنوعی به نقطه اشباع رسیده است. طبق نظرسنجی ۲۰۲۵ Stack Overflow، حدود ۸۴٪ پاسخ‌دهندگان از ابزارهای هوش مصنوعی استفاده می‌کنند یا قصد استفاده از آن‌ها را دارند و ۵۱٪ توسعه‌دهندگان حرفه‌ای به‌صورت روزانه با این ابزارها کار می‌کنند. با این حال، احساسات مثبت نسبت به این ابزارها به ۶۰٪ کاهش یافته است. اکنون ۴۶٪ توسعه‌دهندگان به‌طور فعال به دقت هوش مصنوعی بی‌اعتماد هستند، در حالی که تنها ۳۳٪ به آن اعتماد دارند. ۶۶٪ آن‌ها بزرگ‌ترین دغدغه‌شان را «راه‌کارهای تقریباً درست اما نه کاملاً دقیق» می‌دانند.
پژوهش ۲۰۲۵ DORA از Google Cloud نیز همین تنش را تأیید می‌کند. در حالی که پذیرش AI در میان متخصصان توسعه نرم‌افزار به ۹۰٪ رسیده و بیش از ۸۰٪ آن‌ها بهبود بهره‌وری را گزارش کرده‌اند، تنها ۲۴٪ گزارش کرده‌اند که اعتماد زیادی یا بسیار زیادی به این ابزارها دارند. این وضعیت — یعنی «کارآمد بودن بدون داشتن اعتماد» — دقیقاً همان چیزی است که شغل تست‌کننده را به‌جای حذف، گسترش می‌دهد. این نیاز به بازتعریف نقش توسعه‌دهندگان را برجسته می‌کند، مشابه آنچه در بررسی ۵ مهارت حیاتی برای بقای برنامه‌نویسان در عصر هوش مصنوعی ۲۰۲۶ به آن اشاره شد.
توهم خط لوله سبز (The Illusion of the Green Pipeline)
داده‌های فنی، ریسک تکیه بر کدهای تولیدشده توسط AI بدون نظارت سخت‌گیرانه انسانی را برجسته می‌کنند. گزارشی از CodeRabbit روی ۴۷۰ درخواست تغییر در گیت‌هاب (۳۲۰ مورد با کمک AI و ۱۵۰ مورد صرفاً انسانی) نشان داد که تغییرات تولیدشده توسط AI به‌طور کلی ۱.۷ برابر بیشتر دچار مشکل بوده‌اند. به‌طور مشخص، مشکلات مربوط به منطق و صحت کد ۷۵٪ رایج‌تر بود و یافته‌های امنیتی تا ۲.۷۴ برابر بیشتر از کدهای صرفاً انسانی بود.
امنیت همچنان بزرگ‌ترین نقطه اصطکاک است. گزارش ۲۰۲۶ Veracode درباره امنیت کدهای هوش مصنوعی زاینده (Generative AI) نشان داد که تقریباً ۴۴٪ از وظایف تولید کد توسط AI، یک آسیب‌پذیری شناخته‌شده را وارد پروژه کرده‌اند. نرخ عبور از تست‌های امنیتی به‌طور متوسط تنها ۵۶٪ بوده است؛ عددی که نسبت به گزارش قبلی (۵۵٪) تقریباً ثابت مانده و هیچ پیشرفتی نداشته است. در واقع، سینتکس (Syntax) کدها تقریباً حل شده، اما رفتار امن و صحیح هنوز یک چالش جدی است.
وابستگی‌های توهمی و اسکواتینگ (Slop Squatting)
علاوه بر خطاهای منطقی، عامل‌های هوش مصنوعی ریسک‌های سیستمی زنجیره تأمین را از طریق «وابستگی‌های توهمی» ایجاد می‌کنند. پژوهش USENIX Security 2025 با عنوان «ما یک بسته برای شما داریم!»، ۱۶ مدل زبانی بزرگ (LLM) و ۵۷۶,۰۰۰ نمونه را ارزیابی کرد. یافته‌ها نشان داد مدل‌های تجاری به‌طور متوسط در ۵.۲٪ موارد و مدل‌های متن‌باز در ۲۱.۷٪ موارد، بسته‌های نرم‌افزاری خیالی تولید کرده‌اند که در مجموع منجر به ایجاد ۲۰۵,۴۷۴ نام بسته توهمی شده است.
این بسته‌های شبح‌وار، بستری گسترده برای حملات «اسکواتینگ» (Slop Squatting) فراهم می‌کنند؛ جایی که مهاجمان نام‌های اختراعی AI را ثبت کرده و منتظر می‌مانند تا یک توسعه‌دهنده یا یک عامل AI آن‌ها را نصب کند. بنابراین، بررسی منشأ وابستگی‌ها (Provenance Checks) باید اکنون به عنوان یک گیت کیفیت اصلی در نظر گرفته شود، نه یک اقدام بهداشتی اختیاری. اگر یک عامل AI یک بسته NuGet یا npm را اختراع کند، عملیات ادغام (Merge) باید فوراً با شکست مواجه شود.
پیاده‌سازی گیت‌های عامل‌محور (Agentic Gates)
برای مقابله با این ریسک‌ها، Suprajyotsna Dasari، مهندس نرم‌افزار در شرکت Cognizant، رویکرد «اعتماد صفر» را در برابر ادعاهای عامل‌های AI پیشنهاد می‌کند. او هنگام مدیریت ارتقای سازمانی از .NET 8 به .NET 10 در بازه زمانی حدود دو هفته با استفاده از اتوماسیون‌های AI، گیت‌های کیفی خاصی را پیاده کرد تا اطمینان حاصل کند که خلاصه گزارش عامل AI به عنوان حقیقت پذیرفته نشود.
این گیت‌های کیفی در مقیاس بالا شامل موارد زیر است:
- اهداف امتیاز جهش (Mutation Score Targets): حفظ اهداف ۶۰ تا ۷۰ درصدی در منطق‌های تغییریافته. این کار تضمین می‌کند که مجموعه تست‌ها، جهش‌های واقعی را از بین می‌برند و نه فقط خطوط کد را پوشش می‌دهند؛ تا از «تئاتر پوشش کد» جلوگیری شود (جایی که درصد پوشش بالا می‌رود اما مسیرهای بحرانی، مانند جابجایی مقیاس تبدیل سلسیوس به فارنهایت، نادیده گرفته می‌شوند).
- تست‌های مبتنی بر ویژگی (Property-Based Testing): اعمال این تست‌ها روی منطق‌های پرریسک برای اطمینان از اینکه رفتار سیستم در تمام دامنه‌ها درست است، نه فقط در یک «مسیر خوش‌بینانه» (Happy Path) واحد.
- بررسی منشأ (Provenance Checks): اعتبارسنجی هر بسته در برابر توهمات و حملات اسکواتینگ برای بستن «انبار بسته‌های توهمی».
- سیگنال‌های تغییر و تکرار (Churn and Duplication): شناسایی کدهای تکراری و بازنویسی‌های بیهوده، که یک عادت رایج در عامل‌های AI است که یک ایده را به سه روش مختلف بازنویسی می‌کنند.
این رویکرد، ادعای عامل AI (مثلاً «مهاجرت کد کامل شد») را به عنوان یک «فرضیه» می‌بیند که پیش از ادغام، نیاز به شواهد دارد. باید پذیرفت که عامل‌ها با اطمینان صحبت می‌کنند، اما اطمینان به معنای صحت نیست.
حفظ دیسیپلین‌های سنتی
این تحول، جایگزین دیسیپلین‌های سنتی نمی‌شود. تست‌های API، بررسی‌های احراز هویت، تست‌های دود (Smoke Testing) و اتوماسیون UI با ابزارهایی مثل FlaUI و PowerShell همچنان ضروری هستند. بسته‌بندی از طریق NuGet، MSI و MSM همچنان نیازمند اعتبارسنجی نصب و مسیرهای Silent-path است. گردش‌کارهای عامل‌محور صرفاً حجم کد را افزایش می‌دهند و در نتیجه، حجم شکست‌های احتمالی را نیز بالا می‌برند.
برای متخصصان فنی، این موضوع فرض بنیادین «برنده شدن بهره‌وری با AI» را تغییر می‌دهد. اگر عامل‌ها سریع‌تر از توان تفکرِ سیستم‌های تأیید کد ارسال کنند، نتیجه یک پیروزی نیست، بلکه یک حادثه به تعویق افتاده است.
آینده متخصصان کیفیت
سرمایه‌گذاری اکنون به سمت تست‌کنندگانی می‌رود که می‌توانند شواهد را طراحی کرده و تست‌های جهش را در خط لوله‌های CI ادغام کنند. این موضوع فرصت‌هایی را برای افرادی با مسیرهای غیرسنتی ایجاد می‌کند. خودِ داساری پس از یک دوره شش ساله در عملیات HR و داده، با تکمیل کارشناسی ارشد در سیستم‌های اطلاعاتی در UMBC در می ۲۰۲۴، به حوزه کیفیت منتقل شد.
هدف، عبور از فرهنگ «تأیید کورکورانه» (Rubber-stamping) بیلد‌های سبز به سمت فرهنگ قضاوت مستقل و سخت‌گیرانه است. پاسخ‌دهندگان Stack Overflow که قصد استفاده از AI برای تست را دارند، همچنان بی‌اعتمادی انسانی را در مرکز قرار می‌دهند؛ وقتی آن‌ها به دنبال کمک هستند، دلیل اصلی ترجیح دادن یک انسان به AI، عدم اعتماد به پاسخ‌های AI است.
در نهایت، بزرگ‌ترین دارایی این حرفه، غریزه انسانی برای بی‌اعتمادی به پاسخ AI در مواقعی است که ریسک‌ها بالا هستند. آینده مهندسی کیفیت در دستان کسانی است که حاضر نیستند یک عامل «مطمئن» را با یک عامل «صحیح» اشتباه بگیرند.
گام بعدی شما
- استقرار تست‌های جهش (Mutation Testing) در خط لوله CI برای شناسایی کدهای «پوشش‌داده‌شده اما غلط».
- پیاده‌سازی گیت‌های بررسی منشأ برای تمام بسته‌های NuGet یا npm که توسط AI پیشنهاد شده‌اند.
- جایگزینی تست‌های تک‌نمونه با تست‌های مبتنی بر ویژگی (Property-Based) در بخش‌های حساس منطق کسب‌وکار.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو