Как протестировать приложение перед запуском: практический план

Чтобы протестировать приложение перед запуском, выпишите несколько сценариев, которые пользователь должен уметь пройти до конца, пройдите каждый как совершенно новый пользователь на ноутбуке и телефоне, а затем попробуйте способы, которыми всё может пойти не так: пустые данные, неверный ввод, второй аккаунт, медленное соединение. Всё, что связано с деньгами или личными данными, проверяйте особенно тщательно и повторите основные сценарии на живом URL после публикации. В конце понаблюдайте, как человек, который никогда не видел приложение, пытается им пользоваться.

Для этого не нужны команда QA или фреймворк для тестов. Нужны список, час-два времени и дисциплина, чтобы действительно пройти его по порядку.

Шаг 1: Запишите сценарии, которые важны

Сценарий — это задача от начала до конца, ради которой пользователь приходит. У большинства приложений их от трёх до шести действительно важных. Для приложения записи, например:

1. Зарегистрироваться и подтвердить аккаунт
2. Найти занятие и записаться
3. Отменить запись
4. Оплатить абонемент на занятия
5. Персонал: посмотреть сегодняшние записи

Если вы уже написали пользовательские истории, их критерии приёмки — это уже ваши тест-кейсы. Если нет, напишите по одной строке на сценарий с описанием того, как выглядит «успех».

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

Шаг 2: Проверьте основной путь как новый пользователь

«Основной путь» — это сценарий, который идёт ровно так, как задумано. Проверяйте его так, как его переживёт посторонний:

• Используйте приватное окно браузера, чтобы не быть залогиненным и не иметь сохранённых данных.
• Используйте новый аккаунт с реальным email, к которому у вас есть доступ.
• Начинайте с главной страницы или ссылки, а не со страницы, которую вы закладками сохранили во время разработки.

У новых пользователей нет данных. Многие баги проявляются только тогда, когда список пуст, у профиля нет фото или ещё ничего не куплено. Ваш собственный аккаунт, полный тестовых данных, эти баги скрывает.

Шаг 3: Попробуйте сломать

Теперь повторите каждый сценарий и сделайте что-то неправильно намеренно.

Обновление стоит проверить отдельно: если приложение работает, когда вы проходите по нему кликами, но обновление более глубокой страницы показывает 404, см. как исправить ошибки 404 после развёртывания.

Шаг 4: Проверьте права доступа двумя аккаунтами

Это самый важный тест для любого приложения с аккаунтами и тот, который чаще всего пропускают.

Создайте двух обычных пользователей, A и B, и (если в приложении они есть) администратора.

• Под A создайте запись. Войдите под B. Может ли B её увидеть, изменить или удалить? Не должен, если это не задумано дизайном.
• Под A скопируйте URL одной из ваших записей. Войдите под B и откройте этот URL напрямую.
• Под обычным пользователем откройте админ-страницы, введя их адреса вручную.
• Полностью выйдите из аккаунта и попробуйте те же адреса.

Если здесь вы нашли проблему, не запускайтесь, пока её не исправите. Проверка должна происходить на сервере, а не только за счёт скрытой кнопки. Наш чек-лист безопасности для приложений, созданных с помощью AI, раскрывает тему глубже.

Шаг 5: Проверьте на реальных устройствах

Откройте приложение на настоящем телефоне, а не только в узком окне браузера.

• Можно ли нажать каждую кнопку без масштабирования?
• Не перекрывает ли клавиатура поле, в которое вы печатаете?
• Прокручиваются ли таблицы и широкий контент или переносятся, а не сдвигают страницу в сторону?
• Читается ли текст без щипков?

Попробуйте хотя бы один iPhone (Safari) и один Android-телефон (Chrome), если можете их одолжить. Safari, в частности, имеет свои особенности с датами, видео и элементами с фиксированным позиционированием.

Шаг 6: Проверьте деньги и почту от начала до конца

Всё, что списывает деньги с карт или отправляет письма, требует полного прогона.

Платежи. Используйте тестовый режим вашего платёжного провайдера и тестовые номера карт. Проверьте успешную оплату, отклонённую карту и отменённое оформление. Убедитесь, что заказ или подписка появляются в вашем приложении после оплаты, а не только в панели провайдера. Если приложение опирается на вебхуки (сообщения, которые платёжный провайдер присылает вашему серверу), проверьте, что они приходят в опубликованном приложении, а не только в разработке. Затем, перед запуском, переключитесь на боевые ключи и сделайте одну небольшую реальную покупку, которую вы вернёте.

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

Шаг 7: Проверьте скорость и ошибки

• Откройте инструменты разработчика браузера (правый клик → Исследовать) и посмотрите вкладку Console на каждой основной странице. Красные ошибки стоит исправить, даже если ничего не выглядит сломанным.
• Загрузите сайт на телефоне через мобильную сеть, а не через Wi-Fi. Если первый экран грузится несколько секунд, сначала проверьте размеры изображений.
• Запустите бесплатный аудит, например Lighthouse в инструментах разработчика Chrome, чтобы быстро оценить производительность и доступность.

Шаг 8: Тестируйте опубликованное приложение, а не только предпросмотр

Предпросмотр и опубликованное приложение — это не одна и та же среда. Перед тем как рассказывать кому-либо о запуске, повторите основные сценарии на живом URL:

• Все переменные окружения и секреты заданы для опубликованного приложения?
• Используется ли правильная база данных с ожидаемыми данными?
• Ведут ли перенаправления при входе и ссылки в письмах на живой домен?
• Корректно ли загружается обновление глубокой страницы?

Шаг 9: Понаблюдайте, как пользуется кто-то другой

Дайте одному-двум людям цель («запишитесь на йогу в субботу»), а не инструкции. Наблюдайте, не помогая, и записывайте, где они колеблются. Это самый быстрый способ найти запутанные формулировки и спрятанные кнопки. Для более масштабной версии см. как провести бета-тестирование.

Когда они наткнутся на баг, опишите его как следует: шаги, ожидаемый результат и фактический результат. Наше руководство как написать хороший баг-репорт показывает формат.

Использование AI для тестирования

Если вы создаёте приложение с помощью AI, можно попросить его помочь спланировать и провести тесты:

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

Войди под двумя разными тестовыми пользователями и проверь, может ли пользователь B увидеть или изменить что-либо, созданное пользователем A, в том числе открыв URL записей A напрямую. Опиши, что нашёл, прежде чем что-либо исправлять.

Отчёт AI о тестировании считайте первым проходом. Сценарии с деньгами и правами доступа всё равно проходите сами.

Тестирование в Mythex

В Mythex команда /test запускает App Testing: агент управляет браузером на вашем живом предпросмотре, кликает по страницам, делает скриншоты и сообщает о сломанных сценариях в чате. Лучше всего она работает с конкретным сценарием, например «протестируй регистрацию и запись на занятие». Исправляйте найденное командой /fix или обычным сообщением, затем снова запустите /test. App Testing использует предпросмотр, поэтому после публикации основные сценарии на опубликованном URL проверьте сами. См. App Testing в документации и наше руководство как отлаживать приложение, созданное с помощью AI на случай, когда что-то не работает.

Частые ошибки

• Тестирование только под собой. Ваш админ-аккаунт с большим количеством данных скрывает баги пустых состояний и прав доступа.
• Тестирование только на ноутбуке. Многие посетители многих сайтов заходят с телефона.
• Пропуск второго аккаунта. Утечка данных между пользователями — самый серьёзный баг, с которым приложение может выйти.
• Доверие предпросмотру. У живого приложения другие настройки; тестируйте и его.
• Исправление багов без повторной проверки соседних функций. Исправление одной формы может сломать другую, которая использует тот же код.

Чек-лист перед запуском

• Основные сценарии выписаны и расставлены по приоритету
• Каждый сценарий проходит как совершенно новый пользователь в приватном окне
• Пустой, неверный, длинный и дублирующий ввод обработан
• Обновление работает на каждой странице
• Пользователи не видят и не могут изменить данные друг друга, даже через URL
• Админ-страницы закрыты для обычных пользователей и гостей
• Работает на реальном iPhone и Android-телефоне
• Платежи протестированы: успех, отказ, отмена, и приложение обновляется после них
• Письма приходят, не попадают в спам и ведут на живой домен
• В консоли основных страниц нет красных ошибок
• Основные сценарии повторены на опубликованном URL
• Хотя бы один посторонний человек попробовал приложение, пока вы наблюдали

Вопросы