دموی موفق کافی نیست؛ ارزیابی باید در فرایند تحویل قرار گیرد
تست دستی و تولید یک دموی موفق نشان نمیدهد رفتار عامل در طول زمان یا تحت تغییرات پیکربندی و نسخهٔ مدل پایدار میماند. تغییر در پیکربندی واکشی، نسخهٔ مدل یا مجوزها میتواند باعث حذف استنادها، فراخوانی ابزار نامناسب یا تغییر جریان کاری شود. برای تضمین رفتار مداوم، ارزیابی باید در مسیر انتشار محصول یک مرحلهٔ اجباری باشد.
«اگر یک اجرای تکرارشونده یا افت قابلتوجه در یک جریان کاری با ریسک بالا را نتوان بازتولید کرد، محصول نباید از دروازهٔ انتشار عبور کند.»
ویژگیهای یک سیستم ارزیابی تکرارپذیر
ویژگیهای کلیدی
- اجرای مداوم سناریوهای ثابت در طول مسیر توسعه و ذخیرهٔ شواهد اجرای هر سناریو.
- اجرای کدی که زمینه را میسازد، ابزارهایی که عامل فراخوانی میکند و مجوزهای زمان اجرا تا شرایط واقعی شبیهسازی شود.
- ثبت هر انحراف قابلتأثیر از جریان کاری بهعنوان خطا تا بهعنوان رگرسیون دائمی پیگیری و اصلاح شود.
تعریف رفتار صحیح پیش از نوشتن تست
قضاوت کلی مانند «پاسخ خوب بود» کافی نیست. ابتدا فهرستی از کارهایی که عامل باید انجام دهد، مرزهای هر کار و نتایجی که خارج از محدودهٔ عملیاتیاند بنویسید. مثال برای یک عامل پشتیبانی:
- پاسخ به پرسشهای صورتحساب با استفاده از رکورد حساب صحیح و ارجاع به سیاست جاری.
- ممنوعیت تغییر پلن یا افشای دادهٔ مشتری دیگر بدون مجوز صریح.
- در صورت نبودن سیاست مرتبط، اشارهٔ روشن به نبودن سیاست و پرهیز از حدس زدن پاسخ.
- در صورت نبود دادهٔ ضروری، قبل از ادامهٔ فرآیند از کاربر اطلاعات بخواهد.
نتیجه را از فرایندی که آن را تولید کرده جدا کنید: عامل ممکن است پاسخ صحیح بدهد اما پس از بازیابی سند اشتباه یا فراخوانی ابزار غیرضروری به آن رسیده باشد. این اجراها در نمای مکالمه موفق بهنظر میآیند ولی ضعفهایی را پنهان میکنند که در شرایط دیگر بروز خواهند کرد.
شروع با الزامهای قابل مشاهده
برای هر کار چند الزام قابل مشاهده تعریف کنید. حقایق ضروری باید توسط منابع نامگذاریشده پشتیبانی شوند و عملیاتهای تأثیرگذار (مانند بهروزرسانی حساب) باید منتظر تأیید صریح بمانند. قوانین با ریسک بالا باید اظهارات دقیق و معیارهای سنجش مشخص داشته باشند؛ بیان آنها ممکن است منعطف باشد اما معیارها روشن باشند.
ساخت سناریوها از کار واقعی کاربران
مجموعهٔ آزمایشی اولیه را کوچک و قابلنگهداری نگه دارید؛ ده کار واقعی معمولاً ارزش بیشتری از یک مجموعهٔ بزرگ پر از پرامپتهای غیرمرتبط دارد. منابع مناسب برای ساخت سناریوها:
- تیکتهای پشتیبانی و لاگهای جریان کاری
- گزارشهای حادثه و گفتگوهای واقعی با کاربران
- درخواستهای متداول و موارد مرزی مثل دادهٔ مفقود یا سند قدیمی
برخی سناریوها باید چندنوبتی طراحی شوند: مثالاً درخواست تغییر حساب در نوبت اول، ارسال شناسه در پیام بعدی و تأیید در پیام سوم. تست باید بررسی کند عامل آیا شناسه و تغییر پیشنهادی را بین نوبتها حفظ میکند و جزئیات نامرتبط را وارد نمیکند.
هر سناریو نیاز به فیکسچر دارد
اسناد، پاسخهای ابزار و وضعیت حساب را منجمد کنید تا یک اسنپشات شناختهشده بسازید. نسخهٔ سیاستها و مجوزهای عامل به همان اندازه اهمیت دارند. فیکسچرهای ثابت مشکلات غیرقابلبازتولید را از بحث به رشتهٔ مهندسی تبدیل میکنند و روند رفع را تسهیل میکنند.
کل مسیر اجرا را آزمایش کنید، نه فقط پاسخ نهایی
امتیازدهی صرف به پاسخ نهایی تفاوت عامل و یک چتبات را پنهان میکند. عامل مراحل متعددی را انجام میدهد: بازیابی داده، انتخاب ابزار، ساخت آرگومانها و تصمیمگیری دربارهٔ ادامهٔ کار. هر مرحله میتواند از مسیر موردنظر منحرف شود حتی اگر پاسخ نهایی قانعکننده باشد.
اطلاعات زیر را ثبت و نسخهبندی کنید: درخواست و دستورالعملهای سیستمی، مدل و نسخهٔ دقیق آن، پرامپتها، پیکربندی واکشی، ابزارها و مجوزهای بهکاررفته. این دادهها کمک میکنند هر رگرسیون را با شرایط اجرا مرتبط کنید و منشأ افت را بیابید.
رگرسیونها را ثبت، تحلیل و نمایه کنید
خطاهای تولیدی را بهعنوان رگرسیون دائمی ثبت کنید. گذر زمان نشان میدهد تیم روی چه مواردی هزینه کرده، چه اشتباهاتی تکرار شده و چه اصلاحاتی مؤثر بودهاند. ترکیب این دادهها با سناریوهای واقعی ارزیابی را از یک کار یکباره به دارایی محصول تبدیل میکند.
گامهای عملی برای تیمها
- ادغام ارزیابی در CI/CD و تعریف آستانههای توقف انتشار.
- نسخهبندی فیکسچرها و همگامسازی تغییرات سیاست یا پیکربندی واکشی با تستها.
- اتوماسیون ردیابی رگرسیونها و استفاده از آنها برای بهبود معیارهای کیفی.
منابع مفید برای مرجع: ویکیپدیا — عامل هوشمند و ویکیپدیا — آزمون نرمافزار. قرار دادن ارزیابی در دل محصول به تیمها امکان میدهد پیش از گزارش کاربران، افتها و انحرافات را شناسایی و اصلاح کنند؛ این رویکرد کیفیت عاملها را در مقیاس حفظ میکند.
