چطور اپ ساخته‌شده با هوش مصنوعی‌تان را آزمایش کنید وقتی هرگز نرم‌افزار آزمایش نکرده‌اید

با هوش مصنوعی یک اپ ساختید. روی مسیر خوش‌فرجام کار می‌کند — اسمتان را تایپ می‌کنید، روی دکمه کلیک می‌کنید، صفحهٔ موفقیت را می‌بینید. حالا چه؟ آماده است که برای سه کاربر بتای خود بفرستید؟ برای تیمتان؟ برای مشتریانتان؟

اگر پیشینهٔ نرم‌افزاری ندارید، آزمایش حس یکی از آن کارهایی را دارد که «برنامه‌نویس‌های واقعی» انجام می‌دهند — با فریم‌ورک‌ها و assertionها و خط‌لوله‌های CI. خبر خوب: بیشترِ آزمایش این نیست. بیشتر آزمایش، به‌ویژه وقتی چیزی کوچک و جدید عرضه می‌کنید، یک نفر است که با قصد و هدف کلیک می‌کند. شما می‌توانید این کار را بکنید. این پست دربارهٔ انجام دادن آن از روی قصد است، تا باگ‌ها را پیش از کاربرانتان پیدا کنید.

هدف این نیست که اپ ساخته‌شده با هوش مصنوعی‌تان را مثل یک حرفه‌ای آزمایش کنید. این است که آن را مثل یک دوست بدبین آزمایش کنید که واقعاً می‌خواهد کار کند.

ترفند دو فهرست

پیش از اینکه روی هر چیزی کلیک کنید، ده دقیقه با یک سند خالی بنشینید و دو فهرست بنویسید.

فهرست الف — مسیرهای خوش‌فرجام. آن سه یا چهار کاری که یک کاربر قرار است با این اپ انجام دهد چیست؟ برای یک SaaS معمولی، شاید این باشد: ثبت‌نام، ساختن اولین پروژه، دعوت از یک هم‌تیمی، گرفتن خروجی از یک نتیجه. برای یک اپ دایرکتوری‌مانند: جست‌وجو، فیلتر، کلیک روی یک آگهی، ذخیرهٔ آن. سه یا چهار جریان واقعی، به زبان ساده.

فهرست ب — مسیرهای ناخوش‌فرجام. اگر کاربر کاری انجام دهد که تقریباً درست است اما نه کاملاً، چه؟ ایمیلش را با یک تایپو تایپ می‌کند. وسط جریان دکمهٔ بازگشت را می‌زند. دو تب باز می‌کند و همان چیز را در هر دو ویرایش می‌کند. یک فرم خالی ثبت می‌کند. محتوای یک سند Word را — با تمام قالب‌بندی — در یک فیلد متنی پیست می‌کند. لپ‌تاپ را می‌بندد و ده دقیقه بعد دوباره بازش می‌کند. سعی می‌کند با یک نشانی ایمیل که از قبل در سیستم وجود دارد یک هم‌تیمی دعوت کند.

فهرست مسیر خوش‌فرجام همان است که اپ‌ساز هوش مصنوعی‌تان برایش بهینه کرده. همان است که هوش مصنوعی هنگام نوشتن کد ذهناً آزمایشش کرده. فهرست مسیر ناخوش‌فرجام جایی است که باگ‌ها زندگی می‌کنند، چون تقریباً هیچ‌کس — نه هوش مصنوعی، نه شما وقتی پرامپت می‌زدید — به آن حالت‌ها فکر نمی‌کرد.

وقتی واقعاً آزمایش می‌کنید، اول فهرست الف را طی کنید تا کارکرد پایه را تأیید کنید. بعد بخش عمدهٔ وقتتان را صرف فهرست ب کنید. فهرست ب جایی است که ارزش هست. فهرست ب همچنین جایی است که می‌فهمید واقعاً می‌خواهید اپ وقتی اوضاع به هم می‌ریزد چه کار کند، که اغلب یک گفت‌وگوی روشن‌کننده با اپ‌ساز هوش مصنوعی را ضروری می‌کند («وقتی فرم نیمه‌پرشده است، باید هشدار بدهد یا خودکار ذخیره کند؟»).

سه چیز برای خراب کردن عمدی

وقتی فهرست‌هایتان را داشتید، این سه دسته اکثر باگ‌های واقعی در اپ‌های ساخته‌شده با هوش مصنوعی را می‌گیرند.

ورودی‌های خالی و عجیب. فرم را بدون پر کردن هیچ‌چیز ثبت کنید. آن را با یک فیلد پرشده ثبت کنید. اسمی ۵۰۰ کاراکتری ثبت کنید. اسمی با ایموجی ثبت کنید. یک URL را در فیلدی پیست کنید که انتظار یک اسم را دارد. فیلد ایمیل را با «test»، با «test@»، با «test@example»، با نشانی «a@b.co» امتحان کنید — آیا ایمیل‌های کوتاهِ معتبر را می‌پذیرد؟ اپ‌سازهای هوش مصنوعی اغلب اعتبارسنجی اضافه می‌کنند، اما اعتبارسنجی می‌تواند در هر دو جهت اشتباه باشد — بیش از حد سخت‌گیر (کاربران واقعی را رد می‌کند) یا بیش از حد شل (آشغال را می‌پذیرد).

رفتن به عقب و به پهلو. بیشتر اپ‌ها خوب کار می‌کنند اگر مثل یک تور گردشگری مطیع از میانشان عبور کنید. درست لحظه‌ای خراب می‌شوند که کسی کاوش کند. روی دکمهٔ بازگشت کلیک کنید. دوباره به جلو کلیک کنید. صفحه را وسط یک جریان رفرش کنید. همان صفحه را در دو تب باز کنید و در هر دو ویرایش کنید. خارج شوید و دوباره وارد شوید. اگر یک دکمهٔ «بازگردانی» دارید، سه بار پشت‌سرهم رویش کلیک کنید. این‌ها حالت‌های حاشیه‌ای نیستند. این‌ها همان طوری است که آدم‌های واقعی از نرم‌افزار استفاده می‌کنند.

داده‌ها بعد از آن. آن چیزی را که اپتان می‌سازد بسازید. یک پروژه، یک پست، یک رکورد، هرچه. بعد فردا برگردید. آیا هنوز آنجاست؟ آیا قالب‌بندی جان سالم به در برد؟ اگر ویرایشش کنید، آیا ویرایش ذخیره می‌شود؟ اگر حذفش کنید، آیا واقعاً رفته، یا وقتی رفرش می‌کنید برمی‌گردد؟ اپ‌سازهای هوش مصنوعی اغلب جریان «ساختن» را عالی پیاده می‌کنند و فراموش می‌کنند که هر چیزی که می‌سازید باید ماندگار بماند و بعداً قابل‌ویرایش باشد.

«به‌قدر کافی خوب» چه شکلی است

شما هرگز اپ ساخته‌شده با هوش مصنوعی‌تان را تا حد کمال آزمایش نمی‌کنید. نرم‌افزار بیش از حد درهم‌تنیده و زمان شما بیش از حد ارزشمند است. پرسش این نیست که «آیا بی‌نقص است» — این است که «آیا برای گروه بعدی آدم‌هایی که می‌خواهم پیش رویشان بگذارم، به‌قدر کافی خوب است».

این هم یک سلسله‌مراتب تقریبی که می‌توانید قرض بگیرید.

به‌قدر کافی خوب برای دمو: مسیر خوش‌فرجام بدون کرش کار می‌کند. دکمه‌ها جایی می‌روند که باید. می‌توانید یک ضبط صفحه نشان دهید بدون اینکه چیزی را قیچی کنید.

به‌قدر کافی خوب برای کاربران دوستانه: مسیرهای ناخوش‌فرجام داده را از دست نمی‌دهند. فرم‌ها به‌جای شکست خاموش به شما می‌گویند چه چیزی اشتباه است. رفرش کردن صفحه چیزها را خراب نمی‌کند. سه دوست می‌توانند از آن استفاده کنند بدون اینکه برای کمک به شما پیام بدهند.

به‌قدر کافی خوب برای کاربران پرداخت‌کننده: اپ کاربرانی را که هرگز ندیده‌اید مدیریت می‌کند. مرورگرهایشان، داده‌هایشان، عادت‌هایشان. راهی دارید که ببینید کی چیزها خراب می‌شوند (ردیابی خطای پایه کافی است — به یک داشبورد فانتزی نیاز ندارید). می‌توانید اصلاح و دوباره مستقر کنید بدون اینکه آدم‌هایی را که همین حالا استفاده می‌کنند خراب کنید.

بیشتر سازندگان در سطح «کاربران دوستانه» عرضه می‌کنند و بعد همان‌طور که بازخورد می‌آید ارتقا می‌دهند. این درست است. اشتباه این است که از «به‌قدر کافی خوب برای دمو» بدون گام میانی مستقیم به «به‌قدر کافی خوب برای کاربران پرداخت‌کننده» بپرید. کاربران دوستانه چیزهایی پیدا می‌کنند که کاربران واقعی پیدا می‌کنند — اما بابتش عصبانی نمی‌شوند. از آن فاصله استفاده کنید.

کی از هوش مصنوعی بخواهید برایتان آزمایش کند

اپ‌ساز هوش مصنوعی‌تان می‌تواند با آزمایش کمک کند، اما باید دربارهٔ آنچه می‌خواهید مشخص باشید. «تست اضافه کن» یک پرامپت بد است. کدی تولید می‌کند که شبیه تست به نظر می‌رسد و احتمالاً پاس می‌شود، بدون اینکه واقعاً چیزی را که برایتان مهم است بررسی کند. بیشتر آن تست‌های خودکارتولیدشده تأیید می‌کنند که ۱+۱ هنوز ۲ است.

یک پرامپت بهتر: «همین حالا سعی کردم فرم ثبت‌نام را با فیلد ایمیل خالی ثبت کنم و کرش کرد. پیدا کن کجا این مدیریت می‌شود و یک بررسی اضافه کن که به‌جایش یک خطای دوستانه نشان دهد.» باگ مشخص، اصلاح مشخص، نتیجهٔ مشخص. هوش مصنوعی در این کار خوب است. در «مطمئن شو اپم بدون باگ است» بد است، چون این یک وظیفه نیست — یک آرزوست.

چیز دیگری که اپ‌سازهای هوش مصنوعی در آن خوب‌اند، بازپخش باگ شماست. اگر توصیف کنید چه کردید، چه انتظار داشتید و چه شد، اپ‌ساز معمولاً می‌تواند کد را ردیابی کند و یک اصلاح پیشنهاد دهد. انضباطی که نیاز دارید، انضباط نوشتن واضح آن سه چیز است. بیشتر گزارش‌های باگِ تازه‌کارها نسخه‌ای از «کار نمی‌کند» هستند. بیشتر گزارش‌های باگِ قابل‌اصلاح «الف را کلیک کردم، انتظار ب را داشتم، ج گرفتم» هستند.

آزمایش، خواندن است نه فقط کلیک کردن

یک چیز آخر. لازم نیست هر خط کد در اپ ساخته‌شده با هوش مصنوعی‌تان را بفهمید تا آن را خوب آزمایش کنید. اما باید دست‌کم نگاهی سرسری بیندازید. فایلی را که هوش مصنوعی همین حالا تغییر داد باز کنید. تابعی را که اضافه کرد بخوانید. لازم نیست بدانید هر کلیدواژه چه معنایی دارد — باید بدانید آیا تابع به نظر می‌رسد دارد همان کاری را می‌کند که خواستید.

خیلی از باگ‌های ساخته‌شده با هوش مصنوعی «کد خراب است» نیستند. «کد کاری کمی متفاوت از آنچه می‌خواستید انجام می‌دهد» هستند. یک فیلد در جای اشتباه ذخیره می‌شود. یک دکمه یک چیز را به‌روز می‌کند اما چیز مرتبط را نه. یک دکمهٔ «حذف» به‌جای حذف، پنهان می‌کند. بدون خواندن آنچه واقعاً ساخته شده نمی‌توانید این‌ها را بگیرید.

با کد مثل چیزی رفتار کنید که می‌توانید ممیزی‌اش کنید، نه چیزی که مجبورید بنویسیدش. این همان تفاوت میان یک اپ ساخته‌شده با هوش مصنوعی است که به آن اعتماد دارید و یکی که فقط امیدوارید کار کند.

نسخهٔ ساده

اگر هیچ چیز دیگری به خاطرتان نماند: دو فهرست را بنویسید، چیزها را عمداً خراب کنید، و تصمیم بگیرید در کدام سطح «به‌قدر کافی خوب» عرضه می‌کنید. بیشتر باگ‌ها در یک اپ ساخته‌شده با هوش مصنوعی ظریف نیستند. روی فهرست مسیر ناخوش‌فرجامی نشسته‌اند که هیچ‌کس زحمت نوشتنش را نکشید.

اگر یک تکلیف کوچک می‌خواهید: یک اپی را که ساخته‌اید انتخاب کنید و چهار چیز را امتحان کنید — یک فرم خالی ثبت کنید، وسط جریان رفرش بزنید، یک رکورد را ویرایش کنید و فردا بررسی‌اش کنید، و از یک دوست بخواهید بدون تماشای شما از آن استفاده کند. هرچه خراب شود، فهرست باگ واقعی شماست. باقی همه‌چیز فقط امروزوفردا کردن است.