Чек-лист тестування інтернет-магазину перед запуском: 60 пунктів.

Чек-лист тестування інтернет-магазину потрібен власнику, який збирається запускати або оновлювати сайт і хоче впевнитись, що клієнт зможе знайти товар, покласти його в кошик і заплатити. Нижче 60 пунктів, згрупованих за етапами шляху покупця. Їх можна пройти самостійно за вечір або передати тестувальнику. Ми користуємось саме цим скелетом, коли готуємо QA-аудит інтернет-магазину, тільки на практиці пунктів значно більше: близько 150.

Головна ідея проста. Не все в магазині однаково важливе. Баг у футері коштує вам нерву, баг у кошику коштує вам грошей. Тому перевіряємо в порядку «від грошей»: спершу оплата й checkout, потім кошик і каталог, потім усе інше.

Як користуватись чек-листом

Перед стартом підготуйте три речі.

• Тестове середовище (staging), яке максимально схоже на бойове: ті ж версії PHP і бази, ті ж інтеграції, але в режимі sandbox. Тестувати оплату реальною карткою на проді не потрібно.
• Набір тестових даних: кілька товарів з різними станами (є в наявності, закінчується, немає, з варіантами, зі знижкою), 2–3 акаунти, промокоди, тестові картки платіжки.
• Пристрої: мінімум один iPhone з Safari, один Android з Chrome, десктоп з Chrome і Firefox. Емуляція в DevTools корисна, але реальний Safari на iOS ламається інакше.

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

1. Каталог і пошук (10 пунктів)

Каталог формує перше враження і приводить трафік з пошуку, тому тут перевіряємо і функції, і дані.

1. Усі категорії відкриваються, у списку немає порожніх сторінок і 500-х помилок.
2. Кількість товарів у лічильнику категорії збігається з кількістю на сторінці.
3. Фільтри працюють поодинці й у комбінації; після застосування змінюється URL, і за посиланням можна повернутись до того ж результату.
4. Скидання фільтрів повертає повний список, а не «нічого не знайдено».
5. Сортування за ціною справді сортує числа, а не рядки: 900 не стоїть після 10 000.
6. Пагінація: остання сторінка, сторінка поза діапазоном (?page=999) дають зрозумілу відповідь, а не помилку.
7. Пошук знаходить товар за назвою, артикулом і з помилкою в одну літеру; кирилиця й латиниця працюють однаково.
8. Порожній результат пошуку показує підказку і популярні категорії.
9. Картка товару: фото, ціна, опис, варіанти, наявність відображаються правильно; для товарів без фото є заглушка.
10. Товар «немає в наявності» не можна купити, але його можна знайти, і є кнопка «повідомити про появу» чи схожі товари.

Окремо перевірте ціни. Ціна в списку, на картці, у кошику й на checkout має бути однаковою до копійки, з урахуванням знижок і округлення.

2. Кошик (8 пунктів)

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

11. Додавання товару з картки, зі списку й з «швидкого перегляду» працює однаково.
12. Зміна кількості перераховує суму миттєво; кількість 0 і від'ємна кількість не ламають кошик.
13. Не можна додати більше, ніж є на складі, і повідомлення про це зрозуміле.
14. Видалення товару і повернення «скасувати» не залишають «привидів» у лічильнику на іконці.
15. Кошик зберігається після оновлення сторінки, закриття вкладки й входу в акаунт (гостьовий кошик зливається з акаунтним).
16. Промокод: валідний, прострочений, використаний, регістр літер, комбінація з іншою знижкою, мінімальна сума. Помилка пояснює причину.
17. Безкоштовна доставка від суми: поріг відображається і спрацьовує, коли сума перетинає його і вгору, і вниз.
18. Якщо ціна або залишок змінились, поки товар лежав у кошику, користувач бачить повідомлення, а не дізнається про це на оплаті.

3. Checkout: замовлення без реєстрації (12 пунктів)

Саме тут губляться гроші. Про типові баги цього етапу детально в статті Чому губляться замовлення на checkout: 7 типових багів, а тут базовий перелік.

19. Замовлення можна оформити як гість, без обов'язкової реєстрації.
20. Валідація полів показується біля поля, а не одним повідомленням угорі; введені дані не зникають після помилки.
21. Телефон приймає формати +380…, 380…, 0…, з пробілами й дужками і зберігається в єдиному вигляді.
22. Email із пробілом наприкінці (типовий результат автозаповнення на телефоні) обробляється, а не відхиляється.
23. Кирилиця, апострофи й лапки в імені та адресі не ламають замовлення (спробуйте О'Коннор і Ґанок).
24. Вибір доставки змінює вартість і підсумок одразу, без перезавантаження.
25. Самовивіз показує адресу та години роботи.
26. Адреса: для кур'єрської доставки обов'язкові потрібні поля, для відділення вони приховані й не блокують відправку.
27. Подвійне натискання на «Підтвердити замовлення» створює одне замовлення, а не два.
28. Кнопка «Назад» у браузері не скидає форму і не дублює замовлення.
29. Після успішного замовлення клієнт бачить сторінку подяки з номером замовлення; оновлення сторінки не створює нового замовлення.
30. Якщо сесія закінчилась посеред оформлення, користувач не втрачає кошик.

Додайте сюди тест «повільний інтернет»: у DevTools увімкніть Slow 3G і оформіть замовлення. Саме тут вилазять кнопки без індикатора завантаження і подвійні кліки.

4. Оплата й Нова Пошта (10 пунктів)

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

31. Успішна оплата карткою в sandbox: замовлення отримує статус «оплачено», клієнт отримує лист.
32. Відхилена картка: замовлення залишається «очікує оплати», клієнт бачить зрозуміле повідомлення і може спробувати знову.
33. Клієнт закрив вкладку на сторінці банку: замовлення не зависає, а є механізм повторної оплати за посиланням.
34. Платіжка надіслала callback двічі: замовлення не оплачується двічі й не дублюються листи (ідемпотентність).
35. Callback прийшов раніше, ніж клієнт повернувся на сайт: статус все одно правильний.
36. Оплата при отриманні і накладений платіж мають окремі правила (ліміти, комісія) і правильно відображаються в замовленні.
37. Нова Пошта: пошук міста за частиною назви, однойменні населені пункти в різних областях розрізняються.
38. Відділення і поштомати завантажуються, пошук за номером працює, закрите відділення не пропонується.
39. Вартість доставки і строки відповідають тарифу перевізника, а ТТН створюється з правильними габаритами й вагою.
40. Помилка API перевізника не блокує замовлення: менеджер бачить, що ТТН не створилась, і може повторити.

5. Акаунт і листи (6 пунктів)

41. Реєстрація, вхід, відновлення пароля: лист приходить, посилання працює один раз і має термін дії.
42. Не можна зареєструвати той самий email двічі, навіть в іншому регістрі.
43. Історія замовлень показує правильні статуси й суми.
44. Транзакційні листи (підтвердження, оплата, відправлення) приходять не в спам, коректно виглядають у Gmail на телефоні і містять правильні дані.
45. Підписка на розсилку і форма зворотного зв'язку працюють, є згода на обробку даних.
46. У листах для адміністратора немає особистих даних, яким там не місце, а повідомлення в Telegram чи CRM приходять з усіма полями замовлення.

6. Мобільна версія й сумісність (6 пунктів)

Для більшості магазинів понад половина трафіку мобільна, тому це не «додатково».

47. Перевірте ширини 375, 768 і 1440 пікселів: немає горизонтального скролу і обрізаного тексту.
48. Кнопки й поля зручні для пальця (орієнтовно від 44 пікселів), поля мають правильний тип клавіатури: tel для телефону, email для пошти.
49. Липка шапка чи банер не перекриває кнопку «Купити» і поле вводу, коли відкрита клавіатура.
50. Safari на iOS: оформлення, оплата, фільтри, випадаючі списки.
51. Chrome на Android, Firefox та Edge на десктопі: головний сценарій покупки.
52. Модальні вікна закриваються, фокус не втікає за них, а сторінка під ними не прокручується.

7. Швидкість, SEO і безпека (8 пунктів)

53. Lighthouse на мобільному для головної, категорії й картки товару. Орієнтир: LCP до 2,5 с, CLS до 0,1. Як читати ці метрики без розробника, пояснюємо в статті Core Web Vitals для власника магазину.
54. У кожного товару й категорії унікальні title, description, один h1 і canonical; фільтровані сторінки не створюють нескінченних дублікатів.
55. robots.txt і sitemap.xml на місці, а тестове середовище закрите від індексації (і це не переїхало на продакшн разом із noindex).
56. Є мікророзмітка Product і BreadcrumbList з правильними ціною та наявністю.
57. Сайт працює по HTTPS без попереджень про змішаний вміст; http і www перенаправляються на єдину версію.
58. Сторінка 404 корисна, а старі адреси мають 301-редиректи.
59. Базова безпека: пароль не передається в URL, адмінка закрита і не лежить за адресою /admin без захисту, форми захищені від спаму.
60. Аналітика: події purchase, add_to_cart, begin_checkout доходять, а трекінг не спрацьовує до згоди в cookie-банері.

Не хочете проходити 60 пунктів самі? Ми зробимо безкоштовний експрес-чек за 48 годин: 10–15 ключових проблем з відео і пріоритетами. А повний QA-аудит інтернет-магазину коштує від 6 000 грн.

Що робити з результатами

Після проходу чек-листа у вас буде список проблем. Не намагайтесь виправити все одразу, а розкладіть за впливом.

• Блокери: клієнт не може купити або оплатити. Виправляємо до запуску, без винятків.
• Критичні: є обхідний шлях, але частина клієнтів піде (баг лише в Safari, не працює промокод).
• Значущі: псують враження чи SEO, але гроші не втрачаються.
• Косметичні: виправляємо, коли є час.

Хороше правило для запуску: нуль блокерів і нуль критичних у шляху «товар → кошик → оплата». Решту можна запускати зі списком відомих проблем і планом виправлення.

Ще одна практична порада: після кожного релізу повторюйте хоча б 12–15 ключових пунктів (розділи 2–4). Це називається регресійне тестування. Якщо воно щоразу забирає години ручної роботи, варто подумати про автоматизацію найважливіших сценаріїв. Коли це виправдано, а коли ні, ми розписали в статті Ручне vs автоматизоване тестування.

Типові помилки тих, хто тестує сам

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

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

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

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