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

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

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

Крок 1: Запишіть сценарії, які мають значення

Сценарій — це завдання від початку до кінця, яке користувач приходить виконати. У більшості застосунків є три–шість таких, що справді важливі. Для застосунку записів:

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

Якщо ви вже написали користувацькі історії, їхні критерії приймання — це вже ваші тест-кейси. Якщо ні, напишіть по одному рядку на сценарій з описом того, як виглядає «успіх».

Ранжируйте їх. Сценарії, які приносять гроші або які проходить кожен користувач (реєстрація, вхід, основна дія), тестуються першими і найретельніше.

Крок 2: Протестуйте щасливий шлях як новий користувач

«Щасливий шлях» — це сценарій, який іде точно так, як задумано. Тестуйте його так, як його бачила б стороння людина:

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

У нових користувачів немає даних. Багато помилок з’являються лише тоді, коли список порожній, у профілі немає фото або ще нічого не куплено. Ваш власний акаунт, повний тестових даних, їх приховує.

Крок 3: Спробуйте його зламати

Тепер повторіть кожен сценарій і свідомо зробіть неправильно.

Оновлення варто окремо відзначити: якщо застосунок працює, коли ви проходите його кліками, але оновлення глибшої сторінки показує 404, див. як виправити помилки 404 після розгортання.

Крок 4: Перевірте права доступу двома акаунтами

Це найважливіший тест для будь-якого застосунку з акаунтами, і його найчастіше пропускають.

Створіть двох звичайних користувачів, A і B, і (якщо вони є у вашому застосунку) адміністратора.

• Як A, створіть запис. Увійдіть як B. Чи може B його побачити, змінити або видалити? Не повинен, якщо це не передбачено дизайном.
• Як A, скопіюйте URL одного з ваших записів. Увійдіть як B і відкрийте цей URL напряму.
• Як звичайний користувач, відкрийте адмін-сторінки, набравши їхні URL.
• Повністю вийдіть і спробуйте ті самі URL.

Якщо тут знайшлася проблема, не запускайте застосунок, поки її не виправлено. Перевірка має відбуватися на сервері, а не лише через приховану кнопку. Наш чеклист безпеки для застосунків, створених AI, розглядає це глибше.

Крок 5: Тестуйте на реальних пристроях

Відкрийте застосунок на справжньому телефоні, а не лише у вузькому вікні браузера.

• Чи можна натиснути кожну кнопку без масштабування?
• Чи клавіатура не закриває поле, у яке ви вводите?
• Чи таблиці та широкий вміст прокручуються або переносяться, а не зсувають сторінку вбік?
• Чи текст читається без збільшення пальцями?

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

Крок 6: Протестуйте гроші й листи від початку до кінця

Все, що списує оплату з карток або надсилає листи, потребує повного проходження.

Платежі. Використовуйте тестовий режим вашого платіжного провайдера і тестові номери карток. Перевірте успішну оплату, відхилену картку і скасоване оформлення. Переконайтеся, що замовлення або підписка з’являються в застосунку після оплати, а не лише в панелі провайдера. Якщо ваш застосунок покладається на вебхуки (повідомлення, які платіжний провайдер надсилає вашому серверу), перевірте, що вони надходять на опублікованому застосунку, а не лише в режимі розробки. Потім перед запуском перейдіть на живі ключі і зробіть одну невелику реальну покупку, яку ви повернете.

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

Крок 7: Перевірте швидкість і помилки

• Відкрийте інструменти розробника браузера (клік правою кнопкою → Inspect) і подивіться вкладку Console на кожній основній сторінці. Червоні помилки варто виправити, навіть якщо нічого не виглядає зламаним.
• Завантажте сайт на телефоні через мобільний інтернет, а не Wi-Fi. Якщо перший екран завантажується кілька секунд, спершу перевірте розміри зображень.
• Запустіть безкоштовний аудит, наприклад Lighthouse в інструментах розробника Chrome, для швидкої оцінки продуктивності й доступності.

Крок 8: Протестуйте опублікований застосунок, а не лише попередній перегляд

Попередній перегляд і опублікований застосунок — це не одне й те саме середовище. Перш ніж розповідати комусь про запуск, повторіть основні сценарії на живій адресі:

• Чи встановлені всі змінні середовища і секрети для опублікованого застосунку?
• Чи використовується правильна база даних з очікуваними даними?
• Чи використовують перенаправлення після входу і посилання з листів живий домен?
• Чи коректно завантажується оновлена глибока сторінка?

Крок 9: Спостерігайте, як хтось інший його використовує

Дайте одній-двом людям мету («забронюйте заняття з йоги на суботу»), а не інструкції. Спостерігайте, не допомагаючи, і записуйте, де вони вагаються. Це найшвидший спосіб знайти заплутані формулювання й приховані кнопки. Для більшої версії цього див. як провести бета-тестування.

Коли вони натрапляють на помилку, запишіть її як слід: з кроками, очікуваним результатом і фактичним результатом. Наш посібник про як написати добрий звіт про помилку показує формат.

Використання AI для тестування

Якщо ви створюєте з AI, можна попросити його допомогти спланувати й провести тести:

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

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

Сприймайте звіт AI про тести як перший прохід. Усе одно самі пройдіть кліками сценарії, пов’язані з грошима і правами доступу.

Тестування в Mythex

У Mythex команда /test запускає App Testing: агент веде браузер по вашому живому попередньому перегляду, проходить сторінки, робить скриншоти і повідомляє про зламані сценарії в чаті. Вона найкраще працює з конкретним сценарієм, наприклад «протестуй реєстрацію і запис на заняття». Виправляйте знайдене командою /fix або звичайним повідомленням, а потім знову запустіть /test. App Testing працює з попереднім переглядом, тож після публікації перевіряйте основні сценарії на опублікованій адресі самі. Див. App Testing в документації та наш посібник як налагодити застосунок, створений AI на випадок, коли щось ламається.

Типові помилки

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

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

• Основні сценарії записані і ранжовані
• Кожен сценарій проходить як абсолютно новий користувач у приватному вікні
• Оброблено порожні, неправильні, довгі і дубльовані вхідні дані
• Оновлення працює на кожній сторінці
• Користувачі не можуть побачити або змінити дані одне одного, навіть через URL
• Адмін-сторінки заблоковані для звичайних користувачів і відвідувачів без входу
• Працює на справжньому iPhone і Android-телефоні
• Платежі протестовано: успіх, відмова, скасування, і застосунок оновлюється після цього
• Листи приходять, не потрапляють у спам і ведуть на живий домен
• Немає червоних помилок у консолі на основних сторінках
• Основні сценарії повторено на опублікованій адресі
• Принаймні одна стороння людина пройшла їх, поки ви спостерігали

Запитання