.png)
До випуску "в люди" будь-який програмний продукт (сайт, додаток) проходить довгий шлях перевірок і допрацювань, доки він на 100% не відповідатиме сподіванням користувачів. Перевірка якості ПЗ, відповідності заявлених до нього вимог і реальної функціональності, пошук і виправлення помилок (багів) і усунення дефектів — ці та інші задачі вирішує тестування. Воно потрібно як самим розробникам, щоб побачити готовність продукту до ринку, так і замовникам — щоб переконатися, щоб бюджет витрачений не даремно.
Ручне тестування (manual testing) — класичний метод оцінки якості ПЗ, коли тест-кейси запускаються без використання засобів автоматизації: тестувальники вручну проходять тестові сценарії і складають звіти про помилки. Цей процес досить трудомісткий і тривалий, без поєднання з автотестами використовується тільки на невеликих проектах.
Автоматизоване тестування виконується за допомогою спеціальних скриптів, при цьому втручання людини зводиться до мінімуму, а точність і швидкість перевірок набагато вища.
Щоб говорити про автоматизацію тестування предметно, розглянемо приклади її впровадження в наших проектах: системі управління школою дистанційного навчання (на базі Source LMS), healthcare-проекті та великому онлайн-магазині.
У випадку системи управління школою і онлайн-магазину автотести потрібні як перевірка усталеного критичного функціоналу. Такі сценарії кардинально не змінюються, але вимагають постійної оцінки працездатності, тому було прийнято рішення замінити одні і ті ж ручні перевірки на автоматичні.
Автоматизація присутня і на healthcare-проекті, де крім економії часу ціллю є моніторинг стану критичних сценаріїв на сайті в будь-який час. Також ми розробили і внутрішню систему нотифікації про результати тестування.
Критичні сценарії і моніторинг були обрані для автоматизації як задачі, що найменш динамічно змінюються і найбільше потребують покриття на всіх проектах. Тести можуть дописуватися і змінюватися, але не вимагають постійної підтримки з боку будь-якого з відділів.
Критичні сценарії — сценарії, помилки в роботі яких принесуть клієнтові збиток, завадять отримати очікуваний прибуток. Наприклад, для e-commerce проектів це процес пошуку і покупки товару, реєстрація і авторизація.
Так, в автоматизації проекту інтернет-магазину в основні сценарії входить додавання товару до кошика з різними параметрами, перехід у картку товару і перевірка правильності даних в ній, оформлення замовлення з вибором опцій доставки та оплати. В роботі healthcare-порталу ці сценарії включають роботу з купонами (завантаження, покупка, отримання, відображення) для зареєстрованих і незареєстрованих користувачів.
Приклад одного з автоматичних тестів в системі управління школою: авторизація на сайт, вибір зі списку контролю знань необхідної перевірки (набір питань з варіантами відповідей), повне проходження контрольного завдання і отримання результату (оцінки в балах). Його ми розглянемо нижче.
Покриття автотестами будь-яких сценаріїв, аж до цілого проекту, можливе, але не завжди доцільне.
Некритичні сценарії викликають мінімум простоїв, дискомфорту клієнтів проекту і не впливають на прямі доходи замовника. Наприклад, перевірка справності виведення статичних сторінок інтернет-магазину: на них присутня різноманітна інформація, але в разі проблем з цими сторінками замовник зазнає набагато менше ускладнень, ніж при помилках в роботі замовлення товару.
Перевірки за допомогою автотестів проводяться перед релізами, а також планово за розкладом:
Для всіх проектів можна запустити тести вручну шляхом виконання скрипта з консолі або з використанням інтерфейсу Gitlab.
Репозиторії з автотестами для всіх проектів лежать, а як основний стек був обраний Playwright + Jest. Такий варіант має ряд переваг:
Переваги стека дозволяють відчутно заощадити час при покритті великої кількості сценаріїв поведінки для кожної з можливих конфігурацій пристроїв клієнтів.
На проекті інтернет-магазину випробували стек Java + Selenium. Наш відділ тестування зупинився на ньому, щоб розширити використовувані технології в автотестуванні та створити більш складний по архітектурі фреймворк. Цей стек зарекомендував себе при написанні найрізноманітніших тестів і відмінно підходить для перевірки end-to-end сценаріїв.
При створенні автотестів для healthcare-порталу ми обрали зв’язку Python + Selenium. Це перший проект, на якому з'явилася автоматизація тестування в компанії, і вибір мови програмування і фреймворка саме такий в силу експертизи команд розробки, тестування і DevOps.
Коли ухвалено рішення про необхідність автоматизації на проекті і обраний технологічний стек, підбираємо сценарії для покриття тестами, створюємо тестову документацію з конкретними кроками і набором даних для кожного сценарію, розробляємо тестовий фреймворк і інтегруємо його за участю DevOps-команди.
Сам процес автоматизації тестування зазвичай проходить так:
На нашому healthcare-проекті тести перезапускаються автоматично, якщо на одному з кроків сталася помилка.
При запуску тестів можна вибрати параметр оточення, що визначає, де саме будуть відбуватися автоматичні перевірки: на тестовому середовищі чи на проді. Прикладами кроків, що виконуються, є авторизація, додавання до кошика, покупка, оплата тестовими картками, отримання листа, завантаження файлу.
Після завершення тестування або на екран, або в базу зберігаються результати проходження сценарію. Якщо на якомусь етапі виникла помилка — одержуємо повідомлення про це, якщо все пройшло успішно — дістанемо повідомлення про успішне проходження. На проекті healthcare-порталу лист приходить на пошту клієнта і на пошту компанії, що особливо корисно при виникненні проблеми на сайті: наступний запуск автотестів з успішним прогоном всіх тестів показує, що проблема вирішена або більше не повторюється.
1. Автотест запускається вручну або автоматично за розкладом на сервері.
2. Автоматично відкривається браузер, вибраний в скрипті для запуску (будь-який, наприклад, Chromium). При запуску за розкладом із сервера автотест працює в headless-режимі.
3. Скрипт автоматично вводить адресу сайту, потрапляє на сторінку авторизації та переходить в кабінет учня.
4. Згідно з обраними параметрами скрипт переходить у вибраний тест. Ціль — пройти всі завдання і набрати максимальний бал. Для контролю результати звіряються з даними з бази, до якої скрипт теж підключається автоматично.
5. Скрипт проходить тест без втручання людини, проставляючи правильні відповіді, заздалегідь отримані з бази.
6. Коли урок пройдений, на сторінку виводиться оцінка “автостудента”. Очікуваний результат — 12/12 балів.
7. Після закінчення тесту вікно браузера автоматично закривається, а інформація виводиться в консолі:
Результати можна зберігати в базі, передавати на пошту, виводити коментарем до задачі.
1. Запускається скрипт автотесту, після чого автоматично відкривається браузер.
2. На головній сторінці сайту автоматично вводяться реєстраційні дані для входу в особистий кабінет.
3. З кабінету скрипт переходить в калькулятор і випадковим чином вибирає місто для підрахунку вартості пакета аналізів.
4. Додавання декількох аналізів до кошика, розрахунок оптимальних тарифів. На екран виводяться підібрані знижки і вибрані пропозиції.
5. Дії повторюються для інших випадково вибраних міст.
Результати проходження виводяться на екран або надсилаються на пошту.
По проекту онлайн-школи час тестування скоротився в середньому на 20%:
На healthcare-проекті до автоматизації ручне виконання тестових сценаріїв займало 30-40 хвилин і було обов’язковим при кожному циклі тестування. Тоді як автотести повністю відпрацьовують за 10-12 хвилин.
При тестуванні функціоналу онлайн-школи частину кейсів все одно потрібно виконувати вручну. Однак кейс з автоматизацією покриває в середньому 15-20% всього тестування для більшості релізів. У рідкісних випадках (при відсутності змін в модулях, не покритих автотестами) цей показник може доходити до 60%.
На healthcare-проекті автотести скоротили час на тестування на 99% — тестувальник залучається на проект вкрай рідко, і якщо залучається, перевіряє результати виконання тестів.
Крім цього автотести дозволяють відслідковувати стан системи, отримувати нотифікації про проблеми для клієнта і для нас. Так що з боку DevOps на підтримку потрібна мінімальна кількість часу — залучаються тільки, якщо тести падають кілька разів.
Ще один плюс — автоматичний перезапуск тестів, якщо на якомусь етапі стався збій. Завдяки цьому вдається виключити "помилкові" падіння, коли система працює нормально, але стався короткочасний збій, який не вплинув на роботу сайту, але завадив автотестам коректно виконатися. Внутрішня система нотифікації дозволяє завжди знати, що прод робочий, дізнатися про проблему і швидко на неї відреагувати.
Підбиваючи підсумки, скажемо, що автоматизація тестування — це інвестиція в майбутнє компанії і можливість значно підвищити якість і швидкість оновлення програмного продукту, оптимізувати витрати.
Якщо ви хочете впровадити автоматизацію на своєму проекті, зв’яжіться з нами. Підберемо найбільш ефективне рішення і налаштуємо систему тестування під ваші специфічні вимоги.
