31. 10. 2026·15 хв читання

Скільки тестування потрібно сайту або застосунку перед запуском?

A smartphone with a checkout screen on a crash-test sled and a QA checklist with payments marked in red, cover of a Peretz article on testing before launch

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

КОРОТКО

Скільки тестування достатньо

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

Покупці помічають збої, навіть якщо ніколи про них не пишуть. У дослідженні Baymard Institute серед онлайн-покупців у США, які покинули замовлення на етапі оформлення, 17% назвали причиною помилки або падіння сайту, рівно стільки ж, скільки поскаржилися на задовге чи складне оформлення (Baymard, список оновлено у вересні 2025 року). Помилка в кошику рідко потрапляє у звіт як помилка: вона виглядає як конверсія трохи нижча, ніж могла б бути, місяць за місяцем.

Потрібний обсяг тестування визначає ціна збою.

ЦІНА ЗБОЮ

Спершу оцініть збій, потім тести

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

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

Найнебезпечніші збої стаються без шуму. Про форму, яка видає помилку, повідомлять за кілька годин. Форма, що дякує відвідувачу, а лист при цьому не приходить, може так працювати тижнями. Ми зіткнулися саме з цим на одному з наших проєктів, який не був у пріоритеті: під час оновлення з Laravel 7 до Laravel 13 зміна в налаштуванні шифрування пошти в Laravel 11 залишила б форму з подякою на екрані, а всі листи із заявками зникали б. Ми надіслали справжню тестову заявку й дочекалися листа, і лише після цього крок вважався завершеним.

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

КРИТИЧНІ СЦЕНАРІЇ

Що тестувати першим

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

Грошові сценарії. Оформлення замовлення з кожним способом оплати, повернення, купони, податки, вартість доставки та подовження підписок.
Реєстрація і вхід. Реєстрація, підтвердження пошти, скидання пароля та сесія, що закінчилася посеред оформлення замовлення.
Форми і заявки. Кожна форма від кліку відвідувача до поштової скриньки та CRM, з перевіркою, що лист не потрапляє в спам.
Листи і сповіщення. Підтвердження замовлень, рахунки, сповіщення про доставку та внутрішні оповіщення всіма мовами сайту.
Ролі і права доступу. Що кожна роль може бачити й змінювати, з перевіркою під реальним акаунтом кожної ролі.
Усе інше. Контентні сторінки, пошук, фільтри та адмінка.

Цей список працює завдяки двом звичкам. Кожна перевірка доходить до бізнес-результату, а не зупиняється на екрані: замовлення перевіряють, доки воно не з'явиться в адмінці й не піде лист на склад, заявку, доки вона не опиниться в CRM із зазначенням джерела. А тестувальник пробує те, що роблять реальні люди і забувають специфікації: два кліки по кнопці оплати, ім'я з апострофом, порожнє поле, кнопку «назад» після оплати, телефон, що втрачає зв'язок посеред оформлення.

Тест-кейси для цих сценаріїв, із кроками, даними та очікуваним результатом для кожної ролі, зберігаються в TestRail, Qase або Jira, щоб будь-хто міг повторити їх за місяць. На сторінці QA і тестування описано, наскільки глибоко йде кожен вид перевірки.

ПРИСТРОЇ І ШВИДКІСТЬ

Браузери, телефони і навантаження

Після критичних сценаріїв перевіряють середовище, в якому вони працюють. Вебпродукт тестують у Chrome, Safari, Firefox та Edge, на кількох розмірах екрана і на повільному з'єднанні. Safari заслуговує окремого проходу на справжньому iPhone, бо помилки верстки, яких ніколи не буває в Chrome, часто першими з'являються саме там. Playwright запускає той самий тест у Chromium, Firefox та WebKit і вміє емулювати телефони й планшети (документація Playwright, жовтень 2026 року). Емуляція все ж не замінює справжній телефон, коли йдеться про дотики, екранну клавіатуру та камеру.

Мобільним застосункам потрібні реальні пристрої: збірки з TestFlight і Firebase встановлюють на телефони, дібрані під вашу аудиторію, зокрема старі моделі, якими люди ще користуються, і хоча б один маленький екран. Поганий зв'язок, вхідний дзвінок під час оплати, push-сповіщення, яке відкриває не той екран: саме такі помилки користувачі знаходять уже за перший тиждень, якщо їх ніхто не шукав.

Швидкість завантаження сторінок перевіряють звичайними лабораторними інструментами до запуску. Навантаження відповідає на інше питання: що станеться, коли трафік, який ви очікуєте в день розпродажу, під час кампанії або після публікації в медіа, прийде одночасно. Навантажувальні тести в k6, JMeter або Gatling моделюють такий трафік і показують, що починає гальмувати першим: база даних, черга чи зовнішній API.

Найдорожчі помилки виглядають на екрані як успіх.

ДОСТУПНІСТЬ

Доступність стала юридичним ризиком

Якщо ви продаєте клієнтам у США, доступність сайту стала постійним джерелом судових позовів. Юридична фірма Seyfarth Shaw, яка відстежує справи за розділом III закону ADA, нарахувала 3 117 позовів щодо доступності сайтів, поданих до федеральних судів у 2025 році, на 27% більше, ніж 2 452 у 2024-му. Це 36% усіх федеральних позовів за розділом III ADA за рік. Найбільше позовів подано в Нью-Йорку (1 021) і Флориді (961) (Seyfarth Shaw, березень 2026 року). Позови в судах штатів і досудові претензії йдуть понад ці федеральні цифри.

Міністерство юстиції США застосовує розділ III до того, що пропонують бізнеси, відкриті для публіки, зокрема через свої сайти, але регламенту з детальними технічними стандартами не має; наявні стандарти, як-от WCAG, слугують корисним орієнтиром (ADA.gov, роз'яснення від березня 2022 року). На практиці мірилом є WCAG, і поточна версія це WCAG 2.2, рекомендація W3C, остання редакція якої датована 12 грудня 2024 року. Порівняно з WCAG 2.1 у ній дев'ять нових критеріїв, серед них фокус, який не перекривають закріплені елементи, мінімальний розмір кнопок і доступна автентифікація (W3C, жовтень 2026 року).

У Європі є жорстка дата. Європейський акт про доступність (European Accessibility Act) набув чинності 28 червня 2025 року (AccessibleEU, Європейська комісія), і до послуг, які він охоплює, належать електронна комерція та банківські послуги (Європейська комісія). Мікропідприємства, що надають послуги, тобто компанії з чисельністю менше 10 осіб і річним оборотом або балансом не більше €2 млн, звільнені від вимог; мікропідприємства, що продають товари, ні (CCPC, відомство із захисту прав споживачів Ірландії). Компанії за межами ЄС, яка продає онлайн покупцям у ЄС, варто виходити з того, що вимоги стосуються і її магазину.

Дослідження WebAIM Million 2026 знайшло автоматично виявні порушення WCAG на 95,9% головних сторінок із мільйона найвідвідуваніших сайтів, у середньому 56,1 помилки на сторінку. Текст із низьким контрастом трапився на 83,9% з них, зображення без альтернативного тексту на 53,1%, поля форм без підписів на 51% (WebAIM, дані за лютий 2026 року). Усе це знаходить базова перевірка.

Базова перевірка доступності перед запуском охоплює навігацію з клавіатури всім сценарієм покупки чи заявки, видимий фокус, текстові альтернативи для зображень, підписи та повідомлення про помилки у формах, колірний контраст і правильні заголовки. Ті самі виправлення допомагають програмам, які читають ваші сторінки: у двох із 15 перевірених нами інтернет-магазинів США спливне вікно підписки залишало в дереві доступності лише iframe, і ШІ-агент для покупок не бачив ні ціни, ні кнопки. Експеримент описано в статті про те, як ми відправили ШІ-агента по покупки в 15 магазинів США. Якщо продукту потрібен повний аудит у фахівця або формальний звіт про відповідність, ми так і кажемо.

БЕЗПЕКА І ДАНІ

Базова безпека і перенесення даних

Тестування перед запуском не замінює тест на проникнення, але має ловити слабкі місця, що трапляються знову і знову. Хто може бачити й змінювати які дані, з перевіркою під кожною роллю, і чи перевіряє це правило сервер, чи інтерфейс просто ховає кнопку. Ключі та платіжні реквізити, залишені в коді, який виконується в браузері. Введення, що потрапляє в базу без перевірки, і сторінки помилок, які показують відвідувачам налаштування. Для продукту, швидко зібраного за допомогою ШІ-інструментів, ці перевірки ще важливіші: інтерфейс там часто виглядає готовим, а правила доступу так і не написали. Для такого продукту ми починаємо з оцінки MVP, від $3 000: вона показує, що залишити, що виправити і що переписати, а тестування потім охоплює те, що лишається.

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

кількість записів до і після для товарів, клієнтів і замовлень;
акаунти, в які досі можна увійти, з історією замовлень у потрібного клієнта;
редиректи з усіх старих адрес, що мали трафік або посилання;
поштові налаштування на новому сервері, бо без записів SPF і DKIM заявки починають потрапляти в спам;
robots.txt і доступ краулерів, адже новий хостинг може за замовчуванням закрити сайт від пошукових і ШІ-краулерів.

Останній пункт не теоретичний. На одному нещодавньому проєкті після переїзду на новий хостинг-акаунт GPTBot і краулери Meta почали отримувати помилку 403, а хостинг сам додав їх у robots.txt. Решта списку в нашій статті про те, які пункти перенесення сайту агенції зазвичай пропускають.

РЕГРЕСІЯ

Тестування після кожного оновлення

Будь-яке оновлення фреймворку, CMS, плагіна чи платіжного модуля може зламати те, що вчора працювало, а регресійне тестування це набір перевірок перед кожним релізом, який підтверджує, що все досі працює. За час життя сайту саме воно стає головною статтею витрат на тестування.

Наші власні оновлення показують, що зазвичай знаходить регресія. Нещодавно ми перевели один із наших проєктів, який не був у пріоритеті, з Laravel 7 на 13, а сайт Інституту трихології та його інтернет-магазин на OpenCart 3.0.5.1. Найчастіше в цих оновленнях спливали проблеми верстки та CSS: стилі, прив'язані до старих версій бібліотек, з'їжджали після оновлення. Кожна така проблема проявилася на тестовій копії і була виправлена до релізу, і оновлені системи просто запрацювали, коли вийшли в робочий режим.

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

Після приблизно трьох днів розробки один день приймання охопив 15 публічних сторінок трьома мовами, 30 екранів адмінки, справжню тестову заявку, журнал помилок і 987 внутрішніх посилань. Уся історія в нашому кейсі про те, як ми пройшли шість версій Laravel за три дні. Для живого сайту такі планові оновлення з регресією на копії входять у підтримку та обслуговування сайтів, від $1 000 на місяць, а повна регресія перед великим релізом замовляється як робота QA.

АВТОМАТИЗАЦІЯ

Ручне чи автоматичне тестування

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

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

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

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

Автоматизуйте те, що усталилося, а те, що змінюється, перевіряйте руками.

Наскрізні тести пишуть на Playwright, Cypress або Selenium, вони живуть у вашому репозиторії і запускаються у вашому пайплайні: GitHub Actions, GitLab CI або Jenkins. Тест, який час від часу падає, лагодять або прибирають, а не перезапускають до зеленого результату, бо нестабільні тести привчають команду не зважати на червоні збірки. Сам пайплайн, тестова копія і відкат, що виконується відомою командою, це робота інженерів із DevOps і хмарної інфраструктури, від $50 до $70 на годину.

ОБСЯГ ЗА ПРОЄКТОМ

Розумний обсяг тестування за типом проєкту

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

Проєкт	Чого коштує збій	Розумний обсяг перед запуском	Звичайний формат
Корпоративний сайт або сайт-візитка	Втрачена заявка, погане перше враження	Кожна форма до пошти і CRM, основні сторінки в чотирьох браузерах і на телефонах, швидкість, базова доступність	Разова перевірка
Сайт для заявок із CRM	Заявки, що зникають, поки форма дякує відвідувачу	Те саме плюс шлях кожної форми в CRM, сповіщення, перевірка теки «Спам», події аналітики	Разова перевірка, регресія після оновлень
Інтернет-магазин	Втрачені замовлення, повернення, зірваний розпродаж	Оформлення з кожним способом оплати і доставки, податки та знижки, листи про замовлення, навантажувальний тест перед піками	Тестувальник перед запуском, регресія перед кожним релізом
Вебзастосунок або SaaS із ролями	Дані одного клієнта видно іншому, зламаний білінг	Права для кожної ролі на боці сервера, API, білінг, регресійний набір, автотести критичних сценаріїв	QA з першого спринту, автоматизація
Мобільний застосунок	Падіння на пристроях, які ніхто не перевірив, повільні виправлення через рев'ю магазинів	Реальні iPhone та Android-телефони, поганий зв'язок, push-сповіщення, API, оплата в застосунку	Ручне тестування, Appium після стабілізації
MVP або продукт, зібраний із ШІ	Відкриті ключі, відсутні правила доступу, оплата, що падає на граничних випадках	Спершу рев'ю коду, потім критичні сценарії та граничні випадки	Оцінка MVP, потім прицільне тестування
Перезапуск або переїзд на іншу платформу	Втрачені дані, просілі позиції, листи в спамі	Кількість записів, акаунти та історія замовлень, редиректи, поштові записи, доступ краулерів, повна регресія	Чек-лист перенесення плюс регресія

Коли продукт робимо ми, тестування не купується окремо. У розробці MVP, від $20 000, дизайн, розробка, тестування і запуск входять в одну фіксовану ціну за погоджений обсяг, а QA працює з першого спринту.

Винятком може бути невеликий внутрішній інструмент. Нашу власну систему для заявок, проєктів і рахунків приблизно за місяць зробили senior-розробник, який сам її і тестував, та розробник рівня junior-middle. Уважний senior може перевіряти свою роботу, поки користувачі це колеги. Коли з'являються клієнти, платежі або часті релізи, окремий тестувальник окупається, бо автор сценарію зазвичай перевіряє його так, як той задуманий, а не так, як його ламають користувачі.

ВАРТІСТЬ

Скільки коштує тестування

У Peretz Agency QA і тестування коштують від $30 на годину, це стартова ставка за ручне тестування. Інженери з автоматизації, старші QA та вузькі навички, наприклад навантажувальне тестування, коштують дорожче. Ви оплачуєте відпрацьовані години за рахунком раз на місяць або фіксовану суму на місяць за тестувальника на повний день, банківським переказом за договором; у ставку входять робота фахівця, договори, техніка, HR-супровід і звітність.

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

Тестування можна замовити трьома способами:

Разова перевірка перед запуском, переїздом або великим релізом, з обсягом, погодженим заздалегідь. Підходить сайту, що змінюється рідко.
QA-інженер у вашій команді, який бере завдання у вашого керівника у вашому трекері. Ми надсилаємо шорт-лист, від 2 до 4 перевірених кандидатів, зазвичай у строк від 1 до 3 тижнів; перший місяць випробувальний, і якщо фахівець вам не підходить, достатньо попередити щонайменше за два тижні. Як відбувається добір, описано на сторінці Найняти QA-інженера.
QA всередині проєкту, який робимо ми, входить у ціну проєкту.

Для порівняння: медіанна річна зарплата аналітика із забезпечення якості або тестувальника ПЗ у США в травні 2025 року становила $104 300, без урахування соцпакета і витрат на найм (Бюро статистики праці США, жовтень 2026 року). Наші тестувальники приходять із великого пулу фахівців у Європі та Україні, яких ми знаємо особисто й перевірили самі. Усі наші ціни на сторінці цін.

FAQ

Часті запитання

Скільки тестування потрібно сайту перед запуском?

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

Що має бути в чек-листі QA перед запуском?

Спершу критичні сценарії: оформлення замовлення та оплата, реєстрація і вхід, форми та листи із заявками, листи про замовлення і системні листи, права кожної ролі. Далі реальні пристрої та браузери, швидкість і навантаження, базова доступність і безпека, а під час перезапуску перенесення даних.

Скільки коштує QA-тестування?

У Peretz Agency QA і тестування коштують від $30 на годину за ручне тестування; автоматизація та старші інженери дорожчі. Разову перевірку перед запуском оцінюємо й погоджуємо до початку роботи. Платні інструменти та виправлення помилок до ставки тестування не входять.

Коли окупається автоматизація тестів?

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

Чи обов'язкова перевірка доступності сайту за законом?

У США Міністерство юстиції застосовує розділ III ADA до бізнесів, відкритих для публіки, зокрема до їхніх сайтів, і у 2025 році до федеральних судів подали 3 117 позовів щодо доступності сайтів. У ЄС Європейський акт про доступність діє з 28 червня 2025 року для таких послуг, як електронна комерція, з винятком для мікропідприємств, що надають послуги.

Що зазвичай ламається під час оновлення чи перезапуску сайту?

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

Джерела

Скоро запуск і незрозуміло, скільки тестувати? Подивімося, скільки вам коштуватиме збій.

Записатися на стратегічну сесію

QA і тестування