Как тестировать приложение на ИИ, если вы никогда раньше не тестировали ПО
Практическое руководство по тестированию приложения на ИИ, когда у вас нет опыта в QA. Куда кликать, что ломать намеренно и как понять, что оно уже достаточно хорошо, чтобы им поделиться.
Вы построили приложение с ИИ. На счастливом пути оно работает — вы вводите своё имя, нажимаете кнопку, видите экран успеха. И что теперь? Готово ли оно к отправке трём бета-пользователям? Вашей команде? Вашим клиентам?
Если у вас нет ИТ-бэкграунда, тестирование кажется одной из тех вещей, которыми занимаются «настоящие разработчики» — с фреймворками, ассертами и CI-конвейерами. Хорошая новость: на самом деле большинство тестирования не такое. Большинство тестирования, особенно когда вы выпускаете что-то небольшое и новое, — это один человек, осмысленно кликающий вокруг. Это вы можете. Эта статья о том, как делать это намеренно, чтобы найти баги раньше, чем их найдут ваши пользователи.
Цель — не протестировать ваше приложение на ИИ как профи. Цель — протестировать его как параноидальный друг, который искренне хочет, чтобы оно работало.
Трюк с двумя списками
Прежде чем что-либо кликать, сядьте на десять минут с пустым документом и напишите два списка.
Список А — счастливые пути. Какие три-четыре вещи пользователь должен делать с этим приложением? Для типичного SaaS это может быть: зарегистрироваться, создать первый проект, пригласить одного коллегу, экспортировать результат. Для приложения-каталога: искать, фильтровать, кликнуть по карточке, сохранить её. Три-четыре реальных сценария, простыми словами.
Список Б — несчастливые пути. Что, если пользователь делает почти правильно, но не совсем? Вводит свой email с опечаткой. Нажимает кнопку «назад» посреди сценария. Открывает две вкладки и редактирует одно и то же в обеих. Отправляет пустую форму. Вставляет содержимое документа Word — вместе со всем форматированием — в текстовое поле. Закрывает ноутбук и открывает его снова через десять минут. Пытается пригласить коллегу по email-адресу, который уже есть в системе.
Список счастливых путей — это то, под что оптимизировал ваш ИИ-конструктор приложений. Это то, что ИИ мысленно протестировал, пока писал код. Список несчастливых путей — это то, где живут баги, потому что почти никто — ни ИИ, ни вы, когда писали промпты, — не думал об этих случаях.
Когда вы действительно тестируете, сначала пройдите по Списку А, чтобы подтвердить, что базовые вещи работают. Затем потратьте основную часть времени на Список Б. Список Б — это где ценность. Список Б — это также где вы выясняете, чего вы на самом деле хотите от приложения, когда всё идёт наперекосяк, и это часто вынуждает на проясняющий разговор с ИИ-конструктором («когда форма заполнена наполовину, нужно предупредить или автосохранить?»).
Три вещи, которые стоит сломать намеренно
Когда у вас есть списки, вот три категории, которые ловят большинство реальных багов в приложениях на ИИ.
Пустые и странные вводы. Отправьте форму, ничего не заполнив. Отправьте, заполнив одно поле. Отправьте имя длиной 500 символов. Отправьте имя с эмодзи. Вставьте URL в поле, которое ожидает имя. Попробуйте поле email с «test», с «test@», с «test@example», с адресом «a@b.co» — принимает ли оно нормальные короткие email-адреса? ИИ-конструкторы приложений часто добавляют валидацию, но валидация может быть неверной в любую сторону — слишком строгой (отвергает настоящих пользователей) или слишком мягкой (принимает мусор).
Движение назад и вбок. Большинство приложений работают нормально, если идти по ним как послушная экскурсионная группа. Они ломаются в тот момент, когда кто-то начинает исследовать. Нажмите кнопку «назад». Нажмите «вперёд» снова. Обновите страницу посреди сценария. Откройте одну и ту же страницу в двух вкладках и редактируйте в обеих. Выйдите и войдите снова. Если у вас есть кнопка «отменить», нажмите её три раза подряд. Это не крайние случаи. Это то, как реальные люди пользуются ПО.
Данные потом. Создайте то, что создаёт ваше приложение. Проект, пост, запись — что угодно. Затем вернитесь завтра. Оно всё ещё там? Пережило ли форматирование? Если вы его отредактируете, сохранится ли правка? Если вы его удалите, оно действительно исчезло или возвращается при обновлении? ИИ-конструкторы приложений часто отлично делают сценарий «создать» и забывают, что всё, что вы создаёте, должно сохраняться и редактироваться позже.
Как выглядит «достаточно хорошо»
Вы никогда не протестируете своё приложение на ИИ до совершенства. ПО слишком запутано, а ваше время слишком ценно. Вопрос не в том, «идеально ли оно», — вопрос в том, «достаточно ли оно хорошо для следующей группы людей, перед которыми я его поставлю».
Вот приблизительная иерархия, которую вы можете позаимствовать.
Достаточно хорошо для демо: счастливый путь работает без падений. Кнопки ведут туда, куда должны. Вы можете показать запись экрана, ничего не вырезая.
Достаточно хорошо для дружелюбных пользователей: несчастливые пути не теряют данные. Формы говорят вам, что не так, вместо того чтобы молча отказывать. Обновление страницы ничего не ломает. Три друга могут этим пользоваться, не пиша вам за помощью.
Достаточно хорошо для платящих пользователей: приложение справляется с пользователями, которых вы никогда не встречали. С их браузерами, их данными, их привычками. У вас есть способ видеть, когда что-то ломается (базового отслеживания ошибок достаточно — модный дашборд не нужен). Вы можете чинить и передеплоить, не ломая тех, кто уже пользуется.
Большинство разработчиков выпускают на уровне «дружелюбных пользователей» и затем повышают планку по мере поступления обратной связи. Это правильно. Ошибка — пытаться прыгнуть из «достаточно хорошо для демо» сразу в «достаточно хорошо для платящих пользователей» без промежуточного шага. Дружелюбные пользователи находят то, что нашли бы реальные пользователи, — но они не злятся из-за этого. Используйте этот разрыв.
Когда просить ИИ протестировать за вас
Ваш ИИ-конструктор приложений может помочь с тестированием, но вам нужно быть конкретным насчёт того, чего вы хотите. «Добавь тесты» — плохой промпт. Он сгенерирует код, который выглядит как тесты и, вероятно, проходит, не проверяя на деле ничего из того, что вам важно. Большинство таких автосгенерированных тестов подтверждают, что 1+1 по-прежнему 2.
Промпт получше: «Я только что попробовал отправить форму регистрации с пустым полем email, и оно упало. Найди, где это обрабатывается, и добавь проверку, которая показывает дружелюбную ошибку вместо этого». Конкретный баг, конкретное исправление, конкретный результат. В этом ИИ хорош. Он плох в «сделай так, чтобы моё приложение было без багов», потому что это не задача — это пожелание.
Ещё одна вещь, в которой ИИ-конструкторы хороши, — это воспроизведение вашего бага. Если вы опишете, что сделали, что ожидали и что произошло, конструктор обычно может пройти по коду и предложить исправление. Дисциплина, которая вам нужна, — это дисциплина ясно записать эти три вещи. Большинство отчётов о багах от новичков — это та или иная версия «оно не работает». Большинство исправимых отчётов о багах — это «я нажал X, ожидал Y, получил Z».
Тестирование — это чтение, а не только клики
И последнее. Вам не нужно понимать каждую строчку кода в вашем приложении на ИИ, чтобы хорошо его тестировать. Но вы должны хотя бы пробежать глазами. Откройте файл, который ИИ только что изменил. Прочитайте функцию, которую он добавил. Вам не нужно знать, что означает каждое ключевое слово, — вам нужно знать, делает ли функция то, что вы просили.
Многие баги, созданные ИИ, — это не «код сломан». Это «код делает что-то слегка отличное от того, что вы хотели». Поле сохраняется не туда. Кнопка обновляет одно, но не связанное с ним. Кнопка «удалить» скрывает вместо удаления. Вы не поймаете этого, не прочитав, что было на самом деле построено.
Относитесь к коду как к чему-то, что вы можете проверять, а не как к чему-то, что вы обязаны писать. В этом разница между приложением на ИИ, которому вы доверяете, и тем, на которое вы просто надеетесь, что оно работает.
Простая версия
Если вы не запомните ничего другого: напишите два списка, ломайте вещи намеренно и решите, на каком уровне «достаточно хорошо» вы выпускаете. Большинство багов в приложении на ИИ не тонкие. Они сидят в списке несчастливых путей, который никто не потрудился написать.
Если хотите небольшое домашнее задание: возьмите одно построенное вами приложение и попробуйте четыре вещи — отправьте пустую форму, нажмите обновление посреди сценария, отредактируйте запись и проверьте её завтра, попросите друга воспользоваться приложением без вашего наблюдения. Что бы ни сломалось — это ваш настоящий список багов. Всё остальное — прокрастинация.