Тестируем ваше AI-приложение глазами постороннего человека (пока баги не нашли ваши пользователи)

Почему баги вылезают только тогда, когда приложением пользуется кто-то другой?

Потому что вы уже точно знаете, как пользоваться тем, что сами построили — вы наводите курсор куда нужно, никогда не выбираете дату из прошлого, тестировали на десктопе. «Тестирование посторонним» — это когда вы отдаёте готовое приложение человеку, который никогда его не видел, и в реальном времени наблюдаете, что ломается, сбивает с толку или останавливает его — раньше, чем это увидят настоящие пользователи.

Вы построили приложение для бронирования с помощью своего AI-конструктора. Тестируете сами: выбираете дату, вписываете имя, подтверждаете. Работает.

Пробует коллега: выбирает дату, видит, что часовой пояс перепутан. Замешательство. Уходит.

Пробует мама: случайно выбирает дату из прошлого — приложение падает.

Пробует друг с телефона: календарь не открывается (по полю просто не получается тапнуть).

Ни один из этих багов не сложный. Но все они невидимы для вас, потому что вы точно знаете, как пользоваться тем, что сами построили. Посторонний человек найдёт каждый краевой случай, который вы пропустили. Хорошая новость: тестирование глазами постороннего — дёшево, и оно ловит именно то, что действительно важно.

Как протестировать приложение глазами постороннего?

Отдайте приложение человеку, который о нём даже не знал, понаблюдайте, как он пробует его «с холода», и запишите, что ломается или сбивает с толку. QA-команда не нужна. Нужен один человек и 10 минут.

Способ первый: спросить реального человека (15 минут)

Напишите другу: «Можешь по-быстрому попробовать и сказать, что думаешь?» Дайте ссылку, пусть повозится 5–10 минут, а потом спросите:

Что вы пытались сделать?
Всё сработало так, как вы ожидали?
Что сбило с толку?
Что бы вы изменили?

Вас ждут сюрпризы. «Я не смог найти кнопку отправки» (потому что вы спрятали её в модальном окне). «Я не знал, что нужно заполнить email» (потому что вы не пометили поле как обязательное). «Почему в моей брони указан вторник, если я выбрал среду?» (проблема с часовым поясом, которую вы не заметили).

Почему это работает: реальный человек проходит и по «счастливому пути», и по случайно сломанным путям, о которых вы даже не думали.

Но есть нюанс: скорее всего, человек будет к вам добр. Он может не сказать, что что-то реально плохо работает, просто чтобы не задеть ваши чувства. Смотрите больше на его лицо, чем на слова.

Способ второй: протестировать на устройстве, которым вы не пользуетесь (5 минут)

Если вы строили на десктопе — протестируйте на телефоне. Если строили на телефоне — протестируйте на планшете.

Откройте приложение и попробуйте:

Тапнуть кнопку у самого края экрана (она может оказаться обрезанной)
Прокрутить, не задумываясь (работает ли скролл?)
Заполнить дату (есть ли нормальный календарь, или приложение ждёт, что вы её напечатаете?)
Сделать фото, если приложение работает с изображениями (какой формат, какой размер, насколько быстро?)

Большинство AI-конструкторов неплохо делают адаптивную вёрстку, но вас удивит, что именно ломается на ширине 375px или на медленном соединении.

Почему это работает: мобильное устройство меняет всё — и то, насколько быстрым кажется приложение, и то, как люди с ним взаимодействуют. Двухсекундный запрос к базе данных на десктопе — это нормально. На телефоне в сети 4G это ощущается как что-то сломанное.

Но есть нюанс: это работает ровно настолько, насколько хватает вашего терпения. Протестируйте один сценарий целиком, от начала до конца, на одном устройстве. Не устраивайте экскурсию — выполняйте задачу.

Способ третий: тест по чек-листу (10 минут)

Если вы ещё не готовы звать реальных людей, протестируйте приложение сами, но так, будто видите его впервые:

Откройте приложение. Забудьте, что именно вы строили. Как вы думаете, что делает это приложение?
Выберите первое, что выглядит кликабельным. Не думайте о том, что вы хотели, чтобы оно делало. Делает ли оно то, что вы бы предположили?
Попробуйте выполнить основную задачу (забронировать что-то, заполнить форму, создать пост), не заглядывая в подсказки. Получилось с первого раза?
Найдите обязательные поля. Помечены ли они наглядно? (Один только цвет заметен не всем.)
Совершите ошибку (оставьте поле пустым, введите неверные данные). Сообщает ли приложение, что не так?
Попробуйте на телефоне. Читается ли текст? Можно ли попасть по кнопкам?

Это не замена реальным тестировщикам, но это лучше, чем выпускать что-то непротестированное.

На что обращать внимание, пока кто-то тестирует ваше приложение?

Следите за паузами и колебаниями, обходными путями, невнятными состояниями ошибок, вялым поведением на мобильном и данными, которые как будто исчезают — за каждым из этих признаков стоит конкретная, исправимая проблема.

Заминка: если человек медлит перед тем, как нажать кнопку, — кнопка недостаточно очевидна. Если он спрашивает «мне это нужно заполнять?» — поле помечено недостаточно ясно.

Обходной путь: если он пытается сделать что-то, что не срабатывает, и находит другой способ — у вас UX-обрыв. (Пытается отправить форму нажатием Enter вместо клика по кнопке. Пытается очистить поле тройным кликом вместо крестика.)

Состояние ошибки: если что-то ломается — сетевая ошибка, ошибка валидации, таймаут — объясняет ли приложение, что делать дальше? Или просто показывает сердитую красную рамку?

Мобильный опыт: если на регистрацию тапа уходит три секунды, человек решит, что приложение сломано (скорее всего, нет — просто медленная сеть, — но ощущается именно так). Если он не видит текст из-за низкого контраста, он не станет жаловаться — просто уйдёт.

Путаница с данными: если человек что-то создал, а потом не может это найти, или думал, что сохранил, а оно не сохранилось — это баг, который живёт в схеме вашей базы данных. Конструктор, скорее всего, сделал именно то, что вы просили, но то, что вы просили, не совпадает с тем, чего ждут пользователи.

Может ли ваш AI-конструктор исправить баги, которые нашёл посторонний?

Да — как только вы опишете, что именно увидели, а не то, в чём, по-вашему, проблема, конструктор может исправить это напрямую. Вам не нужно чинить это самостоятельно:

«Поле даты не работает на мобильном» → конструктор может заменить его на нормальный календарь.
«Форма не показывает, какие поля обязательны» → конструктор может добавить визуальные пометки.
«Не могу найти, куда нажать, чтобы отправить» → конструктор может сделать кнопку крупнее или переместить её.
«Когда я опечатываюсь, я понятия не имею, что пошло не так» → конструктор может добавить встроенную валидацию.

Главное — быть конкретным насчёт того, что вы увидели, а не того, в чём, по-вашему, проблема. «Приложение сбивает с толку» не помогает. «Я заполнил три поля и не смог найти, куда нажать дальше» — помогает.

Тест на постороннего — каждый раз

Прежде чем сказать, что всё готово, прежде чем показать это реальным пользователям — отдайте приложение человеку, который не знает, что это вы его построили. Понаблюдайте, как он пользуется им «с холода». Запишите, что ломается.

Вы найдёте:

Баги, о существовании которых даже не подозревали
Сценарии, которые оказались сложнее, чем вы думали
Допущения, которые вы сделали, но которые пользователи не разделяют

Самое приятное: этот тест бесплатный, занимает 10 минут и сокращает количество сообщений в духе «а почему это не работает?» вдвое.

Переключите часовой пояс на телефоне на что-нибудь странное, воспользуйтесь своим приложением и возвращайтесь, если найдёте что-то интересное.