مدل می‌گوید کار تمام شد. برنامه اجرا می‌شود، صفحه خوب به نظر می‌رسد و تست‌ها هم سبز هستند. آیا می‌توانیم منتشر کنیم؟
شاید؛ اما هنوز نمی‌دانیم تست‌ها رفتار مورد نیاز را سنجیده‌اند یا فقط با همان پیاده‌سازی هماهنگ‌اند. همچنین ممکن است مسیر موفق را دیده باشیم و رفتار شکست را بررسی نکرده باشیم.
از قرارداد تغییر شروع کنیم
پیش از خواندن کد، بنویسیم چه چیزی باید تغییر کند و چه شواهدی آن را ثابت می‌کند. مثلاً «کاربر بتواند درخواست مشاوره ثبت کند و نتیجه را ببیند» هنوز مبهم است.
قرارداد دقیق‌تر این است: ورودی نامعتبر ارسال نشود؛ هنگام ارسال وضعیت انتظار دیده شود؛ موفقیت فقط پس از پاسخ معتبر سرور اعلام شود؛ در شکست، اطلاعات فرم حفظ شود؛ و ارسال تکراری به ثبت ناخواسته درخواست‌های یکسان منجر نشود.
حالا معیار داریم. بررسی را با این رفتارها انجام می‌دهیم، نه با میزان مرتب بودن کد.
تغییر را کوچک و قابل توضیح نگه داریم
Diff، یعنی تفاوت نسخه قبلی و جدید، را بخوانیم. آیا مدل برای ساخت یک فرم، بسته جدیدی نصب کرده، تنظیمات پروژه را تغییر داده یا بخش نامرتبطی را بازنویسی کرده است؟ هر تغییر اضافی باید دلیل داشته باشد.
از مدل می‌توان توضیح خواست، اما توضیح خودش مدرک صحت نیست. باید فایل‌ها و اثر تغییر را ببینیم. اگر تغییر برای بازبینی خیلی بزرگ شده، آن را به بخش‌هایی تقسیم کنیم که هر کدام هدف و روش بررسی مشخص دارند.
یک مثال که مسیر موفق پنهانش می‌کند
کاربر فرم را ارسال می‌کند. سرور درخواست را ثبت می‌کند، اما پاسخ در شبکه گم می‌شود. مرورگر خطا نشان می‌دهد و کاربر دوباره ارسال می‌کند. آیا دو درخواست ساخته می‌شود؟
غیرفعال کردن دکمه در زمان ارسال مفید است، اما این سناریو را به‌تنهایی حل نمی‌کند. در صورت نیاز، جلوگیری از اثر تکراری باید در سرور و با طراحی مناسب درخواست انجام شود. همچنین رابط باید درباره وضعیت نامطمئن، پیام قابل فهمی بدهد.
همین یک مثال نشان می‌دهد چرا بررسی فرانت‌اند به دیدن تصویر صفحه محدود نیست. قرارداد API و رفتار سرور هم در تجربه نهایی نقش دارند.
تست‌هایی که می‌توانند ایراد پیدا کنند
از شرط‌های پذیرش و سناریوهای شکست تست بسازیم. برای فرم مثال، پاسخ موفق، خطای اعتبارسنجی، شکست سرور و قطع ارتباط را جداگانه بررسی کنیم. برای خطای مشخص، آزمونی داشته باشیم که در نسخه معیوب شکست بخورد و پس از اصلاح عبور کند.
اجرای تست واحد، بررسی نوع‌ها و ساخت پروژه کمک می‌کند. اما برای مسیر کاربر باید رابط را هم استفاده کنیم: با کیبورد، روی موبایل و با خطایی که عمداً ایجاد کرده‌ایم. هیچ‌کدام به‌تنهایی همه کیفیت محصول را ثابت نمی‌کند.
مرز اعتماد را در کد پیدا کنیم
آیا داده کاربر به‌صورت HTML اجرا می‌شود؟ آیا کلید سرویس در کد مرورگر قرار گرفته؟ آیا حذف یا تغییر داده فقط به مخفی بودن یک دکمه وابسته است؟ این سؤال‌ها باید به مسیر مشخص کد و کنترل سمت سرور وصل شوند.
بازبینی AI می‌تواند سرنخ بدهد، اما یافته‌هایش هم نیاز به بررسی دارند. مستندات رسمی GitHub تأکید می‌کند بازبینی Copilot باید مکمل بازبینی انسانی باشد و بازخورد آن تأیید شود. دو مدل که یک نظر می‌دهند، جای شاهد اجرا یا تحلیل مسیر کد را نمی‌گیرند.
انتشار باید راه بازگشت داشته باشد
پیش از انتشار بدانیم اگر خطا دیدیم، چگونه به نسخه قبل برمی‌گردیم و چه کسی مسئول پیگیری است. اگر ساختار داده تغییر کرده، فقط برگرداندن فایل‌های برنامه ممکن است کافی نباشد. اثر تغییر داده و سازگاری نسخه‌ها را جداگانه بررسی کنیم.
پس از انتشار نیز یک آزمون کوتاه روی مسیر اصلی انجام بدهیم و خطاهای مربوط به همان قابلیت را پایش کنیم. عبارت «منتشر شد» با «در محیط واقعی درست کار می‌کند» یکسان نیست.
قاعده‌ای که ارزش حفظ کردن دارد
برای هر ادعای «درست شد»، یک شاهد مرتبط بخواهیم: تستی که خطا را می‌گیرد، نتیجه اجرای مسیر یا بررسی روشن کد.
AI می‌تواند زمان ساخت را کم کند. وظیفه مهندس این است که بداند چه ساخته شده، کجا ممکن است شکست بخورد و با چه شواهدی آماده انتشار است.
