Як тестувати свій застосунок на ШІ, якщо ви ніколи раніше не тестували софт

Ви зібрали застосунок зі ШІ. Він працює на щасливому шляху — ви вводите своє ім’я, клікаєте кнопку, бачите екран успіху. Що тепер? Чи готовий він, щоб надіслати трьом бета-користувачам? Вашій команді? Вашим клієнтам?

Якщо у вас немає софтверного бекграунду, тестування відчувається як одна з тих речей, що роблять «справжні розробники» — з фреймворками, асершенами й CI-конвеєрами. Хороша новина: це не те, чим більшість тестування насправді є. Більшість тестування, особливо коли ви випускаєте щось маленьке й нове, — це одна людина, що клікає навколо з наміром. Ви можете це зробити. Цей допис — про те, щоб робити це свідомо, щоб ви знайшли баги, перш ніж їх знайдуть ваші користувачі.

Мета не в тому, щоб тестувати свій застосунок на ШІ як профі. Вона в тому, щоб тестувати його як параноїдальний друг, що щиро хоче, щоб воно працювало.

Трюк із двома списками

Перш ніж щось клікати, сядьте на десять хвилин із порожнім документом і напишіть два списки.

Список A — щасливі шляхи. Які три-чотири речі користувач має робити з цим застосунком? Для типового SaaS це могло б бути: зареєструватися, створити перший проєкт, запросити одного колегу, експортувати результат. Для застосунку-каталогу: шукати, фільтрувати, клікнути на лістинг, зберегти його. Три-чотири справжні потоки, простою мовою.

Список B — нещасливі шляхи. А що, як користувач робить щось майже правильно, але не зовсім? Вводить свій e-mail із друкарською помилкою. Тисне кнопку «назад» посеред потоку. Відкриває дві вкладки й редагує те саме в обох. Надсилає порожню форму. Вставляє вміст документа Word — з форматуванням і всім — у текстове поле. Закриває ноутбук і відкриває знову за десять хвилин. Намагається запросити колегу, використовуючи e-mail, який уже є в системі.

Список щасливих шляхів — те, під що оптимізував ваш конструктор застосунків на ШІ. Це те, що ШІ подумки тестував, поки писав код. Список нещасливих шляхів — те, де живуть баги, бо майже ніхто — ні ШІ, ні ви, коли промптували, — не думав про ці випадки.

Коли ви справді тестуєте, пройдіться спершу Списком A, щоб підтвердити, що базове працює. Потім витратьте більшість часу на Список B. Список B — там, де цінність. Список B — також там, де ви з’ясовуєте, що ви насправді хочете, щоб застосунок робив, коли все йде шкереберть, що часто змушує до уточнювальної розмови з конструктором на ШІ («коли форма наполовину заповнена, вона має попереджати чи автозберігати?»).

Три речі, які треба навмисно зламати

Щойно у вас є списки, ось три категорії, що ловлять більшість справжніх багів у застосунках на ШІ.

Порожні й дивні вводи. Надішліть форму, нічого не заповнивши. Надішліть її з одним заповненим полем. Надішліть ім’я на 500 символів. Надішліть ім’я з емодзі. Вставте URL у поле, що очікує ім’я. Спробуйте поле e-mail із «test», із «test@», із «test@example», з адресою «a@b.co» — чи приймає воно легітимні короткі e-mail? Конструктори застосунків на ШІ часто додають валідацію, але валідація може бути хибною в будь-який бік — надто сувора (відхиляє справжніх користувачів) чи надто м’яка (приймає сміття).

Назад і вбік. Більшість застосунків працює нормально, якщо ви йдете крізь них як слухняна екскурсійна група. Вони ламаються тієї миті, коли хтось досліджує. Клікніть кнопку «назад». Клікніть «уперед» знову. Оновіть сторінку посеред потоку. Відкрийте ту саму сторінку у двох вкладках і редагуйте в обох. Вийдіть і ввійдіть знову. Якщо у вас є кнопка «скасувати», клікніть її тричі поспіль. Це не крайні випадки. Це те, як справжні люди користуються софтом.

Дані потім. Зберіть річ, яку будує ваш застосунок. Проєкт, допис, запис, що завгодно. Потім поверніться завтра. Воно все ще там? Форматування вціліло? Якщо ви редагуєте, чи зберігається правка? Якщо ви видаляєте, чи воно справді зникло, чи повертається при оновленні? Конструктори застосунків на ШІ часто бездоганно роблять потік «створити» й забувають, що все, що ви створюєте, має триматися й бути редагованим пізніше.

Як виглядає «достатньо хороше»

Ви ніколи не протестуєте свій застосунок на ШІ до досконалості. Софт надто заплутаний, а ваш час надто цінний. Запитання не «чи воно ідеальне», а «чи воно достатньо хороше для наступної групи людей, перед якими я його поставлю».

Ось приблизна ієрархія, яку ви можете позичити.

Достатньо хороше для демо: щасливий шлях працює без падінь. Кнопки ведуть, куди мають. Ви можете показати запис екрана, нічого не вирізаючи.

Достатньо хороше для дружніх користувачів: нещасливі шляхи не втрачають даних. Форми кажуть, що не так, замість того щоб тихо збоїти. Оновлення сторінки нічого не ламає. Троє друзів можуть скористатися, не пишучи вам по допомогу.

Достатньо хороше для платних користувачів: застосунок справляється з користувачами, яких ви ніколи не зустрічали. З їхніми браузерами, їхніми даними, їхніми звичками. У вас є спосіб бачити, коли щось ламається (базового відстеження помилок достатньо — вигадливий дашборд не потрібен). Ви можете виправити й передеплоїти, не ламаючи людей, що вже користуються.

Більшість будівників випускає на рівні «дружні користувачі» й потім оновлює, поки приходить зворотний зв’язок. Це правильно. Помилка — намагатися стрибнути від «достатньо хороше для демо» прямо до «достатньо хороше для платних користувачів» без проміжного кроку. Дружні користувачі знаходять речі, які знайшли б справжні користувачі, — але вони не гніваються через них. Скористайтеся цим розривом.

Коли просити ШІ протестувати за вас

Ваш конструктор застосунків на ШІ може допомогти з тестуванням, але вам треба бути конкретним щодо того, що ви хочете. «Додай тести» — поганий промпт. Він згенерує код, що виглядає як тести, і, ймовірно, пройде, насправді не перевіряючи нічого, що вам важливе. Більшість цих автогенерованих тестів підтверджує, що 1+1 усе ще 2.

Кращий промпт: «Я щойно спробував надіслати форму реєстрації з порожнім полем e-mail, і вона впала. Знайди, де це обробляється, і додай перевірку, що показує дружню помилку замість цього». Конкретний баг, конкретне виправлення, конкретний результат. ШІ в цьому хороший. Він поганий у «зроби так, щоб мій застосунок був без багів», бо це не завдання — це бажання.

Ще одна річ, у якій конструктори на ШІ хороші, — це відтворення вашого бага. Якщо ви описуєте, що ви зробили, що очікували й що сталося, конструктор зазвичай може простежити крізь код і запропонувати виправлення. Дисципліна, яка вам потрібна, — це дисципліна чітко записувати ці три речі. Більшість звітів про баги від початківців — це якась версія «воно не працює». Більшість виправних звітів про баги — це «я клікнув X, очікував Y, отримав Z».

Тестування — це читання, а не лише клікання

Остання річ. Вам не треба розуміти кожен рядок коду у вашому застосунку на ШІ, щоб добре його тестувати. Але ви маєте принаймні переглянути. Відкрийте файл, який ШІ щойно змінив. Прочитайте функцію, яку він додав. Вам не треба знати, що означає кожне ключове слово — вам треба знати, чи функція, схоже, робить те, про що ви просили.

Багато багів застосунків на ШІ — не «код зламаний». Вони — «код робить щось трохи інше від того, що ви хотіли». Поле зберігається не в те місце. Кнопка оновлює одну річ, але не пов’язану. Кнопка «видалити» ховає замість видаляти. Ви не зловите цього, не прочитавши, що насправді збудовано.

Ставтеся до коду як до чогось, що можна аудитувати, а не до чогось, що ви маєте писати. Це різниця між застосунком на ШІ, якому ви довіряєте, і тим, на який ви просто сподіваєтеся, що він працює.

Проста версія

Якщо ви не запам’ятаєте нічого іншого: напишіть два списки, навмисно ламайте речі й вирішіть, на якому рівні «достатньо хорошого» ви випускаєте. Більшість багів у застосунку на ШІ не тонкі. Вони сидять у списку нещасливих шляхів, який ніхто не потурбувався записати.

Якщо хочете маленьке домашнє завдання: оберіть один застосунок, який ви зібрали, і спробуйте чотири речі — надішліть порожню форму, натисніть оновлення посеред потоку, відредагуйте запис і перевірте його завтра й попросіть друга скористатися ним без вашого нагляду. Що зламається — це ваш справжній список багів. Усе інше — прокрастинація.