Ручне vs автоматизоване тестування: що потрібно малому бізнесу.

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

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

У чому різниця між ручним та автоматизованим тестуванням

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

Автоматизоване тестування — це коли ті самі сценарії записані кодом, і програма виконує їх сама. Наприклад, скрипт на Playwright відкриває браузер, додає товар, проходить checkout і перевіряє, що замовлення створилося. Запускається за кілька хвилин і повторюється скільки завгодно разів.

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

Що саме ловить ручне тестування

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

• Логічні помилки: знижка застосовується двічі, доставка рахується некоректно для певного міста.
• Проблеми зручності: кнопка під клавіатурою на мобільному, незрозуміле повідомлення про помилку, форма, що очищається після невдалої валідації.
• Візуальні дефекти: текст, що налізає, зображення, що розтягнулися, неправильний шрифт.
• Нестандартні шляхи: повернутися «назад» після оплати, відкрити кошик у двох вкладках, змінити кількість до нуля.
• Реальні пристрої: старий Android, Safari на iPhone, повільна мережа.

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

Ручне тестування потрібне перед запуском нового сайту, після великих змін, при додаванні складного функціоналу (оплата, інтеграція з доставкою, особистий кабінет). У нас це послуга ручного тестування сайтів від $20 за годину; для магазину є окремий QA-аудит від 6 000 грн.

Що саме ловить автоматизоване тестування

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

Кандидати на автоматизацію в магазині:

1. Реєстрація й вхід користувача.
2. Додавання товару в кошик, зміна кількості, видалення.
3. Оформлення замовлення гостем і зареєстрованим клієнтом.
4. Застосування промокоду.
5. Оплата в тестовому режимі платіжки.
6. Пошук і фільтри каталогу (базові випадки).
7. Форми заявок і зворотного зв'язку.

Приклад простого автотесту на Playwright:

import { test, expect } from '@playwright/test'

test('гість може оформити замовлення', async ({ page }) => {
  await page.goto('/catalog/krosivky-run')
  await page.getByRole('button', { name: 'Додати в кошик' }).click()
  await page.goto('/cart')
  await page.getByRole('link', { name: 'Оформити замовлення' }).click()

  await page.getByLabel('Телефон').fill('+380501234567')
  await page.getByLabel("Ім'я").fill('Тест Тестович')
  await page.getByRole('button', { name: 'Підтвердити' }).click()

  await expect(page.getByText('Дякуємо за замовлення')).toBeVisible()
})

Такий тест виконується за кілька секунд і запускається автоматично при кожному оновленні коду. Якщо хтось зламав кнопку «Підтвердити», ви дізнаєтеся до релізу, а не зі скарги покупця. У нас є окрема послуга автоматизації тестування: Playwright-сценарії ключових шляхів і запуск у CI, вартість визначається після аудиту.

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

Скільки це коштує: порівняння за порядком величини

Точні суми залежать від проєкту, тому дамо орієнтири з нашого прайсу й логіку витрат.

• Ручне тестування — погодинна оплата: ставка QA-інженера $20–25 за годину. Витрати повторюються при кожному релізі, але гнучко масштабуються: не треба нічого будувати наперед. Для магазину разовий QA-аудит із чек-листом 150+ пунктів стартує від 6 000 грн.
• Автоматизація — разова інвестиція в написання й налаштування плюс невелика підтримка. Перші сценарії готові приблизно за 1–2 тижні. Далі кожен прогін майже безкоштовний.

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

Не впевнені, з чого почати? Ми зробимо безкоштовний експрес-чек вашого сайту за 48 годин і підкажемо, де достатньо ручної перевірки, а де вже час на автотести. Деталі — на сторінці ручного тестування.

Як вирішити, що потрібно саме вам

Замість абстрактних порад скористайтеся простою схемою рішень за ситуацією.

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

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

Сайт працює, оновлення нечасті

Ручний регрес перед кожним релізом за готовим чек-листом. Складіть із 20–30 пунктів найважливіше (оформлення замовлення, оплата, форми) і проходьте після змін. Це дешево й надійно.

Оновлення часті, а помилки у checkout уже коштували замовлень

Час на автотести критичних шляхів. Починайте з трьох-п'яти сценаріїв, що безпосередньо приносять гроші: кошик, checkout, оплата. Типові баги в цих місцях ми розбирали в статті чому губляться замовлення на checkout.

Розробка ведеться постійно, є команда

Поєднуйте обидва підходи: автотести в CI на кожен pull request, ручне тестування нових фіч перед випуском. Виділений QA в команді (part-time чи full-time) закриває це без наймання штатного співробітника, деталі — у форматі виділеного спеціаліста.

З чого почати: покроковий план на місяць

Реалістичний сценарій для малого магазину без тестування взагалі:

1. Тиждень 1. Ручний QA-аудит: проходимо весь сайт за чек-листом, фіксуємо баги з відео та пріоритетами. На виході — список проблем і набір тест-кейсів.
2. Тиждень 2. Виправлення критичних і серйозних багів. Повторна перевірка виправленого.
3. Тиждень 3. Вибираємо 3–5 найважливіших тест-кейсів для автоматизації: ті, що торкаються грошей. Пишемо Playwright-сценарії.
4. Тиждень 4. Підключаємо запуск автотестів до процесу розгортання (CI). Домовляємося про правило: реліз не виходить, якщо автотести червоні.

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

Що потрібно, щоб автотести справді працювали

Автотести — не «встановив і забув». Вони потребують трьох речей, без яких швидко перетворюються на джерело шуму.

Стабільне тестове середовище

Тести мають запускатися на окремому стенді з тестовими даними, а не на живому магазині. Для оплати використовується тестовий режим платіжки, для Нової Пошти — тестовий ключ або заглушка. Це дозволяє безпечно створювати замовлення й не плутати їх зі справжніми. База даних перед прогоном скидається до відомого стану: інакше тест, що вчора проходив, сьогодні впаде через чужі дані.

Стійкі селектори та сценарії

Тест, прив'язаний до верстки («третій div у другому блоці»), ламається від будь-якої правки дизайну. Надійніше шукати елементи за роллю та підписом (кнопка «Підтвердити», поле «Телефон»), як у прикладі вище, або за спеціальними атрибутами для тестів. Тоді змінити колір чи відступ можна без ремонту тестів.

Запуск у CI і правило реакції

Автотест має сенс тільки тоді, коли його запускають автоматично й хтось реагує на червоний результат. Типова схема: тести стартують на кожен pull request і перед релізом, а звіт із відео та трасою падіння доступний усій команді. Домовтеся про просте правило: якщо тести червоні, реліз не виходить, поки причину не з'ясовано. Падіння може бути як реальним багом, так і застарілим тестом, але ігнорувати його не можна.

Приклад розрахунку окупності

Візьмемо умовний приклад, щоб показати логіку, а не конкретні цифри для вашого бізнесу. Припустимо, повний ручний регрес ключових сценаріїв займає 3 години, а оновлення виходять раз на тиждень. За рік це близько 50 прогонів по 3 години, тобто 150 годин. За ставки QA-інженера $20–25 за годину це десятки тисяч гривень на рік тільки на повторення однієї й тієї самої перевірки.

Автоматизація тих самих сценаріїв — разові витрати на 1–2 тижні роботи й невелика щорічна підтримка тестів. Прогін автотестів займає хвилини, і людина потрібна лише для розбору падінь. У такому прикладі автоматизація окупається протягом першого-другого кварталу. Якщо ж релізи раз на квартал, тих самих чотирьох прогонів на рік не вистачить, щоб виправдати витрати, і дешевше лишити ручний регрес.

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

Типові помилки малого бізнесу

• Автоматизувати все й одразу. Великий набір крихких тестів — тягар: вони падають через дрібниці, і їх перестають слухати. Краще мало, але стабільно.
• Автоматизувати нестабільний інтерфейс. Якщо дизайн змінюється щотижня, тести постійно ламаються.
• Покладатися лише на розробника. Автор коду тестує так, як задумав, а не як вчинить покупець.
• Не фіксувати результати. Без звіту неможливо порівняти реліз із попереднім і довести, що виправлене справді виправлене.
• Думати, що тестування — витрата, а не страховка. Один пропущений баг в оплаті зазвичай коштує більше, ніж місяць регулярного регресу. Точну суму для вашого магазину порахуйте за кількістю замовлень на день і відсотком, що пройшов би checkout.

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

Підсумок

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

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