Багато перевірок сайту починаються з дії людини після випуску: прочитати заголовок, відкрити меню, перевірити безпечний стан форми або переконатися, що таблиця тарифів має сенс. Перетворювати кожну таку дію на набір тестів із кодом може бути зайвою роботою. Якщо залишити все в пам'яті, результат важко повторити.
RenderLog дає таким перевіркам збережене місце. Набір перевірок може містити сценарії, дії, очікувані результати, області перегляду та візуальні еталони. Той самий сценарій можна уточнювати вручну, запускати після розгортання через CI або API чи виконувати за розкладом.
Описуйте стан, який людина вже вміє перевіряти
Починайте з видимого результату, а не з технічної реалізації. Для сторінки реєстрації це можуть бути обов'язкові поля й доступна дія надсилання. Для сторінки з цінами - плани, валюта та основна дія. Для документації - заголовок, навігація й потрібна фраза у відображеній сторінці.
Додавайте дії лише тоді, коли вони приводять браузер до потрібного стану. Потім опишіть очікуваний результат перевіркою. RenderLog підтримує перевірки видимих елементів, тексту, значень полів і позначених станів, а також візуальний результат. Короткий сценарій із ясною відповіддю легше підтримувати, ніж довгий процес без рішення наприкінці.
- Заголовки та вміст сторінки, які мають залишатися після зміни тексту
- Форми, меню та стани інтерфейсу, до яких веде короткий шлях
- Важливі для SEO тексти та стани метаданих у відображеній сторінці
- Ділянки макета, для яких погоджений еталон спрощує перегляд зміни
Перетворюйте знімок на перевірку за допомогою очікуваних результатів
Знімок показує відображений результат, але сам по собі не пояснює очікування. Перевірка додає рішення: цей заголовок має існувати, цей текст має бути видимим, поле має містити значення або елемент має бути позначеним. Перша перевірка має бути близькою до ризику, через який ви зберегли тест.
Візуальне порівняння відповідає на інше питання. Воно допомагає побачити зміну макета, відступів або адаптації відносно погодженого еталона. Поєднуйте їх, коли вони доповнюють одне одного. Якщо запуск потрапляє на сторінку входу, CAPTCHA або відсутній селектор, правила помилки мають позначити це як невдалий результат.
- Називайте потрібний текст, щоб рецензент не вгадував очікування за пікселями
- Використовуйте візуальний еталон для змін макета й адаптації
- Завершуйте запуск помилкою, коли отримано неправильний стан
- Тримайте сценарії достатньо вузькими для зрозумілого рішення
Запускайте той самий тест там, де команда вже працює
No-code тест корисний, коли відповідає ритму команди. Запускайте його вручну під час редагування, з CI після випуску, через API із процесу розгортання або за розкладом для сторінок, які змінюються окремо. Збережений сценарій тримає очікування та історію разом, а спосіб запуску може змінюватися.
Переглядайте результат запуску, а не перетворюйте розклад на скриньку з повідомленнями. Невдала перевірка, змінений еталон або неправильний результат мають підказати наступну дію. Якщо ніхто не відповідає за помилку, зменште обсяг тесту або визначте шлях сповіщення.
- Уточнюйте сценарій ручними запусками до його регулярного виконання
- Запускайте збережені перевірки з робочого простору, API, CI або за розкладом
- Переглядайте знімки, результати перевірок та історію разом
- Надсилайте сповіщення людині, яка може виправити стан
Тримайте no-code перевірки точними та чесними
No-code перевірки добре підходять для видимих сторінок, коротких процесів, перевірок вмісту та візуального перегляду. Вони не скасовують тестів на рівні коду, роботи з доступністю, рішень щодо браузерів чи повного end-to-end набору для складної логіки. Вони також не роблять сторонню залежність передбачуваною.
Найкращий перший набір невеликий. Оберіть сторінку, визначте стан, напишіть перевірку, запустіть один раз і погодьте процес перегляду. Додавайте сценарій лише тоді, коли попередній результат корисний. Так історія залишається читабельною, а помилка стосується сторінки, а не окремого проєкту з підтримки тестів.
Оберіть наступний шлях у RenderLog
Переглянути посібники RenderLog
Відкрийте практичні посібники про no-code перевірки, візуальний перегляд і API.
Посібник: як тестувати форми сайту без коду
Почніть із видимого стану форми та збережіть лише потрібні повторювані перевірки.
Моніторинг змін на сайті
Зберігайте повторювані перевірки для публічних сторінок, випусків і важливих станів.
API знімків сайту
Використовуйте запит, коли продукту чи процесу потрібен готовий файл.
Посібник: no-code перевірки сторінок і форм
Починайте зі стану, який уже перевіряє людина, і зберігайте лише потрібні сценарії.
Посібник: SEO-перевірки для сайтів
Поєднуйте вміст, візуальні докази та no-code перевірки важливих сторінок.
Посібник: рано завершуйте неправильні результати
Не давайте сторінкам входу, CAPTCHA та відсутнім селекторам виглядати як успішні запуски.
Збережіть наступну перевірку, яку інакше повторювали б вручну
Назвіть стан сторінки, додайте важливу перевірку та запустіть сценарій один раз. Залишайте його лише тоді, коли результат дає команді зрозуміле рішення.