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

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

Сайт в цей час активно розвивався, що вимагало частих оновлень. Потрібно було регулярно перевіряти сайт на наявність помилок в основному та додатковому функціоналі. Тестування та командна робота були організовані на високому рівні:

• всі завдання в диспетчері завдань Jira;
• кожне завдання мало окрему гілку функцій для зручності тестування;
• перелік кодів було налаштовано перед відправленням до репозиторію (phpcs);
• команда зі сторони клієнта була глибоко залучена в процес тестування.

Пошук помилок ускладнювався великою кількістю релізів і наявністю деякого застарілого коду зі старого проєкту Magento. Через це помилки з’являлися там, де ми їх не очікували. Оскільки це активний інтернет-магазин, деякі помилки можуть коштувати дорого. Наприклад, якщо клієнт не зможе зробити замовлення, компанія втратить прибуток. З цієї причини було вирішено впровадити систему автоматичних e2e (наскрізних) тестів, які запускали основні та найважливіші сторінки та функції магазину.

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

Процес налаштовується за допомогою інфраструктури тестування Codeception. Розглянемо детальніше, як працюють автоматизовані тести:

• Етап тестового запуску включено в послідовні завдання.
• У цей момент запускається віртуальна машина, яка використовує рушій Selenium (спеціальний браузер).
• Тести з коду PHP інтерпретуються в реальні дії «користувача» – наведіть курсор на кнопку, натисніть, знайдіть поле, введіть дані, подивіться, чи з’явився елемент і т.д.
• Фреймворк Codeception виконує всі ці дії та на контрольних точках порівнює очікуваний результат із реальним (наприклад, чи сталася у формі помилка перевірки даних, чи ми побачили повідомлення про успішне виконання через кілька секунд).
• Якщо будь-яка з дій приведе до результату, який ми очікуємо, виконання сценарію (тесту) закінчиться з помилкою.
• Під час відлагодження програміст просто бачить його в консолі та продовжує редагувати тест.
• А під час розгортання середовище просто зупиниться та надішле сповіщення в командний чат, що було завантаження, яке працювало не так, як потрібно.

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

Коли у нас була перша стабільна та швидка спроба тесту, ми масштабували цей підхід до всіх основних функцій великого веб-сайту, наприклад:

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

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

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

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

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

На додачу, розробники сайту WordPress написали тести, які перевірили роботу Rewards Club. Досить відповідальна функція, тому що користувачам не подобається, якщо вони не отримують хоча б 1 бал.

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

Цікавий факт! Поки ми розробляли тести, ми знайшли з десяток багів у старих релізах. Завдяки комплексному підходу у них не було більше шансів з’явитися. Маєте помилки або проблеми з продуктивністю на вашому веб-сайті? Напишіть у професійне агентство розробки WordPress прямо зараз!