Як тестувати вебформи без коду

Почніть з одного стану форми

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

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

Підготуйте стабільний стан сторінки

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

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

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

Перевіряйте видимі очікування

Знімок може показати, що форма виглядає завершеною, але текстова перевірка явно фіксує важливу умову. Перевірте заголовок, текст згоди, підпис кнопки або повідомлення про успішне надсилання. Для поля перевірте значення чи стан, якому має довіряти людина.

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

Прив'язуйте перевірки до призначення форми. Не перевіряйте кожен декоративний підпис. Невеликий набір важливих очікувань переживає навмисні зміни тексту й дає зрозумілу причину невдачі.

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

Перевіряйте помилку й успіх окремими результатами

Форма може тихо зламатися, коли повідомлення про помилку зникає або помилка сервера виглядає як успіх. Якщо важливі обидва стани, створіть окремі сценарії. Для помилки використайте безпечне неповне чи неправильне значення та перевірте видиме повідомлення. Для успіху перевірте екран або блок, який має з'явитися після прийняття даних.

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

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

Розбирайте невдалу перевірку форми

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

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

Окремо перевірте адресу сторінки, локаль, тестові значення та час очікування. Такий короткий список часто показує, що змінилася не форма, а стан, у якому її відкрив запуск.

Знайте, коли краще підійде тест у коді

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

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